Fost - Art
Scary LightingI've been through and lit most of the existing rooms we have, and they've ended up looking quite 'moody', sometimes even pretty scary. The original idea with Mr. Robot was for it to be really fun looking and colorful, so I redid one of the rooms in an attempt to make it 'toony'. Perhaps it's just our nature, but we all prefered the edgier look. I'm pretty sure it's not the most sensible thing to pursue, because it will more than likely dent the game's broader appeal, but we were all convinced this was the look we should stick with. Anyway, for better or worse, the game's visual mood is closer to Ridley Scott's 'Alien' now than it is to Mario.
New 'Moody' Lighting (note - there's no mipmaps at this point, hence the textures looking a little rough!)
Original 'Bright' lighting
Ghost HackThe big Mr. Robot new addition is Ghost Hacking. Poo Bear came up with the idea, so I'll let him explain how it works. It's going to be a lot of work (in fact, it's pretty much a game in its own right) but it's one of those things that people seem to universally 'get'. Everyone we've mentioned it to has been really enthusiastic about the idea (even people who haven't even shown any interest in indie games before).
Ghost hacking takes place in a virtual computer world, so I needed to come up with some ideas for how it should look. I've been looking at the stuff United Game Artists did on Rez, the Johnny Mnemonic Movie (ok, it was pants, but it had some great looking cyberspace animations), and I've also had an excuse to read my copy of the Ghost In The Shell 2 comic - which features tons of cyberspace shots.
Map Screen ComponentsInitially I've been working on the components for the Ghost Hack Map screen. I may still change the look of them (I've been experimenting with a more monotone feel to the whole thing, but I'm not sure how easy it will be to reproduce in game, or even if it would be preferable.) Every surface of these models animates to some degree.
I had always thought abstract graphics would be quicker to make, but I've found there's just as much effort involved in their production. Modelling effort is much lower, but the time spent with materials and texturing tricks rises drastically. Most of the scenery in Mr. Robot shares the same material (which is good anyway, as it helps speed up rendering on slower machines) but each of the Ghost Hack objects has a minimum of 4 custom materials, many containing unique texture animation properties and multiple passes. I have a new found respect for game artists working on visually abstract games :).
Additional HUD work
Also finished the big map (above). This can be called up on a button and is pretty much the size of the screen, allowing you to get a clearer picture of what's going on. With the addition of ghost hack there is now much more to do in terms of HUD work, and we are having a rethink how it will all be implemented. The big map may be a good way to do things; if we keep it all within the 'PDA' of the big map, we can run a second HUD on there, and have the whole game running on Asimov's PDA ingame :). We'll have to see...
Goober - Programming
DirectX8 Vertex FetchingI'm still working through getting the DX8 renderer up and running, it's taking far longer than I expected :(. One nasty problem that arose, and required some changes to the common code as well as the DX8 specific code, was that of vertex fetching and vertex programs. DX9 decouples the vertex fetch and vertex program such that, provided your vertex contains all the data that the vertex program makes use of, you can bind any vertex buffer and any vertex program and it all just magically works, which is obviously really nice. DX8 kicks you in the kneecaps by insisting that when you create a vertex program you have to specify the vertex declaration to use with it. That means that a vertex program is only suitable for use with one format of vertex buffer. I made extensive use of DX9s nicely decoupled system when I first wrote the renderer, which has come back to bite me in the butt now that I have to port it all to DX8. What I've ended up doing is essentially writing my own version of the decoupling inside the vertex program management part of code. It's a reasonable design, and I think it'll be ok in use, but we'll need to wait and see just how much it increases the number of active vertex programs at any given time.
I took some time to look into ways of speeding up future developments and ways of facilitating user mods where possible. I ended up looking into Lua for high level scripting and it seems like a great fit for high level logic and general management. As a proof of concept I hooked it into our UI system, so you can create windows, buttons, etc, set up their parameters, and even write script to handle events. This all worked great, and I can definitely see us making plenty of use of it in future titles (the front end for Mr Robot is pretty much done, so we're going to stick with the old way for that). One of the really nice things about the way it's all hooked in is that the UI can export a Lua script to recreate its state. So, for example, a designer can use an interactive console to create a bunch of UI elements and set them up, then he can ask the UI to export all those objects to a script, which can be loaded later. While it's not quite as nice as a mouse driven UI for placing controls, it's an enormous improvement on the current "Edit in notepad->Save->Load game to check->Quit game->Back to notepad" system that we're using (and used for Starscape). As well as UI stuff, I'm planning on putting Lua hooks into pretty much every bit of the engine eventually. I don't think we'll write entire games in Lua, but it'll be nice to be able to prototype chunks of logic in Lua (again, with the interactive console) and, once they're working right, consider leaving as script or converting to C++ for efficiency's sake.
For more info on Lua go to lua.org and have a browse around. You could also look elsewhere on the web, there are a whole bunch of sites that carry information about Lua, the language itself and how to hook it into C/C++ apps.
Poo Bear - Programming
Ghost HackingMr. Robot has evolved into a fairly unique game, but we still thought it needed something else to make it feel like a Moonpod game. Then one day it clicked, the ship is full of robots and controlled by an omniscient computer program via a shipwide network. Robots can upload their minds to the net and then download them into new bodies so why not have Asimov battle it out in cyberspace as well as in physical space. Along his journey through the ship, Asimov will sometimes be able to pick up the 'ghosts' (electronic souls or intelligent programs) from fallen robots. These robot characters you "save" will fight alongside you jacked into the network. In real space you spend your time running from the enemy robots, but in cyber space you get to turn the tables and dish out some damage.
There's going to be a lot of work involved in making this - it's almost a game in its own right that you see via Asimov's Personal Data Assistant, but the exciting thing from a design point of view is how it will intergrate with the main game (people asked us about secrets before and this has opened up a lot of exciting opportunities to hide useful ghost hack items around the ship). You could power up your ghosts with items and Energon found in the real world or if Asimov needs a recharge he could jack in and gather Energon online. Certain obstacles in real space might be surmountable in cyberspace as the network connects every electronic item and robot on the entire ship.
I've already started work on the first part of Ghost Hack which is the map screen. When you hack a computer terminal, you'll be able to travel around a virtual component map, so I've been getting that up and running, with selectable transit points and making it all accessible from terminals in the main game.
The Ghost Hack Map screen.
One question that remains is how and when "jacking in" is presented, in days of old we would take the easy route and compartmentalize the ship into areas and place barriers between them that can only be removed via hacking in to a nearby terminal and defeating the system. That then implies a certain difficulty level which would require the player to spend some time in other battles "levelling up" his team. To do that he needs to explore his current area of the ship fully in real space and find as many pickups and energon crystals as possible whilst also hacking any secondary terminals he finds to further gain experience and gather items. The end result is the player gets to see every bit of content we made and doesn't really have a lot of choice in the matter.
Another approach that seems more in vogue these days is to let the player have a much greater say in how the game is played. One way to do that would be to have a game over condition based purely on real space platform action, then another game over condition based purely on your hacking performance. This means building different routes through the ship, perhaps by allowing Asimov to bypass sections by hacking into one bit of the network and then downloading himself out of another bit into a duplicate body. With certain critical enemies either defeated by physical means i.e. maneuvering them into an energy barrier or by hacking into their minds. Ideally you would need to do equally well at hacking and platforming to see a third "complete" ending, encouraging people to see and do everything but not forcing them. Did you save all the human crew but some of the bots were lost or did you save all the bots but some of the human crew died? Can you just jump on the head of any robot that is giving you grief, hack into it and disable it? Obviously the problem here is we are creating content that some people wont see and we also have a much larger and more complicated level structure designed to offer players choices i.e. platform jumping sections, problem solving sections, hacking sections, robot dodging, etc.
I think we'll end up with something inbetween, time is a hard mistress. ;)
Character Collision ResponseThere's a lot of jumping between platforms in Mr. Robot, so I've spent a lot of time tweaking the response to collision trying to get it just right.
So far Asimov has just been using a basic box system, and so could overhang edges even if the box was just slightly still on the edge.
There's a trade off here, you don't want to overhang edges, have it possible for the model to be pushed through walls, crates etc, and don't want to fall through gaps in the floor and get stuck.
The best way to do this is to have humanoid characters, that are taller than they are thin, and don't have bellies wider than their feet.
Mario 64 (which turned out to be the best title we researched for character collision response) works like this - mario's collision with the floor is based on a single point in the middle of his feet.
A lot of little fixes are then in place to stop mario appearing to do weird things like put his body through geometry: Mario goes flat against walls, can't walk off edges (and therefore fall straight down though geometry), and he is given a tiny kick off the edge when he runs off it, so that he never passes though a wall.
Considering it was one of the first 3D platform games ever made, Mario does an impressive job with player collision response.
Mario - no problems with falling off if you walk.
Mario pressed up against a wall.
Mr. Robot can't use some of these tricks for purely gameplay reasons (you have to be able to walk off edges in Mr. Robot), and I've spent ages trying out different tricks and ideas to get the most natural feel for Asimov. Things like using different collision volumes for his feet, or using a thin collision volume and pushing the player out of geometry when there's a problem and so on.
After I had tried just about every combination of ideas and tricks we knew of, and still not being 100% satisfied, I decided to go back to the drawing board. I first put in place more data reporting of Asimov's current status, so now I could tweak the points at which the responses kicked in. If Asimov hangs over an edge by a certain amount, I could make him topple off. Too late and it looks like he can walk on air, too early and everything feels very slippery. Now though, I could tweak it more easily, and soon found the sweet spot.
If you really try to mess things up, then there is a chance you'll see occasional odd things happen, but it's now hopefully more than acceptable. It's certainly comparable to collision responses seen in other games (even Mario can walk through geometry if you put your mind to it) and most importantly, the game won't ever break. There's a danger as developers that you'll just get used to things, but it seemed ok to us (Fost play tests things like this to death!).
My final thought in collision response is a tip for any other developer wanting to make a game with similar character issues: make your lead character as thin as possible; short, squat looking heroes with bodies much wider than their feet are probably the hardest thing to make work :D
CameraAnother problem that took far longer than I imagined was finalizing the camera. Due to the down-angled perspective view that Mr. Robot uses, we ended up having a lot of black on screen with the basic camera. I wanted to minimise that, both because it gets more art on screen and it gives the player the most clear picture of the room he/she is dealing with.
You would think working out the best way to fit as much of the room on screen as possible would be straightforward, but it turned into one of the project's toughest challenges. Lots of tiny issues conspired together to make one big pain. Things like the room sometimes being much bigger than is actually visible (to accommodate hidden objects that are masked off) or the need to keep a decent amount of visible space round Asimov so enemies don't jump in from the edges of the screen and catch the player off guard.