The third part of the Explodemon Saga describes how Explodemon’s various game systems were fleshed out and shows the first full draft of the finished prototype.
When I came to implement crates, that mainstay of video game furniture, I kept coming back to Half-Life 2 and its gravity gun. Every physics object in Half-Life 2 reinforced the player’s knowledge of the real world; objects that were thrown responded as expected, and their interactions with other physics objects provided predictable rules that could be used to solve puzzles. Because the forces emitted from my game’s explosions had the potential to be a similar source of physics-based gameplay, I wanted to try to create the same sense of physicality, of destructiveness, of reliable and predictable rules, but in a 2D platform game.
I therefore spent a while coding a (simple) physics system. Crates would respond to relevant forces in relevant directions when hit by explosions, bounce off other crates and so on. I made the objects move fast and land heavy, to emphasise the arcade-like direction the game was heading.
Following on from objects moving as expected, I felt it was important that the player enjoy every single explosion that they created, to make even the simple act of pressing a button be rewarding and moreish. I’m a big believer that if you make the lowest level of a game’s interface enjoyable, you’ve got a much better chance of building a rewarding game on top. To this end, I made lots of shit blow up into tiny pieces; windows, solid walls, wooden crates, areas of solid rock (completely stolen from Yoshi’s Island).
A big breakthrough came when I mimicked Half-Life 2’s time-delayed exploding barrels, by creating a crate that would itself explode after a period. A by-product of this was that the player could hit these exploding crates into other crates, creating chain reactions and destroying things at distance, purely by exploiting the properties of the physics system. The beginnings of a fun system that allowed for a good degree of player expression were beginning to form.
By now it was December 2005, and during work hours at Curve, we’d finished off the Superman joystick game and were almost there on the Spider-Man pack. We’d been speaking to a number of publishers, desperately trying to get a break back onto consoles, but we’d been confounded at every turn. The industry was still in a state of transition, and only safe bets (studios, as well as IPs) were being funded. Still, we’d been lucky enough to arrange another two joystick game packs to start in the New Year, so the worry of running out of work was kept at bay for the holiday season, a feat that we wouldn’t always manage in later years. Just before I was set to visit my in-laws in Australia for Xmas, I created this build of Explodemon, which shows the results of my ramblings above.
The three week Australian trip, away from computers and games, ended up being a powerful catalyst for the productive period on Explodemon that would follow. Unable to implement any ideas, I built up a number of concepts in parallel, concepts that I was raring to get started on the moment I got in front of a PC. Due to my desire to create a polished platform game, I remember diving right into writing the definable keys, menu system and checkpoint code on my return, something I think my wife found a little strange!
Another contributor to the productivity of this period was the dire lack of need for creativity during my work hours. Early in January 2006, we’d begun production on two joystick games. The first was based on the excellent Avatar: The Last Airbender cartoon series, which I selflessly allowed Rudolf (Kremers, Eufloria) to do the design work on. I’d then left myself with the real dregs; the Thomas the Tank Engine joystick game. It’s not something I really want to go into in too much detail, but suffice to say that it was the worst project I’ve ever worked on, beset with major production hiccups that were outside our control. With all of that creative momentum building up, and nothing to fulfil it apart from my lunch time project, Explodemon rapidly began to take shape.
Combat was my first port of call. I created a really simple enemy by taking the crates, making them move left and right wherever they landed, and giving them sprite animations to match. Insta-enemy. After seeing how well the exploding crates turned out, I had the enemies explode when they ran out of health, but only when they came to a stop. This last part was key because it meant enemies could be used to create chained explosions by aiming them with your own – in other words, the enemies themselves could become weapons. Being able to then have these enemies airlifted in by Halo-style dropships was just total geeky empowerment for me.
Meanwhile, I’d had this really great idea about the combat; a mechanic that would keep every encounter interesting. My inspiration this time was the risk/reward mechanic used in Bangai-O’s special attacks. In Bangai-O, you squeeze one of the triggers to unleash an attack that fires multiple shots in all directions. The brilliant bit is that the attack fires off more shots the more danger you are in. It works on proximity, so the closer the enemy shots are to you – and the higher the number – the more powerful the special attack is when executed. Since all enemy shots are destroyed by the special attack, the aim is to wait until the very last moment when you are about to take a hit before pressing the special attack button to unleash a super powerful counter. It’s risk/reward in a distilled form, and is pure Treasure genius.
Because the player’s main attack in Explodemon was centred on their location, and Explodemon himself took damage if he touched an enemy, I took Bangai-O’s mechanic and applied it to the player explosion. If the player played safe and exploded an enemy while they were far away, they did little damage and got little reward. However, if they waited until the very last moment when they were just about to make contact, the explosion did massive damage and the player got a large reward.
Now, when I say reward, I’m not just referring to a glowing sense of self-satisfaction. It was important that this reward meant something - that players valued and desired it. To fulfil this function, I created Explosion Levels. The high concept for Explosion Levels was simple: the higher your explosion level, the more powerful you were. The ‘reward’ for defeating enemies were red orbs; the ‘better’ you defeated them, the more orbs you got, the higher your explosion level, the more powerful you became. The opposite of this was not defeating the enemies well, where leaving it too late to explode or just plain taking a hit would reduce your Explosion Level. So, a simple yet deep system worked its way into the combat:
- Explode at the last minute to play well and get more powerful.
- Mess it up and get less powerful until you eventually die.
Also adding to the strategy the player would have to form during the combat was the recharging gauge that had to be full before exploding. It gave a rhythm to the combat, with the player constantly alternating between two states. When the gauge was full, the player was capable and destructive – able to choose how, where and when to attack. However, once the explosion had been released, the player was now on the defensive, unable to strike back. While in this state, the player needed to skilfully dodge and evade attacks, manoeuvring themselves into the ideal position to attack again and, if playing well, coinciding this positioning with the gauge fully recharging. This system (along with the risk/reward explosion mechanic) was to be my take on Halo’s famous “30 seconds of fun”, and it has ensured that the combat in Explodemon has remained absorbing to this day.
For the defensive state, where the player was waiting for their gauge to recharge, I needed Explodemon to be responsive and manoeuvrable. For this, I created the slide, which was a movement technique that the player could employ but not use offensively, instead lifting enemies and objects into the air and buying time and space. The creation of this move was also down to my longstanding dislike of the Mega Man games. I’ve never played more than 30 minutes of a Mega Man game to this day, because I find the abilities of the main character too limiting. I find the fact that he can’t crouch or shoot in more than two directions to be frustrating rather than enabling. He’s so immovable, and I understand why some people like the gameplay that the limitations create, but for me it’s like moving a brick around. I find it funny when people say Explodemon is inspired by Mega Man, because it’s true in a way that people might not expect: some of Explodemon is how it is because I wanted the main character to be nothing like Mega Man!
The final part of the combat puzzle was the counter. I used to play a huge amount of Street Fighter II and, to a lesser extent, Tekken. I’d always enjoyed the complexity afforded by the rule sets of beat-em-ups, and especially the idea of advanced techniques. These kinds of features bring depth and longevity for more committed gamers, and I wanted to add that kind of feature to the combat in Explodemon. I was inspired by the Alpha Counter and Parry systems in Street Fighter and also the Counter and Chicken system in Tekken. I wanted something reaction-based that would turn the tables for the player if they were in a tough situation, but only if they were quick enough and understood the game well.
And so, Explodemon’s own counter technique was born: if your explosion gauge was empty and you could not attack, but you were inside an explosion created by an enemy or other object, then you could ‘counter’ it. I saw this as Explodemon drawing power from the explosion he was in to create one of his own. It manifested itself as a half a second window within which the player had to press the explode button, indicated to the player by a [!] above their head. If you were quick and played strategically, you could repeatedly explode, quickly clearing a mass of enemies with panache.
With these systems in place, I created two levels in which to showcase the game. I also included a bunch of other mechanics, like the Metroid-inspired boost run, and the missile redirection mechanic. Created in March 2006, these two levels formed the main gameplay levels for the next three years. You can check them out in their entirety in these two movies.
In the next part I’ll look at how Explodemon finally bust out of its Game Maker prototype to become an internal project at Curve, and detail the response we got from publishers when we showed them what we had.
In this second part, I look at how I cracked the fundamentals of character control, got addicted to code, and show where my inspirations came from.
It was November 2005 when I first started writing the player code for Explodemon. After hunting around for some sprites that I could borrow that would do everything I wanted (thanks, Pulseman), I started trying to make the little fella run left and right. I’d always liked how much depth of control the inertia in the 2D Mario games created – the feeling of weight that resulted, combined with the feeling of being just on the edge of control, unable to stop quickly - so I started by emulating that. Pressing in a direction would slowly increase speed up to a maximum, and pressing in the opposite direction (or releasing the stick) would decrease speed until at a standstill. It was easy enough to get working and once I'd matched up the animation and direction with the speed, I was done. Hee hee, there he goes! Easier than I thought! It was my first true taste of the secret Power of Coding; a god in a universe of my own creation. I ran that little guy left and right for ages, slowly tweaking the variables until he was perfect. Now what? Oh yeah, it’s a platform game.
I remember jumping being a bit trickier. Sending him upwards was easy enough, but having to check whether the little guy could fall and to align him to the floor if not, resulted in me constantly sticking him inside it. Once I’d done some brief fixes on that, I spent a while playing with the values for his rise and fall, and also on how holding down the jump button would make you go jump higher and how long you could do so. This, for me, was the crux of the issue. The balance between the running speed and acceleration, how high the player could jump, how you controlled yourself in the air, and how tactile it felt; these elements formed the rhythm of the game, its heartbeat, its soul – and it just had to be perfect. I did some tests on timings in other platform games, but eventually just went with my own gut instincts. I admit to feeling an immense sense of satisfaction when I was done. The control felt solid, responsive and enjoyable, and I’d managed to do it all myself in just a few lunchtimes and evenings. I really felt like I’d cracked some special code, like the mysteries of the ages were laid out before me. All of those games I’d played and revered suddenly seemed within my capabilities. I think that this was the moment that I became totally hooked.
Now that I had the basics, I needed a high concept. The inspiration came from three separate places. The first was Meteor Strike, one of the Superman joystick games we were working on, and a kind of simple evolution on Missile Command. There was a mechanic in it where you could destroy certain enemies that would create an explosion that could then be used to destroy other enemies. A key strategy was to repeatedly chain these explosions together in order to clear the screen. It worked out pretty well in a basic fashion, but I thought it might be nice to see how that would work with a platform game. The second inspiration was a simple block puzzle game I was working on, a match 3-style game whereby you had to clear black blocks by detonating like colours next to them. As you progressed, the explosions ‘levelled up’ and got more powerful so you could clear the black blocks more effectively. (If you're interested, you can download the Windows-only prototype I created here. You can see an early version of Explodemon's levelling mechanic already forming itself). It was the first thing I’d ever coded, which was exciting in itself, but it was a bit dull and I'd kind of lost interest in making it great. Instead, my idea was to transport that mechanic to a platform game. As for the third inspiration, I used to work with this talented artist called Jamie Turner. Jamie was a bit of a star at Blue52, always churning out great work and great ideas. We had an excellent working relationship too, collaborating together to create the mighty Rock Troll concept, another unsigned gem. However, Jamie was clearly too good to stay in the UK for too long and about 6 or 7 years ago got a job in Tokyo, working at Nintendo second party, Genius Sonority. At GS, he worked his way up from effects gaijin in the corner to game director gaijin, even working with Miyamoto at one point. He’s now working at Pokémon creator, Game Freak, and we’re in touch regularly.
There were always new games concepts bouncing around at Blue, and Jamie had a few, one of which was Exploding Robot 12. Jamie’s concept went something along the lines of humanity’s last hope - a robot that couldn’t stop himself exploding - being sent out to destroy the alien menace that was threatening all of mankind. From what I remember, it wasn’t so much a platform game, as an action puzzler, where you had to navigate sections that you didn’t want to destroy, as well as blow up the enemy spacecraft and whatnot. I always liked the idea, and my recent explosion-based thoughts lead me to wonder if it would translate well to a platform game. I mentioned it to Jamie and he was up for me carrying the idea on. The early builds even had the codename ‘R12’.
Inspired by rocket jumping in FPSs and the physics of the grenades in Halo, I first experimented with using the explosion as a double jump substitute; instead of jumping and then jumping again, the idea would be for the character to jump and then explode, with the explosion’s force propelling you away. Also, with something as fun and destructive as explosions, I wanted them to be unlimited and available at all times - but knew that I needed to nerf it somehow, or risk the player being too powerful. I went for a recharging gauge; exploding would empty the gauge, and you’d have to wait until it filled up before you could explode again. Both of these concepts went in and, well, just worked. I also coded in the ability to double jump, but you could only do it after you’d exploded in the air. This simple feature ended up being quite instrumental in creating some of the unique player character control that we’ve got in Explodemon today. You can play the build as it stood after two weeks here.
Once I had the explosions moving the player around, it was obvious that everything else in the world needed to be moved by them too. I needed something to get me started, and the answer was obvious. I didn’t even flinch. Old Man Murray be damned, it was time for crates.
One of the downsides of being a game developer is the relatively high chance of seeing your hard work get cancelled or go unsigned. There are so many forces acting against a game being funded – and then more again against it being completed – that it’s a miracle that any games get published at all. Most developers I know have their fair share of stories about games that should have made it, and, of course, I’m no different. So, in the interest of letting you, the reader, in on my particular part of this murky world of could-have-beens, and in order to vent some of my frustration at my hard work being forever lost, I present Deadlight.
Conceived during the final 18 months of now-defunct independent UK developer, Blue52, the concept for Deadlight sprang out of the desire to reuse the tech we’d created for our shadowy stealth game, Stolen, in a game which actually suited it. The engine was pretty advanced for PS2, with some sophisticated lighting and shadowing effects, the now oft-used bloom, bump mapping and specular highlighting. With the Doom 3 demos being shown at E3 a year or so before, we thought that our engine was essentially as close to id’s Tech4 as you could get on PS2, and so the kernel of an idea was formed. The FPS market was massively under-represented on the platform, and after all that sneaking around in Stolen (failing to combine non-lethal stealth with fun), I personally wanted to make something where the primary activity was the proven mechanic of shooting things really dead.
Of course, every game needs a hook, and the inspiration again came from the desire to do the exact opposite of Stolen; in that game you moved around the shadows, waiting (boringly) for your opportunity to strike or pass (boringly) unseen. The high concept for Deadlight was for the player to avoid the shadows and stay in the light, and to aggressively protect themselves against the threat that dwelled in the dark. This simple premise, combined with the desire to harness existing technology, pretty much forced the concept to shape itself. And so, a first-person survival horror game was born.
Quite early on it was decided that we’d need the game to be set in a closed, controlled location. Since the head of the New Projects Group at Blue just fucking loved massive ships, we settled on an ocean liner, the SS Hyperion. The cruise liner allowed us to showcase a variety of locations within one setting; from elegant ballrooms, luxurious casinos and passengers’ cabins, to the crew’s confined quarters, the industrial engine and engineering areas, and open deck. Even the ocean and the hull of the ship would provide compelling settings for set pieces when combined with a genuine fear of the dark. For the purposes of our fiction, once our vessel was located north of the Arctic Circle, it would be subject to weeks of extended night. Perfect.The setting necessitated that the creatures be born of the sea, so the ocean soon came to permeate all areas of the design. Real-life monsters of the deep proved excellent visual reference for a survival horror aesthetic; with spiky teeth, hideous dead-looking eyes, cadaverous skin and undeniably alien forms. Bioluminescence also provided a signature creature ability. Many creatures that live at great depth use light for various means, whether communicating their intent/mood or luring in potential pray. It was our intention to use bioluminescence to portray unsettling patterns in the darkness, indicating where there may be a creature threat, but not always which creature it was or which shape it took. The colours and patterns would change depending on what the creatures were doing, allowing us to communicate to the player whether they would, for example, move to attack, had not seen you, or were otherwise engaged.The deep sea inspiration also strengthened our main light mechanic. The original concept was for light to be painful to the enemy creatures, and for the player to use it to keep them at bay. It would be a resource to manage and control, from collecting torch batteries and shooting out blackened windows, to the genre clichés of restoring power to areas and lighting flaming rags. It was also a very economic way of radically changing the gameplay of an environment by altering nothing but a few of our engine’s light values.
Our research into the deep provided us with a very interesting enhancement to this mechanic. Most of the visible spectrum is absorbed within 10 meters of the surface of the ocean, and almost none of it makes it past 150 meters. Blue light, with its shorter wavelength, penetrates further than red light, which is at the other end of the spectrum. The side effect of this is that many creatures of the deep have not evolved the ability to see red light, because it can’t be seen at distance. However, most can see blue light, and this is why it is used largely in bioluminescence as a lure for prey.
We stole this science wholesale for our light mechanics. Red light would be used to illuminate an area without alerting creatures, which could not see it, and blue light would be used to attract creatures, much like the angler fish. While totally non-scientific, we kept white light as painful to the creatures since we liked what it brought to the gameplay. Here are a couple of the target renders we did in order to communicate the mechanics to the team and to publishers.
Aside from the bioluminescence and susceptibility to light, we were also keen on the concept of an ecology having formed on the SS Hyperion. This would mean a hierarchy, essentially a food chain, of different species hunting or hiding from each other. The strategy for the player would be to learn which species formed which part of the food chain and exploit it. As an example, while being pursued by one species, you could use blue light to attract the attention of one of its predators, or alert its presence to something that it might find tastier. While we never had time to fully explore this system, it certainly sounded intriguing.
We eventually got the chance to turn the Deadlight concept into reality when Stolen was cancelled by SCEE. It had been with them for about 2 years at that point, but had always been a troubled title and no one was really surprised when it happened. Still, a new home needed to be found for it, and while that was happening, the company split into two teams in order to work on two separate concepts; Deadlight and a classic Wild West movie license that we had the opportunity to pitch about. We had a couple of months with which to create a playable demo for each concept in order to provide valuable selling tools for the future of the company.
Despite the threat of company closure looming over us, it was quite a fertile and fun time for some of us. We had weekly show-and-tells where each team would showcase their progress that week, and a winner was decided. It quickly became very competitive (especially when we lost the first week), but it proved quite a productive period. Here, then, is a video playthrough of the end result on PS2. Amazingly, this took 13 people only six weeks, starting totally from scratch. While it wasn’t 100% successful at demonstrating our mechanics, we had created a compelling, playable demonstration of what Deadlight could be.
After six weeks of working on the Deadlight prototype, Stolen was signed by Hip Entertainment, and Blue continued on with that. I formed part of a team that would continue to develop Deadlight and pitch it about, although did eventually move back on to Stolen to see it through to ship. While there was always a lot of interest from publishers, Deadlight was never to be. Because Blue52 had had two games cancelled – although through no fault of their own (one because a publisher closed a subsidiary, and another that was a new IP platform game in a green light meeting against two other established franchises, where only two could get green lit) – it meant that the company hadn’t shipped a game for nearly four years, and were deemed to be a high risk investment. With the death of Blue52, we tried to reposition Deadlight on PSP with the newly formed Curve Studios. We got extremely close with one publisher, even getting as far as flying to the US to sign an agreement, only for them to change their mind while we were en route!
And so that brings me back to my opening paragraph. While a solid title for 2004, it was just the wrong time for Deadlight. New IPs were becoming riskier bets for publishers as the then-current generation of consoles came to a close, and so it was probably always destined for failure. It’s good to see Alan Wake continue some of the themes and mechanics that we were pursuing in Deadlight, although their treatment of white light looks way better realised than ours was. Still, with more development, maybe we would have ended up with a similar treatment to Remedy’s. I guess we’ll never know, since Curve don’t make games as big as Deadlight any more (it would be even bigger now in the HD era!). That’s fine by me though; our small is pretty beautiful.