During my time at Paladin I worked on a game for Blind Ferret Entertainment based on their hit webcomic Looking For Group. It’s been the biggest game I’ve worked on and it was a lot of fun, even though we eventually ran into problems that stopped it from going into full production. I wrote a few blogposts about the proces of turning this comic about a game into a game about a comic.
Building a new game always requires some forethought. Before you can start dressing up levels with explosive barrels you need to think about ‘what do I consider a level?’ and ‘how much exploding should explosive barrels do?’ That is why we build prototypes.
For Fork of Truth we had to start with the basics – movement and camera.
You may have a mental image of the way something should work, but by building it you often discover that there are things you haven’t thought about. For example: having a fixed isometric camera and a character that follows your mouse cursor sounds like a fine system, but if you then walk downwards on the screen, your left and right directional buttons are inverted. So we had to correct the movement to be relative to the camera, independent of the character’s rotation.
Upon seeing the above prototype one of our programmers remarked “it’s funny to see the difference between a programmer’s prototpes and an artist’s prototypes. I mean you’ve got the vignette and the dynamic shadows all up in there and stuff, really cool!” Heh. They are unnescessary frills but they make the prototype just a bit more pleasant to look at.
Now, Isometric cameras are usually orthographic, but we found much nicer results with a perspective view. Then we tried zooming, and this worked very nicely to show the characters up close, but made it impossible to see or fight anything standing ‘below’ you, since our camera does not rotate. So we could either make the camera rotate, which we didn’t want to do because it would triple the work we had to do to make the level look good from every angle, or we could adjust the camera curve so it never zoomed to a point where this became a problem. All these considerations I could not foresee when typing up the game design document.
The control scheme we went with was very similar to a third person game with strafing and mouselook etc, but unlike a third person game our camera does not rotate, so now we had the matter of a character walking one way while facing the other. Does he turn his head? How far can he turn? Does he walk backwards at some point? Do we need a different animation for that? What happens if he attacks?
Now we cross over into the territory of animation blending, a topic our Technical Director Niels did some stellar work on using Mechanim. These are all things we needed to think about before we started building our systems so that they were as flexible and modular as possible so we could easily extend them if we thought of new features down the road.
Once we liked the feel of the controls we added in attacks, enemies, and built a little level around this. And again we discovered things to think about: if a player goes behind a house that obscures the camera, do we turn the house transparent? Does the camera zoom way in? Do we outline the character so you can see it through walls? Do we redesign the level so this never even happens?
Every prototype raises questions that we can then investigate in a new prototype. And it’s important to make it a NEW prototype, so you can look back and compare, salvage what works and throw out what doesn’t, so you end up with something that has been tested and improved upon even before it was properly built.
And then with all these systems fleshed out, you can start to see how they work together. Opportune time to delve into gameplay topics, like how far apart should the enemy spawns be to make the pace of the level enjoyable? How many enemies can a player handle at once? Do we need less enemies or should the player’s attacks just be more powerful? How many meteors can Richard summon at once before the game crashes?
You know, important questions.