Poo Bear - Programming
I've been finishing off the control code for the core enemy robots and testing them in game. So we now have:
(spot the homage!)
Move around on the raised walkways taking random turns down junctions.
Move in a straight line until they hit something at which point they turn a random amount and move off again.
move in a straight line until they hit something at which point the try to do a 90degree left turn before carrying on.
If they are blocked they try a 90degree right turn and if that doesn't work they just reverse their course.
They follow the edge of whatever they are touching so they tend to move in circles around obstacles.
Move in a straight line between two obstacles.
Come straight towards the player and try to grab him.
Don't move but spin round firing out waves of energy.
A lot of time has been spent on Asimov, the player's robot. It's absolutely vital that people just enjoy running around and jumping, in a way everything else is secondary to that. In a fully 3D environment getting the player to move around and be controllable in a way that "feels" right is very difficult. There are just more possibilities of interaction than in a 2D game and you are also asking more from the player in terms of spatial awareness. Motion and control have to be smooth, engaging and offer rich feedback to the player.
Pick up any Mario game and you can feel the fluidity of the characters movements across the screen, it's smooth and easy and yet there is still skill required to really master the game. Similarly in Sonic, the game is easy to get into, but you soon realise keeping him moving at full speed and getting those hard to reach bonuses is going to take practice. A more up to date example would be the new Prince of Persia games, for all their faults there is a real sense of achievement when you finally manage to pull off a string of moves that gets you onto that high shelf. MrRobot doesn't aim anywhere near as high, but it's still vital we get people smiling as they are running around and demonstrate rewards for the practice needed to enhance skill.
It will still require a lot of play testing before I'm happy with how the game feels, but i'll have to wait until more of the game is complete. It is difficult to assess something like "control feel" without a whole string of features completed. Visual clues like shadows, lighting, clicks when a button depresses, a puff of smoke on skidding all add something to the overall feel. Without them often something will feel wrong and you can often waste time changing things and still never get it quite right. You must find a balance between waiting for enough features to be complete and not leaving something too long that is obviously wrong. A big mistake developers make is to not really finish things before moving on, you have to know how far to take something. I've often heard people say "well it isn't much fun yet, but when XYZ is done i'm sure it will feel great" and usually it still sucks even when XYZ is done.
Right now I'm working on 'Samson'; a new robot with a unique purpose, I think he is going to be great. Once that is done I can get one entire zone finished and working, which will be a very important milestone. For the first time we will be able to sit down and get a feel for the whole game. At that point you can make decisions about difficulty, how long the game will take to play, what to put in the rest of the game, etc. It's a big step closer to being finished :)
Goober - Programming
Lighting, file versioning and loading screens
I've been working on getting the lighting system in place for Mr Robot. Essentially, the approach is to code everything in vertex shaders, and not really worry about it. The scenes for Mr Robot aren't terribly complex, and don't usually contain more than a few light sources, so we can get away with a very simple straightforward approach.
My first step was to work out how we wanted to do lighting. Originally I wanted to implement a system that would just do diffuse vertex lighting, then the specular component would be added on top by way of a dynamically generated sphere map. The thinking behind this was that the specular highlights would be smoother than just doing the calculations per-vertex. The downside was the time it took per frame to recalculate the sphere map. The problem is that the sphere map is only correct for any particular position, once the light receiver moves the sphere map needs to be updated. We could opt to update the map every 'n' frames (or preferably, ping-pong between two sphere maps, updating the next one by x% each frame to amortize the cost over a number of frames). Another idea is to actually sit down and optimize the algorithm used from O(n^x), where x is the number of lights (I think that's right for big-O notation anyway). Any solution requires time to implement though, and we are unsure of how it'll turn out. This is where a decision needs to be made, and the decision was that my time would be better spent on other, more important, features. At some point I'll probably revisit this idea, if only because I hate to leave problems like this half-solved. If it works out then we could retrofit it to Mr Robot in a patch, or use it in another title. The lesson here is to be pragmatic about such things, it might seem like a cool idea, but if it doesn't help the project significantly then you should think about whether it should be in there at all.
So once I'd decided what not to do, I started looking at the lighting, and for some inexplicable reason it was just plain wrong, and I couldn't work out why. Lots of head scratching later I discovered that the normals in the model files were in a different coordinate system to the one the game uses. This is a real pain because those normals need to be right, but I don't want to burden Fost with additional work by asking him to export models time and again. Thankfully I made sure to include a version number in the model file. So now the loader checks the version number, if it's an early version the loader will fix up the normals during load. We'll probably end up re-exporting all models for the final build but, for now, we can ignore the problem and get on with getting things done. The lesson here is to include version numbers in your file formats; the data will likely change a few times before becoming stable, so you need to include some way of avoiding getting in everyone's way and allowing development to continue with as little hindrance as possible.
Another thing I've done is to add hooks into the file system to allow us to show a progress bar during the initial loading phase. I'd wanted to do this for Starscape, but the opportunity never arose. I like having a progress bar, even if it might be a little inaccurate, because it indicates to the user that something is happening, and gives them an (possibly vague) idea of how long it will take. So now we have a fairly generic way of adding a progress bar to Mr Robot and future projects.
Some pics, just for fun:
Here's a first go at some lighting code. This is actually doing the lighting in C code and passing the results down to the graphics API in the diffuse vertex color. This was just for me to clarify how I wanted the lighting to work before I went ahead and implemented it in a vertex shader (debugging vertex shaders is a pain ;))
Here's a view of the editor, showing placement of lights. This is due to change because Fost has been complaining that the wireframe spheres obstruct his view (fair comment really :)).
Here's an in game view, just for fun. You may notice a bit of a bug to do with which objects are affected by which lights, but that should be fixed soon.
Fost - Art
I've been texturing up the remainder of the initial enemy set. Poo Bear has been coming up with new ideas for enemies already that we might want to try out, but we now have a fairly complete set that make for interesting combinations.
Stalker's have one purpose: your destruction!
They will take the fastest path to you
(and absolutely will not stop until you are dead, etc...)
Guardians orbit geometry.
Final Result reminds me of Johnny 5
from Short Circuit
Patrollers turn left if they encounter an obstacle (or right if that path is blocked)
Grid Runners patrol walkways and are prone to random directional decisions based on available paths.
Maniacs are hard to predict;
changing to a random tangent on each encounter.
Designing textures - breaking "Texture artist's block"
All artists are different and it's good to know your limitations and work on them. My big issue is the time I spend designing anything. The best part of my job is at the end of the day I get to say 'I made killer robots today' - and in an odd way that's the root of the problem - I love what I'm doing so much that I want everything to be perfect. I'm quite fast at modelling-mapping and texturing a model, but I really labour of the design process. This extends to everything - I've done some work to speed up my model design processes, but I noticed another big bottleneck is textures. I've tended to make them up on the spot once I get to them, which usually results in lots of mistakes. Needing to re-uv map bits to accommodate new ideas, and many instances of "texture artist's block" where I've backed myself into a corner.
So, I came up with a little plan:
Model and UV map, then take a screengrab from opposing angles like so:
I can then mess around with this in photoshop to my heart's content - making sure all detail line work will match up, and that I'm happy with the final result. Since I'm doing it to convince myself (no annoying producer to worry about :) ) it can be as messy and quick as I like; I'm essentially just doodling:
It's worked far better than I expected; with one change in the plan - It's best to do the doodle before UV mapping incase any special mapping considerations crop up. I've saved an entire day for each of the character models - a fantastic result!
This month we also took delivery of 100 Mr. Robot mousemats.
They are completely cool (I'd want one even if I didn't work here!) I keep staring at the one on my desk - it's a great feeling to have something you've made sat on your desk all day - even if it is just a mousepad.
We haven't decided what to do with them yet - some are earmarked for friends and family, and we have sent some to our forum regulars as a thankyou for keeping our spirits up over the past year. After that, we'll probably give a few away as competition prizes to some websites, and then we are going to sort out some kind of competition plan for Starscape high scores.
Incidentally, if anyone in the UK is looking for somewhere to have some mousemats printed I would definitely recommend promotenow. Reasonable prices even on short runs (like the 100 we had made) great quality (most importantly - the print was perfect both in colour and detail) and really fast turn around.
Knocked up a wallpaper of that too:1600X1200