To Applet or not to Applet?

Some free games require you to download the source code and compile it yourself. Some require you to just download and install. Others are just download, unzip and run. However, by far the easiest are flash/applet web games, where you just point your browser at them and that's it - once the game has loaded you can play it straight away.

However, maybe due to this simplicity, or maybe due to the fact that a lot of web games are simple in themselves, they are not treat with the same level of respect as games that require more work to start up. It seems that the more effort you are prepared to expend to get a game working, the more time you are prepared to spend on it.

(Taking this to the extreme, I find that when I play a lot of old Speccy games, of which I have many fond memories, I give them approximately 10 seconds of my time (since that's pretty much how long it takes to load it up nowadays) whereas in the past, when it took minutes, I'd play them for longer and give them far more of a chance. Actually, I think I've just invented my own axiom: "The time a player will spend playing an average game is directly related to how long it took to them to run it.". You heard it here first!)

Anyway, back to my point. I've got a game called Island Commander, which is an applet, but is increasing in complexity. However, because of the lack of "respect" that web games get, I'm tempted to turn it into a stand-alone game so that people will take it more seriously. In addition, nothing is more galling than seeing comments by people about games written as applets, all saying how much they hate applets.

Is it mercenary to make it harder for people to play the game in the hope that they will spend more time on it? Maybe my whole premise is wrong, and flash/applet games get played far more than stand-alone games. However, out of all the most popular free open-source games out there with large communities, I can't think of any that are web games.

Trawling My Own Archives (Part #2)

There are literally tens of directories in my newfound treasure-trove of old source code, and I'm slowly getting through them. It's taking a bit longer than it should due to my old habit of sharing common (but now missing) libraries of source code between projects and using network drive letters that no longer exist.

However, here are 3 more to whet your appetite for the good old days when games were simpler (so simple in fact, that even the author is struggling to find the point).

The first game is one I originally called Floater, in an amusing play on the gameplay of Thrust-type games. There's not a lot to this game at the moment - you float around in an Asteroids/Thrust kind of way and shoot some bullets, not that there are any baddies to shoot at yet. If memory serves, I planned to make this a network version of Thrust or something, a bit like Gravity Force.



The next looks like some kind of puzzle game, though again I can't seem to work out what the actual game is supposed to be. It's almost fun though, as you bounce a ball around lots of other balls, and kinetic energy is passed between them. I think I wrote this on the assumption that some kind of game idea would magically appear once the mechanics are in place. I'm still waiting...



I've saved the best until last - this one is actually quite good and almost complete, and has a point! In a nutshell its a top-down shooter, a bit like GTA 1 but without the cars. The "missions" (if they can be called that) are randomly selected, and range from killing a Terminator-like robot to killing a group of rioting vegans (I always like to include a bit of social commentary in my games). I might actually release this one since it looks like I spent a fair bit of time on it.

Cheating AI

While writing Island Commander, the temptation has always been to allow the AI to cheat, as this would make it so much easier to write.

A programmer has only two options when writing an AI if they want to make a challenging game: allow it to cheat, or to analyse the game so much that they can break down the "secret" of winning into something like a flowchart, where every situation is covered and has an appropriate response.

Needless to say, this is no easy option for anything above the simplest of games (can you imagine something like this for chess?). In addition, every time a change is made to the game, or a feature added, the whole "flowchart" (and thus the AI code) needs to be changed.

However, this is the only option, since if any situation is not covered, the human players will quickly identify it and take advantage of it, and from that point on, the AI is no competition. Something I have been told several times!

Trawling My Own Archives

I came across a directory in the depths of my computer's filesystem the other day, which had old programs that I wrote when I was first learning Java. It was a nostalgic experience, but needless to say, none of the programs lived up to their epic names, and most were good examples of brevity of code; there were utilities like "MailingList", which was a one-class Java program that read a text file and emailed it to a hard-coded list of addresses. Also "AutoRunSQL" would basically run a hard-coded line of SQL at regular intervals (why you would want to do this is left for the reader to guess). There was also something called "CommerceNet", which preceeded Ebay and was intended to be a protocol for buying and selling, which would have changed the world if anyone else had known about it.

However the programs were mostly games, which should come as no surprise. The first I came across is called "Mr Do". It shows how long ago I wrote it because I'd even forgotton there was an old game called Mr Do, and this is a simple but quite playable copy of it:-



There was also another arcade clone, this time Bombjack. It looks like I lost interest in this before I'd ripped all the sprites I was needed, so the player and the enemies are all squares. However, the game seems to be all there, even down to "vibrating" bombs.



Finally, what looks like a homage to old ZX Spectrum games from the early 80's, is something called "Roadster" which I have no recollection of, but that's hardly surprising since it looks like I spent a grand total of 8 minutes writing it. I've no idea what's even going on.



However, strangely, this game has given me some insperation for my next project, which will be based around laying down train lines. Nothing so complicated as Railroad Tycoon, but more of a casual puzzle game.

Look out for more programming gems coming soon! And if anyone actually wants any source code, let me know.

Blindingly Obvious Programming Tips #3

I've not implemented this tip myself yet, since I've only just had the idea, but I thought I'd commit it to screen before it disappears from my head.

One of my peeves about programming are function calls with long lists of esoteric parameters. Stuff like "sprite.draw(10, 12, true, true, false, true);". Unless you can memorised the order and meaning of each of the parameters, you have no idea what that function call is going to do exactly. Multiply that by the number of functions in a typical program, and you realise that a solution is needed.

Some languages can get round this and have named parameters. I don't believe Java has those yet; the closest we have is javadoc annotations. However, my solution is pretty simple: create "constants" (or as close as Java will allow) with meaningful names that are simple booleans. Then the above function call can be re-written as

sprite.draw(10, 12, B_COLLIDES, B_FOREGROUND, B_HAS_HALO, B_FLICKER_SLIGHTLY);

Much more understandable.

Some programmers shoot us all in the foot

I really like Linux, and use it whenever I can for work and home systems. However, every so often something happens which makes you wonder which side the programmers of Linux software are on.

The latest problem is to do with Remote Desktop in Ubuntu 9.04 - Jaunty Jackalope. I've been using Remote Desktop quite happily for a few years on earlier versions of Ubuntu, but now I've upgraded, it seems to have a problem - the "Advanced" tab is missing. This means I can't choose the port number, along with various other settings.

A quick Google later, I discover this gem:

And yes, I've removed the 'advanced' tab. 'Advanced' users know to how use gconf-editor to tunning applications. The advanced tab was a mistake I made. Blame me.

What? "'Advanced' users know to how use gconf-editor"? I like to consider myself an advanced user, but I've only used gconf once, and I always have to remind myself how to get to it. But how am I supposed to know that I even need to use gconf? And where in gconf (which is the equivalent of RegEdit) are the settings I need?

And how on earth can regular users be recommended to use Ubuntu with arrogance like this? It's like we want to build a wall between us and the kind of people we need to bring on board if Linux is ever to get into the mainstream.

Java/Ubuntu Graphics Problem

I do most of my development on a Windows box (even though I dislike Windows and much prefer Ubuntu) so I've not noticed this problem before, but it seems that Java software that uses non-OpenGL graphics runs like a dog on versions >= 8.04 of Ubuntu.

One thing I like about Java is that it generally runs identically on most platforms, but sometimes something comes along which stops that "feature" dead in its tracks. The KeyPressed/KeyReleased bug was one of these, meaning I had to write special code get around it. If you don't test software on all the platforms, you won't know about these issues (as I am finding).

I've only got two Ubuntu boxes to test on, and one of these is a VM (which can add its own set of problems), so I'd be interested if anyone else experiences this. And I'd really like to hear from anyone who has a solution!

Metal Glove Solid Update

Now I've improved the performance of Metal Glove Solid, I've turned my attention to the average graphics. This thread on the Freegamer forums (about another stalled Gauntlet-remake) contains some useful walls. I've grabbed these and stuck them in MGS, and this is the result:-


Pretty basic, huh? True, but it's the first version, and I'm combining the change in graphics with a new map generator, rather than rely on designing my own maps. Here we see two rooms joined by a corridor. Procedurally generated content is the future; this is it in it's most basic form, but even this can provide a million different styles of dungeon, so no two games will be the same.