Full details here: http://rockethands.com/ruby-ogmo

Zarch is the name of a game on the Acorn Archimedes; I played the Amiga port, which was called Virus. In fact, Zarch itself was a full-fledged version of an Archimedes demo called Lander. David Braben (yes, he who, along with Ian Bell, created Elite) wrote it in three months in 1987. Virus, the Amiga port, didn’t look as good (no light-sourced polygons), ran slower, and was released a year later, but I still loved it.

Virus on the Amiga. Image by Wikipedia.

Lander became known for its fast, smooth, solid-3D graphics. In 1987 this was an almost unbelievable achievement. ACE magazine (which was known for rating games out of 1000 points, and for publishing a lastability graph with each review that extimated how much you’d still be enjoying the game after an hour, a day, a week, a month and a year) featured it on it’s cover, along with the headling: “Solid 3D – The Future of Games?”

I loved playing Virus for its procedurally generated landscapes, but what really clicked for me was the controls. It was the first game I played where a mouse was the preferred control method for movement. Moving the mouse rotated the ship around two axes, while the right mouse button was used to generate thrust. First time players would instantly crash and burn, due to the precision and sensitivity of the controls, and the learning curve was steep. Persistence paid off, however, and after plenty of practice it was possible to skim low over the landscape and turn on a dime. Sweet.

The left mouse button, of course, was used to fire your weapon. The gameplay consisted of ridding the landscape of all polluting alien craft before they could complete their task of seeding the verdant land with their evil red virus. Simple, really.

Post Scriptum

Some people have asked how to get hold of The Sentinel, Exile and Zarch (aka Virus). Here’s how:

1. Purchase the Plus edition of Amiga Forever, which includes licensed versions of all Amiga Operating System ROM and 100 games of various quality. It costs US$30, and it comes with Exile included.
2. Search Google to try to find versions of The Sentinel and Virus that you can run under emulation via Amiga Forever, but that may not be available with the permission of the copyright owner.
3. Alternatively, search Google for free remakes of these games (although I cannot vouch for their quality).

Exile is an “arcade adventure” (a now defunct term; these days you’d call it an “exploration platformer”) that features realistic physics and AI, and which has a large map that was mostly procedurally generated (but then touched-up by hand). How could I not love it?

The Chimps of Ni. Image by: Hall of Light

I discovered Exile when a playable demo was included on the cover of Amiga Power in 1991. I played the demo for hours on end, and eventually wound up buying the full game (reaching the limits of the demo took quite a lot of playing). I just loved the exploration, and the ways that items interacted with one another. You could pick up a glass jar, carry it into a pool of water to fill it up, then gently transport it across the map to use to extinguish a fire, for instance.

Much of the game involved experimenting with the world, and solving subtle puzzles to open up new areas for exploration, all interspersed with moments of frantic combat.

The physics engine was quite advanced for the day. In fact, it was a rarity to play a game that had any kind of physics simulation at all, so it was quite a novelty. It was fun to pick up and throw objects of all sorts, just to see what would happen.

The AI was also impressive. You discover and interact with many different kinds of creatures in the caverns beneath the planet’s surface, including anthropomorphic monkeys who say “ni” and steal items from you, and a friendly robot who responds to your whistle, and which you can use to solve puzzles.

Exile was conceived and written by Peter Irvin and Jeremy Smith (Jeremy, RIP, also wrote the classic C64 game Thrust). How good is it? Well, Edge Magazine has awarded only three perfect 10/10 ratings to games that were released before the magazine started publication. Those games are Elite, Super Mario Bros. and Exile. Which means you should play it. Now.

The Sentinel is an extremely weird game, but I loved it from the moment I bought the Commodore 64 version at KMart in 1987. I went on to love the Amiga version even more.

A typical view in the game. Image by: C64-Wiki

It was conceived and written by Geoff Crammond, who also wrote REVS (a great driving game on the C64), Stunt Car Racer (an insanely great game on the Amiga, which was best enjoyed by linking two Amigas together with a null-modem cable for multiplayer mayhem), and the Grand Prix series (a realistic driving simulation that started life as Formula One Grand Prix on the Amiga in 1992).

For me, The Sentinel is an outstanding game. It features a first-person view of a solid-3D landscape, which was incredible at the time. The ten-thousand levels are procedurally generated, which is something I’ve loved, from the days of Mike Singleton’s The Lords of Midnight and Midwinter through to Derek Yu’s Spelunky and Asobo’s Fuel (which Shamus Young has deconstructed at length).

The game mechanic is stealth; you must creep up on and ultimately destroy the all-seeing Sentinel, which occupies the highest square of the chessboard terrain, and which slowly rotates its gaze. You, of course, start each level standing on the lowest square. And, most unfortunately, you cannot move; only rotate.

To vanquish the Sentinel, you must absorb energy from the trees scattered around the level, and then use it to create robots that you may transfer your consciousness into, thereby teleporting yourself from square to square around the terrain. You gain height by creating stacks of boulders, and then creating a robot on top of them. In this sense, The Sentinel is a game of resource management, with trees, boulders and robots representing one, two and three units of energy respectively.

The trick is that you can only absorb energy from a tree, boulder or robot (when teleporting, it always pays to absorb the robot that you’ve teleported from) if you can see the square that it’s standing on. You must therefore work to increase your height, opening up lush new fields of tree-energy to mine. All the while, the Sentinel does the same thing; it absorbs energy from all bounders and robots it can see (including you), and uses it to create new trees at random places around the level. I loved this aspect of the game; it satisfies the first law of thermodynamics!

You can imagine how gut-wrenching it can be playing a level, with the gaze of the Sentinel upon you, watching your energy slowly drain away while you frantically scramble to create a new robot in a safe location, teleporting there only to watch your former self transform from robot to boulder to tree as the Sentinel consumes its energy.

Things get worse. If the Sentinel can see you, but not the square that you stand upon, then it transforms a nearby tree into a Meanie, which, when it rotates to face you, forces you to hyperspace. This consumes three units of energy, and transports you to a random square on the level that is lower than the one you were standing on. You could also initiate a hyperspace yourself, as a last-ditch attempt to avoid the full gaze of the Sentinel.

Victory was sweet. Standing above the Sentinel, immune to its gaze, you’d spend some time gloating before absorbing its energy to win the level. You’d then go on to a harder level, with the exact level number determined by the amount of energy you had remaining (so you’d jump more levels if you finished with more energy to spare). And because the levels were procedurally generated, there was no need to save the game. You’d simply write down the  8-digit code for the level you were on, and type it in the next time you wanted to resume your game (or, sneakily, try to reverse-engineer the algorithm, or enter level codes that you’d got from a friend at school, or seen printed in a magazine).

Later levels featured Sentries, which had all of the power of the Sentinel, but which stood on lower squares around the level. This made things even more frenetic.

Zzap!64, the premier games magazine at the time, refused to award The Sentinel a score in its review of the game, stating that such a wholly original game is in a class of its own, and therefore defies rating. Over twenty years later this is still the case. Everyone should play this classic game.

Confrontation. Image by: Playdead

The reason why I feel compelled to share my thoughts on LIMBO is that several friends have made statements to the effect that the demo was boring and that it’s just an average platform game with great lighting and artwork. I respectfully disagree, but I no longer find it important to convince everyone else they’re wrong (turns out you eventually grow out of that), and I appreciate having friends who have different opinions to me (I gave up wanting to be surrounded by clones of myself when I turned 8). So, rather than explain why everyone else is mistaken, I thought that I’d just try to explain why I like LIMBO, and why I think it’s more than a run-of-the-mill platformer with a pretty face.

Background

I’ve been playing games for 30 years or so. I used to be able to play Elite on the Commodore 64 from 5pm on a Friday to 5pm on a Sunday with few interruptions, but these days I have a wife and two small kids, which means I need to grab a spare 30 minutes here and there. The longest gaming session I’ve had in the last 5 years was playing Resident Evil 4 on the GameCube for 8 hours straight with the curtains drawn and the surround sound turned up, and only a six pack of beer and a few packets of chips for company, but that was Before Kids, and the wife was interstate at the time. The games that shaped me are Exile, The Sentinel and Zarch. I love puzzles, text adventures, the old LucasArts games and new games that favour atmosphere, exploration and narrative over precision, action and competition. These days I mostly play iPhone, XBLA and online Flash games. Yes, I’d like to try Red Dead Redemption, but I don’t think I can make a commitment to completing it. And no, I’m not a fan of the FPS genre in general. I do find many contemporary AAA titles repetitive and boring. Heck, I even thought Half-Life 2 got repetitive, and that’s supposed to be pretty good.

All of which means: perhaps it’s just me?

Style

The first thing you notice with LIMBO is its style. The animation, art, lighting and sound are all spot-on. Everything appears in silhouette, and a subtle vignette means that objects lose detail towards the edges of the display. In general, it looks like foreign arthouse cinema, and the typography used on the credits screen is consistent with that look. Everything contributes to an overall sense of foreboding. This puts you on the edge of your seat from the get-go. Something’s about to happen, and you don’t know what it’ll be.

Controls

The second thing you’ll notice is the controls. Or, should I say, the lack of controls. It’s the stick to move, one button to jump and a second button to manipulate stuff. Couldn’t be easier. No, I don’t want to spend time learning a complicated control system anymore; I don’t want that to be a barrier to entry. My time is precious, so I’d rather learn by doing. Character movement is fluid and natural, and platforming is as satisfying as it was in the original Prince of Persia.

Insta-Death

The third thing you’ll notice is the insta-death. Now, that’s often a sign of bad game design. But here I think it’s great. It never sets you back very far, and, although some instances (like the water) are unpredictable, you quickly learn the rules. All drops are fatal if you can’t see the bottom, so no leaps of faith are required. And many insta-deaths are forecast, and are therefore avoidable with careful play. When they’re not, the results are sometimes used to foreshadow a similar situation that occurs later in the game (one red herring is used to great comedic effect), or to form part of an intricate puzzle (such as turning the death traps against others).

Puzzles

These are what I really enjoyed about LIMBO. They’re so well designed. There’s no repetition, which is always so common in other games (as if the designer, happy with themselves for inventing a cool puzzle, decides to reuse it throughout the game, turning an original and fun idea into a chore). All objects that you can manipulate have a use, so there’s no blind alleys. And many objects have multiple uses, which is often really clever. Great puzzle design means that situations that initially seem impossible are surmounted after a little bit of experimentation, exploration and thinking. You get to experience that moment of insight throughout the game, which is very rewarding.

Game Length

I’m not an achievement whore, and I don’t care much for leaderboards, so, although they’re present in LIMBO, they’re not going to compel me to play through again. I’m very happy to have experienced LIMBO in 5 or 6 sessions of between 30 minutes and an hour each over the course of two weeks, and I found myself anticipating the next play session, as I do with the episodes of a great TV series. That synchronised pretty nicely with my wife watching some Mindless American Drama on the TV after the kids were put to bed, and didn’t hinder my ability to do other stuff after hours. Finally, the ending is really well done, and worth seeing. I will play LIMBO again, for the same reason that I watch great movies again; simply to re-live the experience. The short game length and lack of repetition benefits replayability greatly.

LIMBO is pretty, immersive and lean to the bone. An almost perfect game.

For me, this event was totally different to the Global Game Jam held earlier in the year. Due to the lack of other sites around the globe, I wasn’t spurred on by a sense of competition. It was more a case of manufacturing inspiration and enthusiasm by surrounding yourself with like-minded people and imposing constraints in the form of a deadline, a theme, and a “significant asset”. Also, the non-presence of that Louis Castle douchbag removed hate as a motivating factor, so I wasn’t keen to develop an evil game with Louis as the antagonist, as I did for GGJ.

Mr. Wittber chose to announce the theme and significant asset well in advance of the jam, giving everyone ample time to think about what they wanted to do. This was a great decision, as the amount of dithering about was reduced almost to zero, replaced with interesting discussions about several really promising game concepts. I went into January’s Global Game Jam wanting to make a flash-based game, which I’d never attempted before, and I used the time to learn how to write a game in ActionScript, using the FlashPunk framework, from scratch. This time, I knew I wanted to create a fluid simulation, similar to this one. I was pretty happy when I found out that the significant asset was a bubble, because that fitted what I wanted to achieve. As for the theme of “choose two at the expense of the other”, my first thought was the old project management adage “cost, quality, time: choose any two”. Kudos to Simon for choosing a much, much better theme than GGJ2010.

During the pre-Jam BBQ (during which Simon proudly revealed his massive cheese kransky, which both honoured and humbled me), I discussed two concepts with Jack, Nick et al.:

1. A resource management game called Gusher, whereby you send out geologists to explore land and sea, them choose a suitable spot to drill an exploratory hole, then build an oil rig to extract the crude, then refine it, store it to manipulate the market, then pipe or ship it to sell. You’d need to manipulate the media and the authorities, and there’d always be the chance of an incident (either deliberate or accidental). Each choice would allow you to fix two of the three cost, time and quality constraints, so, for instance, you would get an inaccurate report of where to drill if you sent your geologists out on a tight deadline and didn’t pay them very much.
2. A fishing game called Floater where you paddle your wooden boat across a turbulent ocean, choosing to stop and fish, bail out your vessel or move it left and right (only being able to do two of these things at a time).

After I began coding, I quickly realised that the fluid simulation would take a long time to code, and wouldn’t run at a decent framerate in Flash (I coded up a quick demo in C++ and in Flash, both using Box2D, to find big performance hits with more than 100 physics objects at once in Flash). So I started doing a little bubble simulation instead, using Box2D’s built-in support for buoyancy. This quickly led to an idea of a chef cooking a pot of soup on the stove, with ingredients being thrown in to raise the water level, and a game mechanic of merging like-coloured bubbles both to increase score (the deliciousness of the stock) and decrease heat (hence reducing the likelihood of losing an ingredient due to the intensity of bubbling, which would be the lose condition).

This worked out pretty well. Jack helped out with the graphics and playtesting, and the game mechanic came together nicely. You can have a go yerself on the RocketHands web site. Comments and feedback welcomed!

So what now? As I mentioned to Jack, Simon, Anthony and others at the end of the Jam, I treated things this time around as a great way of getting started on a project, rather than as a great way of finishing something off. So I plan to keep working on the soup-making game, which I’ve called Gusher2, until it’s at a point where I’m happy with it. With that in mind, here’s my to-do list:

• Ask Simon Boxer to draw some lewd cartoonish graphics, inspired by Muscle March. We need an attract screen, the main game screen in the same style, a win screen, a lose screen, and five distinct ingredients (celery, tomato, carrot, onion and kransky sausage).
• Add an egg-timer, and constrain playtime to 3 minutes, with a new ingredient going in every 30 seconds.
• Make the ingredients change the water level when they go in, and change the tint and alpha of the stock, to ramp up the level of difficulty as the game progresses.
• Display the current score somewhere on screen, and tweak the scoring mechanism to favour multi-merges.
• Continue to improve the game mechanic. Some playtesters have said they’d prefer to click on bubbles, rather than click-and-drag. So I’ll try that out.
• Animate some fire under the pot, some particles in the stock, some steam on top of it and so on.
• Add suitable sound effects, musical stings and… voice acting. Oh yeah: “My soup… she’s a-ready!”

After all that, I’m going to perform an experiment with online flash games:

1. Integrate with mochimedia. to experiment with in-game advertising as a revenue stream, to get analytics information, to keep online high scores, and so forth. Did I mention I want 5 different win screens, depending on whether you’re the top scorer, in the top 10%, and so on?
2. Integrate with Kongregate, to do much the same thing with a different API (mochimedia and Kongregate have an agreement to stay off each other’s turf, so to properly experiment you need to do both).

I’m hoping that integration with these services will increase re-playability. After all, competing with members of your social network for high scores seems to work. I’d like to give it a shot.

I want to get all of this done in the next four weeks. I’m working on three other projects. I have two small children. I’m building a house. We’ll see how it goes!

I’ve achieved the following things in my first sabbatical week:

1. Found an office in Leederville that I’ll be moving into next Wednesday.
2. Completed a prototype of one of my projects, the d-board (get it here).
3. Pitched three of my other ideas to a handful of people who are interested in funding them with Real Money ™.
4. Met with an accountant to set things up for if and when I actually do make any money.
5. Started planning the implementation of MegaHAL10, another of my projects.

Thanks all so much for the overwhelming support. It’s been great. And don’t forget to subscribe to “The Occasional Jason” if you want more detailed updates; the subscription form is over there on the right (if you’re viewing this on my blog).

The other goal of the InputManager is to give game contexts and game systems controlled access to input controllers. For example, when a particular game context is active, it may require exclusive access to touch. In other circumstances, several game systems and contexts may use touch simultaneously (as would be the case when implementing game entity control with touch and overlaying a HUD that contains buttons that may be pressed). I want to avoid the usual technique of having entities, contexts and systems query the input devices directly, so that’s taking a bit of thought and hacking to figure out.

I expect I’ll be a day or two on this, and then will move onto entities.