Saturday, February 25, 2006

Update Saturday 25-Feb-2006

We've been trying to get through some of the high priority bugs and various game-play changes in order to do a beta release this weekend in time for the previous beta expiring.

One of the changes was to add the game level and player rank to the saved game selector menu. This is pretty easy since there is a tiny interpreter used to read the save game meta-data for the game selector and an object that represents the game file on disk. A change to both of these plus a change to the save routine did the trick. I also added a "was this data present" flag which means that older files are handled (it just doesn't show the missing meta-data).

One of the more difficult bugs that is outstanding on my list is a problem with the call-signs. They occasionally appear as garbage (although I've made the display routine just display '?' for parts that are rubbish). Because the bug is difficult to replicate it's quite a difficult one to track down. Additionally we've had bullets that certainly shouldn't have a call-sign being shown with call-signs in the game.

I've also been looking at the highlight in the file selector menu - it's a text arrow like this --> which is a pretty naff. The main constraint is time to make the new effect. Good effects and ideas are easy - fast ones are rarely good. Additionally I really wish the menu code had been properly made into objects. Whilst the code is neat enough, it's sort of a procedural object hack that doesn't support inheritance and virtual functions which means altering the original code. This type of change also happened in the dungeon game that this came out of ... which meant we replaced functionality. It would have been cleaner and more extendable with proper OO. I guess won't have time now either. Maybe for the future.

Guess I should carry on with that call-sign bug.

Saturday, February 18, 2006

Java Paradroid

The original C64 Paradroid was a cool 'plan-view' robot battle game by Andrew Braybrook. The Spectrum conversion called Quazatron was good as well - it was 3d 'isometric' style graphics, and I played it for many hours. Anyhow... back to Paradroid.

Of course, quite a few people have done remakes of Paradroid. However the following one is of note because it's a full 3d game, it's written in Java and it's nice and responsive.

http://www.jpct.net/paradroidz/

Who says you can't write games in Java?

Additionally whilst looking around for links to put in this article, I came across a spectrum port of Quazatron written in Flash.

http://bitshifter.net.nz/flash-games/play-quazatron/

I've seen reasonable (i.e. fast, playable) isometric games in flash before, of course - this one is a really cool Dalek game (although all other BBC Doctor Who games suck):

http://www.bbc.co.uk/doctorwho/games/lastdalek/index.shtml

P.S. The original dev diary by the Andrew Braybrook is here. Nice to read from a legend who actually sounds human!

Internet Servers and Conservative Software Developers

Two subjects not related to each other and both a bit of a rant.

Internet Servers

Firstly, as some people might know, the people who arrange the hosting lightsoft.co.uk disappeared a couple of weeks back. They were a small company who had moved the servers around a bit, but originally were cheap compared to other web providers and we'd been running with them for many years without a hitch.

So what happened from our point of view? Well, the web server that hosts out pages went off line and email stopped working. It took almost a week to get lightsoft.co.uk back up and running. The process was basically try to contact them, get a new provider, contact the DNS agency to change over, wait for them to try to contact the old service provider, etc.

The web pages going off-line is bad for a tiny shareware company (for any company?). Additionally, since we released the Zex beta we were waiting for feedback and it had just started coming in on the forum. Practically all that information was lost - since we don't do daily backups. We did have a backup that wasn't very old luckily. In the interim we re-directed the product pages on Versiontracker and MacUpdate to the new provider - but only after we'd confirmed in our own mind the old one was dead and got a new one.

If the web pages going offline wasn't bad enough we also lost all lightsoft email for a week. From a personal point of view this was as bad as losing the Zex feedback or sales since ALL of my personal email comes in via lightsoft (to avoid problems if I have to change ISPs). This includes not only customer support emails but mailing lists, friends and family but internet shopping and contacts for various technical matters.

The moral of this story? I'm not sure. I guess in our case we've gone with a big provider who we know does a good job.

Conservative Software Developers

Doing lots of software I get to work both on my own, with Stu and with larger teams. Both myself and Stu are technophiles. We investigate new technologies, learn new languages, try out new techniques. Contrary to my previous post (regarding C++) this can be things that are not necessarily popular but might be powerful. Of course you don't know whether something is powerful for you until you try it yourself.

Sometimes I have to temper my desire for improvement in the knowledge that constant change doesn't ship. This can be settling with a good enough language, avoiding restructuring bad code or just doing the minimum to ship. This balance is hard to strike but is critical if you are not going to end up never shipping or shipping product that won't be useful in the future. Both ends are bad.

This leads me to my problem; Software developers are meant to be into new stuff. In my experience this isn't true - software developers, for the most part, are not computer geeks. They tend to be people paid to do a job and even the ones who are technical tend to be very conservative in their choice of technology.

This has really being irritating me for the past few months, not because being cautious is a bad thing - in fact avoiding too much change is critical to avoid wasting vast amounts of money for your employer. But there is the opposite extreme - not changing at all.

Thing I tend to see:

Not sure about C++ ... lots more space, confusing to developers, etc. C can do everything anyway.
I don't like OO - might take lots more space, be slower, etc.
I don't like (automatic) merge policy version control, seen problems (manual merges).
I don't believe in UML - don't believe there are any advantages.

Now the problem is that these people demand proof that the techniques or tools will give improvement. As far as I can see there is no magic metric that will give this. But it feels to me, and many others, that some of these things will help improve things like reliability, ability to change code and maintainability. Of course, taken to extremes they can be damaging. But generally can they be so bad if so many (clever) people use them?

Arguments like "well we can do any change you want in this C code" don't mean it couldn't be lots more maintainable. Deciding what to improve is hard, of course. Some changes won't have the desired effect and they may have a negative effect. But it's critical to consider how things could be done better and actually try out some of those techniques lest someone make you irrelevant. Also, the customers for software want quick changes as well as other things - the driver for fast changes as a customer need is much harder to measure. It doesn't mean that it's not important.

As an example of types of change that could be done - migrating from C to C++ is great because you can test the water of OO whilst mostly writing C in C++ compiler is entirely possible. Hence you can test whether it's an advantage (or at least not a disadvantage) and learn as you go.

Luckily with the right approach you can encourage change. It's slow and hard work. And the one advantage with Software Developers: they work with technology and generally have a logical mind. If you ask if it's worth trying to improve software quality or maintainability long term they will very seldom disagree.
Newer›  ‹Older