Also with this entry, I'm appending information about a new game in development at Moonpod. The project is called 'War Angels' and is being developed for us by Hamish McLeod. We are very excited about War Angels, as even in its current early production state it's great fun running around with all those guns!


-------------------------
Fost - Art
-------------------------

Space... The Final Frontend

The front end (setup and game start screens) for Mr Robot needed a backdrop, and so we decided it would be nice to show a little diorama of the Eidolon (the colony space ship that is the setting for the game), with slow camera pans past it as it travels to its destination. In constructing the Eidolon, we discussed several designs which were progressively outlandish. What would the criteria be? Mr. Robot is set before Starscape's faster than light drive becomes common use, so the ship would be a sub-lightspeed, long haul ship. Many of our designs incorporated crew space separate from the propulsion system via extremely long 'spines'. The separation allowing for hazardous drive technologies. This was an aesthetic we liked, but in the end we u-turned and came up with a conventional outline for the space craft.

The Eidolon grinds through space.

We decided that after travelling more than 100 light years, raw materials would be very important, and so the entire ship should be able to land and be dismantled so it could be converted into the colony. This meant the ship had to be somewhat aerodynamic, even if it was probably for a one shot landing on a planet. All of which has absolutely no bearing on the game whatsoever - but sometimes its fun to think why everything is like it is rather than just making it pretty :)


Final schematic shots of the Eidolon (Wallpaper)

Modelling the Eidolon was a pretty swift affair once we had decided on a design. I made a quick mockup for the scene - an extremely rough approximation of what I wanted to achieve. It's almost just a fleeting impression of a scene, and I doubt many of you will see the point of it, but I have always found it can really help me solidify an image I have in my mind, and then it's easy for me to get on creating the final scene. It also really helps me work out the light colouring I want to strive for. Since the Eidolon is the first thing you will see when you boot the game up (after the loading bar at least!) it's important for it to set the right mood for the game, and look as polished as it can be.

UV mapping and texturing ended up taking far longer than I had imagined. The model weights in at approx 6,500 polys. Whilst in game character models in top end PC hardware can far exceed this these days, they tend to be easy to map. The mapping does not need to be very regular, and you can often get away with flat mapping 90% of the model from front and back, then just pulling the seams a little.

Regular geometry can conversely be much harder; if the texture also contains lots of regular geometric patterns (as in this case) then the mapping needs to be perfectly square, even across the whole model. It's akin to gift wrapping the worst shaped present you can imagine :)
The model also had to be mapped twice - the first set of UVs are used to maximise the colour map by spreading the available texture over one half of the ship, then mirroring the model to create the other side. The second set roughly covers the whole model with no overlaps so I can create a light and shadow map. These two maps are then multiplied together in the shader. Additionally, the alpha in the colour map is used to pick out a few areas that need to be self-lit (like the windows). The colour map itself was yet another area that soaked time - all the regular geometric patterns have to flow round the contours of the ship and match up over uv seams. It was a look I really wanted to create but filling a 1024 square texture with single pixel wide geometric patterns can at times make you go cross-eyed :) Once that was complete, all that remained was to separate the text that is imprinted onto the side of the model into it's own separate set of polys, so it can be flipped on the other side (otherwise, after mirroring, it comes out backwards!), and write the glowy, animating texture shader for the jets.

All this has made me extremely appreciative of the work Relic put into Homeworld 1 and 2. Their space ship creations are wonderful and were a big inspiration to me on this part of the project.

Here's a short rendered spin round the final model:

(4 meg flash video)


Early oil pastel colour test used to gauge composition and 'mood'.


Final scene animating in the game's front end.

Raistlin:The Footpad

Do we have enough robots in this game yet? Hell No! Yet another addition to the robots onboard the Eidolon is Raistlin. Raistlin is the ship's comms specialist unit. Built round a lightweight robot skeleton; he is designed for speed allowing him to quickly locate and fix any errors in the miles of communication cabling onboard the Eidolon. Raistlin generally keeps himself busy in the darker corridors of the ship undetected by normal sensors due to his high level of interference shielding. Other droids often go about their business without even realising he is there except on the rare occasions he has something to say. Asimov has always been a little afraid of Raistlin's shadowy and secretive nature.

Concept Art


Final Model

The design phase for Raistlin was the fastest of the robots yet. I tend to mess around with all kinds of ideas before getting inspiration, and can often end up taking longer to design the model than to actually build and texture it (a process that is pretty quick once I know what I'm doing). I don't think this is normal amongst artists btw, as I know people who seem to be able to come up with great ideas at the drop of a hat. I find it much harder to work out what designs I'm going to go with and feel comfortable making. However, in Raistlin's case, he needed to be very lightweight, and so this dictated the design from the start and I think the constraints helped me enormously. I really like it when the design of a model fits its function:)

Game Data Server

In advance of Poo Bear implementing some of the front end features, I've been writing some new scripts to handle data requests direct from the game; effectively creating a data server the game can query. This allows us to do several things: Firstly, if you are connected to the internet, the unlock process can be handled for you, making it incredibly straightforward. The script can also pass binary data down to the game if requested, and so we can now have an 'update' button in the front end - one click and any patches are downloaded and automatically installed. That's the theory anyway :) Poo Bear still has to implement the much harder part that the game has to take care of.

-------------------------
Poo Bear - Programming
-------------------------

Easing The Player Into The Game

I've spent a lot of time creating the game's first phase which introduces the characters, sets the stage for the plot and explains the different game mechanics. The ideal I'm aiming for is that set by Nintendo and now much copied. A Nintendo game doesn't require the player to read a manual or feel they are taking part in a separate stand alone dry tutorial. They want you to get playing straight away, to introduce and explain new game mechanics gently as they appear. The goal is to get the player having fun immediately (within seconds) and to get him comfortable with how the game works, why he is there, and what he is trying to do. All without the player feeling they are back at school or that they are having to work at it.

To try and achieve these goals I've made the first section of the ship require a linear progression with each room adding a single new game mechanic. You will also meet some of the main characters and get a feel for being a lowly maintenance robot performing his day to day duties. So hopefully you begin to understand how the game works, what is happening within the world (your ship) and your relationship to your crewmates. Everything starts out fairly normal, but along the way you get clues to things starting to go wrong and then at the end of the first phase everything falls apart and fate selects you to step up.

Writing dialog and plot is very difficult, I'm not talking about the quality of the writing here, we have a professional writer to take care of that. It's avoiding reams of text that lie above the game, again Nintendo are very good at this. Players need to be directed to perform interesting tasks or be taken through interesting situations; it's no good just having 5mins of gameplay and then expecting them to read/listen 3 paragraphs of text (no matter how well written) that don't immediately impact on what they are doing. To achieve this you really need a good scripting system, this takes the pressure off the programmer and ensures it is relatively easy to bind the player's activities and the dialogue together and keep those activities fresh and interesting. Now I'm not saying MrRobot achieves this, just that it is a goal to aim at.

In MrRobot I need to communicate that Asimov is a lowly bottom of the ladder generic maintenance bot, only recently activated, desperate to impress his superiors so he might gain a specialist role and gain his comrades' respect. A classic story theme, although his aspirations are thwarted in daily life, fate puts him at the centre of a catastrophe only he can conquer requiring him to rise above his self imposed limitations and realise he can gain the recognition and respect he seeks without needing a new specialist robot body or title.

Communicating all that in a simple fun action/puzzle orientated adventure game is very difficult. A lot of well written prose might work quite well in a more serious rpg adventure title, but it wont do here at all. So instead those themes need to be in the designers head at all times and they need to "leak" out through the dialogue/activities as naturally as possible. If you do it right most people might not really consciously even notice and you might not communicate everything to everyone; people pick up different things. This is what happens in good quality episodic tv shows, they only have 45mins with you and there has to be some big in your face action (or fox will drop it) - i'm thinking firefly here :) . How do they communicate character relationships, setup an interesting world background, develop each character, develop multiple over arching story threads? Sounds impossibly hard, but it's what they all try and do with subtlety and transparency. The same thing happens in games, but the techniques are different and it happens much much less often. Something to strive for even if you don't achieve it. A writer cannot do it on his own, weaving plot into gameplay is crucial and you need a game designer to do that, but he cannot do it alone either. He wont have the writing skills or more importantly the understanding of how to develop interesting characters, their inter-relationships and the larger over arching plot/story that a player might actually care about.

Mouse Control

On a more practical level, I've added mouse support. People just love their mice and even if it makes more sense to use keys or game pad a lot of people just don't want to let go of that mouse. So the instant you touch the mouse in Mr. Robot, a little direction icon appears at Asimov's feet and you can drive him around. Left mouse to walk and right mouse to jump. Simple and a lot better than I thought it would be, but not as accurate as keys.
Mini Mouse Control Flash video

Simple Position/Euler angle Animation Scripts

To spice up the front end and encourage the idea you are inside a giant space ship we're going to show it slowly gliding by in the background of the front end. A very simple implementation where camera position and orientations are entered, comma separated, one frame per line (25 fps) into a text file (although I think Fost is managing to get some useful ascii data from blender now). The frontend is locked to the same update rate so each update overwrites the camera with the next frames data. You really can't get a simpler camera track animation system than that. Even better, the camera never goes vertical so we can use simple euler angles for its orientation. No need for a more complex quaternion implementation as we never have gimbal lock and we don't need to interpolate rotations. A lot of people avoid euler angles like the plague but there are still cases where they work fine. A 3 day job turns into a single afternoon. I hate it when projects slip because people become obsessed with "clever" implementations, bulletproof code that works in any situation and is completely reusable. Those goals are laudable, but taking shortcuts is quite often a more sensible approach especially when goals are shifting, the game is still unplayable or deadlines are slipping.

-------------------------
Hamish - War Angels
-------------------------
Hello everyone. Because this is my first entry, I'm going to start off with more of an overview of game:

War Angels is a top-down action game controlled in the same way as Crimsonland, Alien Shooter, Mutant Storm and other similar games. Set in an alternate future where the Nazis were not defeated in 1945, and the free people of the world continue to fight a desperate battle against the futuristic Third Reich. You take control of one of four female mercenary commandos, each with their own special abilities (which I'll go into later).

The player will follow a story that folds out through the levels as the game progresses. At the start of the game you are employed by a research organisation to stop their time travel technology from falling into German hands, which will eventually lead you across four different locations and time periods, each with their own set of enemies and weapons. Weapons will range from laser cannons, multi-missile launchers and micro nukes in the far future to advanced projectile weapons like hand-held miniguns and railguns in the earlier time periods. There will be over 40 unique weapon types to play with along with many different grenades and character abilities.

Minigun, Salvo Missiles, Flamethrower and Laser Cannon in action




The game can be controlled by keyboard and mouse (by default, using the keys to move and mouse to aim) or keyboard only, mouse, joystick and gamepad.

The prominent gameplay mode will be Campaign Mode, where you work your way through the story in four different time periods, collecting weapons, money and upgrades. After each level there is a non-combat headquarters section, the main feature of which is the shop. As you're a mercenary, you'll have to buy most of your equipment with the money you get paid for completing objectives. Enemies will also drop money and equipment, and many powerups can be found hidden around the levels.

Arcade Mode will be added if we have time, where you can jump straight into the action and compete for an online high-score. If we have even more time Co-Op Mode will be added, where you can play arcade mode with another person on the same computer. These might have to be saved for a patch or expansion, though.

Map Scripting

My first task in converting the game from a pretty demo (as it was before I joined Moonpod) into an actual game was to get some proper game levels up and running. I already had a basic editor, but to give the maps some action I needed to make some sort of scripting system.

Scripts are composed of two types of objects, Triggers and Events. Events are enemy spawns, powerup spawns, music cues, sound cues, anything the player observes. Events are linked to Triggers, which usually take the form of invisible boxes on the map.

When the player triggers a Trigger object (usually by stepping inside the box) all the linked Events will activate (enemies will spawn and attack the player). This gives the illusion of enemy tactics and organisation, where flanking and ambush attacks can be made easily even with simple "run at the player and shoot her" enemy AI.

Characters

This month I've been working on the four characters you'll be able to play as. Each character has their own special ability which you can develop as you play. Your other teammates will help you in many of the levels as AI characters aswell, but to see their special abilities in action you'll need to play as them. (As the characters are not yet named, I'll name them by their special skill for now)

Heavy Weapons

This character will be able to purchase and find weapon modifications for her guns. The most common and useful weapon modifications will be alternate fire modes. For example, when you buy an extra barrel mod for your shotgun, pressing alternate fire will do a more powerful but less accurate double shot. The machine gun will be equippable with a tripod, which can be deployed on the ground, making the player into a stationary turret but greatly increasing the accuracy of the machine gun.

Scientist

This character gets a hovering robot drone, which can be equipped with a miniature arsenal of guns and missiles. With your special fire key you can order it to move and attack - allowing you to surround enemies and using it to scout ahead and clear out fortified positions.

Commander

The commander has the authority to call in air support from your allies. Airstrikes, artillery shellings, paratroopers and in the future orbital laser and nuke strikes will all be available to call in at the players whim. Non-offensive support options like supply drops will also be available.

Covert Ops

The covert ops has a special utility weapon, able to hack into electronics from a short distance. It can be used to make enemy vehicles lock up, turn enemy drones against them, make nazi cyborgs brains go haywire - when it is fully upgraded the beam emitted will even be able to fry normal infantry. Out of battle it can be used to reprogram enemy security systems and other computers around the level. Hacking an ATM machine in the city will make it drop an extra cash bonus for you.