A platform game with a worms style ninja rope, wall jumping and invisibility. This was my first AS3 project and was essentially a reaction to the crippled mechanic of Knuckleheads. We set out to make the most agile platform game character I've ever made. It uses optimisations from the Knuckleheads engine, the rope from Dangle and the collision engine from Dirk Valentine. The rope wrapping engine took a week to code, it had to be as solid as possible being a major game mechanic. I also spent a week coming up with combat A.I. for the monsters. I wanted the player to spar with the monsters and get them to drop their guard instead of just hammering them. The stealth effect I based on the octocamo from Metal Gear Solid 4. Due to the rendering order I accidentally captured the background a frame late for the stealth effect. This accident caused an interesting ripple as monsters would pass by the character so I left it in. We planned on putting falling scenery, breaking glass and smoke effects into the game but there just wasn't the time. I spent pretty much all of my spare time writing more code to fit as much in as we could as well as trying to learn AS3 on the fly.
A platform game where you control a barbell shaped character. The heads are held together by a spring, which on the one hand gives me normals I can use for determining the right directional force required to attach and detach a head. On the other hand, springs can punch through scenery, which is why there are no moving platforms in this game. The Mario dungeon theme we found has a rich amount of traps and ideas to borrow from. I found making this game a bit fustrating because most of the challenge in it is simply in getting from A to B. Whilst level building was fun, I've prefered projects where I'm working on a superhero type character. In this game you control a drunken cripple. It's amusing, but it gets on my nerves after a while.
A mini game involving flinging a snot thing as far as you can. This game I made quite long ago and only got to tidy up recently. It uses a chain of particles held together by rather unrealistic springs. One major issue was making sure the highscore board could not be hacked or messed around with. From the original build I had to make changes to cap the mouse position and disable the right mouse button (which can be used to jump the mouse position). Then I had to make sure that all of the variables in the particles were added to random numbers in memory to make them hard to find with Cheat Engine. I use this practise in all games now. I feel that people who want the prestige of dominating the highscore board by skill alone shouldn't be put off by gimps who hack the game.
A puzzle game where you reach the exit by pulling the floor towards you or pulling yourself towards pieces of floor. Out of all the games I've made so far, this one has the most concrete solid engine, and it's the one I enjoyed making the most (Headcase would come next). I was keen to make an online level editor for this to see what other people can make - unlike other games I've made there's no rules needed for level building. (In Dirk for example we had to keep teleporters close to allow them to communicate and space out monsters with processor killing A.I. In this game it's near impossible to make broken levels). It features a version of the A* algorithm that I optimised a lot. I also ported this algorithm to Processing. There's technique in the algorithm I extended to features like the teleporters and arrows to prevent infinite loops - I mark those elements with the in game timer - a repeat marking means a loop has occurred, and I don't have to reset those markers because the next time I do a check the timer has moved on.
A platform game where you shoot platforms out of a gun. This game came after Headcase and Snow Drift in production so there was a strong desire to make a game that was solid and looked beautiful. Simon was itching to try out a steam punk style and so this project became the one. Platform collision was managed by pushing out along the direction of penetration that was the shortest. For a row of blocks I used a buddying system and with moving blocks I hoped no one would notice the odd behaviour when two blocks are snuggled. The chain measures its depth of penetration to resolve collision. A useful algorithm I came up with for this game was to use a paint fill algorithm to detect usable elements in the level. This means that walls that the player can't reach are ignored by the main code. I got pretty stroppy as this project drew to a conclusion, it took a lot out of me. I hope you the player get a lot out of it and enjoy playing the prettiest game I've made so far.
A multiplayer racing mini-game. In order to get the nice ability to ram other players off of the track I had to ask our resident ball physics specialist Chris Burt-Brown where he gets his equations from. He pointed me to a nice ball physics discussion (some of the equations mentioned have errors - make sure you read the whole thread). If we had the time and the money, we could have fleshed this game out with more tracks and A.I. players. The intelligence required to make it round quick and ram people off however would have had me scratching my head for at least two-weeks. Oh well...
An underwater sub game where you collect treasure and blow-up the local wildlife. We made this in homage to the tradition of lander-games, but we didn't want you to blow up when touching any scenery. The sub in this game handles collision using a pentagon mesh of springs. Each vertice is a particle that resolves against collision with pixels using the Bresenham algorithm. I also learnt about Flash's displacement map filter for those wavy transitions.
A plaform game where you slide to attack monsters. This game was made to capitalise on Christmas and the success of the Off the Rails game we made. I couldn't use the logical collision engine from Headcase in this one so I didn't have time to perfect block collision as we raced against the Christmas deadline. Not to mention that I started out with the Off the Rails engine and had to ditch it for a new and buggier one. However it has been well received.
A game where you can walk on walls and can kill monsters by leaping from wall to wall. The wall walking mechanic was made as simple as possible and we decided that like Sonic the Hedgehog, if you've got the key held down, you keep going. Simon Hunter who did the artwork for this game and also the game Flood remarked, "hey, I'm ripping off myself!" in reference to the wall walking mechanic. Level design was a drawn out process due to the sheer freedom of the controls and the logical nature of the engine. Although I hated the first week of making the engine, I grew to love making this game and was pleased it made Internet Game of the Month in Edge magazine's January 2008 issue.
A track and field style rail cart game. At some point in the design process I asked Matt if it was okay if the cart exploded every time it hit an obstacle. I thought this would make the repeated deaths entertaining. (It did.) Thus the Debris class was born and copied into every game that followed. The cacti are actually ragdolls but their limbs eventually came out so short that this effect is lost. The rail cart is actually a spring that is shoved left and right by reading the gradient of a piece of track. This game runs like a greyhound on meth. I think it's down to the small quantity of MovieClips on screen at any one time as well a scrolling mechanism I use that attaches and deletes clips as you move through the level.
Nanobots
A shoot em up with switching weapons. We looked at a number of shoot ems for inspiration for this game including Radiant Silver Gun, Ikaruga, R-Type and Geometry Wars. We tried to cope with potential overhead trouble by limiting collision to circles. Unfortuately this game taught us some harsh lessons:
- Geometry Wars is not level based for a reason. It's practically the shoot em up equivalent of pin ball. There's no exploration involved either, so no surprises, just the marathon.
- More enemies means more development time. Headcase only has 5 monsters, and yet it's still a strong title.
- Many short levels instead of a few long levels. Some other games could do with this. Long levels basically punish the player for playing the game - short and sweet works.
A game where you draw shapes to pop balloons. This game uses a Back Propagation neural net that I ported from Java to Flash to recognise the symbols drawn. This game got poor reviews and yet reached over a million plays within a month. This taught us two things: facts are better than opinions, and quick games are brilliant for making money off of advertising. Somebody even made a DS version of the game. He's done the shape recognition differently and it could do with a little polishing but I'm still flattered as well as impressed.
A game where you swing between platforms using the mouse. This game essentially took the Worms 2 ninja rope and made a whole game out of it. It was my first game for Nitrome so I only built the engine, the interface was all built by Heather Stancliffe. It used line intersection code with a spring based on the springs in the Flade engine. There are things I would do differently if I did this game again: intelligent scrolling (a la Headcase), keyboard control instead of the mouse waving tactic and easier levels. I made all the levels in this game and we've since learned at Nitrome that programmers make punative levels. If you're playing one of my games then the later levels are usually all mine. If you're stuck on level 19 or whatever thinking it's impossible, it's because of me. And I'm laughing at you.