The other day, I was given a link to an online Java applet called Powder Game by Dan-Ball. I had played a really similar game before, but I don’t think it was made by the same person (though I could be wrong). It’s a great little Java applet – it simulates a variety of particles, each with their own unique behaviour and properties. The way different ‘elements’ interact is what makes it interesting – Fire and magma will slowly burn through oil but cause sticks of c-4 and fireworks to explode violently. If you drop some oil into a pool of water it’ll happily sit on top of it, but denser materials such as stone will sink straight to the bottom.

Stargate eat your heart out.

As well as an abundance of different particles at your disposal, you can also conjure little stickmen, boxes, bubbles, fans and spinning wheels, all of which interact with the environment you make for them.

Particle sims are pretty common (I even made one myself a while ago), but what really makes powder game stand out is its simulation of air pressure. As you pump air into a region (or have a fan do it for you), the pressure will increase. Particles will always try their best to move into a region with lower pressure, and as a result will swish around quite elegantly until they find a comfortable spot to settle. Filling an enclosed space with air and then watching it explosively decompress as you erase a chunk of the wall, hurling asunder person and particle alike, is particularly fun.

The rapture! The rapture!

Being a computer geek, the first thing I thought when I ran this applet was, ‘I wonder if I can make a computer out of this?‘. I tried, and ultimately failed, to replicate a water integrator using water particles and a spinning wheel. I’ve yet to find an reliable alternative way to flip back and forth between two states, but I’m sure one must exist so I’ll keep looking.

Links:

Powder game (http://dan-ball.jp/en/javagame/dust)

This project was, by far, the most enjoyable one I’ve ever undertaken at university. The assignment was simple, as they often were – we had to remake Space Invaders using Blitz Basic. As it was the third and final assignment on my Computer Games Development module, I decided to pull out all of the stops and spend a solid month or so (I’m sad like that) creating what you see here.

Brainvaders juggles the Space Invaders formula around a bit. Instead of being stuck with the same old boring ‘pchoo rifle‘, you’re given the ability to upgrade your alien-blaster to a choice of four other weapons (rapid fire, double shot, triple shot and homing). You can also upgrade your shields to withstand more damage, and buy a few nifty extras like a tractor beam and ‘orbiters’, which help with the alien blasting. Upgrades can be purchased in exchange for alien brains (which are favoured for their mild creamy taste. Great on toast!), which must first be seperated from their original owners.

Brainvaders follow the typical Invaderesque style of movement (Drop down! Increase speed! Reverse direction!) with the added freedom of being able to swoop down to get a bit close and personal whenever they feel like it. This will happen more often as you kill more of them, so don’t stay still for too long…

As you dispose of waves of enemies, new ones will arrive that are slightly stronger and more aggressive. If you die, the game won’t actually end, you’ll just lose around half of your points. Thus, you’ll be able to keep playing until you get bored.

All of the content was made by me except the sound effects which were all made by my good friend, Matt Griffith, whose voice acting abilities are almost godlike.

Links:

• Source code & exe

Recently, I’ve been busier than ever. I’ve had no less than four projects to juggle, two of which are now – thankfully – complete. I’ve been working on the other two almost incessantly, but during my brief breaks I’ve been writing a computing article that should hopefully interest. For now, I’m just going to post the remainder of my university projects from last year. These ones are a bit more exciting!

The first is Stick Tennis. This is the first graphical game I got to make in university, and made a nice change from Interactive Fiction!. The assignment specification was incredibly simple: make a Pong game. Beyond that we had free rein, as long as it didn’t stray too far from the original concept.

The rules of Stick Tennis differ slightly to those of the original Pong. The scoring system is a dumbed-down version of tennis (each successive point is worth 15, 30, 40, etc) and the playing field is a lot longer than it is wide. I was actually quite lucky to pass this assignment with the score that I got (85%+) because I neglected one of the fundamental rules of Pong – that the ball should be able to bounce off the top and bottom of the field. Luckily, my lecturer overlooked this.

If you find it difficult to hit the ball, don’t worry – for a pong game it’s insanely difficult to control! You’ll probably get bored and stop playing before winning against the computer anyway. It’s not the exactly the most exciting game in the world, but it might keep you entertained for a few minutes while you watch the ridiculous budget stickman animations in action (which I’m actually really proud of).

I’ve included the source code for anyone interested in taking a peek. It’s in Blitz Basic format (.bb)

Links:

Source code & exe

Logic gates are useful things. While I’m typing away at my PC writing this article, millions (if not billions) of gates are flipping ones and zeroes at my very whim (it almost makes you feel powerful, in a sad, nerdy kind of way).

Jobs involving logic gates are dwindling in number. The problem is, logic gates aren’t vogue any more, so nobody wants to learn how they work. Why’s that? Well, they haven’t changed much at all since they were invented many years ago, and the icons still leave much to the imagination. That’s why I’ve invented a host of brand new gates, in order to put them back in the limelight!

So without further adieu, I present the list …

Schrödinger’s Gate

Named in tribute of the late physicist, whos profusely overhyped thought experiment had loving cat owners across the globe waking up in a cold sweat (and, today, has Erwin himself spinning in his grave).

Schrödinger’s gate takes two inputs. The first must be connected to a source of random fluctuation, such as the decaying nucleus of a radioactive atom (good luck finding one on its own). Alternatively, a good brownian motion producer – say a nice hot cup of tea – will do the trick.
Naturally, without an observer, your digital cat will be permanently stuck in a state of both existence and non-existence, which would just be ridiculous! That’s where the second input comes in. Input B’s job is to simply observe the gate (by always being ‘on’), thus collapsing the wave function and making sure you’re given a sensible output of either 0 or 1. Which one, you ask? Well, that depends on your interpretation.

Watergate

This gate follows the principle of ‘garbage in, garbage out’, which is to say that any value entered in will pass in one end and come out of the other with nothing added and very little taken away. Unless, of course, it’s in the gate’s “best interests” to be a little more economical with the truth (table), in which case it’s anyone’s guess what it’s going to regurgitate.

Fuzzy gate

This gate is made entirely of fluff. It works kind of like a logical ‘and’ gate, only more… vague. Generally, it’ll only output a 1 if all inputs are also 1, in typical and gate fashion. But if it’s in a good mood, it might just say ‘ahh, go on then‘ and output a 1 even if not all of the inputs are 1. Or if it’s feel particularly cynical, it may just output a zero even if all of the inputs are one. It brings back the element of fallibility that has been somewhat lost with the advent of the computer.

Green gate

This gate was designed as a “carbon neutral” alternative to the relative energy guzzler that is the silicon transistor. It’s made entirely out of organic free-range components, and thus is unable to actually perform any transitions at all, meaning it’ll always output zero. If you want to go green, you have to make some sacrifices!

Left handed gate

This gate was invented for the sake of the small portion of the population who use their left hand to perform their computing tasks rather than their right, and are sick of the predjudices painfully endured by their fellow lefties daily.
It works just like a ‘regular’ (you fascist.) gate, only the inputs are on the right and the output is on the left. Ingenious! I took a risk in documenting this revolutionary gate, as I’m not sure if the world is ready for it yet…

So, that concludes my list! With any luck, the lovely folks at Intel will stumble upon this page and decide to make me a very, very rich man…

In my first year of university, I made the mistake of taking Computer Games Technology as a result of my pipe dream to become a profesional games developer. I’ve had a little sense smacked into me since then, but in the time that I did spend on the course, I made three games which I’m releasing for all to play.

The first game is an interactive fiction (text adventure) game called School’s Out in which you play a school kid who manages to get himself locked in school at the beginning of the mid-term break. Using the objects lying around the school, and your own wits, you need to find your own way out before you die of boredom (or your own stupidity).

It was made using Inform 6, which is a functional but limited language (I’ve heard 7 is much better, but we couldn’t use that). To run the .z5 file you’ll need a z-machine interpreter; I recommend Frotz.

School’s Out was a collaborative effort by myself and two others in my group, Stuart Hayes and Ben Holland. We wrote out a walkthrough as part of the specification, but none of us seem to have it any more! I still remember how to complete it, though, so if you’re stuck, just post a comment or something and I can help.

Links:

Source code & .z5 file

The the second assignment I had to undertake for my Programming (PR1201) module was to make an interactive map of an area (real or fictitious) using the Java applet API. The basic features it had to exhibit were:

1. Interesting landmarks such as lakes, buildings, forests, etc. These were to be drawn with basic shapes – circles, rectangles, irregular polygons, etc.
2. The ability to click on the map and be given info about the nearest landmark, as well as the distance from the cursor.
3. Buttons corresponding to each landmark. Clicking on the should give information about that landmark.
4. A bar representing the map’s scale (i.e. 100 pixels = 1 metre).
5. A search box programmed with some basic search queries.

With a new-found penchant for making everything 3D, I started working on a new engine for rotating and tilting a world map and calculating the positions of sprites sitting on it. This was much easier to do than my previous project because the Java applet API can render filled polygons, but Java elements can’t.

I chose an imaginary nature park for my location, so there are plenty of trees and lots of water. If you look at allenk_groupG_Initialiser.java, you’ll see there are a hell of a lot of sprites dotted around. Luckily, I didn’t have to code them by hand – I modified my applet to output Java code to a file, and voila – a makeshift park editor.

I got a score of 90% for this applet, which is the highest score I’ve achieved for a piece of coursework so far.

Links:

Source code and class files
View the applet in your web browser

I’ve decided to release my university projects from last year onto the Internet for people to examine, scrutinise, use to help them with their own studies and hopefully enjoy.

The first project on display is my first Programming assignment, for which we were asked to create a short animation in Java using an educational package by Bailey & Bailey, Java Elements.
Skirting the assignment brief somewhat, I made a small 3D rendering engine which used Elements’ line drawing functionality to draw triangles, which in turn make up complex 3D shapes. I think I got away with this not strictly being ‘an animation’ because it spins about its axis.

I made this before I had any real concept of good OO practices such as encapsulation and decoupling, so there’s plenty of room for improvement. I’m still proud of it because this is the first time I’d tried making something of this nature and I have to say it went really well.

I scored around 85% for this, which I was happy with, but could have pushed towards 90% or possibly higher, had I followed the brief a bit more meticulously (one of the requirements was that I had to use all of the shapes provided by Elements, which I definitely didn’t do).

Links:

Source code and class files
Java Elements package (required to compile and run; include this in your Java classpath.)

By the time I had gained some confidence in my programming abilities, I had pretty much become a hardcore C++ fan. I’m a bit of a speed freak when it comes to programming. If something isn’t working as efficiently as it could be, I get a compulsion to look inside it, see what’s slowing it down and try to find a better way to do things (I know, it’s a curse). C++ lets you do this more easily than some languages because of its relative closeless to the hardware (code is compiled to native instructions, so there’s very little ‘unavoidable overhead’) as well as its high degree of expressibility (for example, I can think of about five ways to implement arrays off the top of my head, each one best suited to a particular situation).

Since starting level 2 of my course, I’ve been inclined by myself and lecturers to take a look at the bigger picture of the software development industry (a picture I’ve not had much of a chance to see, since I haven’t quite “broken in” yet). The thing I’ve gradually come to realise is that the end users don’t care whether software is blazingly fast, as long as it’s fast enough to do the job at hand. Things like ease of debugging and the ability to quickly add new features should always be paramount. If you always aim dogmatically for the most efficient solution (which C++ often tempts me to do) you might just be shooting yourself in the foot.

One of my modules in Computing is “Software Development: Tools and Principles” in which we all use Microsoft C#. We just recently started a huge project which must be programmed exclusively in this, so we have plenty of time to get comfortable with it. Now, I’d never even touched C# (or any languages of that nature, like Java) before I started the course, but luckily it’s similar enough to C++ in syntax to make the transition a pleasant one.

So in the few monthsI’ve been using C#, here are some of the things I’ve noticed that are different from C++ (and it’s mostly good stuff):

• No pointers – So that means no more messing around with the * character. You don’t seem to get as much control over memory, but going back to my point earlier: unless you’re concerned about super speed (in which case you probably wouldn’t be using a .NET language), it just means less hassle.
  You can still choose to pass objects by reference or value, and store objects as both classes (which exist on the heap) and structs (on the stack).
• More straightforward syntax – In C++ you need to use . to access members of objects on the stack, :: to access static members and things in namespaces, and -> to access instance fields.
  In C#, all of these are accessed using the dot character. And why not? The compiler should know what kind of object you’re referencing from the context its in, so the less rules you need to remember, the better.
• Garbage collection – Most programmers probably know this, but the .NET CLR uses a garbage collector by default. This means you don’t have to worry about freeing an object once it’s been created, because when you’re finished with it the memory will get recycled. If you’re not a big GC fan, you can override it by marking a block as ‘unsafe’, which will let you write unmanaged code, and allow you to use those lovely pointers.
• Exceptions for error handling – Because they’re made by different groups of people, common libraries used in C++ use quite a variety of methods to report when something’s gone wrong. Some will return boolean false, others will return an integer. Some won’t return anything but will put an error value somewhere for you to find yourself. In the Framework Class Library (the collection of ‘built-in’ classes within the .NET framework), everything uses exceptions to report problems. I haven’t seen many, but most 3rd party libraries seem to all use them extensively, too. So you’ll have much more consistency in your code, even if it uses code made by others.
• It’s JIT-compiled – This means your program can theoretically be ran on any system, because your code will stay in an abstract platform-independent form (known as Intermediate Language) until it’s ran, at which point it’s converted to the native code of the system it’s running on. This allows for processor-specific optimisations, which would be much more complicated to do in natively compiled apps. Some people aren’t fans of JIT-compiling because of the neccessary evils of extra memory and processor overhead, but processing power and memory are relatively cheap nowadays, especially for the kinds of companies who use JIT-compiled software in their industry.
  

So, in conclusion: if you want your software to be fast and in-touch with the hardware it’s on, use C/C++. If you want to be fast enough, and also instantly portable* onto other systems (see Mono), use .NET or Java.

* ok, this is arguable, but I still think it’s a step forward from natively compiled code.

Warning: Big rants below.

I’ve been using Microsoft’s (in)famous instant messenger app since version 4.6 which came out in 2001 (back when it was called MSN Messenger). Between then and now, I’ve seen it undergo a lot of changes. Some of them were great (like the ability to send files, which was introduced in version 5). Others were more questionable (winks, added in version 7). But if there’s one thing that never seems to change between versions of WLM, it’s the bugs.

Any programmer knows that software can never be perfect, and even the most expertly coded application can still have bugs. I accept that. What irritates me is that these bugs have been around version after version, and none of them have been fixed yet. I could understand if they were hard to find or repeat, but they’re all glaringly obvious, and in an average day of chatting, I can guarantee you’ll come across at least one.

Here are the four main bugs I come across every single time I use WLM:

Messages fail to send for no reason.

I put this bug at the top of the list because it’s the most tenacious and also the most annoying. After using WLM for a long enough period (perhaps a few hours), it will suddenly decide to fail every time you try to send a message. I did a few tests and concluded that the ‘error’ occurs on the client side, not on the server, so it must be a bug in the client. The only possible way to fix this is to close the WLM exe and start it again – simply logging out will only fix it for a couple of minutes.

Temporary solution: Close WLM down completely and hope it’s more merciful next time.

When a conversation gets too long, it breaks.

This is a slight improvement from the first official WLM release (version 8), in which holding a conversation that was past a specific length would cause every succeeding message to appear on the same line, turning the whole thing into a complete mess. Now, because the WLM team over at Microsoft are so good at debugging their software, having a long conversation will only break the window when you send/receive an ink (handwriting) message or a file. For files it’s just a minor annoyance, but when you just spent ten minutes drawing a detailed ink message, the last thing you want is for it to fail, especially if it happens on both sides at once (this does happen, and it means you’ll have to draw the entire thing again).

Temporary solution: Close the window periodically, to keep the conversation log short. Close and re-open the window before sending an ink message.

The entire file transfer system.

The WLM file transfer system is a sloppy mess of barely-working components, stuck together with a child’s glue stick in order to make something that just about passes itself off as a feature.

• About 1/3 of the time, the person you send the file to won’t even receive the file invitation.
• Other times, the invitation will be sent, but the file will never actually start sending.
• If you’re lucky enough to witness a file actually sending, don’t dare cough or even look at it the wrong way. It will fail. Since there’s no resume feature, you’ll have to send the whole thing again!
• Chance of failure is tenfold for every other file you try to send concurrently.

Usually when a file send goes wrong it’s port-related, but I’ve tested this with both my computer and the remote computer set to DMZ (which effectively exposes it to the rest of the Internet, as if there were no firewall), so how can this is due to anything other than their bad programming?

Temporary solution: Use email (GMail allows 20mb attachments) or upload the file somewhere, if you want it to be recieved before next Christmas.

Offline mode messaging

Although the offline mode system is handy, it’s still littered with bugs. Messages you send are even less likely to arrive than regular messages, and some will be saved in the MSN backlog for up to a day before you receive them. You can’t send a file if you’re in offline mode, even though you can receive them (well… I say receive… see the previous bug). If you try to talk to someone who’s in offline mode, there’s a chance you’ll lose the ability to talk to them until they talk to you first.

Temporary solution: Don’t send important messages in offline mode.

Minor bugs (honourable mentions)

• Sending too many custom emoticons at once sometimes makes them turn back into text.
• Certain system settings cause the status to stick to a specific value (such as ‘busy’) when you log in, ignoring the status you’ve actually selected.
• A single-person conversation sometimes goes quantum and turns into a multiple-person conversation containing two copies of the same person. When they send you a file, a new single-conversation window will pop up.
• Ink messages sometimes ‘wibble’ (the lines move back and forth of their own accord).

Why’s it so buggy?

I can think of three likely reasons:

1. Microsoft care more about making the interface looking pretty than about the application working properly. In every version of WLM since 8.0, the interface has changed but the bugs remain exactly the same. Get your priorities right, MS!
2. Microsoft only updates a product when it’s in their best interests, not when it benefits the users. IE 7 is a prime example of this. IE 6 was riddled with HTML and CSS rendering bugs, but MS only decided to bring out a new version when they realised Firefox was gaining popularity (5 years later). Fail.
3. It’s a bloated mess. The Microsoft WLM client is 30mb, three times larger than its closest alternative, Pidgin (which supports 15 other IM protocols alongside MSN). If you’ve ever tried to learn about the protocol it uses to communicate with the MSN server, you’ll realise how horrific it is to work with. A complete re-code is the only thing that can save the poor thing.

Despite all these bugs, I still continue to use WLM because I think it’s one of the best IM apps available. I just wish MS would pay more attention to their users for once, but I suppose that’s a pipe dream for now (isn’t it always?).

Modern games owe a hell of a lot to their predecessors – almost every game stands on the shoulders of those created before it. Modern first-person shooter games have a lot to thank Wolfenstein for, and without Populous, the entire genre of ‘god games’ may not even exist today.

As well as being forerunners for the incredibly popular games industry, retro games are some of the most innovative and fun ever produced. That’s why I want to pay homeage to some of those games. I’m a big fan of the Megadrive (aka Genesis) and SNES – I grew up with them – so a lot of the games in this article will be titles from those consoles (although quite a few old PC titles will probably find their way in).

So, without further adieu, the first lucky game in the Retro Game Awards is…

Dynamite Headdy

Platform: Megadrive
Released: 1994
Producer: Treasure

Overview
In Dynamite Headdy you play the role of Headdy, a puppet with a detachable head which he uses to attack enemies. Upon visiting his friends in North Town he finds out that the evil Dark Demon has gotten his grubby mitts on Headdy’s puppet buddies, and is bent on converting them into his own evil minions. Headdy almost suffers the same fate until the ‘puppet picker’ machine sees him as a reject and sends him down into the dust collector, from which he makes his escape.

Why’s it so good?
From the moment you start playing Headdy, you feel completely immersed. The graphics (which are incredibly bright and colourful) all resemble props, backdrops and other stage instruments, with the occasional tear or a piece missing to reveal a wooden support or a stage light. The developers even took this a step further in certain places and have the whole level set in a back-stage area, or have the backdrop dragged in by little puppets while you’re still fighting in the foreground.

The gameplay looks basic at first – pressing B will make Headdy attack by shooting his head forwards, headbutting anything that gets in the way. Shooting little boxes known as ‘headcases’ will change your head temporarily, depending on which head it shows on the case (each case usually has two or three, and cycles through them). There are 18 kinds of heads to choose from, each has its own function (hammer head does more damage and lets you move heavy objects, outline head makes you invincible, protection head makes a ring of fire around you, etc…).
The interesting part is what happens when you shoot things that aren’t enemies. As well as using your cranium to do damage, you can use it to manipulate yourself and other objects. Grabbing the little orange balls known as ‘hangmen’ lets you pull yourself up to higher platforms, pull lids off containers, activate switches and all kinds of other things.

Combine this kind of innovative gameplay with great level design, pretty graphics and decent music and you have a game that’ll stand the test of time for a long while.