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

More Animation

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