Fost - Art
Growing PainsSpent a lot of time dealing with print work and and overcoming issues getting various bits of artwork into the game. Something I'm looking forward to on future projects is having a mature - production proven toolset; we've always had entirely new engine and tools for every game we've made, so there's always going to be delays whilst certain things don't work as expected. Even existing code can be an issue on new projects - Mr. Robot reuses the gui system from Starscape, but pushes it in some new directions. Things you thought would just work usually don't when you try anything that wasn't used on Starscape. The gui system has been causing Goober a long list of headaches. Just simple stuff like hitting the limits on window and button styles, non-square borders not working for said components, changing the highlighting system messed up fonts a little and so on. Stuff you just can't predict until you start to use it - all of which adds up to delaying myself and adding to Goober's workload. Whilst there's always going to be new stuff coming in, it will be nice to have some of the basics out of the way on post Mr. Robot projects.
Someone asked me for a wallpaper of the 'Maniac' enemies, so I knocked one up.
New LogoOur front end screen will have a looping backdrop of the Eidolon (the space ship aboard which Mr Robot is set). After I mocked up how this should look, it was clear that a more 3 dimensional logo would look better in the front end. This resulted in a new logo for Mr. Robot:
Mr Robot/New Starscape CD DesignsIt's quite exciting receiving final print designs through the door, really feels like you have a final product almost within reach! We want to get all the printed parts for the CD-ROM package sorted out well in advance of release (print bureaus in the UK are notoriously random with their turnaround times - although the cd printing company we use is really great.) Also our stocks of Starscape cds are running pretty low so we needed to get some more manufactured. It thought it would be nice to come up with a new and hopefully more eyecatching design.
I went through a couple of test prints with the bureau - colour match up was spot on but brightness levels were pretty low. Here's my technique for handling this:
- Open the source file in Photoshop and zoom until it;s about the same size on screen as the physical media..
- Take the sample you received back from the bureau and hold it up to the screen.
- Add a levels layer in photoshop and drag the grey point down to darken the image until it matches the sample.
- Now add another levels layer, and drag the grey point up until you are happy with the brightness level.
- Turn off the previous levels layer (the one you used to darken the image with) and the result should be what you need to resend to the print bureau.
There's far more accurate ways to colour match - but they can be complicated, and the above always seem to work for me (the only safe thing to do is keep ordering test samples until you are happy.)
Black Amaray ShortageRan out of DVD cases this month, and when I went to our usual supplier, the case quality they had was pretty dire (most cheap cases come out of China, and only a few of the Chinese brands seem to be any good.) I decided I'd have another look around and see if I could find a good supplier of Amaray brand cases (Amaray's are always top quality, but usually extortionately priced unless you want to buy enough of them to fill my house [rolleyes] ). currently, it seems impossible to get hold of black Amaray cases, although suspiciously we managed to get a pretty good deal on some lime green cases (anyone any guesses why there are lots of xbox coloured cases available??). Coloured cases are normally much more expensive, but these only cost a little extra, though we did have to buy a pretty big order to get the prices down. It was worth it though - the cases are top quality, and coloured ones are extra cool :)
Hopefully nobody will try popping Starscape in their Xbox by mistake :)
Ghost Hack GuiNow that we have ghost hack and it runs on Asimov's PDA, the whole thing needs it's own gui system, so I've been working up new sets of bitmap fonts and new windows/button styles.
Z80 RoboWhilst thinking up some ideas for secret in the game, we came up with a unending list of crazy ideas. One of the most bizarre was the idea of a room containing a ZX spectrum - if you click the use button near it, it will play out audio that if piped into a real ZX Spectrum (or emulator that supports audio input) will run a small spectrum program and display an image. We all laughed at the idea - but saying it can't be done usually makes me at least research the matter! thanks to some wonderful people on comp.sys.sinclair I managed to build this spectrum TAP file (turn off fast load in emulators for full on nostalgia effect :) )
I also got talking to one a guy in the UK who makes spectrum games and demos, and we are hoping to get a little Z80 based minigame up and running!
Hopefully we'll be able to come up with some way to link this into the main game - maybe the image will contain a security code to open a door to a room with a useful item.
Poo Bear - Programming
Ghost BattlesNow that I can set up component maps for you to wonder around I needed to actually implement the hacking / confrontation bit. I've seen this done before in various types of mini-game and always found it a bit lacking. Being a Japanese turn based battle game fan I decided to envision hacking as "ghost" versions of the main characters, their brain maps or software souls, battling it out against other software entities inside the ships "net".
Each component on the map may or may not trigger a battle that takes place in an arena that resembles the inside of that component.
It looks straightforward and hopefully the gameplay will need little explanation, each of your ghosts or avatars can be ordered to do something and when you're ready every avatar (good and bad) takes an action ordered by their initiative. Avatars can try to physically infect their opponent or launch a remote program at their enemy. Secondary actions like running away or enhancing a compatriot are also supported. If the player wins he grows more powerful and there is a chance he will get something like a software upgrade or energon (a commodity useful in ghost hacking and also in real space).
Battle ManagementThe downside to all this is the need for a lot of management screens which take a long time to put together. A lot of the fun comes from deciding what type of ghost's to take into battle and how they should be configured. That means the player is performing quite complex actions which means taking a lot of time to make sure these screens are easy to use. There is also a certain amount of duplication, you need full detailed control of your ghost's outside of a battle, but you also need a lot of similar streamlined functionality within the battle (i.e. changing one software upgrade to another, picking a program to launch, activating a carried process, etc).
Currently I'm working on the "outside a battle" management screens.
Bringing the two games togetherMelding two different genres together seamlessly is very difficult, but enormously beneficial (if it works) as you get a richer play experience. One of the many ways in which the two game modes overlap and are tied together is by presentation. Asimov carries a PDA (personal digital assistant) that defines the look of the ingame HUD (head up display) and it is through this medium that he manages all his ghosts, checks the ship map, navigates the battle map and conducts actual battles. So at all times the ship room you are in is visible and sometimes you'll probably still be able to see Asimov stood next to the console he is jacking into. You always use the same PDA. Along with gameplay overlap like shared Energon usage and picking up software upgrades in the ship, this helps bind the two game modes together into one experience. The other important design constraint is to keep both game types at a relatively easy difficulty level, having really tough battles or nightmarish rooms to navigate is fine as long as either they aren't necessary to finishing or there is an alternate way through. An alternate route could even mean having the option to hack your way past a difficult room i.e. upload into the net at one side and download into a spare Asimov chassis on the other. It works both ways too, if a door can be hacked open but the battle is meant to be tough then you could have a key available in a nearby room that can be used instead. Making this happen isn't always easy and generates extra work, but it can let people go through the game favouring one play style or another and could mean if they get stuck or bored of one mode they can switch to the other.
Goober - Programming
Multiple Scene RenderingAs mentioned in Poo Bear's diary, we needed a way to retain the previous rendered scene and also render a completely separate new scene over the top. One option would be to just render everything each frame, but the worry is that will lead to performance issues on lower spec hardware. So the obvious solution then is to grab the scene "underneath" to a texture somehow and just render it as a single quad before rendering the new scene over the top. Sounds simple enough, and it is, but it's worth noting just how bad some solutions are.
Render To TextureUltimately I went with rendering to a texture, it's fast, it works no problem, and should be fine on any hardware provided the render target "fits" within the caps for the device. The caveat is that the rendered scene can only be as big as the biggest texture that the device can handle, so conceivably you could end up in a situation where the game is rendering to a really high resolution window/screen usually, but has to punt down to a 256^2 texture when it wants to store the back buffer. Unlikely, but possible. The redeeming feature of that is that the texture ends up getting blurred out by bilinear filtering, which looks reasonably good actually and helps to affirm what part of the game is currently active.
Before I went with rendering to a texture I tried just grabbing the front buffer/back buffer data directly. I wasn't particularly hopeful of either of these, but I thought I could get something working quickly and see how it performed. I couldn't believe just how bad performance was with both of these methods, far worse than I'd have ever expected. I'm not talking about tens or even hundreds of milliseconds but actual seconds, and multiple seconds at that. Now, we're only doing this grab once every now and again when the user enters the ghost hack part of the game, but it was enough pause that it was downright disturbing and broke the flow of the game completely. I guess the moral of the story is, don't get data back from the graphics card unless you *absolutely* have to (or unless you can guarantee you're running on PCI-Express equipped hardware).