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