Jump to content

  • Log In with Google      Sign In   
  • Create Account

The Moonpod Insider



Finished!

Posted by , 10 January 2007 - - - - - - · 225 views

-------------------------
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:

www.moonpod.com/newsletter/

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.

Ongoing Work

Editor Documentation
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.

Huey The Nanomek
Save Huey!
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.
Save Huey The Nanomek: WIP
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:

Moonpod Prototype Moonpod Prototype
Moonpod Prototype Moonpod Prototype


When will it ever end!?

Posted by , 06 December 2006 - - - - - - · 230 views

-------------------------
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.

Mr. Robot: Intro narration voice actress Rebecca Gethings

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 speexspeech 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:
Mr.Robot-Intro.spx

You can play it back with a media player like foobar2000

Beta Experiences

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:

Semi-Isometric Depth Perception issues in Mr. Robot
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.


Trailer Movie Time!

Posted by , 13 November 2006 - - - - - - · 285 views

-------------------------
Fost - Mr. Robot Art
-------------------------
Final trailer is now out:
Mr. Robot Trailer
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 :)
Mr. Robot: Computer Rank Images

Scoring is based on achieving various objectives, and you get a little medal for each:
Mr. Robot: Achievement Medals

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.
Mr. Robot: More Icons

------------------------------------
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.
Image Magick Game Texture: Premultiplied alpha resize problem.


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


Road To Beta

Posted by , 09 October 2006 - - - - - - · 337 views

-------------------------
Fost - Mr. Robot Art
-------------------------

Chat Displays

Mr Robot: Samson In Trouble
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.
Mr Robot Chat Heads!
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

Mr. Robot: Ghost Hack 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

Mr Robot and Starscape 2nd edition DVD covers arrive!

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 £400. If you want 20,000 of a design printing it will cost you £600. However, if you want 2 designs * 20,000, it will cost you £800. The same amount of ink and paper has been burned up, but you have to pay £200 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.

Bug Tracker

Bug TrackerSpeaking 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.

Moonpod Bug Tracker

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.


Hack Attack!

Posted by , 03 September 2006 - - - - - - · 199 views

-------------------------
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 :(

Starscape: Rin Fubuki Paint Up.
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.

Starscape: Second Edition DVD Cover.

That's off to the printers now so hopefully the Starscape 2nd edition CD-ROM should be back in stock soon :)

More Animation

Mr. Robot: I see you baby! Shakin that ass!
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.)

MR. Robot: Ghost Hack Battlemap

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 !

Mr. Robot: Ghost Hack Battlemap tint variations


------------------------------------
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.

Mr. Robot: Ghost Hack Team!
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 :)


These Bots Are Made For Walking!

Posted by , 18 August 2006 - - - - - - · 525 views

-------------------------
Fost - Mr. Robot Art
-------------------------

Cover Story Revisited

Mr. Robot: Robot Rampage!.

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:
4:3
1024X768
1280X1024
1600X1200

16:9
1280X800
1440X900
1680X1050
1920X1200
2560X1600

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 :)

Mr. Robot DVD Cover Variants.

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.
Mr. Robot: Samson Walk TestMr. Robot: Orgus Walk Test
- 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.

Mr. Robot: Raistlin Walk TestMr. Robot: Zelda Walk TestMr. Robot: Stalker Walk Test
- 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!

Mr. Robot: Samson rotoscope frames.


------------------------------------
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:
screen resolution usage statistics

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.

Mr. Robot: Camera aspect ratio comparison of flatpanel VS CRT at 1280 by 1024.

Should be able to support that in all future games, and in an update for Mr. Robot if not at launch :) .


War Angels: Weapons

Posted by , 20 July 2006 - - - - - - · 122 views

-------------------------
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 -
War Angels Guns

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.
War Angels Gun Collage

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.


War Angels APC

Posted by , 17 July 2006 - - - - - - · 130 views

-------------------------
Hamish - War Angels
-------------------------
Seeing I haven't updated in ages, here's some new screenshots (click for big):

War Angels APC 1

War Angels APC 12

War Angels APC 3

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.






August 2016 »

S M T W T F S
 123456
78910111213
14151617181920
2122232425 26 27
28293031   

Recent Entries

Recent Comments

Recent Entries

Recent Comments



PARTNERS