About this blog
Moonpod Development Diaries.
Or 'What happened after we left the mainstream, and how we survived'
Entries in this blog
Fost - Mr. Robot Art
It's Done! Well, the game is now finished! (you can grab the demo here ). It's been so long in development, that it hasn't really sunk in yet. It's a great feeling - the only way I could describe it is like when you pass your driving test and get to drive around on your own for the first time with a big beaming grin on your face. :D
This is probably the last diary we'll make for a while, although we might consider starting them up again once our next project is under way.
Launch Plan The first thing we've done is email all our existing customers. From start to finish, this process took nearly a week of constant work by the email server. Before anyone thinks we have millions of Starscape customers, we worked out that this was because of our outgoing email scanner on the server which is taking a while to individually scan each message.
We've tried to make a newsletter with some fun things in it by adding a few silly facts and a newspaper style comic. If you missed it, you can read it online here:
Around 15% of the emails we sent out bounce. I'd expected it to be much higher since some of the email addresses spanned back almost as far as 4 years, but it seems many of them have been kept up to date. Interestingly, the most common places the newsletter has bounced from are universities (makes sense as people move on) and mainstream game development companies. The latter shows that we get a surprising number of sales from people working at games companies (I can't really think why that might be), and that people at games companies move around a hell of a lot!
No idea yet how many people who liked and bought Starscape will also buy Mr. Robot. They are both two very different games, so might appeal to different crowds. Maybe we'll just end up with more different customers on our site.
Right now, the editor documentation is pretty sparse, and there's a lot that needs to be added. My ongoing task is to keep updating this with a full reference, tutorials and examples. We intend to support adventure authors as much as we can well into the future and so there's a lot to do just to help get everybody up to speed with the minimal effort on their part.
Partly as an example for adventure authors and partly as an extra for everyone who's bought Mr. Robot, I'm working on a micro adventure that will be available on the Mr. Robot content sharing system.
On accidentally falling into a sub-level of Cryogenics, you discover a trapped nanomek named Huey. I always thought the nanomek rooms were fun in the same way ChuChu Rocket and Lemmings are, so this adventure concentrates on them. They'll probably be a bit harder than the existing rooms though, so the despite the fact there's only 5 rooms at the moment they should prove to be a challenging diversion.
Since you get all the source files, they should illustrate some of the basics of lua scripting adventures - launching conversation, opening and closing doors and detecting a robot's position.
One of the WIP rooms in the 'Save Huey' adventure - coming soon to the Mr. Robot content network :)
Prototyping Other than that, I'm making a few inroads into our protyping work. I have a couple of games that can be investigated with mockup videos, and I've got some collision artwork to make for the other 'working' prototypes.
Poo Bear - Mr. Robot Programming
Can anything else go wrong? We had a fun December, here's a list of everything that went wrong:
My PC exploded. One minute everything was working fine, there was a pop and then the PC wouldn't switch on. Almost everything in it was toasted - graphics card, motherboard, power supply - even the CD-ROM was dead. The hard drive was the only thing that worked, which was lucky, because it was the only thing I really cared about.
An error in the lua script that builds the installer took out the entire installer build directory, which then took 3 days to recreate.
Nick fell down the stairs to his loft, landing on his head. Luckily, he was carrying his removable hard drive at the time (the one which contains all his work) which broke his fall :( It then promptly stopped working. Thankfully, it was just the case circuitry that seemed to be dead, as we lifted the hard drive out and plugged it into an internal IDE slot and it worked.
A short power cut in Sheffield caused a power surge that burnt out our router. We were uploading an updated purchase page at the time and only half of it got uploaded, stopping Starscape sales for a day and a half.
I then contracted the Flu. Not the kind of flu you have when you want to take a day off work, but the kind where it's difficult to stay out of bed for more than 2 hours a day.
Nick then contracted some form Deli Belly (the 'both ends' kind :shock: ), which got to the point where he was considering working off a laptop whilst sat on the loo.
Happy shopper ran out of value cola due to the Christmas demand.
The cocktail sticks that were holding our eyes open finally snapped.
So, what next? We've yet to make a decision on our next game, but there's plenty of time to make our minds up. Right now, I'm working on the Mr. Robot point release which should address any outstanding bugs. After that, we have the Starscape 1.6 update in the works, and then our Mr. Robot expansion will get under way. In the meantime, we are prototyping a couple of ideas and I'm sure one of them will end up getting more attention than the others, and become the game we really want to make next.
It's too early to talk about any of them, but here's a couple of teaser pictures of the prototypes we have in progress:
Fost - Mr. Robot Art
It Talks! We've always been hoping to find time to voice Mr. Robot (and Starscape for that matter), although we knew it was probably not the best idea for version 1 of any indie game. There's reams of dialogue in Mr. Robot and whilst we have employed the services of a writer, that has been for conceptual story writing. we have still been writing the final text, which means mistakes are inevitable. Thankfully we have a few grammar experts in the beta who have been correcting anything they come across, but even so, the final script is going to be available late in the day. There's also the fact that any planned expansions are also likely to add to the dialogue and that you often need to rewrite text that's fine when read but doesn't quite 'flow' when spoken.
All this means it makes sense to get dialogue done for an indie game later in the day. I'm hoping to develop working relationships with several voice over artists so that if we release any expansions it won't be too much trouble to get any additional dialogue done for them that matches the rest of the game.
Even so, there was no reason not to voice the intro. We rewrote it with suggestions from Enzo (mainly cutting it down and simplifying things, and also introducing a 'rhythm' to the sentences.) After searching through voice artist websites and auditioning their show reels (for far longer than I had intended!) I found Rebecca Gethings. Rebecca was really great to work with - very fast turnaround, and great results. Hopefully we'll be able to get the rest of the game voiced at some point with the same ease.
Listen to the intro:Mr.Robot-Intro.mp3
So, you wanna buy anything else but Starscape on moonpod.com? Tough ****! A lot of what I'm doing this month is testing the website with more than one game live for sales. Basically, the site was originally built around selling one product (Starscape) and hardly any of it works when we have two live products. Every time I fix one thing, it unearths another problem. Like the fact that all the emails explain how to unlock the game using the Starscape method, but we've now made this easier so that information is completely wrong :( Main problem is that the script which is called by the payment system doesn't work at all and it's not much fun testing it!
Where did all the sounds go? One of the testers pointed out that lots of the sound effects are repeated. I checked and discovered that a large proportion of the installer was taken up with unassigned sound effects. Somewhere along the way, we've either pasted over or forgotten about wiring these effects up :roll: So I've had to spend quite a lot of time re-assigning them all. During development, you get used to so many things in the game that you don't even notice really obvious stuff like this. Having a fresh set of eyes to look at the game really is a boon.
I ? Intel Extreme One of the purely technical issues we've come across has been related to Intel extreme hardware. Well, you could argue the problem is my own untidy vertex shader writing :) It seems nvidia and ati drivers are a little more forgiving of mistakes :), whereas Intel drivers just bomb out instead :( Any time the vertex shader requests something that isn't in the model like vertex colours, normals or a set of uvs, intel extremes become extremely unhappy. They either don't display that pass of the shader, or more often bomb out the game. It's a pretty easy mistake to make when copying and pasting parts between shaders. Usually I end up requesting something and then not using it in the shader, but I've been in and optimised anything that is unnecessary in the model.
Our in house tester has now been chained to a PC with an Intel extreme integrated graphics chipset, so we seem to have caught all these problems. I don't think mainstream games companies even test on those kinds of graphics boards any more, but since they are quite capable cards as long as you don't want to play the latest games. There's no reason not to support them if you can.
Poo Bear - Mr. Robot Programming
Voice Compression Now that we have a voice file, I thought I would try to work out how much space getting the game fully voiced would take up (something we may be doing in the future). The intro is roughly 1 minute, and sounds acceptable in ogg format at 256k. This is achieved by down sampling to 22kHzand using an ogg quality compression level of 0. We also tried -1 quality level, but it was a little too 'scratchy' sounding. Based on that file size, I estimate that getting the whole game voiced would likely double the size of the game data :shock: That's even a conservative estimate!
Looking around, most of the voice compression formats seem to be geared at telephony. They can go really low, but they seem to prioritise legibility over quality, even when you use their top quality settings.
I've been testing the speex speech compression codec. The main issue I've had is some scratchy noise in any hiss sounds (like you get when words end in 's'). Oddly, the wideband mode seemed to fair better than the ultra mode. Also, running the voice through high pass filters beforehand helps enormously. I managed to reduce the 1 minute of speech down to around 69k (compared to a 256k ogg). At this size, it would be usable with background music, although I still don't think it is ideal. It should be noted that speex is still in beta though. Some more experimentation to be done here...
Here's an example speex file at 100k:
You can play it back with a media player like foobar2000
bugs The Beta is going really well; about as many bugs as I expected. We seem to have been pretty lucky with the people who've joined - the quality of feedback is on par with that I've had from dedicated test teams in the past when we worked on xbox titles. Much better in fact than other betas I've been involved in. I'm not sure why this is other than we've just been really lucky. Main bulk of bugs are Nick's aforementioned Intel extreme shader issues, alt-tabbing problems and lots of game play related bugs. Things that happen in the lua scripts for each room and end up going haywire if the player manages to do things out of (expected) sequence being the most common. Nothing major that I didn't expect. It's also great to get all the little grammar issues sorted out before release (you may recall the drunken proof-reading Starscape 1.0 fiasco :) ).
Feedback The other side of beta is getting general feedback on the game itself. Eventually everyone will start telling you what's wrong with things as they settle into play. I also like to make a note of the very first reactions the game gets - these usually let you gauge how well the game will eventually be received (before testers inevitably find things they don't like :) ). So far first reactions have all been positive, which is a tremendous weight off our minds. Of course, now everybody has gotten over that, we are getting into the valuable gameplay feedback. There has been some great discussion about balancing out the ghost hack section. In the main, this has worked OK, but testing responses and ideas are allowing us to make the best use of what we have, so the final result should be a nicely honed experience.
Hard as Nails The 'reality' sections of the game have had a different set of issues; almost all being related to parts of the game being insanely difficult :) We've discovered that people with experience of the old-school isometric platformers are now pretty rare, and so without that vocabulary of actions built into your mindset, even just jumping over a short space can be pretty hard. Things Nick and I can almost do blindfold turn out to be difficult.
Obviously the market has moved on, but it's funny to think that one of our over-riding design goals with the game was to make sure it didn't have the punishing difficulty that the 8-bit era iso-platformers had. Despite sticking to that rule, people are still finding it pretty hard. At one point in development Nick made some nanomek rooms that I decided were too difficult to use. Nick is resurrecting them as a downloadable mini-adventure, but I'm wondering now if anyone will actually be able complete it!
Depth Perception One of the initial problems many people face is depth perception. The fixed 3D camera we have been using has meant that rooms rarely scroll (the camera tried to keep as much of the room in screen as possible). This led to M.C. Escher like visual problems where the player is confused by the optical illusion and has trouble working out where planes meet, or even what orientation they are in. You can possibly see what I mean in this room:
The problems tend to go away as the player familiarises themselves with the room, and it's certainly nowhere near as bad as any of the old 2D isometric games (3D perspective stops you having real problems with repeated patterns!) I thought we should do as much as we can though and so to combat the issue we've done a few things. First, we picked out some of the worst offenders - it's only a subset of rooms that really cause a problem. Nick then went in a relit them where possible. Having light variation between levels and across the space breaks it up into distinct zones. I've also tried to add supporting columns to any of the free-floating platforms. This adds a visual queue linking a walkway to a floor so you can work out its horizontal position. I've also tried to where possible to move anything upright towards the back of the room. Building steps up towards the camera rather than away from it is the most common way to cause confusion.
Lastly, I've changed the camera so that it is loosely locked to the player, this causes a continual shift in perspective so you can see the various layers of the room move over each other a tiny amount, which compensates for not having stereoscopic 3D. Nick says he continually rotates the view a tiny amount left and right whilst making models, which gives him a good sense of the object in 3D. The same principal should be in effect now with the new camera. Whilst I was not too happy to change the camera in beta ( a sure-fire way to introduce yet more bugs!), it seemed that this would help the most. Initial feedback from on-site testers has backed this up, although the rest of the beta team haven't commented yet.
Tutorial In many ways, the beta group also acts as a focus group. This is especially the case when testing the tutorial. The aim is to get across some of the more difficult concepts (such as ghost hacking) with the minimum of effort for the player. The hardest thing to achieve is to teach someone the game without them feeling like they have been playing through a tutorial. Even getting close to that ideal is something to be proud of. During development it becomes impossible to 'unlearn' the methods you develop to play the game, so new users find themselves stuck in ways you haven't thought of. Thanks to the herculean efforts of the beta team, Mr. Robot's tutorial is already way better than it was when we first implemented it.
Farming Another interesting observation during beta has been the number of people exploiting the game to eke out some more fun in the demo part! For quite a while, we restricted beta users to the demo section to make sure everything was fully working in locked mode. They started to re-hack lots of the ghost maps to harvest out as much energon (basic 'currency' used in ghost hacking) as they could. Sometimes they discovered exploits along the way and managed to obtain high level ghost hacking items and attain high xp levels. Restricting play has to be done very carefully as people appreciate freedom, but you can't let them go too far too fast.
It reminds me of the stories of MMORPG development. Where online game developers have gold farmers, we've got energon farmers! :) I think it would be the tip of the iceberg of problems if we ever develop an MMORPG.
Fost - Mr. Robot Art
Final trailer is now out:
watch the streaming version
or a separate High Res Downloadable version (23 meg - mpeg)
It's always good fun putting trailers together. I also built a streaming flash player for it based around this php streaming method, so we should be able to use streaming video more on our website if it works ok.
Your rank is: ZX Spectrum Mark had the great idea of ranking player scores by historical computers, so there's a little computer icon associated with your profile in game. Hopefully there won't be too many arguments about whether one computer should be a higher rank than another :) the scary thing is, that Mark has programmed most of these computers, and I've used many of the ones that actually had graphical displays to draw sprites or render images. Thankfully the days of trying to render a robot model and running out of memory because you only had 512k are long gone :)
Scoring is based on achieving various objectives, and you get a little medal for each:
The rest of this month I've been putting in place further front end icons (ghost hack has a lot of requirements) and working on help file art etc. It all adds up to make the finishing process not just a case of sticking a game on the website and seeing what happens.
Poo Bear - Mr. Robot Programming
Happy Birthday to us. Moonpod is 4 this month :) It's been a long slog for us, and we've had problems along the way that have delayed us (which are well documented thanks to the transparency of our development as a result of our dev diaries ;) ). It will be nice celebrating Fost's birthday, Moonpod's (on the same day) and (hopefully) Mr. Robot's launch soon :). Hopefully in the future you'll see games coming out far quicker from us than three and a half years per title!
A Good Example of Open Source Working I've been building an installer script - a huge lua-based batch file that takes all the game content, runs various conversions on it such as texture compression and then builds the installer. We needed a commandline based image manipulation application to resize some of the textures (Fost routinely draws textures at higher res than we need them, and then we use coloured mip-maps to determine which resolutions get displayed hen you run the game high res). He found ImageMagick, which is a very popular open source batch image manipulation tool. I am always wary of using open-source applications. Of course, you can't complain when something is free, but I've always found that when you come across a problem with an open source app, it's really difficult to get anywhere. Documentation is more often than not built with doxygen and provides no real-world examples, and asking questions on a forum is a very hit and miss affair - getting told to read the manual (always our first port of call), getting answers to a question we didn't ask through mis-communication problems, or just getting no reply. Like I said - you can't really complain, but it does mean open source isn't always a great answer for critical areas of development.
Sure enough, we came across a problem with ImageMagick: Images with alpha were being converted to pre-multiplied alpha on resize. Pre-multiplied alpha is generally used for video compositing, where the alpha channel is used as a matte. It means that all colour information where the alpha is black is lost. This isn't a problem when you are using the alpha as a matte - since the colour parts that are lost wouldn't be displayed, but when you are using alpha to say - control specular highlights in a game, it's a big problem.
The online manual - whilst well written in this case, bore no fruit, so we were resigned to posting on the ImageMagick forum. This is where we had one of the best open source experiences we've had. The ImageMaick project leader and others started to get to the bottom of the problem within a few hours - we sent them example images, and eventually came up with a way to split the image into separate RGBA channels, work on them separately, and then recombine at the end. All of the best Open Source projects seem to benefit greatly from this kind of top level leadership. anyway, it was a great weight off our minds, and we thank the ImageMagick team for their prompt help.
Data Size Now we have the final compressed installer textures, music and audio , it's easier to get a handle on potential download size. We should be around 25 meg; definitely below 30. It's quite an achievement really - I would never have thought you could crunch a project this big down to this size if you'd have asked me 2 years ago. Compared to Starscape, it has about double the graphical content, and with our original compression tech would have been around 80-100 meg :shock: it also has a smaller install footprint, because the decompressor we are using is fast enough to work on the fly, so we don't need to decompress the textures to disk on install. http://j2k-codec.com/
Final release executables have also had some of the loading code optimised, and loading speeds are much better than the debug exes we use during development.
The lower install size means we've had a few options as far as music is concerned - it's always a tradeoff between quality and number of tracks. We've plumped for slighty better quality of tracks. So there's 9 tracks in the download version. We are also going to have a free extended music download like Starscape which of course has them at high quality, and will include 14 tracks.
Usability Testing We would probably have gone beta about 2 weeks ago, but usability testing brought up a lot of issues we were not expecting, so I've (so far) added about another three weeks in to address usability. It's mainly really tiny things you would not have even guessed would cause a problem. for example: in ghost hack, when you defeat some enemy programs, some experience is awarded and there's a chance your powers will increase as a result. This was relayed to the player in a 'tickertape' along the top of the screen. During usability however, we found that because the text was always there, players didn't realise they needed to press the skip button to continue. This is fixed by moving the information into a box that pops up at the end of a battle, and now players realise they need to do something to continue. Watching someone play your game, then just sit there with a blank expression because they don't know what to do is quite a painful experience! As the game's developer, you become blinkered to user interface issues, because you spend so much time during development using workarounds that they become second nature and you rely on fresh sets of eyes to help you.
Indie Vs Casual It's a problem we have always had and I suspect always will have because of the very nature of the games we like developing. A casual developer once commented that casual developers are professionals, and indie developers are hobbyists. One could easily take offence, but I completely understand what he meant: Casual developers make games which are 100% polished from top to bottom, and a huge part of their development is usability testing. Whilst I would of course argue that we (developing 'indie' games rather than 'casual') approach development in a very professional manner the scope of what we are trying to achieve is far greater, and so we have less time to work on usability to the extent that casual developers do, yet we are working with far more complicated interface systems. I recently had a look at Atlantis Sky Patrol, and it's a game which shows just what heights of professionalism casual game development has reached. The bar is set really, really high with this title. The user interface and experience is just so slick. I would love to see Starscape's interface worked on to such a level. There's a perfect example of the gap though - Sky Patrol is just so highly polished, and you can't imagine a casual game devloper releasing a game with some of the deficiencies in its interface that Starscape has. At the end of the day though, Sky Patrol is just another Puzz Loop clone however. It seems you either sacrifice gameplay complexity or you sacrifice interface polish. Having the time to work on many iterations of usability is something I find appealing, but I've never really thought of any casual game ideas that I find gripping enough to push for Moonpod to make. At the end of the day, I suppose we are making games we want to play, so in some respects it is our hobby :)
Even so, ".. a man's reach must exceed his grasp...", and we should strive for perfection in all areas. It's something I want to look into, development methods to allow us to improve matters. Our current toolset does limit us to some extent; some more gui controls might help address issues in a more straightforward manner. I think what we really need is some form of layout editor though. Ripping out a gui screen and redesigning it from scratch is presently a daunting prospect, yet that's what we often find ourselves doing after our first run with focus group tests. I'm going to spend some time researching gui systems in the future - ceGUIand
Fost - Mr. Robot Art
More tidying up of loose ends; the in game conversation system has pop up displays (much the same as Starscape) for each character as they speak.
HEL, the ship's onboard computer (Above: third row from the bottom, second across), has several states throughout the game. Shown here is his initial state.
We also use this system for in-game help. When you stand next to anything of note, a little icon will flash on the HUD. Press the help button at this point, and you'll get a pop up description of the item.
Ghost Component Interiors
In ghost hack mode, when you enter a battle, it occurs within one of the 'virtual code block components' of the larger computer map. Up to now, we've been using a single placeholder map, so this month I've built a set of interiors for all the ghost hack components. They recreate the exterior look of the component but with subtler shaders so they don't overpower all the combat effects which are launched during a battle.
Mr. Robot and Starscape CD-ROM 2nd Edition DVD Covers
After an incredibly long wait, the Starscape CD-ROM is back in stock. I have to say, I find dealing with print bureaus a complete pain. In this case, they kept telling us the prints were ready, then we would ask them when we should come down to pick them up, and they didn't reply. A week later, we'd contact them again, and they'd tell us they were held up. This happened a few times, and then we were told we couldn't pick them up, and would have to pay an extortionate price to have them delivered. Quite amusing too, because we are close enough to walk to the place. So, I'd been working on a new cover design for some time, and because this had dragged on for so long, it was somewhat complete. I decided to cancel that order and take some time to finish the new cover whilst I searched for a new bureau. In the end, we found a great local printer who even waved the setup fee for the second design (we were having both the new Starscape covers, and the Mr. Robot covers printed) because they were both identical sizes with identical crop markings.
Printing bureau pricing structure is another thing that bugs me. If you want 10000 of a design printing, it will cost you maybe GBP400. If you want 20,000 of a design printing it will cost you GBP600. However, if you want 2 designs * 20,000, it will cost you GBP800. The same amount of ink and paper has been burned up, but you have to pay GBP200 extra so some moron can switch the files in Photoshop.
Anyway! It's done now, and we've got both designs in. This has meant we've spent the last few days hand assembling huge boxes of DVD covers and pre-labelling packaging. Thankfully my Mum likes to come over and spend the day helping out (it's a real cottage industry here!). She's from the pre-computer age, and so doesn't really understand what we do here, but likes to feel like she can help somehow :)
We've also had a flood of orders in from people who've been waiting for the CD-ROM as far back as January. It's interesting to note the appeal having an edition of the game available on physical media (Something like 1/4 to 1/3 of orders are for CD-ROMS), and it might make sense to try and investigate the reasons behind it. Do people just like to have the physical product in their hands? Do they like the art? Or is it that they don't like to deal with online unlocking systems? We'll have to work out a way to answer that!
It's happy milestone getting the boxes in for Mr. Robot. Having something tangible to hold and show people is cool. Now we just have to get the game finished to put in there! We are getting there...
Sonic Death Monkey Mr. Robot's world has been eerily quiet up until this month as we have been putting in sound effects quite late in the project. Obviously, the ideal setup for putting effects into a game is to have someone working with you permanently, however when using external contractors I don't think this is the best way to work, especially in the indie space. When working with anyone over the web, there's a high chance they'll just disappear and you'll not understand why. I'm not talking about people who take your money and dissappear, that's another matter entirely, but when people get part way into a project, then you lose contact with them. Either they have decided to move into another field, something bad has happened to them or they have just lost interest. It seems to be a far easier process if you engage contractors for short periods with greater intensity. In the case of sound effects, this means waiting until very close to the end of the project, and then dropping a fat and as close to 100% complete as possible list of required effects. Letting someone work flat out like this means you've hopefully got their full attention for short time. The downside is you have to put up with placeholder farts and squeaks until very late, and that audio related bugs show up at the last minute.
You also realise just how much work in a game goes into setting things up; we've just taken delivery of 90% of the sound effects for Mr. Robot from our sound engineer, but then we have to go through all the various scripts and config files tagging them with the appropriate effect. It's incredibly laborious, and once done you have to play through the game to test they all work, and also balance out all the volume levels.
I have to say though, it's wonderful to get the audio in; feels like another major milestone has passed, and the game is that much nicer to play.
Sound Effects Taster (0.5 meg mp3)
Poo Bear - Mr. Robot Programming
First! Not a lot to report on this month as apart from connecting up any art content Fost has been providing me with, I've done little else other than continue the bug fix/playtesting session I started last month. The good news is that having slowly worked through the game, fixing parts that did not work, I've just managed a complete session through the game from start to finish! Of course, I wasn't going out of my way to break anything, and I already know several things that can be done in game which stop you from continuing, but it's the first step down the road to beta, and that bug list is now getting shorter and shorter...
Fun Time During the first start to finish playtest I was astonished to find I was really enjoying myself. Now, that may sound like a bizarre comment! but you have to understand that I play through the game ten times more often than anyone else will in its lifetime, and towards the end, it's difficult to face going back to the start all over again. Perhaps it was partly the relief that I hadn't stumbled across a new bug in a long time, or that the latest round of art content additions meant there was very little placeholder art left, but I was enjoying my little romp through the spaceship. It's a great feeling to think - 'Great, we pulled it off after all!', as in the back of your head on a long project, you are always secretly worried that all the ingredients just won't work together and it will turn out to be no fun :( . Fully complete gameplay been a long time coming for Mr. Robot, and we have been working off intuition to some extent. The game actually turning out to contain 'fun' as we had hoped is a big weight off my mind.
Most of the rooms have worked with no or minor gameplay adjustments, and so during playtesting I have started to come up with a wealth of cool ideas that we can consider for the first update. We certainly are not short of ideas now even if we wanted to make about 4 updates! Although it will be interesting to hear the non-bug feedback and ideas that pop up in beta, as they are also likely to influence what we pick for the update.
Speaking of beta, I've been looking for some form of web-based bug tracking software that will allow the beta group to report bugs. I looked at Bugzilla which is the Mozilla foundation's bug tracking tool, and has been heavily production proven during the creation of great applications like the firefox web browser. The only thing that put me off, was it was Perl based and we haven't installed any Perl apps on the server before (although I'm sure it's not too difficult). I thought Bugzilla's interface might also be a little off putting to non-programmers (whom the beta is likely to comprised of).
I narrowed it down to either the free Mantis or commercial (but very reasonably priced) fogbugz. Whilst comparing options like built in Wikis and source control integration, I realised we don't need any of this. These applications are designed for collaborative projects with multiple programmers whereas we really needed something that was easy to use, and designed with community integration in mind. I realised that for an indie developer, managing public interaction with a project, rather than a collaborative development, the forum was the ideal place for this to happen. I looked around for a phpbb mod, and found phpBBMantis, a project to integrate the aforementioned Mantis bug tracker with phpbb (which we use already for the forum). Sadly, the project is just barely up and running, so it doesn't make sense to use it yet in production - one to keep an eye on though. What we really needed was something like the phpbb team's internal bug tracker. That would be ideal, but it was never designed for public use, and so the phpbb team never released it.
So, I decided to write my own for the board, based on the phpbb team's. It came down to switching templates on a bug tracker sub-forum, with each new topic forming the basis of a new bug report, additional info like status and assignee stored in a separate database table. Bugs are tinted and ordered by status and there's a custom post template with the additional fields (which all get stored in their own table linked to the topic). Access to the sub forum is already easy to control using forum groups, so the bug tracker and a beta forum for more general discussion is all we should need to gather feedback during the beta.
I think this is a much more workable solution for the beta testers - since it's based on forum posting anyway, and they need to have a forum account to be in the beta, there's nothing else for them to learn. Fost thinks we could implement this far better with phpbb3 when it comes out so I might rework it then for future projects based on how the Mr. Robot beta goes (in a sense, we are beta testing the bug tracker too!). We want to move to phpbb3 anyway, as it will allow us to implement the community/game intergation features we've wanted to work on for some time.
Fost - Mr. Robot Art
Emit This is liable to be quite a dull diary rather than a dev diary, as I haven't done a lot this month. I have an excuse however, as I spent a few weeks bathing in glorious sunshine in Cornwall. Surprisingly, it is now cheaper (by about half) to get a flight there rather than go by train, and it only takes an hour. The disadvantage was that whilst I was down there there was another so called 'terror alert', and so on the way back, everyone had all their hand luggage burned in an incinerator, were made to walk through the metal detector naked, and then anally probed.
Not working on Mr. Robot :(
As mentioned last month, I've been dragging my heels a bit preparing all the the printed parts for our CD-ROM editions. One thing I wanted to do was come up with a more striking design for a new Starscape cover. I really wanted to go for something with only one or two elements that pretty much filled the front panel, and not much else. I got a bit of artist's block again, so kept leaving it and coming back to it. Eventually, I remembered an old bit of semi-finished concept art for Rin, dug that up, and painted over it some more (above). Now I had a face closeup for for the cover that I liked, I tried just about every piece of Starscape art we have as a backdrop. Poo Bear suggested the old Starscape banner with all the ships - this was always our favourite ad, and it worked a treat. I re-worked the hair a little to curl under the ships and frame them, and the final result is below.
That's off to the printers now so hopefully the Starscape 2nd edition CD-ROM should be back in stock soon :)
Zelda Celebrates- Work it baby! click image for flash anim
The very last bits of animation have also gone in this month, mainly celebration animations for the ghost hack section of the game. Definitely feel like we are on the home straights now, but there's still a lot to get through to finish this game. They say the hardest part of finishing a game is the last 10%, and I totally agree.
Battlemap The 'Battlemap' is a virtual representation of a computer's layout. It's Mr. Robot's ghost hack equivalent of a world map in a traditional RPG: Wander the battlemap in search of your goal, scraping through encounters with the computer's defence programs. I've been finishing off the final components (components are locations where programs may attack you, and are linked together by data pathways.)
I also went through all the components again and recoloured them all so they look consistent. We had talked about tinting all the shaders with a dark, faded green so it all looked like The Matrix :) (see bottom left) but in the end, it actually looked a bit drab during play, so I messed around with colour variations like having more colour, duotone etc. In the end we just plumped for the colourful option !
Poo Bear - Mr. Robot Programming
House of Cards! I dumped out maps of the hub, storage area, cryo deck and mind core onto paper. Using these maps I can get a feel for the layout of the game, how the player will progress through it and therefore how to distribute pickups and ghost hacks to control the games difficulty. Basically do a lot of doodling. I've already been through this process with the real space challenges in the game, but now it is time for the ghost hacking part.
The longer some code is left untested the more likely it is something will have interfered with it. With more time or staff we could perform complete tests on a monthly or weekly basis and fix any problems as soon as they occur. Instead I have to periodically play through the entire game and hit a large number of bugs in code left unexercised for too long. Whenever I have to do anything with wide reaching implications, like distributing pickups, I have to go through this code-exercising / bug-fixing hurdle. It slows everything down, but it has to be done. As the project nears completion the number or possible code interactions grows exponentially.
I'm taking an iterative approach so I'll go through the game fixing any A class bugs which actually prevent me playing on. I'll also list the large number of B and C class bugs that aren't show stopping, but need addressing before beta. If I can squash all the obvious bugs before the real testing begins in beta then it will let people explore the game more extensively and get at the real hard to find nasty bugs.
Hack Tech Once everything was working I made the first definitive list of pickups and their placement. These are things like energon, equipment, armour and weapons. All the things you'll pick up in the real world that are needed to help fight in the cyberspace world of ghost hacking. These pickups are what tie the real world to ghost hacking. Security doors and other real world obstacles must be hacked before you can proceed, creating a connection between your actions in cyberspace and what you can do in reality. The duality of these links ensure two quite disparate game types have a meaningful meeting. This, combined with the consistent control scheme and related robot/computer theming blend everything into one. Without these bonds it would be just like two different games and would feel jarring. You cannot make a new genre just by mixing multiple genres together, in the past that always failed, you have to take a holistic approach.
Working through the game, I'm putting down pickups, creating ghost hack maps and setting up ghost enemies. It's a slow iterative process: add new content, play the game, tweak it, repeat. The real skill is in ignoring your own growing ability at playing the game and making the difficulty level start out very low and ramp up gradually.
It's also time to set the initial level of your robot comrades, you meet them at different points in the game and they should be of similar level to your own avatar. Otherwise the player would have to go through an annoying "leveling up your team mate" phase.
I'm also setting who has access to the different programs available. Brutus is easy, he's a huge robot with all the best ICE so he doesn't have any programs. Raistlin is also easy, he's the opposite, small and weak; he can only use the most basic ICE, but he has all the most powerful attack programs. The others are somewhere in between and it is this distribution of abilities that encourages the player to identify particular strengths and weaknesses and make tactical choices. Informed meaningful choice equals fun - in theory.
The Complete Ghost Hack Team: Gotta-Catch-Em-All!
Falling Down Part way into this process my minor bug list has grown to the point where it is starting to impact gameplay and to carry on play testing would probably be a mistake. So testing stops temporarily and I have to clear off the 90 minor bugs I've found. I'm currently fixing about ~5 a day on average, which is a little depressing, so it will take about a month to clear the list!
Almost a year ago I stepped up from a 40hour working week (9am to 6pm, 5 days a week) to a 50 hww, now I'll have to shift up again to a 72hww. I don't think that is a healthy way to live, but every game I've worked on previously was the same if not worse. With more stable tools and more reasonable schedules maybe it could be different, but it's one of the reasons I don't recommend game development to people. It isn't just unhealthy for your social life, it's not a good way to make games; you are under pressure to write sloppy code, make lazy design decisions and release without proper testing or feedback. Resist!
In the mainstream industry it is called "crunch time" and I think this combined with low wages (compared to normal programming work), is responsible for the young age of game developers. At most companies the average age is about 22 with older staff members leaving due to what is called "burn out" - fatigue resulting from inadequate compensation and excessive crunch time. The result is an extremely enthusiastic workforce with lots of exciting ideas, but the inevitable downside is a lack of professionalism in terms of scheduling, poor management, bad coding practices and immature game designs. Companies reduce this risk by employing larger and larger teams and pushing people into longer and longer crunches. Why do we keep seeing the same game genres over and over and the same gameplay mistakes being made? I think it is largely due to a constant turn over of developers fresh out of university with no previous experience. You only learn by actually doing; if each game takes two or three years to make and all your staff leave after ~4 years then what chance do you have to learn? To all the studio managers out there (none I suspect), nurture your staff and hang on to the ones who are going bald!
Our next game will be different though, a realistic and comfortable schedule, time to reflect on the design, stable tools, prototyping, multiple platforms, focus groups, extra staff to spread the workload, full time tester, weekly game play and stability testing, full time customer support and website staff, ah I can see it now - honest :)
Fost - Mr. Robot Art
Cover Story Revisited
Quite a while back now, I was working on the DVD cover for Mr. Robot. I wasn't totally happy with the design though, so it was left by the wayside a little. So I've finished off the final cover image (above), and due to it's format, it makes a pretty nice widescreen desktop wallpaper (which ties in nicely with Mark's post below!). I can't see I've seen any sites with widescreen wallpapers, but if you are one of the very few people in the world with a 2560X1600 display, hopefully you'll appreciate it (and let me have your monitor!).
Choose your wallpaper:
We always end up going though loads of iterations of colour/layout/text/imagery. I suppose when you are forking out for a large print run it makes sense to get it right. Here's the final process, with the winning layout on top. Bar final text copy and screenshot inserts, it's now ready to go :)
On Designing Robots For Animation... The bulk of this month has been spent finishing all the animations for the robots that need to be animated. The robots who help you in particular have a lot of animations as they also appear in the ghost hack mode, so need an additional set of animations: ICE breaker attack/program attack/damaged/deactivated etc. The hardest thing has been walk cycles though. I usually want to inject a bit of personality into the walk as the way someone walks says quite a lot about them. Serious weight for the heavy lifter, a slight limp for the older mysterious security droid etc. However, that pretty much went out of the window as in some cases, due to the robot's design, just getting them to move in even a vaguely believeable, physically possible, manner turned into a technical nightmare.
During the modelling/design phase, I usually test out the movement of the robots quickly to make sure there aren't going to be any spatial issues with their size and shape. Of course, spinning a model's arms and legs about isn't the same as making them work! I came across two main problems:
1: Some of the robots have limited degrees of freedom compared to a human. Samson for instance cannot move his shoulder joint in an outward motion, and Raistlin has the same issue with his hips. Normally, as the hips and shoulders become slanted in a walk, the joints compensate to keep the legs and arms straight. With fixed joints, they tend to flail out more, which is a particular problem with leg joints. When designing robots - it's best to allow as much freedom of movement as possible without compromising your design, as you'll save time later on during the animation phase!
2: Samson and in particular Orgus, have very short, and very fat legs, with massive feet! When feet are longer than the leg it's almost physically impossible to bend the leg, and swing it forward to make a walk.
Anyway, here's the keyframes (most are on 16 key frames) from the final walk set. the game smooths the animation out by calculating the inbetween frames and morphing between them.
- click images for flash animations...
Samson and Orgus were definitely the two hardest models to animate. Samson has quite insane proportions - feet as long as his legs, arms that go past his feet, and hands as big as his body! Orgus' foot mechanism has so little room for manouvre that he pretty much shuffles along.
- click images for flash animations...
Raistlin, Zelda and the enemy stalker robot. Being much more of humanoid proportions made these much easier, although the lack of feet on the stalker initially worried me, it proved not to be a problem. So there you have it - feet are a complete waste of space!
Poo Bear - Mr. Robot Programming
Mr. Robot: In SuperRoboScopeVision! I've been looking into how we will handle widescreen aspect ratio in all future games. This is something we don't have in Starscape as switching resolutions is not so easy due to its 2D sprite based nature. Also, in the past, there have been very few people using widescreen monitors, mainly a few laptop owners who had top end systems.
With most laptop manufacturers moving toward widescreen displays now (so the laptop can double nicely as a portable DVD player), and flat-panel, widescreen desktop monitors dropping in price (I'm waiting for this 30" beast to drop to street prices :) ) now is definitely the time to be supporting widescreen.
Here's some statistics from our website:
Widescreen displays highlighted in yellow showing that just shy of 7% of the people viewing our website lately have been using wide format displays. Not a huge amount, but enough to warrant supporting that kind of display. Also, this figure has doubled in a very short space of time, and I expect it to grow massively over the next few years.
Mr. Robot currently supports any resolution, but the virtual camera's aspect ratio is locked to 4:3. So I needed a way to set wider fields of view. My ideal choice would be to determine this automatically, but failing that, give the user a wide range of options so they can sort it out themselves.
The first thing that I did was to compile a list of resolutions currently in use, which ended up confusing me even more! Some laptops are actually 16:9 ratio, and some are even 16:10!
What's more, Fullscreen 1280*1024 running on a CRT monitor is squashed to 4:3, yet if you run it in a window it has square pixels, and is a different aspect ratio. Flat panel monitors always seem to have square pixels, so a flat panel monitor with a max resolution of 1280*1024 is also a different aspect ratio :(.
The useful fact there however, is that widescreen flatpanels have square pixels. In the end, I've decided that the best thing to do, is to assume square pixels (which is what Windows desktop does anyway). So, just get the desktop aspect ratio and set the camera fov to the same. The only time this will cause a slight discrepancy is with fullscreen 1280*1024 (A popular but silly resolution; it should be 1280*960) on a CRT monitor. Luckily, there's no noticeable difference between 1280*1024 squashed to 4:3 (like on a CRT monitor) and 1280*1024 with square pixels (5:4) like on a flat panel. Just a 6.25% vertical squash only affecting CRT users at that res.
Should be able to support that in all future games, and in an update for Mr. Robot if not at launch :) .
Hamish - War Angels
Here's a detailed list of all the weapons you'll be able to use in the game at the moment. I'm pretty happy with them right now so I don't think there will be any major arsenal changes. I did say there would be 40 guns to start with, and I have made about 40, but I feel the game plays much better if I crop out the redundant and boring ones and just have the best. So, here they are -
Pulse Pistols - Standard backup weapon, pistols don't perform aswell as full sized weapons but you do get two of them making them a good and affordable complement to some of the bigger weapons. The pulse pistols shoot bolts of energy, and can shoot a charged up shot which is useful against heavy infantry and light armour.
Magnum Pistols - Not as powerful as the pulse pistols, but has a 3-shot burst mode which makes it great for killing waves of soldiers. I think I'll reward players for playing the game with only handguns, Nick and Mark are working on some cool new site features to integrate with our games so players can compete against each other for finding hidden achievement rewards in our games.
SMGs - Weak automatic weapons, but seeing your get two their rate of fire can't be matched apart from the minigun.
Shotgun - Pump action shotgun. Nothing special, but it doesn't need to be reloaded which makes it useful when your other weapons are empty. Shotguns are lethal against infantry but preform pretty poorly against anything else.
Assault Rifle - Accurate and powerful, shoots in three round bursts. Not as useful as other autos against infantry because of its slow fire rate, but its accuracy and damage works well against heavy and elite soldiers. It also has an underslung grenade launcher making it the only weapon with two truly different firing modes.
Machine Gun - Like an assault rifle which spits bullets twice as fast. This makes it quite inaccurate, but you can deploy a tripod which greatly increases its accuracy while making you unable to move. It has a big clip or is chain-fed and doesn't need to be reloaded, I haven't decided yet.
Auto-Shotgun - Shoots 12 shotgun shells lightining fast, dealing a huge amount of damage, enough to kill small vehicles even with the damage penalty shells have against armour. Might even be better for soldiers than the flamethrower. It takes a while to reload though.
Sniper Rifle - Semi automatic high caliber rifle with a laser sight. Unlike most sniper rifles you can fire this one as fast as you want, emptying its 7 bullet magazine in under a second. the bullets will go straight through un-armoured infantry aswell. Its armour-piercing rounds make it extra effective against vehicles, it's weakness probably being large mobs as you have to reload after 7 shots.
Laser Rifle - Another long range accurate weapon, the laser rifle preforms better against armour and doesn't have to reload. It'll be up to the player to decide which rifle they like better.
Lightning Gun - Lets loose bolts of electricity in a nearly 90 degree cone. You can't really aim this thing at all, but it can do a hell of alot of damage if you point it at a horde or stand right next to a tank.
Grenade Launcher - Most games that include a grenade launcher really don't make them worthwhile. You pick them up and go "oh, thats nice" and continue using your assault rifle, saving your grenade launcher for the tough boss battle that never comes. THIS one however is pretty damn versatile, usable against nearly every enemy type in the game. You can fire it in normal automatic mode, or queue up to 4 grenades in the barrel and fire them all at once in a destructive wave of explosion.
Minigun - Fires 3,600 rounds per minute at full speed (which is about as fast as a real one), the minigun shreds through infantry and light armour. It shoots so many bullets you don't really need to aim, but this along with its slow charge-up rate mean you have to buy alot of ammunition, making it quite expensive to maintain.
Laser Cannon - Does anyone find it strange when there's a "laser" in a movie or a game, and it's a ball or beam of light which travels at the speed of a BMX bike instead of 1,079,252,848 kph? Well not this one, it fires a constant stream of hot laser death at perfect accuracy. It really doesn't have a disadvantage so I suppose I'll make it pretty expensive.
Flamethrower - Probably the weapon I spent the most time on, going through at least 9 remakes until I settled on the current version which took six hours to make. Im sick of flamethrowers in games looking and acting like joke weapons (see TFC and ET) so I wanted to do it right. Really good against infantry and can set structures on fire, pretty useless against armour though.
Plasma Pistols - Shoots short range burning green balls of "plasma". Does a huge amount of damage, and I'll probably make the plasma stick to things and keep on burning them after the initial hit.
Pulse Rifle - Another automatic weapon, I really don't know why it's down the bottom. Has two barrels and does more damage than the assault rifle and the machine gun, but doesn't have the alternate fire option they both have. Good if you like things simple.
You may have noticed there are no missiles and grenades listed, don't worry because there's plenty of them aswell, but at the moment explosives are classified as 'items' meaning you hit the item button once and fire a grenade or throw a missile. They're support weapons rather than weapon weapons, it makes more sense being able to fire one missile when you need it than using it as a permanent weapon cause they aren't as versatile as a gun eg. they blow up in your face if an enemy gets too close. I'll update on them when I've done some more work on them, I need to put some more items and grenades in the game first. There's also a few more weapons to come aswell.
Hamish - War Angels
Seeing I haven't updated in ages, here's some new screenshots (click for big):
In these you can see a new APC enemy I've added, which can be equipped with a turret to turn it into a light tank (screenshots will be up when I finish it). You can also see a new version of the HUD which has been adapted to fit in with the new inventory system. There's 6 slots for weapons or items, a weapon (gun) and item (health kit, grenade, missile, other) can be equipped at the same time so you can throw grenades and shoot missiles while firing your primary weapon. There's also a few more interesting items like the personal teleporter which I'll get onto later.
I'll make some more updates on the game very shortly with some much-needed info about the game like the weapons you can use, the enemies and obstacles you'll be facing, how the game plays out and more. If anyone would like to see me update about something now is the time to ask.
Fost - Mr. Robot Art
Escape Velocity Finally finished all the programs for ghost hack so rather than post pictures and spend time writing a load of waffle (that most people ignore anyway :) ) I've put my dev diary efforts into editing together some video captures of some of effects (see below). Note, these normally take place in the virtual world of ghost hack (which we haven't seen much of yet), but for now I've captured them in a 'padded cell' test room :).
The most fun I've had with effects is to use attraction controllers - I've ended up having to work out some basic maths for them so I can put particles into orbit around the controller. When you hit the right combination, you can get some lovely effects as they spin around. It's quite fun to set an enormous lifespan on the particles and watch as their orbits slowly decay and they eventually float away, since you can never get it 100% right. Of course, if we had minute long effects, ghost hack would become pretty boring, so I've tried to make most of the effects quite brief.
Ghost Hacking Video Reel
High res downloadable version (35 Meg, Mpeg)
Or, if you prefer:
Google Streaming Video
YouTube Streaming Video
Poo Bear - Mr. Robot Programming
When a game project moves into its final phase a lot of disparate systems begin to mesh together and people (new users) begin to explore their interfaces as the game takes proper shape and becomes fun(ctional). Systems that were tested and seen to work in isolation suddenly fail as code paths are exercised in new and subtly different ways. I hear people complain that newly released games are often not properly tested and contain too many bugs and obviously they have a right to feel upset, but testing a game properly is extremely difficult. Mr. Robot is just now entering this problematic birthing phase where we are starting to shake out all the skeletons that have long remained hidden within the games many forgotten cupboards.
The front end, coming together nicely, except for that class A bug taking out the debugger...
We will certainly be beta testing the game to bullet proof it further, but some amount of internal testing must be undertaken first lest we be drowned within a deluge of obvious and avoidable bugs from our unhappy testers. The volunteer beta-test team have a right to expect a fairly stable game. However, before even internal testing can begin I must wrestle the many subsystems within the game into compliance. In some ways this is one of the more stressful periods of development as many extremely obscure bugs will be exposed and require me to work long into the wee hours to lay them to rest.
JJ (from Starscape), now an out of work jobbing actress, stands in until the final cast arrives...
The main culprit in this time of woe is memory corruption, it can have many causes and is simply an area of memory that is written over in error destroying whatever was there initially. The most insidious example is when an error causes a piece of innocent empty unused memory to be overwritten causing absolutely no problem whatsoever. Why is this insidious? As we approach the end of development different systems begin to ramp up with their full in-game content, where we initially had 10 sound effects, now we have 200. This is a huge change in memory layout and what were empty or unused areas of memory remain no longer and all of a sudden evil little bugs that have slept quietly for years suddenly wake up.
Inventory, now working perfectly.
There are tools to help out like Compuware's Boundschecker or Rational's purify, but they are very expensive, fragile and complex tools. If you have deep pockets then it would make sense to get one early on and start using it regularly throughout development. Both come with something called "code coverage" which allows you to see how much of your code actually did anything when you ran it. It might seem odd, but this is extremely important as you can create a "test plan" designed to ensure every little bell, whistle and knob gets tweaked during testing. If you aren't exercising every code path then you aren't going to find as many bugs and the devils will lurk undiscovered only to pop up months later when you've forgotten how that system works.
Auto unlock: In game key system.
Deciding What's Next.
As one project slowly grinds to a conclusion, thoughts of the next come to the fore and the plethora of "clever" ideas and swiftly jotted musings that form the game ideas vault are pored over with renewed vigour. The time between projects when ideas are unconstrained, fleeting, paper-based entities is definitely one of the most joyous. As the new project draws near the harsh light of reality forces its way in and begins to burn away many of these flights of fancy. If people were happy with text adventures then we could create epic journeys into the stars or voyages to the very depths of hell and back. However, people want a lot more than a great idea, they want a professional, polished, piece of entertainment served with the minimum garnish of "work" and bothersome "education" and lashings of thrills and eye candy. When I say "work" I mean the effort required to master anything new or unfamiliar. When I say "education" I mean the instruction required to understand what it is you are actually meant to be doing. Don't under estimate "work" and "education". If you've been brainwashed by a multi-million dollar hype campaign and shelled out $50 then you have a pre-built desire to push through any shortcomings, invest some real time and mine out that core of goodness in all games. If you're looking at a free demo it took 2 minutes to download, of a game you've never heard of, while waiting for "Lost" to start on tv, then it better be smooth sailing and instant thrills! So how do you create something so slick and beautiful and yet stand even the slightest chance of delivering it within 12 months?
Don't ask us! Mr. Robot stands testament to our failure to deliver in a timely fashion. :)
Can we change all that? Can our next project deliver something just as innovative, fresh and pretty, but in half the time? Should we even try to work so quickly?
One of the problems with Mr. Robot was the time spent prototyping the idea to start with. It's quite an unusual mixture of puzzle solving, adventure, platform action and turn-based battling. It took many months of experimentation to crystallize those conflicting ideas into something cohesive. Then there was the huge amount of custom hand made content.
If you are trying to make something nebulous within a specific time frame it can help to think about those elements that are more predictable. As you chop away at the available time you begin to see just what is feasible and what isn't. Saying you have a year, or two years to make something sounds a lot, but when you begin to break it down it is amazing to see how quickly that time is eaten away.
1. Update Starscape: The 1.6 update list has been gathering dust a long time, so it is essential we get onto that as soon as we can and it will take at least a month to complete. This isn't even adding new content, just minor improvements, bringing some of the admin systems into line with Mr. Robot, non-critical fixes, etc.
2. Investigate new middleware: After losing our tools programmer we are now far more interested in open source solutions than hiring a replacement. Letting one person create a full set of industry standard tools is a mammoth task and it is very risky to rest everything on custom built foundations written by one person. Some work can be done beforehand, but you will still use at least a month setting up a new renderer, sound system, networking, physics, model exporter, etc.
2. Prototyping: Even if your idea is not innovative you must still do some basic prototyping to ensure everyone understands what it is you are trying to make and what resources you will need. As the prototype takes shape you will get an idea of the tools needed to build it, this usually involves a custom editor of some kind and a scripting system. Even if you are proposing a very simple game you will need at least 2 months here unless you are simply remaking a previous game with minor improvements.
4. Creating tools: Once you have working prototype tools it's time to flesh them out with all the added functionality and time saving features that are essential to prevent your content creators killing you out of frustration. It's vital that your production process is smooth and efficient so expect at least a month here, anything more complex than a few text files and it will take a lot longer.
5. Production: Hopefully you don't have any more questions hanging over the project and everyone can just get on with it. This is the one area that is flexible on time, do you want 10 levels or 5?
6. Testing: A critical phase that it is all too easy to skimp on; expect at least 2 months.
7. Contingency time: However long you think it will take, it will take longer guaranteed, just accept it. If you genuinely believe something will take a year then you better add 2 months on, sad but true.
So if we are proposing something simple (i.e. nothing like Mr. Robot!). With ideas and technologies that aren't too unfamiliar, so it has a chance of a 12month schedule, then we will still need 9 months minimum not including production. So the question then is: how can you produce the content for your game (production phase) in just 3 months? With Mr. Robot each room was hand made and there was a constant need for new room artwork and new hand coded challenges within the rooms. So unless we want a very short game indeed we need to procedurally generate some or all of the content. Starscape is a good example of partial procedural generation as script files were used to create the game universe and seed it. Starscape's universe is quite small but procedural generation can be taken a lot further, just look at Elite or Diablo.
The drawback to procedural generation soon materializes in repetition as human beings are quick to spot patterns and similarities which they then tire of quickly. So procedural content can save time, but to create truly compelling procedurally generated content is very complicated and would take a great deal of research and therefore more time; the one thing we don't have! So it would seem a game like Starscape is what is needed, something driven by a procedural engine yet tightly guided by the hand of a designer. A compromise.
Analysing such a nebulous problem as your next project is very difficult and I suspect there is no solution that is both exciting and risk limiting. I sometimes envy true indie developers, people who make games in their spare time while either studying or holding down a full time job. I personally cannot work on something part time like that, I have to commit all my energies to one thing. However, you are no longer truly independent as the financial pressures of real life soon seek to push you towards shorter schedules and a faster turn around.
Leaving the mainstream industry behind we thought we had defeated the demon entirely, but sadly we just wounded it. We must still find balance in all things even if that means reigning in our ideas and cooling the forge of innovation.
Fost - Mr. Robot Art
Not much text this month (I'm sure everyone just wants pictures anyway :) ), as I'm working overdrive on effects. Normally these will appear in ghost hack mode (a section of the game which takes part inside a virtual computer world), but it's easier for me to set them up and test them in a dimmed room from the main game section, so all the screengrabs reflect this - you'll have to use your imagination and picture the effects occuring in a virtual reality world a bit like the matrix.
When coming from a reference point of making something similar to the real world, e.g: the smoke trail from a missile, you always have that refererence point to work to. With ghost hack, the only criteria is that it shouldn't look like the real world :) It's often hard to know when to stop tweaking an effect and several times I've made perfectly fine effects which then were transformed into something completely different after several iterations of tweaking! Moral: save often!
Things are progressing much faster than with effects creation on Starscape. Mark has made sure effects reloading works off several buttons, which speeds things up no end. I actually value that approach to programming games more than I would the solution of writing a dedicated particle systems editor. Text files aren't hard to edit, but if you don't have the ability to see your changes instantly, then it takes an age to create even the most basic of effects.
Poo Bear - Mr. Robot Programming
XML Storage Decisions
We already use XML for some file types in Mr. Robot, although it was more of an experiment in XML integration than something that was implemented in a sensible way. Whilst prototyping aspects of future games I've started to use it more and think about the best way to approach XML use in games.
I've not seen much discussion about what's considered best practice with regards to how xml is used to store data. There's 3 possibilities. E.g. storing data about a 3000 radius red sphere.
Multiple inline attributes in an empty element:
Multiple empty elements with a single inline attribute inside a containing block:
Whilst the use of multiple inline attributes in an empty element is the most tempting implementation, especially if you've come from using block files, it can get very messy if you have a lot and end up on multiple new lines. Once you start using a deditated XML editor rather than a text editor it starts to make a little more sense. Some commercial editors can even fold up container blocks making it easy to navigate and visually isolate data chunks (in fact, if you look at any xml file in the firefox web browser it will do this). So I've decided the last option fits most types of generic data. For single attribute empty elements I also try to stick to using the attribute name 'value' - it just makes things easier to remember. I'll still probably use several inline attributes for anything that won't break a line such as a particle system colour key like: .
Whether this is good practice is anybody's guess, it just seems to be the best compromise between compactness, readability, and parsability by dedicated XML editors, but then XML wasn't designed with games in mind...
XML Document Type Definitions (DTDs) for Games
Using xml files for just about every type of game development file is currently vogue amongst developers. The main reason it seems developers have chosen this method is because it's then easy to use a lightweight, off the shelf file IO system like tinyxml, so you don't have to write your own text file parsing system. Sometimes though, I get the impression that people use xml files just because it's trendy :). On the face of it, they are much more unweildy than something like a blockfile.
//This is a comment
There's a lot of duplicate text for closing tags, and the HTML style commenting system is a bit unweildy. However, as well as versatile off the shelf file IO code, there is one other major advantage to using xml files that I don't often hear game developers talking about - and that's free file validation by using document type definitions. Document type definitions (DTDs) define what elements and values are allowable in a specific xml file type. This means that you don't have to write your own validation code to check for errors; you can use an off the shelf xml file parser that supports DTD validation (whilst tinyxml doesn't support this so it can stay small in size, there are many other xml parsers that do, such as xerces xml. Better still - you just use the built in validation systems of a dedicated xml editor (like the excellent and freeware xmlpad) to validate the file as it is saved out. Virtually all xml editors will also do code completion using the DTD, so it's easy to remember what tokens go where because the editor shows you what options are available at the current position in the file:
DTD based code completion in XMLPad.
Fost says that if he was still working in a big team as an art lead, he'd be pretty excited about this. Common errors that always crop up when text files are edited by non-programmers can be caught in the editing application before the game is even run. Normally this necessitates programmers adding lots of code to check the files on load and pop up suitably helpful and explanatory error messages. Automatic pre-validation of the files results in a massive time saving on both sides.
Writing a DTD is pretty easy too and it can be stored in a shared location; even on a webserver, so when the DTD updates anybody attempting to parse documents automatically uses the latest version.
Here's an example xml file representing some solar system data:
Solar System XML:
The solar system definition contains
line1: xml header
line2: DTD definition - this will be pulled out by an xml editor and used for validation.
A top level container element which wraps all the information.
A element with setup information for the application (I'd probably put this in its own xml file with it's own DTD though).
A element, that contains multiple containers.
In addition, each instance of contains surface sub containers, and optionally an element.
My point in making it this detailed is to show how different structures can be defined in the DTD:
Solar System DTD:
The first line: tells us to expect a 'solsys' element first, which will contain only 'config' and 'bodies' elements in that order.
The 'bodies' tag is defined: ' '
the '+' means allow any number of 'body' sub-elements.
Next we can define sub elements such as 'orbitScale':
this is marked as 'EMPTY' because is has no closing tag (i.e. it's written as rather than )
Even though the tag is empty, it can still contain inline attributes which are useful for storing game data. The following entry in the DTD defines what attrivute names can be used (in the case, I'm using the attribute called 'value' ):
The '#REQUIRED' keyword means this attribute must be present else the file won't validate.
If the attribute contains data from a predefined set, then we can define this here too, as with the '' parameter:
This means you can insert any of the keywords: 'static', 'Mercury-VSOP87', 'Venus-VSOP87', 'elliptical' into the 'value' attribute. If anything else is present, then the file will not validate.
That's pretty much all you need for DTDs, at least as far as game data is concerned. The only other thing that is useful is the ability to define optional elements, by using a question mark. The 'ellipticalorbit' element in 'body' is optional:
Fost - Mr. Robot Art
More Ghost Hack Sentinels
The ghost hack sentinels have been eating up all my time this month. Creating the shader and moddelling them is fairly swift, but animation can get complicated. Since they are just abstract entities, some are created from a few hundred smaller primitives, which can become unweildy to animate.
- click images for flash animations...
Luckily, they only require 5 states:
WAIT | DAMAGE | ICE ATTACK | PROGRAM ATTACK | DIE
The player avatars in ghost hack need a few more: victory celebration, disabled, and they can also use items and protect themselves with virtual shields. I've now got all of Asimov's ghost mode animations out of the way, but the rest of the team are a fat slice of animation waiting in the wings :)
Content Management Server
As Poo Bear rakes over the front end, we have to discuss what direction we might take with Mr. Robot in the future. As anyone who reads the forum knows, Starscape is written in a way which makes it difficult to update, and this has severely limited the speed at which we can do things. We are hoping to make future games more easily extensible, basically because we love updating our games :). As we discussed the possibility of releasing the editor, we also talked about having a way for users to share the adventures they create. The idea is that the game would connect to the web server and download a current list of user created adventures, which you could then select and play. In turn, the editor would also have the ability to upload a user created adventure - each user having server space to store their adventures and share them with the rest of the world. A fantastic way we'd be able to support the community if there were enought people interested.
It's a great idea, but it's a lot of work. To justify the effort involved, you'd first have to assume we had released the editor with the game (still not a given, as there's a lot work to do on it to make it end-user friendly), and that lots of people start using it. There's no point having an adventure sharing system, if nobody is making adventures to share :) - more than likely when you consider that as an indie developer, we only have a limited audience (World of Warcraft has about as many server clusters as we have forum members!), and that the editor is not likely to be the easiest thing to use, having been designed for internal use only. The problem is, you can't just say "we'll do that in an update if enough people start to use the editor". Whilst that makes a lot of sense from a scheduling point of view, the reality is that shoe-horning features into a system that wasn't designed for it takes a disproportionate amount of time (see Starscape ;) ). In particular, extending or re-arranging things in the front end is a nightmare.
We realised we needed to plan for this and do the groundwork if it was ever going to be a possibilty. Poo Bear has completely redesigned how the front end works so it can support multiple user created adventures, and also extended the file updater (which we already use to get updates from within the game), so it automatically downloads files and resolves any naming conflicts. I've also set up the content manager on the web server side of things. This takes uploads from the game, renames them and saves them in the appropriate place, and adds some information about them to a database. The game can then query the server for a list of user created adventures, and create a list with a short description and picture for each adventure.
Considering this feature might not ever make it into the game, and certainly won't be in version 1, it probably sounds like a bad idea to work on it now, but if we don't do the groundwork, it would probably preclude us from doing the work at a later date.
Odds and Ends
Ghost Hacking Console- click image for flash animation...
Airlock open: simple effect using stretched particles.- click image for flash animation...
Poo Bear - Mr. Robot Programming
User Interface Design (or: The dreaded front end!)
Most programmers view a game's menu system as a necessary evil, a blip on the way to the meat of the game. The problem is the UI is the bridge between the human player and the machine, if it isn't perfect then you're damaging the gaming experience. Sometimes it isn't much of a problem as the game doesn't have much of a UI at all, just hit the go button and you're off. Then the only worry is that you've implemented an intuitive and friendly control system.
With Starscape (our last game) the UI let the game down somewhat as time constraints forced corners to be cut that with hindsight shouldn't have been. MrRobot is even more UI heavy than Starscape so this time we need to get it right. So the approach i'm taking is to rapid prototype the front end, which means to get it functional as quickly as possible, test it and then refactor it as many times as is necessary (or we can afford). It goes against the grain to throw away code, especially if you do it multiple times, but I just don't think there is any other way. This isn't necessary with everything, but some parts of the game are just very experimental and it is quite hard to create a specification without seeing something tangible and "playing" with it.
This is how the full process goes:
Discuss what the player needs to control while doodling on a big white board, this is sometimes called brain storming. Repeat.
Create a rough set of screen sketches on paper annotated with instructions and descriptions. Discuss. Repeat.
Create a more detailed specification on paper. Discuss. Repeat. If the subject is familiar or simple then we can go direct to final implementation.
Create a rough prototype implementation. Discuss. Repeat.
Code the final implementation. Discuss. Tweak.
The "discuss" reference is critical, you must involve other people and their comments can be painful (as they usually mean more work to do). Initially I only involve Fost in such discussions as lay people cannot make constructive criticism when the implementation is very rough as they are not developers and therefore need something more tangible. As the implementation becomes more complete it then becomes essential to involve "civilians" as developers always come with preconceptions and built in understanding that "normal" people just don't have.
Here is the main ghost UI screen which is at stage 5, but still undergoing some tweaks. This screen acts as a hub, off of which hang all the other ghost UI screens.
The downside to all this is it becomes very difficult to accurately schedule how long things are going to take and in general things just do take a long time to implement.
Customising your ghost
This month I've finalised the set of core items for ghost hacking; these are the things that allow you to customise your ghosts and build a unique fighting style. The point of a turn based battle is to provide enough variety of tools that the player can make interesting choices about how to tackle the enemy; it's called strategy :). In Starscape the fun comes from learning how the ships and weapons handle and then throwing your weight around relying on your reflexes with hopefully a little adrenalin running. Ghost hacking is completely different (which is great, programming different genres is fun) the fun comes in evaluating the situation, understanding how all your different pieces fit together and then smiling as your plan works and the enemy are annihilated. I think it's a fairly obvious compliment for the puzzle based platform jumping game mode although I don't remember ever seeing another game do it? Not that I'd ever think for a minute I had a new idea, don't ever think that, never forget: "there are no new ideas, there are only new ways of making them felt" - Audre Lorde.
Anyway, the drawback is you need a rich crop of equipment and functionality with which to develop your strategies and careful balancing must prevent a single strategy always being sufficient. This is why the ghost battle system is designed to be easily extended and modified; adding new ghosts, enemies and equipment just requires editing some text files and writing some new AI with the lua scripts. So initially we just need a simple core set, get everything up and running and then add more where necessary. I expect a lot more will be added to ghost hacking after release based on player feedback.
Below is a table of what we have so far. You can see how certain functions like "energy restore" are common to different types of object. Did we just run out of ideas almost instantly and start repeating ourselves? No, there is method to this madness. Different ghosts are better at doing different things to give the player meaningful choices, but if important core functions only exist in one ghost type then all choice is removed, I have to take one. So if I decide not to take a repair bot then how do I get repaired in a battle? The answer is to slightly change your equipment and play style, search out weapon upgrades that have a restorative effect or perhaps spend more time building up cash reserves and buy off-the-shelf one-shot restoratives. Don't like attack bots? Maybe a crate of data grenades will do instead?
Note: This was originally written for our forum, and so a lot of it is aimed at explaining things to non-programmers. Apologies if I over-explain things a bit for the GDNet crowd :)
Poo Bear - Mr. Robot Programming
We Just Clicked...
Stopping any sound effect sample at the wrong point can always generate a popping noise. What I normally do is fade a sample out over a few frames rather than stop it immediately, which seems to do the trick. However, we came across a problem with a fews samples - during normal playback they would loop perfectly, but now and then we could hear a popping noise. It turned out that this was caused as the sample started up; because the sample wasn't at zero amplitude at the loop transition, on start it would go from nothing to high amplitude instantly and cause a pop - even though it otherwise looped perfectly. We had to fix this by changing any sample loops to transition round zero amplitude.
HIGH AMPLITUDE TRANSITION: This loops fine during playback, but clicks when it initially starts up.
ZERO AMPLITUDE TRANSITION: The sample now loops and starts up without clicking.
The Dark Side Of Scripting
Scripting allows you to control the flow of the game via extrenal text files containing Lua script. This means you don't have to re-compile the game code to change something. Great. A scripting language is said to be "higher level" than C++ which in itself is higher level than C or assembly or machine code. What that actually means is it takes less code at each higher level to do the same thing and you move away from the hard details of how something is done and begin to focus instead on what you want. The result is code that gets slower because you are relying on the compiler or other libraries to interpret what you've asked for and actually do something. So an assembly language program might require a thousand lines of code to do something, whereas a script might do it in two lines, but the assembly language version could be 10-100 times faster.
Of potentially greater importance is the time to get something working. There is a saying, if you have written more than 50 lines of code then there will be bugs and the chances of you finding every single one fall rapidly as the number of lines increases further. I've seen one example where an application was written in C++ and took 2 years to build with 100k lines of code. Soon after it was scrapped due to the inability of the authors to properly maintain and extend it. The app was redone using a scripting language in 3 months and only 5k lines of code. As the application's speed was not an issue the scripting language was more than up to the job. As computers get faster and projects get larger the speed disadvantage of scripts disappear, far outweighed by the ability to get things done quickly.
Scripting languages are also far easier to extend than C/C++ because they are typeless. What does this mean? Well typed languages like C/C++ require you to say exactly what all your variables/data are and what should be done with them before they are used. This means you end up with lots of bits of software that only work when connected to specific other bits. So you cannot just take something out of one game and use it another because chances are it relies on other bits of the current game to function and it only connects to other bits of the current game.
Scripting languages are also platform independant because they work at such a high level that they don't care about the underlying hardware. C and C++ do care about the hardware and great care has to be taken if you want to get things working on another platform.
So scripting languages are great then?
Well, not quite. Scripting languages are best described as glue. Strange term. What I mean is they cannot really do anything on their own. You have to write code in C/C++ called components, these are tools that actually make something happen i.e. display a button on screen, move your character, etc. The scripting language can glue these components together and coordinate them to make things happen. Like a conductor in an orchestra. Scripting languages aren't really setup to define complex objects, only control them. Unlike C/C++ which has powerful compilers, built in mechanisms for managing complexity and sophisticated debuggers.
So anything complicated, time critical or hardware specific cannot and should not be done in a script. All those tools need creating in components that the script can call. It's very difficult to keep your scripts small and you will very soon have a large component tool kit that quickly get out of hand.
Scripts aren't compiled like C/C++ they are loaded and executed when needed, which is both a blessing and a nightmare. Simple errors that are unavoidable only show up when the script executes. If that means travelling through 50 rooms to get to test the new one only to find it crashes due to a simple typo then you can waste a lot of time.
Scripts are typeless meaning any variable name can represent anything and there is no compiler to check what you are doing. So if you simply spell something wrong then the script interpreter will assume you want to make a new object. This object will then be automatically set to some valid default state (like zero or nil) and then everything will happily continue as though nothing is wrong. Half the time this causes a crash and half the time it doesn't, you'll just get behaviour you weren't really expecting and no obvious explanation.
Add this to the fact you have no debugger to check what is going on and you can get in very deep trouble very quickly.
It wont be too bad surely?
Still, the scripts are meant to be small and light, I'm a programmer so I know what I'm doing. It wont be too bad surely?
Part of the big attraction of scripting languages is they allow changes to be made to the game without a recompile. That implies you don't really need the programmer writing the script, I mean if I'm writing all the script why don't I just do it in C++? So now you have a very delicate error prone system being used by non-programmers. I would hope any programmer reading this would now be very scared.
It isn't all doom and gloom though:
Make sure you spend a lot of time thinking about how you will debug scripts and how you can bullet proof them.
Put a system in place so you can execute any new scripts as easily as possible i.e. a special menu that lets you skip to any point in the game, etc.
If non-programmers are using the script then try and find tech-savy people, write very good documentation, test regularly and make sure these people stay with the project until the end as their experience is priceless.
If a script has more than 50 lines in it then look at it very carefully because you probably need new component tools or to rethink the ones you do have.
Plus, even if the programmer is writing everything it is still worth considering scripts. Hard coding things into the game will have a tendency to make the game inflexible, it doesn't have to be that way, but its difficult to stop it happening. As soon as you start using scripts the tendancy will switch and it will feel easier and more natural to create flexible systems. The game becomes "data driven". This means you're creating the intruments not the econductor, he is sitting outside the game code in all those script text files. Scripts are no easy option or silver bullet, embrace them but be prepared!
What about the future?
Windows vista will ship with C# built in, this is a very powerful scripting language Microsoft created. They will also integrate it with Visual Studio which means it should have a powerful debugger just like C++ does now. C# also contains object orientated functionality like C++ which means it does have the ability to express and manage complex systems directly. It can also communicate with DirectX. All this means you could write your entire game in C# and it would run perfectly well. In theory that means you can get the same game in less time, wouldn't that be fantastic. Bear in mind that vista demands and encourages more powerful PC hardware i.e. it's a 64bit operating system with much better support for threads so all those 64bit dual core cpu's will finally get to stretch their legs properly.
There is also an update (will people see it as that?) for C++ called D, it takes a lot of advanced features from the standard template library and integrates them into the language, as well as doing away with explicit memory management by including a garbage collector. On paper it sounds great and when I heard about it I was surprised it hasn't been picked up by Microsoft or GNU and pushed harder (perhaps there are copyright or patent issues). The current implementation can call into C functions so it doesn't mean throwing all your old code and libraries away. It would be easier to use if you could call into C++ code too, perhaps that will be added one day. It is already in serious use too, I believe the new space station manager game shorthike is being developed with it, amongst others.
Digital Mars D
Fost - Mr. Robot Art
As seen last month in placeholder art form, here's the final Hub Room (hopefully an improvement ;) )
We always thought it was important for the hub to be something special, and so every piece of art used in the hub is unique - you could even make a zone out of it if you wanted. Also all the control panels have little animated sections embedded in them. Some things just put a smile on your face when you see them, and all the robots walking around in the hub do that for me :D
We are also starting to use overlay decals on the floor all about the game. These use a 'modulatex2' screen blend mode - basically grey does nothing, white doubles the brightness of whatever is behind it, and black goes black. We can drop these all over the floor to break up the regular patterns a little, and because they use a multiplicative blend mode, they work with whatever lighting is affecting the scene behind them. In the hub they are used to put the Eidolon Insignia on the floor, and zone symbols next to the doors. I'm working on more signage for the rest of the ship - it's something I've wanted to do for many years (wow, I'm sad!) after I saw the fantastic amount of background detail Ron Cobb put into the ship signage for 'Alien'. Ron Cobb has to be my favourite designer of space ship paraphenalia, and he's been a huge influence on me.
This month's mini development tip - Since identifying one of my biggest time losses as being the act of finding files I need on my machine, I've discovered a quick way to get through files alphabetically. When browsing a folder, I always knew you could press any key on the keyboard to skip to that letter, but what I didn't know was that if you press another key quickly enough, it will skip to the first file beginning with that two letter combination. E.g: if you were searching for a file called 'needle.tga' you would press 'n' and 'e' quickly. Great when you are trying to get to one file in a folder full of hundreds. Probably been in Windows since win3.1 and everybody knows, but it was news to me :)
The whole mindcore zone is now starting to look extremely flashy, blinky and stroby (if that's a word :) ). I really wanted to give the mindcore the feel of the ghost hack rooms; since this is where the two games finally come together. So that means lots of time spent fiddling about with texture animation and vertex shader values. we aren't doing anything particularly clever here, just lots of multi-layer texture scrolling combined in different ways. Take the following wall section from the mindcore as an example:
- click image for flash anim...
All the animation is created by scrolling this sinewave texture:
horizontally through the model. The texture is scaled massively along its horizontal axis (u) and scrolled incredibly fast. Each vertical bar is offset slightly and scaled differently so they all flick at different times.
Ghost Hack Sentinels
I've finally started to work on the enemies on ghost hack. They all use lots of morphing animation and texture animation (pretty much like all the backdrop scenery in ghost hack), so they take quite a while to make. Since we are supposed to be inside the ship's computer in data form, everything is represented by abstract shapes, including these attack programs which act like antibodies; cleansing the system of any unwanted intruders (i.e. you :) ). Here's some animations of the current 'wait' states of the models.
*Note: You can click on the pics for a flash animation, but, you'll have to excuse the occasion 'flick' in the animation - whilst the models loop in game, it's impossible to line everything up for a perfect looping video.
Controlled Specular Highlights
For a while, we've had a problem where specular lighting doesn't work in the game, but does in the viewer. It turned out to be the camera position being passed through to the vertex shader differently. Now specular highlights are in, I've gone through and re-exported all the robots so they have an alpha map that controls the reflection. In today's world of self-shadowed normal mapped per-pixel lighting this is a pretty aged technique, but I've always liked having the ability to separate out the specular lighting and control it using texture alpha. You can get a kind of controlled metallicism, and it can all be done in one pass. Basically we are now doing:
Stage1: diffuse lighting, Modulate2x with the texture. Pass through texture alpha to the next stage.
Stage2: specular lighting, modulatealpha_addcolor with current.
So, the texture alpha controls how bright specular highlights are. I think there may be some really old cards that don't support 'modulatealpha_addcolor' mode, but they are pretty much prehistoric. :)
Pretty subtle result, but I like it, you probably can't see a massive difference in the shots, but it looks best in motion.
Specular Control Map
Without Specular Highlights
With Specular Highlights
I've constantly been surprised how well the lighting has turned out in Mr. Robot; now that it's possible to use high polycount models, there's far more subtle light differentiation across a mesh.
Hamish - War Angels
Feburary and March have been busy months for me, unfortunately alot of it hasn't been strictly game development (Talking, planning, organising, designing and so on) so I don't have as much to share as I'd like, but I'll do my best.
Definitely the highlight of the month, I've just taken on board the awesome swedish band Machinae Supremacy, who will now be composing the soundtrack for War Angels. I would go on about the great work they're doing, but I'll let it speak itself. I've uploaded two short song samples which you can hear by following the links below. If you're interested in hearing more from the band they have a huge amount of songs available on their site, specifically the discography section.
Panzerfaust (39 Second Sample)
Lightning War (28 Second Sample)
Making Level 2
When I haven't been dealing with overhead tasks, or playing Battle For Middle Earth 2, I've been hard at work on the second level of War Angels. I decided to do a new map now seeing I had all the required game features to build it from start to finish. Level 1 isn't completely done, but it requires some features that I haven't put into the game yet - indoor maps, sub-objectives, and so on. By going ahead and making Level 2 now I can time how long it's going to take to finish an average map and get a decent estimate on how long this game will take to finish.
Each level is divided into a few sectors for ease of editing. Pictured below is one of the sectors in two stages of development. First I lay out the place in cubes and floor tiles, as seen in figure one. Then I throw it to the game editor where I place enemies and objects and create the 'gameplay' for that particular sector. There's alot of tweaking at this stage, going back to the map / object editor and moving stuff around for the best playability. This takes about a day.
When that's done I go back to the map editor and fill in all the details. This is where it moves from the picture you see on the left to the picture you see on the right. This only takes about two days if I have all the textures I need. Creating new textures will inflate the time I need to create a sector quite a bit, but I haven't measured this properly so I can only speculate about it. Hitting the right balance of creating interesting and varied looking levels without taking years to do so is one of the biggest factors deciding how long the game will take to finish, so it's important to get this done as soon as possible.
Here are some screenshots of the map in action - the levels not completely detailed, but hopefully detailed enough for it to look good.
A new map wouldn't be complete without new enemies to go with it, and here are the most significant ones I've brought in for Level 2:
Mechs have been in the game since as long as I remember, and now I've finally finished them off so they can appear in this map. There's two varieties, the weaker conscript mech which will appear in this mission (pictured), and a stronger Nazi mech with a deadlier selection of weapons which include a chaingun, a flamethrower, a missile launcher and a laser beam. You'll also be able to pilot one at some point in the game which you can see briefly in my last dev diaries video.
These autonomous turrets differ from the norm in that it's usually easier to avoid them than attack them. If you step through their laser detector, or fire at them, they'll retaliate with a burst of highly accurate gunfire. I've been using them to provide some variety to level 2 by breaking it up into small "nazi sections" and "turret sections", one which has you shooting up enemies and the other has you dodging laser beams. There won't be any undestroyable enemies in this game though, so they can be dispatched if you have enough heavy weaponry.
The patrol bots from the first level can now be fitted with gravity generators instead of grenade launchers. These guys will drive up to you and deploy, creating a strong gravitational field around them pulling you in. I came up with this one when one of my friends was running through the first level, and pointed out that you didn't need to fight any of the enemies - you could run past them all to the end without them being able to catch you. With this enemy is place that strategy is going to be alot less effective. I like the idea of enemies who do things to you other than take off your health so expect to see more like this one.
Fost - Mr. Robot Art
The Ripple Effect
- click image for flash anim...
For shaders in the game, I didn't really want to go beyond the vertex shader 1.1 spec if possible. Keeping to that means more hardware T&L cards will be supported, but VS1.1 only allows 128 instruction slots. Of course, it will get emulated on the CPU, and for a game like Mr. Robot, we can probably get away with a fair amount of that, but every little helps.
This however proved difficult with the coolant shader. It was already doing the lighting, and texture scrolling, and scaling of the textures in the vertex shader. The coolant object in Mr. Robot is a 1 tile unit cube scaled to match the appropriate size set in the editor, so I use a multiple of the vertex world position to scale the texture coordinates - that way, the texturing is all at the right scale no matter what size you set the water to be. After all that, there wasn't a lot left to play with, but I wanted to have a mess with putting a 'wobble' into the vertices just to make it a tiny bit more interesting.
A pretty simple way to do this I thought, would be to apply a sine wave to the vertex height, based on the vertex horizontal position + time.
The first thing I did was subdivide the top of the coolant object quite a bit (without any vertices to wobble, it wouldn't look very good at all!) Then after much messing around, I finally got something running at the right scale (Initial tests resulted in screen sized tidal waves :( ). Problem was, it was a little too regular. So, the solution to that is more waves: if you apply lots of waves though a mesh, all at different amplitudes, wavelengths and frequencies, you can make a pretty nice irregular wave pattern. I've actually done this before many years ago with multiple octaves of noise for a pre-renderered water animation. Pretty quickly though, I hit the vertex shader instruction limit, and so whilst I was testing, I dropped out some of the point lights (Mr. Robot supports ambient light, a single directional light, and up to 5 point lights per room).
The problem with this kind of thing, is that it's always a matter of adjusting loads of parameters which all affect each other and so something pretty simple ends up taking all day :( Finally, I whittled it down to 3 sine waves - one running the length of the water, one along the width, and a much finer one at 45 degrees. With a bit of tidying up of the HLSL code, I managed to keep it all inside 128 instructions with all the lights turned on.
The code below is what I'm using - projectedVertex is the vertex in camera space ready for output (I think, not sure I've got the terminology right there :? ) and worldSpaceVertex is the vertex in world space. There's a slight issue in that there's also a small amount of horizontal wobble, but it's so small you can barely see it and is fine for the game. I think it's probably caused by using the wrong matrices to work out the output position, or adding a value to the object in camera space - bear in mind that I'm an artist and not a programmer, so I don't really understand what I'm doing :)
//Sine Wave X
tempY = 0.4*worldSpaceVertex.x; //Scale wavelength (big number=small wavenlength)
tempY = sin(g_time + tempY); //can multiply g_time to increase frequency
tempY *= 2; //Scale Amplitude
projectedVertex.y += tempY; //Add result to vertex position
//Sine Wave Z
tempY = 0.4*worldSpaceVertex.z;
tempY = sin(g_time + tempY);
tempY *= 2;
projectedVertex.y += tempY;
//Sine Wave X+Z
tempY = worldSpaceVertex.x + worldSpaceVertex.z;
tempY = sin(g_time + tempY);
tempY *= 1;
projectedVertex.y += tempY;
//END WAVE EFFECT//
- click image for flash anim...
This was a fun little effect to make for the teleporter. I used to love the really simple teleport effect in Lunar Jetman on the Spectrum, and so this is my mini-homage to that. Just a simple point emitter with very slow moving particles so they have some velocity and they can be velocity aligned. then they are just scaled along one axis - which since they are velocity aligned, and all moving away from a point turns the whole system into a big spiky orange ball.
- click image for flash anim...
You'll have to excuse the 'home movie' shaky camera in the flash anim; it's an artefact of scrolling around for the video, whilst the game camera is also trying to smoothly track the player position. Anyway, it should be possible to see what's going on here. It's an 'X-Ray' type effect, along the lines of many recent RTS games that allow you to see your units through buildings. It works by rendering the robot mesh once looking red and partially transparent, but with 'zenable' set to false (so the shader doesn't use the Z buffer), and then again in a second pass using the standard shader (with Z-Buffer enabled). A little messing around with the order in which things are drawn and we can control whether or not the X-Ray effect will be seen on a per-shader basis.
At this point, I'm not 100% sure if we'll be able to use it as I'll need to re-export any models that we don't want to see the effect on. Probably robots, crates and consoles should still obscure the player. Thankfully it's not necessary, as all the rooms are designed so you don't get confused by to much view-obscuring geometry, but it's a nice little feature for tracking exactly where you are.
More Particle Effect Shots
Asimov taking damage from a hostile robot.
Active waypoint looping effect.
Asimov taking damage in shallow coolant.
Poo Bear - Mr. Robot Programming
Lots of work on ghost hack gaming this month. I'm trying to get all the core functionality working so I can play through it all and finalise the design. To that end I'm trying to get the first part of the game fully working and integrated with ghost hacking. We have two modes that I call "reality" and "hacking". It's very important that they connect together properly so you can move easily between them.
Picking up ghost hack items in the real world and being able to configure them on your avatar.
Other robots giving you objectives to complete that require you to hack into something, recognizing when you do it and the appropriate dialogue firing.
Being blocked by a door in reality, performing a hack, the door opening as a result.
The first ~30 rooms introduce various characters and ease you into learning how the game works both in reality and in hacking. This is the bit I want to get completely working. Even though we don't have all the animations, the models, the items or the frontend screens completed it is important to show the core systems running and meshing together. This is a very powerful development technique in an environment where specifications are nebulous. Some people might find it strange, but developers rarely understand how the entire game will work in detail until it is almost complete. This is usually because the game is implementing ideas that are new to the developers. Note that I didn't say the ideas themselves are new, that happens very rarely indeed. Unless we just make Starscape sequels or games based on our old mainstream titles we will be working with ideas and concepts we haven't implemented before. In that situation you really need focus on getting things working quickly so you can review them.
This prototyping technique continues right through development until all the unknowns are implemented and working. In an ideal world you would create all the prototypes at the start and only when you were happy with everything would you begin production at which point there would be no more unknowns at all. The reality (especially on a tight budget) is the prototypes start out big and flakey and then over the course of the development the prototypes become smaller and more focused as the game locks in on its final form. What I'm doing now with hacking will probably be the last prototype phase in this development. I'm not trying to prove whether hacking works; I've already done that in a much rougher earlier prototype.
I now want questions answered like:
Do all my item ideas work and have I forgotten anything? 'Items' refers the things you use to modify your ghost hacking avatars, like attack programs, defensive upgrades, restoratives, etc.
Do the systems I've designed to synchronise reality and hacking together work as intended? This includes things like when all the avatars die during a hack and you get thrown back into reality and must then search real space for energon pickups you can trade in to buy their runtime lives back.
One of the assumptions I made is that when you complete your hacking objective you'll have to work your way back to an exit to get out. There was no way of testing what that would really be like unless I had a rough prototype.
I needed to know:
How long the hack would take.
How many resources I'd need to get in and out, which corresponds to how much preparation is needed before taking on the hack.
How thrilling it would be "running" for the exit with a damaged party and limited remaining resources.
How annoying it would be to get killed next to the exit.
If this assumption is proved wrong then I have two choices:
Use playtesting to make it easier to get in and out reducing the chance of you being killed near the exit. This means putting things off until the playtesting phase in beta.
Throwing the player out of hacking mode when his objective is complete.
An auto exit on objective complete has an interesting side effect in that it reduces your journey time by 50% and therefore reduces your random encounters by the same amount. This means the hacking part of the game would take half as long. If that was a problem you could just double the size of the circuit maps, but then they are created by hand using a time consuming editor. This is why we need a prototype now, because we must know how big the hacking maps need to be. Especially as some have already been made ;)
Save & Load
I don't actually want players to have to save their game. Eh? Currently we have in game objects called backup points where you can save your "brain" and restore it if anything goes wrong. A slight twist of logic, but I think it works. So the player makes progress up to the next backup point (or waypoint) and then jumps on it and the game saves automatically. So you don't have multiple saves and you don't need to remember where you got to last time. You just start up the game and there you are.
As you strike out for the next waypoint you will have 3 lives which can be exhausted by falling in water or being caught by enemy robots. If you run out of lives you automatically reset to the last waypoint. You can recover your "life" if it gets low by picking up energon units and if you get stuck you can initiate a local reset of the room you are currently in (at any time, for free).
It's another set of ideas that really need prototyping. I'm trying to prevent people going through a loop of explore->die->reload->repeat. Yet I want them to feel the tension of being down to their last nugget of health and desperately searching for that elusive waypoint. A fine balance to achieve indeed.
The way this is implemented requires a copy of your current game save to be loaded into memory. Then, as you progress, the in-memory save is updated with what you have done. If you die or elect to go back to the last waypoint then the in-memory save is thrown away. If you hit a new waypoint then the in-memory save is written to disk and becomes permanent. The amount of information that needs to be recorded is huge. For example: if you move something from one position to another then that needs recording. Anything and everything you can interact with and change in any way needs recording and it all needs to be put back where it was and in its original state if a reset occurs.
I thought it would be interesting to post a shot of the editor in use just to show how truly awful the game can look whilst we are making it :) . We have found that a really good way for us to work is as follows:
I spec out a room design, and start to block it in.
If there are any scenery objects that I require for the room that don't exist yet, I tell Fost, and after we've discussed what it might look like he exports a quick placeholder object of the right size which I use to continue building the level.
As soon as Fost gets round to it, he exports the finished object, and because we've already defined the object (but used a placeholder visual representation) every room that needs it automatically starts looking good the next time the game is fired up.
This saves a lot of time, because we don't have to go through and re-edit the rooms re-inserting finished art. The flipside is it requires a lot of imagination to visualise what the final room could look like.
The picture below is of the 'Hub' room work in progress. It's the central command area for the entire ship, and all sections are accessed from it. Hopefully, Fost will be able to post a comparison shot next month and we'll get to see what it all is supposed to look like - even I don't know yet! If we manage to ship the editor with the game, everyone will have a far better experience than I have, because they'll be able to build rooms using finished artwork and room will looks exactly the same as how you are building it in the editor.
The Eidolon's Central HUB built from placeholder blocks. Note-In case you hadn't guessed, it's not supposed to look this bad!
Tune in next month for the exciting conclusion to 'building the Hub room' ... ;)
Fost - Mr. Robot Art
Set Design - Final Touches.
- click image for flash anim...
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.
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 :)
- click image for flash anim...
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.
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.
- click image for flash anim...
Quite a bit of work has being going into the finale of Mr. Robot this month, I did have some images of HEL (the ship's computer) 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 :)
Poo Bear - Mr. Robot Programming
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:
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.
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.
Fost - Mr. Robot Art
Another hero object we have used in later areas is the Eidolon shuttle. The Eidolon carries several of these for making short scientific expeditions. (Sorry, Asimov can't fly them off though ;) ). I wanted the shuttle to have a small visual link back to the Starscape universe, and so it is designed to look like an earlier model of the Aegis' shuttles from Starscape. It was fun extrapolating the former 2D design into 3D, but it presented a few problems with the collision objects. Static block objects can only be concave boxes on a half height grid. The shuttle had to be designed around this proportion system, and then split up into 6 separate objects each with their own collision. Takes a little while to assemble it in the editor, but it works nicely. I've named the first one Serenity after our TV favourite :)
Assembled Shuttle in game.
Learning C++ - the copy and paste method!
The bane of a game artist's life is usually the editing tool they use. With indie development, there's even less time for programmers to spend making the tools 'friendly' and so editor work is more often than not a case of becoming familiar with what will crash the editor and making sure you don't accidentally do that, and hitting save every five minutes. I can't fail but appreciate that this suffering is necessary - better Poo Bear works on interesting gameplay than have him waste time wading around in editor code he didn't write!
Still, sometimes there are some incredibly minor fixes that could make my life much easier. To this end, I started learning C++ in the only way I know how - hacking around copying bits of code from one place to the other. My previous knowledge of PHP, maxscript and AMOS basic ;) helped me find my way around, and make some small tweaks to the editor.
It's a really bad idea for a non-programmer to start messing about with production code, but I've limited my efforts to the editor in the vain hope I won't destroy everything :) . So far I've changed the way lights are displayed so you get nice, axis aligned wire loops rather than the wireframe ones we had before. I've also added a zoom feature - again, a very basic thing, but we hadn't needed it before I started lighting the rooms. Some interesting lighting effects can be made using really huge lights placed far away, but they were impossible to find without the ability to zoom out. I've also made the editor save the last room it worked on so you can slip right back into what you were doing quickly, and fixed some small bugs where lights were moved around if you resized the room.
All quite small things, but they make my life that bit easier, and put us a bit further down the path to the possibility of releasing the editor. On that note, I've added help buttons and started a compiled html help file (.chm) to the project. Currently, the editor is not releasable*, so I don't want to get everyone's hopes up. I'm keeping as many notes as possible for the help file just in case it becomes possible.
*That's our opinion at Moonpod anyway - we don't like the idea of releasing the editor 'as is' without putting more work into 'bulletproofing' it.
My remaining task list is choc full of small items. I'm basically filling in the blanks. Poo Bear makes a room, and if there's anything unique he needs, he adds it to my list. Since we added a big robot like Samson, we also needed a big door for him to go through. One of the sections in the game also contains an airlock. the airlock in particular ended up being more work than I initially envisaged (Or, I should say, I added a bit more to it than was strictly necessary!). The materials system we have is very capable, but there's no user friendly interface to it. So even adding simple texture scrolling to an object involves quite a bit of messing with the shader. The airlock has 3 separate door sections, and a copy of those doors offset back slightly and darkened to give the impression of depth (remember, doors are built in Mr. Robot from single polygons and use texture scrolling to slide the door out of the way. This means there's no depth to them, but it can be faked with another copy of the doors.). Lining up all these door sections was very difficult because I had to keep resetting rooms and picking up keys to see them open. This is where Lua scripts turned out to be very useful. Poo Bear showed me how to set up the room to open and close the doors on a timer, so the doors perpertually opened and closed. Great for finding visual discrepancies :)
To cap it off, the Airlock also has a basic shader to turn lights on and off, and a slightly more complicated shader that 'camera maps' a texture onto the surface. this is used on a backdrop rectangle that sits outside the doors. As you move around and the camera pans, the space and stars image appears to be locked to the camera, and therefore looks infinitely far away.
Airlock (Left) and Big, Samson Sized Door(Right) in a test room.
The Vacuum (cleaner) Of Space...!
Mini Flash Animation of Dyson the Cleaning Droid.
Meet Dyson - head of the Eidolon's cleaning crew. Dyson has what you would call a 'walk on part' but he was a lot of fun to come up with. Poo Bear's daughter drew me a little picture of a robot with long 'anglepoise' style bendy arms for cleaning up the space ship. I really liked the concept of a futuristic vacuum cleaner robot :) I also love the design ethos behind the products made by the Dyson company. So I came at this design wondering what the people at Dyson would be making in the future :).
Dyson is probably the last robot to go into the game, unless we decide that rooms need something adding to them during play testing.
Final approved Dyson concept design.
Dyson Game Model
Flip ya for real!
Just some quick little art tips. They probably seem obvious and incredibly minor to most people, but every now and then I discover things that make my life easier.
Shorcuts in Photoshop: I've no idea what version it turned up in, or if it's always been there, but in the current version of Photoshop you can edit the shortcut keys. During the texturing process, I end up making loads of selection flips and rotations to construct geometric shapes from basic lines. I added shortcuts for FlipY, FlipX and Rotate 90?. It's amazing how small processes can break your flow of creativity. These 3 shortcuts mean I now just mess about with texture alignment to my heart's content - because it's easy to try things out in an instant.
Never overlap textures: I've made this a golden rull from now on. Sometimes in the past, I've been annoyed how textures won't fit perfectly on a page because of one small part. Sometimes I fix this by re-using the same piece of texture. I'm not talking about texture mirroring here (using the right side of an object mirrored to create the left side), but thinking things like: 'that bit of arm there can be re-used to texture the fingers or hand'. Don't ask me why, it's a mystery, but it just never works! Usually some bit of shading makes the whole thing look fine on one part, and broken on the other. I've stopped doing this, and I'm happier for it!
Relight My Fire!
A continual job on Mr. Robot is lighting the rooms. In theory, I could just use a default ambient light and directional light and save myself some trouble, but I don't think that would really show off the game (plus, it would get a little dull). Besides, I like breaking my own back :)
One thing I've discovered in lighting, is that I can get really nice hue falloffs using two lights in the same position. E.g. one deep orangey-red light with wide range, and a smaller yellowey light. It's obviously double the cost of normal lighting, so I can only really do it in smaller rooms, but I really like the way the hue of the light changes as it falls off.
Although the image has a lot going on, you can probably just make out the lights/ranges and positions:
Poo Bear - Mr. Robot Programming
I've just put the finishing touches on the last section of the ship and I feel like I've just crossed the finishing line of a marathon. I wont say how many separate rooms and corridors and sections the ship has but it's well over a hundred. It would have been easy and quick to just regurgitate different configurations of the same challenge again and again but I decided early on to avoid that at all costs. This is the main reason the game has taken so long to create. The game has a great editor and also makes heavy use of the LUA scripting language; both firsts for us. These tools were essential to hand craft this quantity of unique content, but even with them it was a mountain of work.
Sadly this doesn't mean the game is ready to ship (oh if only that were true!), I still have to setup all the "ghost hacking" battle stages. This is where the robot Asimov must hack into a defended computer system with the help of his comrades. Development is split into phases, you have prototyping, then production, the alpha and finally beta.
Prototyping - is this actually fun? how does the code work? can we build it, create a design document and make the tools?
Production - following the design document go ahead and build everything.
Alpha - bring it all together and get it working properly so you can play through beginning to end and playtest it to hone the fun to its maximum.
Beta - fix all the bugs and get all the ancillary items sorted like installers and websites, etc.
I'd say ghost battles are well into their production phase with the rest of the game now just into the alpha phase. So for the first time I feel I can see the light at the end of the tunnel. Hacking sees you exploring the glowing circuits of various computer brains and secure networks with periodic battles. Ghost battles are turn based and start with each group of adversaries facing off to each other. Asimov and his friends line up on one side and the enemy group into formation on the other. The player then gives orders to Asimov and his friends and then an internal initiative system sees a round kick off with software attack programs flying through the air and I.C.E. breaker attacks smashing into their targets. During the course of the game the hacks get more difficult and Asimov has to power himself up by collecting various upgrades. He also picks up more and more friends for his ghost team along the way.
The LUA scripting has grown into the real backbone of the game code. LUA is a simplified C language that is very easy to use and still allows the author to create very powerful expressive functionality within the game. On its own it cannot interact with the game world so you have to extend the language by providing new commands that allow the script to do things to the game. Getting all the language extensions in took a major time investment, but it has already paid off. It's interesting to compare it to the WarAngels system which went in a lot faster and is much easier to use by non-programmers. It depends what you need in the editing process, with MrRobot each area of the ship is in many ways almost an entirely new game in terms of actual game mechanics. With a mountain of a ship to build I had no choice but to create a powerful scripting system, without which the ship would have had replicated content or been a lot smaller. WarAngels is different and it would have been overkill to do the same thing, adding maybe another 2-3 months onto its schedule for little benefit. In that game the fun comes from exploring the level, finding and using appropriate weapons and ammo, along with the placement, AI and choice of enemy types. Speed and destruction. The right tools for the right job is half the battle.
The command list has grown quite extensive so far:
Hopefully it wont be long until we get the editor in a state players can use it and then they could access exactly the same library of commands when making their own game levels. That would be very cool.
We've just finished some initial testing on the dreaded "built into your motherboard - shared memory" graphics processors that are so prevalent these days. The old ones were terrible, absolutely useless and we had lots of email from people who couldn't understand why no game worked (including ours). The new ones, led by the Intel Graphics Media Accelerator chip (the GMA900) are light years beyond their prehistoric ancestors. Everything works fine and they even support pixel shader 2.0 which is amazing considering how cheap they are, these chips cost pennies and come built-in to bargain basement motherboards. I was so impressed with that particular chip I even tried Doom3 on it and it worked !! Ok I was only running at 640x480 and had everything turned down, but still, an impressive achievement compared to the old Intel eXtreme chips.
Here's a great tip for anyone up against it. The new scientist recently reported the findings of a study looking at how food affects sleep. They found that eating a lot of chilli's every day caused their subjects to require less sleep and remain fully alert longer. It is thought the effects are due to capsaicin, the chemical responsible for peppers' spiciness. It acts on sensors in our brain which control our sleep cycles causing us to spend longer in deep sleep. This mode of sleep usually only lasts for 30mins a night during which you do not dream and it is almost impossible to wake up. Test subjects remained in this state longer. Chilli also cuts the risk of heart disease. So there you go, eat about 30g of chillies a day and get a few extra hours of work done. I tried it and it worked for me.
A Few Room Shots To Keep You Going!
Dyson does some spring cleaning
Asimov ponders what to do. Luckily, the tiny nanomek team are on hand to assist!
Hamish - War Angels
Sorry for the lack of diary updates for those of you who are following the game. I've been working hard converting the game to it's new 3D look over the past few months, so with all the work I've been doing and the lack of substanial screenshot material I didn't manage to start an entry in time. Now that things have settled down and the progress is starting to show I hope I can make an update every month.
Perhaps the biggest advancement I've made on the game in the last few months is from switching to 2D tile-based maps to lightmapped 3D polygonal maps. I was consistently unhappy with the look of my 2D tiles, they were taking a very long time to make and get into the game editor and were taking up alot of disk space. I thought about the limited 3D effects I was already using, then I had an epiphany - why not go the whole way? I did some experimenting with a 3D editor, and after a few weeks I came out with a result that I felt looked alot better, and was alot easier to edit and develop.
I established a good art pipeline with two cheap, independent 3D utilities - Cartography Shop for modelling the levels (placing and texturing all the shapes that make the physical map) and Gile[s] for lightmapping them (Creating a second texture layer over the whole map that is blended over the the top of the original texture map to create lighting and shadows). Both are simple enough for a 3D newbie like me to pick up and plug into my game straight away while complex enough to create decent looking game art.
Before I start making the map I go through a rough planning phase. This is the first time in my game development life that I've actually planned levels, but when you have three programs to run your map through to get it up and running in the game I find it's faster to draw it up first. I already have all the level settings jotted down so I know basically what I'm aiming for to start with, the plan is used mainly to plan the way the gameplay flows, where specific art pieces will go (like the park and the mall) and where certain scripts will be executed. The map will probably change radically while it's being made but this serves as a good starting point.
Constructing the map is a 3-phase process, using three different programs. In Figure 1 you can see one of Cartography Shop's 2D viewports, where I lay out the map geometry. Figure 2 is 3D view of CShop where I set the textures for each polygon and scale/rotate them so they fit to the polygons perfectly. Then it gets exported to Gile[s] where I lightmap it. Lightmapping takes quite a while, doing a full level can take an hour, so I break up a level into 5-10 segments so I can test each piece quickly. In Figure 3 you can see the lit map area in Gile[s]. Finally the lit map is exported from Gile[s] into a format the game can read. I run the game in Editor Mode, where I place all the enemies, scripts and other interactive objects. In Figure 4 you can see me playing the completed map segment.
Ultimately converting the maps to 3D was a big success. Unlike tiles which have hundreds of variations, textures are very easy to modify allowing me to tweak them very easily. Computer-calculated lighting looks alot more natural and consistant than my previous attempts at shading and colouring grey buildings and the perspective of it all looks good in motion as you can see in the video at the end of the post. Here's a comparison shot of the old 2D city park and my current 3D park:
Once the map's been made, I have to populate it with interactive objects; mainly enemies. With action games becoming less abstract and increasingly realistic, designing interesting enemies and challenges becomes increasingly difficult. While this game isn't Rainbow Six I still wanted enemies that had a bit of backstory and seem realistic, at least within the game world. When I started the game I designed my enemies like a strategy game - soldier with 10 weapon variations, tank with 3 turret types, humvee and apc with mounted soldier on top, etc. They were all realistic army units, but many were no fun to fight. Tanks, snipers, machine-gunners and other anti-infantry units could kill you in an instant.
With my latest revision of enemies I've put player fun and variety first, and come up with a new three-enemy set for Level 1. Each one requires a different tactic to defeat, and can be combined together requiring you to use multiple tactics in the same battle. I've also managed to give them a background and purpose in the game world, which won't be readily apparent to the player, but certainly helps make the world feel coherent and detailed to me, which will hopefully show through with the dialogue and story.
Conscripts will be the first type of infantry you fight. They are not true Nazis, but rather people forced into the army when their country was re-conquered by the Nazi army. Not being Aryan they are looked down upon by the real Nazis, and forced into their own divison of the army (identifyable by their blue uniform and yellow V logo) where they are equipped with cheap and often ineffective weaponry. The Nazis use this divison either as meat-shields at the front of an invasion, or in the case of the first level, backwater occupation forces with a low risk of combat. They are not well trained, or often not trained at all, and therefore very weak and cowardly. They will often try and run away when you kill the rest of their squad.
Gameplay wise they are the pefect enemy to start the game with. Easy and fun to kill. There are four or five variations of the troops, with riot gear like shields, batons or grenade launchers. Most troops can be fought in the same manner however - keep your distance, and kill them before they can get close enough to hit you.
The patrol bot was developed to aid Nazi conscript occupation forces in subduing civil unrest and rioting. It can be programmed to autonomously patrol the streets attacking percieved threats, instilling fear and obedience in the citizens of conquered cities. It functions well against rioting civilians, with light armour and an area-of-effect grenade launcher (although it can be equipped with other weapons). Its threat to you is minimal however, and will be taken down easily with high-calibre weapons or explosives.
One enemy type alone doesn't keep the player interested for long, so I made this enemy to compliment the soldiers on Level 1. It is relatively fast so strafing this enemy is more effective than running. It also introduces the player to the concept of armour types early - your team-mates will point out that grenades will destroy them much quicker than bullets will.
Deployable Missile Turret
This deployable missile turret shoots two guided rockets at once, and is used against tanks and low-flying aircraft. Their heat-seeking guidance system won't work on people however, so if you fight them alone they can be taken out with relative ease.
I was previously using machine gunners as mounted enemies for the first level, but these proved to be much more interesting. Missiles are slower than bullets but more deadly, so the player must pick them out of the crowd and dodge them on top of whatever else they're doing. And once you kill them, you can get on their turret and use it yourself. Letting the player use a big gun early on in the game definitely helps sell them on it.
On the programming side of things, I've recently had to write an external scripting system for special in-game events and dialogue. It had to be flexible enough to use for any sort of scene I needed to program in game, and easy enough for script translators to go through and change/add/remove all the dialog. The scripts are all written in an external text file then parsed into the game when it loads up. Here's an example script I've been using to test:
Say Captain #Sup doods#
Say Rayne #Hello#
Say Captain #I'm walking to this spot over here#
Move Captain TestZone
ZoneWait Captain TestZone
Say Captain #I have arrived#
say Rayne #Great work!#
the 'Say' command will make an in-game message box pop up, with the specified character portrait and it will display the specified message. 'Wait' will wait for a certain amount of milliseconds. With these two commands I can create dialog between characters. Aswell as being able make conversations, the script can currently move characters to places with the 'Move' command.
In the game there will be an invisible trigger area set to start the script - in this case 'TestScript'. Other areas like 'TestZone' and characters like 'Captain' and 'Rayne' are also defined in the in-game editor. When the script is started, it will go through and execute each command in order. With simple conditions like 'Zonewait' which waits for an object to reach the specified zone, I have quite a powerful mini-programming language for me, a scriptwriter or a translator to develop the ingame story with.
I've decided to show a short video of the game if possible each month. I'll start off with a much longer preview of the first map (with a few of the more expensive weapons). Right-click the picture to download (18 meg):
Just a quick note: sorry about the slow image loading some people may be experiencing when reading this. Most of the staff at our ISP have been evacuated due to hurricane warnings, and there's nobody available to fix a routing issue. Hopefully it should be cleared up in a few days, and may not even be an issue depending on where you live...
Right - this entry brings us up to date with the current state of the project! So updates will be a lot slower as we have to chug though our monthly workload!
Fost - Art
Mini Flash Animation of backfacing doors
It's always the simple things that turn out to be hard to implement. This month we came up with a problem with doors. We've had an animating door in the game for a long time - the doors were modelled and moved apart with an animation script. We only had one door in the game however, and I had yet to make the stand-alone door frames that are used on the near sides of a room (where no walls are seen). This, of course, presented a problem; we still needed to show locked free standing doors, but when you unlock them, the doors have no walls to hide behind when they slide apart :(.
We tried using multi-part shutters to make the collapsed doors thin enough to be hidden, but the whole thing shimmered badly because of the number of parts, and still didn't quite fit. Then we tried morphing the doors apart, but I couldn't put enough vertices in to stop the texture from warping. Whilst toying with the idea of dropping door animations altogether and just having the doors pop open (not our favourite solution, but time is always pressing as an indie developer, so you have to think about such things), we came up with the idea of sliding the doors apart using texture animation. One edge of the door texture uses texture alpha to go transparent and the material is clamped (which stops tiling, so you don't end up just scrolling on more doors :) ).
It actually ended up looking as good as the original doors - I'd been convinced it would look rubbish so at least there was a happy end to the problem.
Door Types - Open+Free Standing(Bottom Left), Open(Top Left), Locked(Central), Free Standing+Locked(Right)
Female(ish!) Droid Meet Zelda - the Eidolon repair droid. She's the robot equivalent of a nurse - although I suppose that's more of a mechanic or a technician. Zelda is an important character in the game, as due to circumstances you will encounter early on, Zelda will be available via comm link to help you on your adventure.
Whilst Raistlin robot proved to be a quick design job, Zelda presented me with a few problems at the concept stage. We wanted Zelda to be a fembot, and so vaguely feminine yet still be in keeping with the design of the other robots (Which are anthropoidal, but not of human proportion). I tried to find as many pictures of female robots as I could (google image search is a research godsend!) but they all seemed to just recreate women in metal form - pretty just making a picture of a sexy lady but with silver skin and a few bolts poking out in the right places :). I didn't want to make Zelda into a Sorayama style sexy robot, (she's a functional working robot, she just happens to have a feminine personality programmed in), so I had to come up with a new idea of what would make her look feminine.
After lots and lots of doodles, The key seemed to be her proportions - pushed out chest, slim waist, wide hips (Zelda has a big booty!). On top of that, I added knee boot shaped lower legs, and some pigtail-esque head antenna. Hopefully the end result has an air of feminity about it, although I realise it is still not blatantly 'fembot'.
Despite being a little padded out in certain areas ;) Zelda is extremely light-weight chassis, and part of the tutorial will be Asimov helping her out with some heavy duty work she can't take care of.
Zelda Game Model Render.
Final approved Zelda concept design.
Zelda Roughs: All those years at school doodling in my maths book when
I should have been working were useful training after all!
Centerfold We need to get the box cover art sent to the printers as soon as we can. Most print works are inundated with corporate holiday season cards at this time of year, and so there can be big delays on anything sent in. I've just started initial design work, although I still need to finish some of the key characters in the game so they can be included in the cover art.
We also need to get some new Starscape box covers printed out as they've run out much faster than we anticipated. Certain places we advertise with seem to generate a higher than average CD/download sales ratio. Still haven't quite worked out that one, but I can't argue with the figures - some sites definitely attract a crowd of people who love their hard copies! I'll be changing the existing box design for Starscape - I'd like to put the characters onto the cover, and also have both boxes styled in a similar fashion, so I'm trying to develop a layout we can use for all our box covers. I'm a big fan of box covers from the 8-Bit gaming era, and in particular, I loved the later big box designs that Ultimate put out. They all followed a basic layout, yet looked really individual.
Classic box designs from the 8-Bit era by Ultimate.
Rough layout, cover image still to be decided.
Poo Bear - Programming
Design by Wiki On a whim, and inspired by the work Starscape players have already put into the wikipedia entry for Starscape, I installed mediawiki. It has turned out to be a really cool way to explore game ideas. Any ideas that we discuss, no matter how small can get their own page. This might start off with a one sentence description, but grow into a full design doc, even with multiple variants of the same design.
Since it's also accessible from both work and home, it allows one to quickly add ideas as they pop into your head. Works much better than using a private area of the forum too, since you can lay everything out with contents pages/upload images much easier, and the whole thing seems to have a development friendly layout.
We are building up a nice little repository of game designs and ideas, and are even moving over some of our old design work as it's nice to have all our plans collated into one interlinked space. Sometimes, it's worth the effort to try out new ways of working, the wiki immediately felt like the right way to do things and within a few days has really taken off. If you are working on any game project, and especially one where the design is a collaborative effort, I strongly recommend trying out a wiki system and seeing if it is of any benefit.
Textures Too Good for the Game Something which rarely crops up with modern games is having textures which are higher resolution than can actually be seen in the game. We had to put mipmaps in quite late due to some scheduling wrangles, but when they went in, we noticed they were a little bit blurry. Fost creates all his artwork at a higher resolution than is needed (we've worked on several projects where the artists were asked to produce higher resolution versions of the artwork towards the end of the project, which left most of them mentally scarred :) ), so it was likely the textures were never being displayed at anything other than their second mipmap level. To test this, we run the game at 1600X1200 (the greater the screen size, the more likely the game will show top level textures) and fill the mipmaps with flat colours. So if you can see the original texture, then it is being displayed at its best, red is the next level down, blue the second mipmap, and so on.
If you look at the following comparison image, you can see that only the walls are showing some of the original texture though, and even then it is only when they are very close. The floors will need their texture sizes halving, and the player model looks like it will need the texture size quartering. Whilst this might sound like you will be missing out on the best textures, you would never have seen them anyway. It will in fact improve image quality throughout the scene - allowing the higher resolution maps to come to the fore more often.
Online update I finished adding the code to let the game communicate with our website which allows the player to unlock the demo version and check for updates with just the click of a button. Most games communicate via TCP/IP or UDP, but when such a connection is first established it will cause the WindowsXP firewall to pop up and making alarming comments. So instead we are using standard web page style requests via port 80 which is much more acceptable to firewalls and they usually keep quiet about it.
Automatically updating the game was tricky as it means overwriting files that Windows may have locked because they are currently in use (like the main exe) and handling the fact the update may fail part way through. My approach is:
1. download and unpack the entire update into a seperate location. If it fails then it doesn't matter.
2. exit the game, start up a seperate application allowing windows to release any file locks.
3. copy the update over the game and then delete the seperate update folder.
4. exit and restart the game.
To write the little app that does the file copying and deleting I used some open source software called wxWidgets. Why bother? Well wxWidgets provides free cross platform code for doing all manner of windozey type things so this little app will work on windows or linux or mac. Should come in very handy for the future, always good to be prepared. I wanted to get more familiar with wxWidgets anyway as it allows you to create just about any type of Windows style app you can think of, but has a simpler interface that is easier to learn than Windows, never mind being cross platform. I'll use this for creating future game editors I think.
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.
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.
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.
Fost - Art
Move Your Body Goober finished animation support a while back, but I didn't have time then to test it. We are using the MD3 model format (from Quake III) for animated models only. There's some limitations compared to our own format, such as no vertex colours/multiple uv sets, but it supports animation frames, and more importantly, there's a lot of existing, cheap/free animation programs out there that also support MD3. There was a lot of free loader code knocking around which meant Goober could get something up and running quickly.
Getting a model into the game is not as simple as just exporting it because we have to tag the MD3 with our own shader system files, so there's also a separate text file that sets that up. For my first animation I again tried using a bunch of separate meshes exported from wings 3d. I have to say - I would never recommend anyone try this :) It's the worst way you could animate EVER! Basically I'm getting animation out of a modelling package that doesn't support animation. I export each model to a numbered set of moonpod models, and then use a commandline tool that Goober has written to compile the MD3.
This is truly awful, not just because the export process is slow (even when using lots of batch files to automate it), but because you have to animate each frame in isolation, and you can't see the others. I ended up making a pencil rough of the animation on paper, scanning each frame, and then using it as a backdrop to line everything up. then if anything looked odd on the pencil test, I could take a screengrab of the model, print it out, sketch over it on my lightbox, and adjust bits until the pencil test looked good. Then I can use that as a backdrop in wings3d to line up all the objects.
Incidentally, at this point, I must publicly thank Stan Hayward, creator of Henry's Cat, for the valuable animation talk he did on the BBC many years ago. I just had a look and found that Stan has loads of 'getting started' animation lessons here
Animation Pencil Test
Anyway, that's obviously not going to work as a plan for animating the rest of the Mr Robot models, so I need to investigate budget modelling/animation packages. We bought a copy of milkshape ages ago, and I've been putting off learning anything about it, but it does seem to have everything I need to do animation properly and also exports direct to MD3. I'll probably still continue to model using wings3D (I've gotten pretty comfortable with Wings3D over the past few years), and then animate using milkshape. I seem to have a knack for inventing convoluted art pipelines :)
Here's the result of a lot of effort - a 16 frame walk cycle :)
(2.5 meg flash video)
ORGUS: A Brain The Size Of A Planet! We have quite a lot of robots now, but, you can never have enough! Here's our latest addition to the friendly bots on the ship, meet Orgus!
I often model the robots after an initial rough (I call them toilet roll doodles:)) because it gives me enough of a silhouette to know I'll like the end result.
For friendly bots, I tend to work this up into a far more detailed picture - they have for more personality than the enemy bots(I hope!), and it's important to me to get that across. The enemy robots are deliberately 'soulless' and I can usually nail them with a quick scribble.
Orgus Concept Art Stages
Orgus' design is based on how I'd always imagined Marvin the robot should have looked when I read 'The Hithchiker's Guide To The Galaxy'; essentially an enormous brain with legs and arms.
Orgus is slow and weak in the physical world, but will come into his own during ghost hack where the processing power he has available can kick butt!
Orgus Final Game Model
Water Vertex Shaders Not the most interesting way to use vertex shaders, but we've used a vertex shader to scale the textures up and down with water blocks. this means that no matter what size you make them in the editor, they always come out looking the same.
Poo Bear - Programming
Battle Control Battle mode brought with it quite a large management overhead in menu screens as I discussed in our last journal entry and now we have the second menu screen load to implement. This time we need mini-screens within the actual battle for things like:
deciding what each of your avatars is going to do in the next round.
changing the currently equipped items (ice and ice_breakers).
selecting a program to fire off.
selecting a carried item to use.
selecting a special attack.
Menu screens are a real pain, they aren't the most exciting aspect of development yet they are vital to the players experience. They don't usually contribute to the fun but they can easily get in the way of the fun and therefore a lot of care needs to be taken in their development. A lot of the functions within a battle are streamlined replications of the larger menu screens done previously. Why bother? why not just make the player switch to those other more detailed screens? That would have been easier but it would certainly have got in the way of the fun. It would have meant bringing up a full screen menu right in the middle of a battle; not a good idea. Menu screens are a tool to let the player operate and interface with the game, they must be intuitive, enabling and transparent. When the game goes beta we'll enter a cycle of user testing and alteration, not just to fix bugs but to make sure the menus don't get in the way.
Streamlining Workflow If you ever want to give yourself a shock then take one work day and try and analyze your efficiency and work rate. It is difficult to do because if you consciously try and analyze what you are doing from minute to minute it will affect the results. How much time do you spend chatting with colleagues, eating snacks, at lunch, reading emails, browsing the net, day dreaming, writing emails, checking the newsgroups, going to the toilet, in meetings? Now take into account that the human mind cannot stay focused and concentrated on a specific task for long periods and that once distracted it can take up to 15mins to re-enter "the zone" - a fully concentrated state of mind. So before we've even looked at the tools we use we have an uphill battle just to get a decent amount of work minutes each day. Now consider what you are actually doing and how worthwhile it is. Whether you are an artist or a programmer you will spend your time making minor changes and then reviewing them in action. You tweak a texture on a model, save it, export it, run the game, load it, get to the point where the object in question exists, use it, review it, repeat. Same thing happens with code, alter something, compile a new exe, run the game, get to the point where you can see the change, review it, repeat. The bigger the game gets the slower this loop becomes. If you manage to get 2 hours of useful work a day (yes it can easily be that small) how much is spent clicking buttons, waiting for compiles to finish, loading saves, navigating to a certain point in the game? How much of that super valuable focused work time is wasted? The key to maximising work time in game development is fairly obvious:
let the game reload everything on the spot without having to turn it off and restart.
put the minimum number of clicks between starting any operation and completing it.
Automate everything assuming the normal best practice, if there are unusual cases then add provision for handling them but don't break a smooth automated process just because 1 time in 10 a user needs to make a decision.
Put time into tools, they are boring and dull but are vital. The easier it is to do something the faster you can do it. The faster it is to do something the more likely you are to have time to experiment. The more experimentation is done the more unique gameplay emerges making a better game.
Use scripts and initialization files wherever possible, if changing something means recompiling then only a programmer can do it, it will take time and therefore it wont happen most of the time.
LUA scripting This month as part of that mantra we've started putting in the LUA scripts that operate any unique functionality in a room. A room doesn't need a script as most things happen automatically i.e. running, jumping, pushing switches, getting killed. However, if that was all there was to it it would be a little clinical so when we want people to talk to you or something unusual to happen we put it in a script. That way a programmer doesn't have to write it or test it, all he has to do is provide support functionality in the form of a suite of functions the script can call that make things happen (that's my next pile of work spoken for then ;)).
We've also been implementing one-click context sensitive reloading, this means whatever you are looking at in the game you just need to hit one button to make it all reload.
Player Animation The game now supports morph target animation so this month I built a player that allows us to load a range of animations and control how they are played back and tweened. Tweening blends two animations together, this is how you smoothly get from walking to jumping.
Ghost Hack Battle Enhancements I've also been adding some more advanced features to battle mode character development. Your avatars will grow in skill based on their actions while fighting, but the player will also win "upgrades" which he can use to increase abilities like attack and defence and therefore customize his characters to his own preference.
Another layer of strategy is provided by special attacks which must be charged up before they can be used. Each character has unique special attacks which are very powerful but take a long time to charge. You can only do one at once so you could get all your avatars fully charged before a particularly difficult hack or just get lucky when things look bleak and pull off a signature move to save the day.
Goober - Programming
Clumps Previously the room rendering just worked its way through all the objects in the room, found out what model they wanted to use to render (if any) and created an instance of that model for them to use. This is ok for smaller rooms, but once rooms get to any decent size, and contain a large number of blocks, rendering time increases to a point where it's just not going to work out on lower end hardware. This isn't an issue with polygon counts or shader complexity, just a simple fact that we're calling the rendering API's draw function lots of times per frame, which is pretty inefficient. In some cases you just have to do that, and there's nothing you can do about it (like if different models have different shaders or textures), but a lot of the rooms use a small set of models instantiated lots of times, this is where clumping comes in useful. Essentially what you do is instead of creating lots of individual mesh instances, you create one big vertex buffer and pre-instance the model you want into this big vertex buffer. Then when you want to render you just fire the big vertex buffer at the rendering API and it has a decent amount of work to do per draw call, so you amortize the overhead of the draw call itself across a number of models. This is all in now and works automatically, aside from us having to tag which objects are allowed to clump and which aren't, and has worked out to be a good win in terms of rendering time per frame, to the extent that the debug version (at least on our development PCs) runs at intended frame rate again, with some headroom, rather than looking like the main character is moving through treacle. This bodes well for the game running well on lower spec configurations.
Animated Meshes As you can see in Fost's update, animated meshes are in and working. My part of the work has been done for a while, but it's only when systems start to get used in earnest do you see obvious cases where things can be improved. In this case it was just simply making them easier to use from the game code point of view, and making any loading errors more obvious to the user (so Fost can see what might be wrong when loading a new file).
Particle System Next up, and taking longer than I had hoped, is a simple particle system for effects and such. I have a basic system working, but it needs more flexibility to be really useful. Hopefully it'll be at a state where it's usable by Fost and Poo Bear, and at that point we'll have more idea of what other features might be required for it to be useful in the final, shippable game.
Fost - Art
Growing Pains Spent a lot of time dealing with print work and and overcoming issues getting various bits of artwork into the game. Something I'm looking forward to on future projects is having a mature - production proven toolset; we've always had entirely new engine and tools for every game we've made, so there's always going to be delays whilst certain things don't work as expected. Even existing code can be an issue on new projects - Mr. Robot reuses the gui system from Starscape, but pushes it in some new directions. Things you thought would just work usually don't when you try anything that wasn't used on Starscape. The gui system has been causing Goober a long list of headaches. Just simple stuff like hitting the limits on window and button styles, non-square borders not working for said components, changing the highlighting system messed up fonts a little and so on. Stuff you just can't predict until you start to use it - all of which adds up to delaying myself and adding to Goober's workload. Whilst there's always going to be new stuff coming in, it will be nice to have some of the basics out of the way on post Mr. Robot projects.
Someone asked me for a wallpaper of the 'Maniac' enemies, so I knocked one up.
New Logo Our front end screen will have a looping backdrop of the Eidolon (the space ship aboard which Mr Robot is set). After I mocked up how this should look, it was clear that a more 3 dimensional logo would look better in the front end. This resulted in a new logo for Mr. Robot:
Mr Robot/New Starscape CD Designs It's quite exciting receiving final print designs through the door, really feels like you have a final product almost within reach! We want to get all the printed parts for the CD-ROM package sorted out well in advance of release (print bureaus in the UK are notoriously random with their turnaround times - although the cd printing company we use is really great.) Also our stocks of Starscape cds are running pretty low so we needed to get some more manufactured. It thought it would be nice to come up with a new and hopefully more eyecatching design.
I went through a couple of test prints with the bureau - colour match up was spot on but brightness levels were pretty low. Here's my technique for handling this:
Open the source file in Photoshop and zoom until it;s about the same size on screen as the physical media..
Take the sample you received back from the bureau and hold it up to the screen.
Add a levels layer in photoshop and drag the grey point down to darken the image until it matches the sample.
Now add another levels layer, and drag the grey point up until you are happy with the brightness level.
Turn off the previous levels layer (the one you used to darken the image with) and the result should be what you need to resend to the print bureau.
There's far more accurate ways to colour match - but they can be complicated, and the above always seem to work for me (the only safe thing to do is keep ordering test samples until you are happy.)
Black Amaray Shortage Ran out of DVD cases this month, and when I went to our usual supplier, the case quality they had was pretty dire (most cheap cases come out of China, and only a few of the Chinese brands seem to be any good.) I decided I'd have another look around and see if I could find a good supplier of Amaray brand cases (Amaray's are always top quality, but usually extortionately priced unless you want to buy enough of them to fill my house [rolleyes] ). currently, it seems impossible to get hold of black Amaray cases, although suspiciously we managed to get a pretty good deal on some lime green cases (anyone any guesses why there are lots of xbox coloured cases available??). Coloured cases are normally much more expensive, but these only cost a little extra, though we did have to buy a pretty big order to get the prices down. It was worth it though - the cases are top quality, and coloured ones are extra cool :)
Hopefully nobody will try popping Starscape in their Xbox by mistake :)
Ghost Hack Gui Now that we have ghost hack and it runs on Asimov's PDA, the whole thing needs it's own gui system, so I've been working up new sets of bitmap fonts and new windows/button styles.
Z80 Robo Whilst thinking up some ideas for secret in the game, we came up with a unending list of crazy ideas. One of the most bizarre was the idea of a room containing a ZX spectrum - if you click the use button near it, it will play out audio that if piped into a real ZX Spectrum (or emulator that supports audio input) will run a small spectrum program and display an image. We all laughed at the idea - but saying it can't be done usually makes me at least research the matter! thanks to some wonderful people on comp.sys.sinclair I managed to build this spectrum TAP file (turn off fast load in emulators for full on nostalgia effect :) )
I also got talking to one a guy in the UK who makes spectrum games and demos, and we are hoping to get a little Z80 based minigame up and running!
Hopefully we'll be able to come up with some way to link this into the main game - maybe the image will contain a security code to open a door to a room with a useful item.
Poo Bear - Programming
Ghost Battles Now that I can set up component maps for you to wonder around I needed to actually implement the hacking / confrontation bit. I've seen this done before in various types of mini-game and always found it a bit lacking. Being a Japanese turn based battle game fan I decided to envision hacking as "ghost" versions of the main characters, their brain maps or software souls, battling it out against other software entities inside the ships "net".
Each component on the map may or may not trigger a battle that takes place in an arena that resembles the inside of that component.
It looks straightforward and hopefully the gameplay will need little explanation, each of your ghosts or avatars can be ordered to do something and when you're ready every avatar (good and bad) takes an action ordered by their initiative. Avatars can try to physically infect their opponent or launch a remote program at their enemy. Secondary actions like running away or enhancing a compatriot are also supported. If the player wins he grows more powerful and there is a chance he will get something like a software upgrade or energon (a commodity useful in ghost hacking and also in real space).
Battle Management The downside to all this is the need for a lot of management screens which take a long time to put together. A lot of the fun comes from deciding what type of ghost's to take into battle and how they should be configured. That means the player is performing quite complex actions which means taking a lot of time to make sure these screens are easy to use. There is also a certain amount of duplication, you need full detailed control of your ghost's outside of a battle, but you also need a lot of similar streamlined functionality within the battle (i.e. changing one software upgrade to another, picking a program to launch, activating a carried process, etc).
Currently I'm working on the "outside a battle" management screens.
Bringing the two games together Melding two different genres together seamlessly is very difficult, but enormously beneficial (if it works) as you get a richer play experience. One of the many ways in which the two game modes overlap and are tied together is by presentation. Asimov carries a PDA (personal digital assistant) that defines the look of the ingame HUD (head up display) and it is through this medium that he manages all his ghosts, checks the ship map, navigates the battle map and conducts actual battles. So at all times the ship room you are in is visible and sometimes you'll probably still be able to see Asimov stood next to the console he is jacking into. You always use the same PDA. Along with gameplay overlap like shared Energon usage and picking up software upgrades in the ship, this helps bind the two game modes together into one experience. The other important design constraint is to keep both game types at a relatively easy difficulty level, having really tough battles or nightmarish rooms to navigate is fine as long as either they aren't necessary to finishing or there is an alternate way through. An alternate route could even mean having the option to hack your way past a difficult room i.e. upload into the net at one side and download into a spare Asimov chassis on the other. It works both ways too, if a door can be hacked open but the battle is meant to be tough then you could have a key available in a nearby room that can be used instead. Making this happen isn't always easy and generates extra work, but it can let people go through the game favouring one play style or another and could mean if they get stuck or bored of one mode they can switch to the other.
Goober - Programming
Multiple Scene Rendering As mentioned in Poo Bear's diary, we needed a way to retain the previous rendered scene and also render a completely separate new scene over the top. One option would be to just render everything each frame, but the worry is that will lead to performance issues on lower spec hardware. So the obvious solution then is to grab the scene "underneath" to a texture somehow and just render it as a single quad before rendering the new scene over the top. Sounds simple enough, and it is, but it's worth noting just how bad some solutions are.
Render To Texture Ultimately I went with rendering to a texture, it's fast, it works no problem, and should be fine on any hardware provided the render target "fits" within the caps for the device. The caveat is that the rendered scene can only be as big as the biggest texture that the device can handle, so conceivably you could end up in a situation where the game is rendering to a really high resolution window/screen usually, but has to punt down to a 256^2 texture when it wants to store the back buffer. Unlikely, but possible. The redeeming feature of that is that the texture ends up getting blurred out by bilinear filtering, which looks reasonably good actually and helps to affirm what part of the game is currently active.
Before I went with rendering to a texture I tried just grabbing the front buffer/back buffer data directly. I wasn't particularly hopeful of either of these, but I thought I could get something working quickly and see how it performed. I couldn't believe just how bad performance was with both of these methods, far worse than I'd have ever expected. I'm not talking about tens or even hundreds of milliseconds but actual seconds, and multiple seconds at that. Now, we're only doing this grab once every now and again when the user enters the ghost hack part of the game, but it was enough pause that it was downright disturbing and broke the flow of the game completely. I guess the moral of the story is, don't get data back from the graphics card unless you *absolutely* have to (or unless you can guarantee you're running on PCI-Express equipped hardware).
GUI Pain As Fost mentions in his diary, a large part of time this month has also been spent just making sure the UI code works with what Poo Bear and Fost want to do. Initially it was just supposed to be a simple UI system that could support what we needed to do in Starscape, but it's since grown into something more, complete with bugs and missing features. Still, it's better than no UI system at all (just ;)).
Fost - Art
Scary Lighting I'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 Hack The 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 Components Initially 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 Fetching I'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 Hacking Mr. 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 Response There'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
Camera Another 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.
Fost - Art
Violet Zemanova Finished preliminary work on the first of Mr. Robot's human characters: Violet Zemanova, captain of the Eidolon (the space ship on board which Mr Robot is set)
I always end up spending more time on the characters than I think I will. It's often hard to justify the time spent on them - whilst they might add buckets in terms of the atmosphere and immersiveness of a game, they generally add nothing to its gameplay. I really love working on them, but at the end of the day we aren't making movies, so I can't justify too many hours on them.
You will be able to talk to the Eidolon's command crew - who are in a semi-thawed state (there's a better explanantion of this when you play the game - it makes sense - honest ;) ), but they are essentially incapacitated and can only offer advice. Humans in Mr. Robot spend most of the game in hypersleep and so take a bit of a back seat to the friendly robot characters you meet.
The Nanomeks are tiny worker robots. I love Huey from 'Silent Running' and wanted to make something along the same lines :D
I also thought it was nice to continue the inspiration of ZX spectrum games
- the nanomeks remind of the robots from Ultimate's PSSST!'
Can't say with 100% certainty exactly how the Nanomeks will feature in game - we are looking at some sort of lemmings/chuchu rocket style gameplay where you have to rearrange the room and let them go.
We've yet to build the levels (I built one which I thought was easy but it proved very hard!)
HUD Work Generally, I'm a fan of minimalist HUDS, but Mark really wanted to have something substantial looking. I was a little against the idea - the obvious thing to do with robots is have rusty cogs everywhere - which never made much sense to me as they are electronic devices, not clockwork. Eventually we came up with the idea of everything looking a bit like Asimov's Personal Data Assistant, and I made a quick hand painted mockup:
I was really happy with the result, so I've been finishing most of that of for the rest of this month:
hopefully it looks a lot better than the placeholder image we've been using (Mark's programmer art ;) )
Poo Bear - Programming
Bug Hunting I've been getting the first zone playable and that means crunching any bugs that have surfaced. Some can be quite subtle like the rounding error that changed the size of the players collision volume by a tiny fractional amount, hard to spot and caused some very strange side effects. Others are a bit more show stopping, but none the less fun to track down, like these:
Why is every object in the world all in one room?
Why is every object in the world all in one room?
If you look closely at the images above you can also spot that there are some little displays in there now, we call these displays the HUD. Whenever I see these go in I know the game is well on its way to completion.
8bit Pain A lot of old classic platformers/puzzlers were really tough, difficult challenges and one mistake and you're dead penalties. I've seen a lot of indie titles doing the same thing and I wonder if that is because the developers remember those old titles. In general this seems out of vogue now; I think Mario64 is the first platformer I remember that really went out of its way to give you a second chance and the possibility of getting some lives back too.
There is a fine line between so easy it's boring, frustratingly hard and the nirvana of a good challenge. Different people have different difficulty thresholds so the task can seem impossible. One way of dealing with it is to provide mechanisms for people to recover health, if you cannot stockpile health and it is found slightly off the beaten track then people know that if things are looking bad they can always go back a step and regroup without having so much health everything is too easy. The most obvious game that does that is FinalFantasy and I tried to do it Starscape too.
In Mr. Robot you will have 3 lives max, if you fall into the water you lose a life and if an enemy robot gets hold of you then you lose a third of a life and get bounced away. Collecting pickups restores a third of your health and if your health is full but you have less than 3 lives then you can start saving pickups for a new life. The end result is if you take your time and back off when you get down to 1 life then you shouldn't have a problem.
Doesn't that mean the slow steady approach is always going to work and be too easy? If we were computers then yes it would, but luckily we aren't that logical. Most humans hate slow and steady, they like to take "comfortable" risks. So when people go through a room they've seen before or when they have a full 3 lives then they cannot help but be a bit more adventurous, move a bit faster and jump a bit further. When people are doing that and it works then they are having fun, the adrenalin is flowing just a tiny bit, endorphins are being released (mmmm opiates :twisted: ) and their onscreen avatar is almost dancing across the screen. If they could do it constantly without danger then it wouldn't be fun, if it almost always resulted in death then that wouldn't be fun either.
Goober - Programming
DirectX Legacy Up to now I had started developing the 3D technology we're using against the DirectX9 API when it first came out, under the assumption we would research DirectX 9 usage figures further into the project. The hope was that by the time we were ready to release anything using it, DX9 would be commonplace, but we knew there was a chance we would have to make the renderer more backwards compatible.
Well, that time has come, and it seems our hopes have been dashed. Poo Bear pointed out some statistics (can't remember where from now, darn) that pointed to the largest number of people with Windows computers using WinXP with service pack1, and having DirectX 8.1 installed. Which means that our graphics library just plain won't work on those systems, period. This is, quite obviously, a bad thing. Backed up by evidence that most people looking at online games won't make any effort to update versions of DirectX or their drivers (unless they're forced to by WindowsUpdate), this is quite serious.
That's my cue to write a DirectX8.1 compatible renderer (as well). The idea is that we have two renderers for a while, until we're confident that everyone is (or, most people are) switched over to DX9, at which point we can drop the DX8.1 support.
First up, I took a good look at the DX9 renderer to try to isolate those parts which were platform independant, and which were platform specific. The platform independant parts were ripped out into their own library (which broke things horribly for a while, thankfully it was only broken for me, Poo Bear and Fost could continue development oblivious to the horrors I was unleashing), and now I've started working on implementing the DX8 platform specific parts. Basically this boils down to setup of the DX8 device (device/mode enumeration, that sort of thing), management of DX objects (vertex/ buffers, vertex/pixel shaders, textures) and handling of our shader files. Thankfully DX9 is very similar in API to DX8. Yes, there are some differences, but essentially they are the same, albeit with slightly different object names. Which means that device enumeration and handling of DX8 objects was pretty simple to code up. The biggest challenge now is writing a shader compiler for the DX8 renderer that is happy to accept shaders designed for DX9 and just work. Mr Robot doesn't use much in the way of DX9 specific features (such as METs or MRTs, or shader versions > 1.1), so the plan here is to have the DX8 library just drop techniques that don't fit into DX8. Inside a shader we have multiple techniques that can be used to render the object, the shader system selects a technique based on its appropriateness (is that a word?) for the platform the game is currently running on. The idea then is to provide multiple techniques that the shader system can choose from, and always providing a technique which is targetted at DX6 class hardware (fixed function pixel pipeline, two textures maximum). Based on these assumptions we should always be able to find a shader that is appropriate for the DX8 system to use, and it saves us having to do nasty translation of shaders from some gargantuan VS/PS3.0 monster down to DX6 class hardware.
The DX8 shader isn't quite done yet, there's a huge amount of code to wade through, but it's getting there. It's a shame I hadn't thought of this when I first sat down to code up a renderer for us, but I guess you live and learn. It's ok for id/Epic/Crytek etc to target bleeding edge stuff, but indies can't rely on their users having installed the latest stuff.
Tools Besides the renderer stuff I've been supporting the editor code to allow Fost and Poo Bear to edit rooms. Mostly this consists of me fixing bugs to adding features that make editing quicker/easier, although we have finalised the lighting system, which means that Fost can go in and light all the rooms to add that finishing touch.
Goober - Programming
I've been getting vertex animated meshes working. Now, some people might think that vertex animation is a bit of a step back, when you consider that skinned meshes are all the rage with the kids these days, but there are good reasons for doing things this way instead. No, really!
Essentially we needed something built quickly, that was efficient. To support doing skinned meshes we (that is, I) would have to have built an animation system to drive the skeleton, plus tools to export the skeletons, the meshes and the animations from whatever DCC (Digital Content Creation) application Fost wanted to use. This is something we do want to do eventually, but it's overkill for this project when you consider the size of the characters on screen, and how much animation they will require (i.e. not that much really). Using vertex animated meshes, we can just export a bunch of static frames from the DCC app and munge them together to get our vertex animated model. But that's still too much work for me :). So I was playing with an MD3 viewer I wrote one day when I realised the answer was literally staring me in the face (with a railgun in hand at the time too). There are a huge number of MD3 exporters and creation tools available, and loads of them are license free, so we can use them to build our data. The MD3 file format is license free, because it's just a file format. So I've taken that MD3 viewer of mine and munged the code into our engine, and it's working nicely, I think. John Carmack has previously spoken about this very subject, using id file formats in other commercial endevours, and his stance was that it's ok as long as you don't use the id code to generate the data. With the vast quantity of 3rd party tools available, I really don't see that as a problem :)
The other cool thing about doing things this way is that I was able to build and test the system without needing to bother Fost for test data. There are a ludicrous number of Quake3 models kicking around on the net, and that was all the test data anyone should ever need :)
If anyone is interested in writing their own MD3 importer/viewer/tool-chain then I got the file format information from this page. It's all pretty straightforward, even the slightly wacky normal encoding :)
Poo Bear - Programming
All the bots are working for the first zone and the player is moving around well, added items you can pickup like keys and the doors they unlock. So the first zone has really come together and I can move around with all the rooms connected together and see how it all gels.
Adding an onscreen map really helps visualize the "world" and getting that to work was quite fun. In the past I've always had maps either created by an artist or you had to run some slow external process to generate it and there was usually some photoshop touching up required. I never did like that so this time I'm generating it on the fly. This means creating a blank texture in memory, updating it every time you walk into a new room and then uploading it to the graphics card. Sounds simple enough, but getting something like that to work fast when the game has never seen the rooms before is tricky. Think about all the possible room designs someone might make, with stairs and odd shapes, holes, doors and goodness knows what. How can the game work out exactly what the floor is to draw it and still get everything to line up and connect? The answer is to pretend you're the robot and recursively visit everywhere that the robot could if it was walking around and just draw where he walks. Nice and future proof, you always have an up to date map when building levels, it's made automatically and it's guarenteed to scale so when you scroll it around it always lines up properly (unlike the ones an artist makes - tsk!).
Here's one the computer made earlier:
Now that things are closer to actually working you start to see the holes in all those lovely levels you made. It sounded good in your head, it made sense on paper and it looked good in the editor. Why then, does it never work when you're playing the game? All of a sudden people are interested now that things are working and it isn't long before there is a long list of bits of the game where people can do something unexpected and then something breaks or they get somewhere they shouldn't. It might only take a day to get something in and working, but it usually takes 5x that long to fix it up and stop people being able to break it.
Asimov hitches a ride...
Initially getting Samson to work we had to use stand-in box objects to see if we could make it work. His entire design had to be collision led. He also needed to be able to turn on the spot easily so he would not rotate his collision volume into other objects, and also provide a front 'platform' for carrying Asimov. If you see the collision objects around Samson, you can see how they have influenced Fost's design:
Asimov being carried by Samson. everything fits nicely into a box and rotates nicely within the box.
Asimov stands on the platform created by Samson's arms. You can see here how Samson's arms have had to be designed to create the 'shelf' that holds Asimov.
Fost - Art
Started the pretty dull but highly necessary task of masking off areas on all the exising scenery objects. This is one of the final 'cracks' that are stopping the game from looking finished (Even though it isn't finished, we are pretty close to having it look like it is.) If the game was 2D then this wouldn't have been a problem, but with 3D you end up with parts poking out of the back of objects. Since the backdrop will be black, I've added geometry resembling black capes and hoods round the backs of any objects that would show through. It's looking really good so far (I was a bit worried this wouldn't work when objects were next to each other - but so far no problems.
I've also been working on a new robot character. I've really been in hog heaven with this one - he's just a big dumb robot! Something I really wanted to do for a long time is a heavy lifting robot (yes I'm sad). This robot started life as an idea to have other robots as allies to the player that would help him on his journey. The first idea we had was a heavy robot called 'Big AL', that the player could essentially use like a moving platform to reach higher with. In the end we renamed him to SAMS-1 (Samson), because everyone kept calling him 'Big Gay AL' (after the South Park Character) :D.
Currently he weighs in at just over 1500 polygons - which is a bit more than he should have, but I love him so much I don't want to remove anything now! Hey - I'll justify it by saying he's a hero character!
Samson concept art
(At this point we didn't have a name for him,
so I called him 'AL-76' after the Isaac Asimov short story :D)
Render of final Game model
This actually shows why you should always try and design things
from the viewpoint they'll be seen in the game.
Samson's big grinning mouth isn't that visible in the game right now.
I might try and do something about that before we release though. Samson Wallpaper
Choosing a lighting mode
Here's some tests I've been doing of the most basic shader setup for lighting. Basic vertex lighting is multiplied (modulated) by the object's texture map, the trouble with this, is the brightest a model can ever get, is the colour of it's texture, and only then on a side directly facing and close to a light. An easy way round this is to use Modulate2X or Modulate 4X in the shader. This means the light can overbright the texture, and helps stop the whole scene being slightly dull. It does mean however, that you have to mess with the lights a little to stop everything looking like a nuke has just gone off. So I wanted to do some tests first to make sure we were using the right shader mode (changing this later would basically mean redoing each room's lighting :cry:)
In the end I decided Modulate 2X gives enough of a brightness range to work with. Modulate 4X adds a little bit more, but it is much harder to set up more subtle colour variations (It is technically not an issue, but it's much harder to 'think' in 4X - especially when you have lots of lights playing off each other - for me at least anyway!)
Modulate 2X lighting
Modulate 4X lighting
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