Posted: Thu Dec 22, 2005 6:50 pm Post subject: Feb-06: Core Gameplay Complete
"February" - what trendy people are calling "January" this year... -due to the perpetual confusion (and constant nagging ) we are now naming the diaries after the month they are written in. So this is the February dev diary, which is about all the work we've been doing in January, which now never happened, or something...
Set Design - final touches
Like a human tube of polyfilla, I've just been concentrating on filling in all the holes in the scenery objects list. As Poo Bear makes rooms, he makes a note for me of anything that he needs. For example - we've been using Storage area doors in the cryo area, so I've made some shiny new doors for cryo (left). I've also been going through the rooms and adding a few little unique bits of scenery - there's more than 200 static (i.e. not counting robots, items or anything that can be moved around) scenery objects in the game now, so it doesn't look too repetitive, but anything that helps break up the look of the backdrops adds that little bit extra to the overall impact of the game's look. Lighting is also proving to be a great way to alter the look of the rooms.
Anyway, enough talk! This month I'm just going to fire scenery artwork and room pictures at you.
I removed the insignia from the shuttle, so I could add it back in using an overlay object. This means I can have a different insignia decal for each shuttle- just another little thing I think is nice to do so that each room in the game world has small touchness that make it unique.
Fat pipes make great dividers for the cryo section.
Just a corridor, but I really love the way the cryo walls pick out light - cryo rooms are the most fun when playing with lighting setups.
Samson sized service corridor.
Top Tips!
This month's mini development tip - many applications have a hidden away option to increase the number of files in the recent file history list. I've been through all the apps I use on a regular basis setting that value to the maximum. My memory has never been very good, and I waste a lot of time trying to remember where I left things on the hard-drive so this helps enormously. In particular with the text editor I use for editing shader files/objects lists/config files etc this has been a minor triumph of technology over memory loss
Locker Room
It's great when you can re-use existing systems. This locker model uses the same game systems as the doors. The front is using the door texture scrolling mechanism to 'roll up' like a shutter. Items can be picked up by searching lockers througout the game.
Magic Pockets Started work on the inventory items - things Asimov can pick up in the game. There's going to be a ton of items once we get deeper into ghost hack (you can pick up special programs and hacking tools to use in ghost hack). Each item needs an icon that shows up in your inventory, and also I'm adding a 3D model so it can be left on the floor - these aren't really necessary, as everything is picked up in lockers at the moment, but it means the game won't break if someone tries to put an item on the floor. There's already a growing list of ways you can easily break the game because of things you do in the editor, so I'm trying not to so anything that makes the list even longer. We'll have to fix any of those problems before we think the editor can be released, so a little bit of work now is another step towards the editor being public usable.
Secret Squirrel
Quite a bit of work has being going into the finale of Mr. Robot this month, I did have some images of HEL and animation showing him in action, but we decided we should pull them - we've gotten used to being open about what's going into the game, but we should really leave a few surprises in for you! HEL is semi-procedurally animated - I produce an animated control mesh, and sets of objects, and Poo Bear glues it all together with code. I've also been doing a set of scenery objects for the 'Mind Core' section of the ship where the action comes to a head. Again, we want to hold much of that back, but here's the door object I made.
Needless to say, it was a complete and utter nightmare getting this to work It uses the existing door code with an edited shader - so Poo Bear doesn't have to do any work. The shader takes the door opening and closing values and uses them for the texture rotation after scaling them to suitable values. The iris door has 9 blades which I lined after finding a diagram in a technical manual for repairing cameras! I've wanted to make a door like this ever since I saw Dallas crawling around in those air ducts in Alien
Last edited by Fost on Wed Feb 15, 2006 1:45 am; edited 32 times in total
Joined: 14 Oct 2002 Posts: 4121 Location: Sheffield, UK
Posted: Wed Jan 04, 2006 5:19 pm Post subject:
Formula Parser
I've talked previously about the power of the LUA scripting language, but sometimes you don't really need that level of sophistication or the program overhead of setting a full LUA instance up in memory. One obvious example is when you are filling out an initialization file for a game entity like the ghost hack enemies. This simple text file contains default starting values for different bad guys, things like name, model to use, animation lists, strength, etc. Some things however, are better expressed as a formula, see below for actual MrRobot examples:
Code:
key value
fortitude_formula val = 2 + (level / 2);
energy_inc_formula val = 1 + ((0.5 * die) -2);
To make the game use this formula I could have created a LUA instance and executed it that way but I already had a simple function parser on hand that had less overhead and was cleaner to setup.
Done this way the game can pull these formulas out of the initialization files, save them as a small text string and then when needed they are executed directly via the mini formula parser. The words die, level and val are special keywords the parser understands. Without this kind of functionality a game will become littered with hidden magic formulas that can have a major impact on how a game plays. By exposing them in the initialization files a non-programmer can change them as necessary and we don't need to dig through source code to find them or recompile the game when they change. Obviously there is an efficiency overhead associated with doing this, but if it doesn't impact on framerate then its definitely the best approach. This could have been done in Lua almost as easily, I just want to highlight the power and flexibility of scripting languages in general and data driven design techniques specifically.
Download Size
Even in these days of broadband, download size is very important. I think the USA is on track for 65% broadband coverage in the next year or two. So there are a lot of modem users still out there. Even with broadband, file size can still put off people who are browsing and aren't necessarily hunting for your game.
When you look at the size of your game installer you usually find a very high proportion of that space is taken up by artwork. It's a rule of thumb, but most textures are often around 256x256 pixels, so they look nice and crisp at fairly high resolutions like 1025x768. Each pixel has an 8 bit red, green, blue and alpha component. We don't always need the alpha part, it is used by the hardware to control transparent portions of the image. So our example texture will take up 262,144 bytes on disk. MrRobot has about 300 textures currently, which is roughly 75MB. Using something like winzip we can get that down to about 15MB with no loss of quality, a 5 to 1 compression. Now instead of saving the images at full quality (using the tga format) we can use a lossy format like jpg. By saving the image out as a jpg you are pre-compressing it and the harder you do it the worse the image looks. As the compression system is vaguely similar to winzip anyway, then you haven't saved much as winzip wont be able to make a jpg much smaller if at all. The only benefit is you can set the compression level per image by hand, so some might be forced smaller without suffering loss of image quality. So you might get up to 6 to 1, but probably with some image quality issues.
An evolution of the jpg format that isn't widely used is j2k, which means jpeg 2000. This system is far superior to jpg and can easily compress our source artwork at a 10 to 1 ratio, from 75MB to 7.5MB with little to no perceived loss of quality in most images. What I normally do is compress everything at 10:1 and then do a run through of all artwork at the end of the project lowering the compression on the 1-2% of images that are highly complex and suffer artifacts.
The power of j2k has a downside which is extremely slow encode and decode times due to the highly complex nature of the algorithms being used. Probably the oldest freely downloadable j2k library is jasper and the creator did a great service by releasing it. The only problem is, speed wasn't a priority in its development and it is very slow.
Encoding time doesn't really matter, because we encode the images once when building the installer. It's decode time that is vital, the image must be decoded back into a flat 32bit image so the graphics card can load it. Or if you're very clever then one of DirectX's compressed formats like DXT3.
All is not lost. A new decoder codec saves the day by being about 40x faster than jasper and unlike all the other big companies making decoders it doesn't cost $10k I was also shocked by how easy it was to use compared to jasper, just a couple of lines of code and away it went.
You can see an uncompressed (1 meg PNG) image comparison by clicking below :
The new codec is so fast we don't need to have a decompression on install application. Starscape used to install and then launch a small app that crunched through all the images and it took minutes on low spec hardware. The next version of Starscape will hopefully have a rewritten decompressor app that should just take seconds. I think it is worth keeping that post-install decompression app as Starscape is meant to run on very low spec hardware and has a huge amount of artwork. MrRobot being a fully 3d game, is far more efficient with regards to texture space and also needs a higher minimum spec machine to run. Therefore I'm probably going to leave the textures in their j2k format and decompress them on the fly when loaded. Initial tests showed this made the one-off game start load go from 9sec to 13sec which I think is fine. Further testing will be needed of course, but I think it's worth a slightly slower load to make the install process faster and simpler.
Early Usability Testing
The core game (everything but ghost hack) has now reached a point where some basic usability testing can come in handy. We have a small test group of computer illiterates that we find handy for this kind of thing (parents or grandparents are usually very good depending on their familiarity with computers - obviously, some basic knowledge is required.)
We then sit them in front of the game, and let them go. The important thing is not to guide them. Reinforce in advance that this is not a test of them, but a test of the game, and there are no wrong answers - otherwise you end up with them being overly cautious and not wanting to feel stupid trying things. Then just note down what they do, what buttons they click on first etc. You can even video the whole thing if you have a camera handy. If you come across an interface problem, or a bug, then you can just help them past that point and explain that it's a problem with the game, and carry on.
This initial pass has highlighted some basic issues with the tutorial - mainly a couple of points where the player can become lost, or miss something like a door that has been opened for them. Not too bad, and pretty easy to rectify. It's nice to get a lot of things out of the way before beta.
One thing that has been suprisingly successful is the camera. A couple of people in the group were originally chosen to test Starscape because of their inability to play 3D games. It seems that the fixed camera, whilst obviously a choice we made to make development easier on ourselves, also helps people with atrocious spatial awareness make sense of their in game surroundings. They do have some initial trouble with the 'isometrically' lined up controls - 'up' being 'up-right', but they soon get over that, and it's amusing to see people who have never been able to play Mario 64 jumping around like rabbits after 5 minutes with Mr. Robot. When we get nearer release we will do a larger beta test with people randomly selected from those who bought Starscape. With a large beta using players all over the Internet it is important to have squashed as many bugs as you can beforehand. When people are not actually in the room with you it is a lot harder to properly analyse their input.
Procedurally Animated Models (sort of...)
The game's finale takes place inside the 'mindcore', a set of rooms surrounding the ship's supercomputer: HEL. In designing what HEL should look like, we came up with the idea of an animated head built from lots of small cubes. The vertex data to do that would be huge (we estimated 30 meg+ just for HEL's animations!) so we came up with another idea: Fost creates an animated, low poly 'control mesh'. We then read this in and build a representation of it from lots of cubes. the entire thing is then shunted off to a dynamically allocated vertex buffer. It looks pretty nice, but you'll have to take my word for it, as we've made the decision to leave most of the mindcore art as a surprise for everyone Wink
Super Powered Batch Files
When preparing the installer we need to pull in exactly the right files from all over the development machine while also applying any special processing like image compression. This is more difficult than it sounds as the game probably has ~700 different files and the development system probably has double that in temporary, debugger, build files. With Starscape this was done using some hand written instructions (which were then lost) and some horrible windows batch files.
Once again the power of Lua comes to the rescue, if you download Lua you'll also get a standalone exe that can load lua text files and execute them. This means your batchfiles suddenly have all the power and sophistication of a programming language. I didn't end up using the interpreter that comes with lua as I wanted to add a few extra functions to do some specific things. Very easy to do, just code them up in C++, tell lua about them, build a new exe and the lua textfiles can then refer to these functions by name and pass data around as if they were built into the language. You can do everything a batch file can (as far as I know) and a huge amount more and the files are infinitely easier to read.
Last edited by Poo Bear on Wed Feb 15, 2006 6:09 pm; edited 6 times in total
Joined: 08 Nov 2005 Posts: 556 Location: Bergen, Norway
Posted: Wed Feb 15, 2006 8:34 pm Post subject:
Ho, awesome. I actually made a little jump when I saw Samson. He looks great in the game. And the pick-up objects look really nice, too. All up to your typical standards, Fost.
I'd like to make a comment about Poo's post, but to be honest, I didn't understand a word of it.
I've been dying to ask you something.
Now that you've been working on Mr. Robot (that little, 6-month project you started all that time ago. ) for this long, you've no doubt learned a lot. Are there any particular things you've learned during this development that you'll definitely be bringing on to your next games like Battlescape etc?
Therefore I'm probably going to leave the textures in their j2k format and decompress them on the fly when loaded. Initial tests showed this made the one-off game start load go from 9sec to 13sec which I think is fine. Further testing will be needed of course, but I think it's worth a slightly slower load to make the install process faster and simpler.
What about an installer option to decompress the files permanently in order to reduce the loading time? Then again, if the effects remain as insignificant as you wrote, it should not be necessary on a modern system...
What about an installer option to decompress the files permanently in order to reduce the loading time? Then again, if the effects remain as insignificant as you wrote, it should not be necessary on a modern system...
Bear in mind that because we want to keep our games nicely optimised so they work well on older systems, we tend not to upgrade our devlopment computers very quickly. The figures quoted are from Athlon 2500s.
Also, texture sizes are using development textures (which I always make far bigger than necessary, then scale down to optimal size at the last minute , so it's likely texture size will be 1/4 of what it is now. I'm pretty sure reasonably proced current hardware, you are looking at below 1 second impact on the load time...
Joined: 25 Nov 2004 Posts: 480 Location: Karlsruhe, Germany
Posted: Wed Feb 15, 2006 9:24 pm Post subject:
Fost wrote:
Also, texture sizes are using development textures (which I always make far bigger than necessary, then scale down to optimal size at the last minute Smile, so it's likely texture size will be 1/4 of what it is now. I'm pretty sure reasonably proced current hardware, you are looking at below 1 second impact on the load time...
I originally wanted to also complain about the idea of decompressing the texture data during runtime.
If it's true what you are saying... that the impact is below 1 second on current hardware, then this is all right for me, though. But everything above 2 seconds of decompression time really should be done during install. Long launch times do annoy me. Long install times don't.
Poo Bear wrote:
When we get nearer release we will do a larger beta test with people randomly selected from those who bought Starscape.
I really should buy Starscape soon, I guess!
By the way... Is there any plans to release a game bundle containing Starscape and Mr. Robot? (At least for the CD case versions.) For a little bit of a discount, of course.
Once again it was lots of fun to read about your progress and technical views on Mr. Robot!
(Really looking forward to see all this in action!)
If it's true what you are saying... that the impact is below 1 second on current hardware, then this is all right for me, though. But everything above 2 seconds of decompression time really should be done during install. Long launch times do annoy me. Long install times don't.
Texture load time in Mr. Robot shouldn't be too bad - it's the model data, particularly from animated models, that is the biggest chunk of time loading. Starscape might be another matter - there's tons of texture data (all the rotations frames for thos ships add up!), and it currently works suprisingly well on hardware that should really be laid to rest. We'll need to do more testing there. Mr. Robot I'm very confident won't slow down by any amount where anyone could even tell the difference.
Slyh wrote:
By the way... Is there any plans to release a game bundle containing Starscape and Mr. Robot? (At least for the CD case versions.) For a little bit of a discount, of course.
This will be the case for everything once we have more than one game - the buy page will also offer you all the additional games at a discount if you buy in one go. Anyone who bought Starscape already shouldn't worry - I'm also working on a 'coupon code' system, so we'll be able to send out a discount coupon for Mr. Robot to everyone who bought Starscape. Not sure of the details yet - but we mainly wanted to make sure that anyone who had already supported us didn't feel new customers were getting a better deal. Just make sure your email addresses are up to date, and you've elected to receive our newsletter, otherwise we can't legally (or ethically for that matter) mail you
Well icarus, it's prolly because both the samson corridor and the drive room for event horizon have the same sort of spikey projections.
What I'm realy curious about is if have a function in game (besides looking uber cool,) that hallway does look rater dangerous.
both the samson corridor and the drive room for event horizon have the same sort of spikey projections.
You know - I never made that connection! It would be nice to get some rooms looking close to how the ones in event Horizon looked. that was really freaky up until the end when they turned all the lights on...
Code_Crank_Call wrote:
What I'm realy curious about is if have a function in game
It does, but it would be no fun when you play the room if I told you
imadoki wrote:
Question: How long did you guys work on Starscape?
Err, I think it was 7-8 months, but then we did about another 3 months work on it after release.
imadoki wrote:
Another question: How long have you been working on Mr. Robot?
Eek, if I have to work that out, I'll get pretty depressed!
There was a month's research into it a long time back, followed by 3 months full on development as a prototype, at which point we decided it was a great idea, but we wanted to do it with a more mature 3D engine (at this point, we were still thinking of making another game using the Starscape engine). Then, at the point we halted Battlescape, to now, it's been 13 months. So - 17 months in total , and we still have quite a few to get through just to finish ghost hack and start testing
Looking back, it would have saved a lot of time to use an open source 3D engine, but there weren't any around we liked at the time.
I sometimes wonder if we shouldn't have called the game 'Duke Robo Forever'...
both the samson corridor and the drive room for event horizon have the same sort of spikey projections.
You know - I never made that connection! It would be nice to get some rooms looking close to how the ones in event Horizon looked. that was really freaky up until the end when they turned all the lights on...
the spiky projections wer just weird
i know they gave some sort of explanation for them but i don't rember it
one thing i didn't like about that movie was the captan went to hell in the end
its one thing for the hero to die, but do they have to send him strait to hell
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
) we are now naming the diaries after the month they are written in. So this is the February dev diary, which is about all the work we've been doing in January, which now never happened, or something... 
Started work on the inventory items - things Asimov can pick up in the game. There's going to be a ton of items once we get deeper into ghost hack (you can pick up special programs and hacking tools to use in ghost hack). Each item needs an icon that shows up in your inventory, and also I'm adding a 3D model so it can be left on the floor - these aren't really necessary, as everything is picked up in lockers at the moment, but it means the game won't break if someone tries to put an item on the floor. There's already a growing list of ways you can easily break the game because of things you do in the editor, so I'm trying not to so anything that makes the list even longer. We'll have to fix any of those problems before we think the editor can be released, so a little bit of work now is another step towards the editor being public usable.
) for this long, you've no doubt learned a lot. Are there any particular things you've learned during this development that you'll definitely be bringing on to your next games like Battlescape etc?
