Oh, let’s start with names again shall we?
When you set out to paint a picture you start with a blank canvas, and a world of possibilities. You can then dip your brush in oil paint or gouache or watercolour paint and let rip with your imagination. Likewise if you decide to write a short story, or a poem, or a sonata you start with a blank page and a pen and the freedom to express yourself. Going digital, if you want to write a word doc, or create an image in Photoshop, a model in 3DS Max, or write a blog post in WordPress you fire up your program of choice and start with a clean state that you can immediately attack with keyboard, or mouse, or touchscreen or tablet. These are endeavours that typically take hours, (but may last days (or maybe longer)).
When you set out to make a video game, you fire up XNA, or Unity or GameMaker, and the first thing it asks is for the name of the project. Before you can place one pixel or create one polygon or type one line of code it wants the name of the thing that you will be creating. This is a project that could last months or years. A name, right now, before you go any further.
Fingers crossed in a short while I’ll finish my current game, and release it to critical acclaim, and people will love it, and the rather silly name “Super Thrustforce: Orbital Meat Police” will be known to gamers across the world.
But deep down I’ll always know it lives in a directory called “TestProject01”.
I tend to start lots of projects – I’ll often abandon them quickly afterwards, and then start something else instead. So I’m used to having to name these things with temporary names, knowing that I’ll live with something placeholder, but can rename the end product if it ever materialises. However, if I haven’t started something new in a while I tend to forget this part of the process, and the request for a name upfront is always jarring.
To cut to the chase, many years ago I decided to have a pop at writing a Uridium-style game in XNA – a bi-directional side-scrolling shoot-em-up played over the surface of giant enemy dreadnought spaceships. I wanted this to be a short project with a definite goal to aim at, and this seemed small enough. I gave it a quick think over, thought it should be easy enough and then fired up XNA. I hit the project name barrier. I dunno, let’s try “SHMUP”. Nope – it already exists. Of course it does, I’ve had half-hearted stabs at my favourite genre loads of times. OK “Shooter01”? Already exists. “ShootEmUp”? Gone. Fuck it, “Star Weasel”? New project created – result! Blank canvas time, let’s make a game.
I now have a game called Star Weasel, for no reason other than I have an abiding fondness for all of the sock-shaped creatures of the mustelid family (stoats, ferrets, polecats and weasels), and a mental toin coss picked “Star” over “Space” as a way to make a critter sound like a game name.
So after all that preamble here’s a quick video of the game:
This was made in late 2009 to early 2010. I think it holds up fairly well, and bears an awful lot of similarities with current project STOMP. Possibly too many. Bold colours, untextured polygons relying on a shader to look nice, 2D game in a 3D world, a background starscape with 3D planet and moons orbiting far faster than they should etc.
More worryingly – that ship. On the left Star Weasel, on the right STOMP:
Look at them! They’re almost identical. And they’re both dreadful (of all the models in STOMP the thing I like least is the player’s ship – it’s getting a redesign right now). Four or five years and any number of different projects separate these two games, and yet I made the same godawful spaceship for both. STOMP’s ship actually started off blue, but somewhere along the line I recoloured it on a whim, and somehow managed to make it almost the same as the ship in Star Weasel – THAT I NEVER LIKED THEN EITHER.
Moving on, and to follow up on my post I <3 3D, here’s a quick video showing off the various camera angles I added for the fun of it:
So to smmarise what we have then is the basic framework for a Uridium style game, with some shootable objects and enemy turrets and whatnot. Not shown are enemy homing mines, which were implemented quite nicely, but I’ll get on to them later.
So, what went wrong with the Weasel? Two things mainly.
The first was scope. The game became far too complex and daunting. As with Dogfight Thing I started with a simple premise and quickly over-complicated it to the point that it became a mountain to climb. For starters I’d decided (because the enemy dreadnoughts were component-based) to make a level editor, and that’s a whole heap of no-fun whatsoever in its own right. However the biggest issue was in the actual game design, and looking back I think I can see exactly how it went wrong.
I started out as an artist, and one of the things I know I’ve always been weak at is making superfluous shit up. In art classes back in the day I used to love drawing dragons and monsters and castles and stuff, and was pretty good at it, because I could justify everything I was drawing. So what if my dragon has a few ear-piercings? It’s a dragon with a strong sense of identity and a personal stylist with very little regard for their own personal safety.
I was rubbish at spaceships though (and as we’ve seen – I still am). Good spaceships tend to be covered in clutter – all manner of vents, and panels and stuff. Superfluous shit. I struggle with this – I want to have a reason for everything.
So I start working on a game featuring enemy dreadnoughts with shootable surface objects, and I immediately have to start giving functions to these things. That’s a shield generator, that’s a radar nodule, that’s a power unit, etc. Suddenly I see a very different game emerging, with interwoven systems like a fully-functioning star-destroyer might have. Do you take down the tough defence cannons first, or try to endure their onslaught whilst you soften them up by destroying the shield generators? Destroying weapons-guidance systems would make enemy fire less accurate, and getting rid of radar would make enemy fighter passes less frequent. Suddenly we’ve gone from a game where I can just place lots of stuff that needs shooting, to one that needs careful planning and balancing so that all of these systems justify their existence, and levels will need to be populated with extra care and attention.
I still think there’s a really nice game in this, it’s just not the one I set out to make.
The second problem was that the game was in 3D. I was going to do a companion piece to my I <3 3D blog post (called “I h8 3D”), about the unforeseen problems that using a 3D engine can bring, but never got around to it. However, this game illustrates one of the main issues really nicely.
It’s all very well thinking “I’ll make Uridium in 3D”, spending a bunch of time knocking up some models, whipping together an XNA project and getting the basics of a side-scrolling shoot-em-up in place, but you really should spend a little bit of time thinking through the mechanics of the game and how they’ll translate to a 3-dimensional solid world beforehand.
In the original game, the player shoots targets and dodges obstacles on a 2d plane, and that bit’s easy to replicate in 3D. In the original game the enemy fighters and mines live on the same plane and yet ignore the targets and obstacles – they simply appear to fly over them, because sprites can do that if they want to. You can’t do that in 3D – you’d see them fly through solid objects. To fly over the obstacles they have to actually fly over the obstacles, and if they’re doing that then the player can’t shoot them, so there’s no point in them being there.
The alternative then is rather than having waves of stupid enemies that simply pass back and forth (nice and easy to program), is to have smart enemies that can navigate around all the clutter that someone stupidly positioned all over the otherwise nice empty deck (much much harder to program). And those nicely-implemented homing mines I mentioned earlier? In their simple-minded desire to head straight for you, they’ll fly straight through anything in their path, which looked rubbish. So then I made them destroy whatever they hit instead, which meant they were more of a threat to their own ship than the player was because they almost always hit something friendly. It was kind of amusing for a while, but it looked pretty stupid in the scheme of things. The other option was making them explode on contact but not destroy the target, but this still meant they rarely bothered the player, and also robbed them of the ability to look like dangerous explosives. Basically they needed to be much smarter, or they needed removing.
I’ve already mentioned elsewhere that I’ve tended to struggle even getting started with AI. I always want to do it well, so put it off until later to do it properly, and often never get back to it. In this case, it was probably the straw that broke the camel’s back.
I’d only wanted to work on a short project, and suddenly it had become a lot more complex than that, and I just lost the will to carry on with it. I actually really like the idea of making the game at its fullest – with complex functioning systems, and smart enemy defence forces – it’s just not something that I enjoyed stumbling into at the time. One to revisit later, maybe.