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


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.