-------------------------
Fost - Art
-------------------------
Dastardly Doors
Mini Flash Animation of backfacing doorsIt's always the simple things that turn out to be hard to implement. This month we came up with a problem with doors. We've had an animating door in the game for a long time - the doors were modelled and moved apart with an animation script. We only had one door in the game however, and I had yet to make the stand-alone door frames that are used on the near sides of a room (where no walls are seen). This, of course, presented a problem; we still needed to show locked free standing doors, but when you unlock them, the doors have no walls to hide behind when they slide apart :(.
We tried using multi-part shutters to make the collapsed doors thin enough to be hidden, but the whole thing shimmered badly because of the number of parts, and still didn't quite fit. Then we tried morphing the doors apart, but I couldn't put enough vertices in to stop the texture from warping. Whilst toying with the idea of dropping door animations altogether and just having the doors pop open (not our favourite solution, but time is always pressing as an indie developer, so you have to think about such things), we came up with the idea of sliding the doors apart using texture animation. One edge of the door texture uses texture alpha to go transparent and the material is clamped (which stops tiling, so you don't end up just scrolling on more doors :) ).
It actually ended up looking as good as the original doors - I'd been convinced it would look rubbish so at least there was a happy end to the problem.
Door Types - Open+Free Standing(Bottom Left), Open(Top Left), Locked(Central), Free Standing+Locked(Right)
Female(ish!) Droid
Meet Zelda - the Eidolon repair droid. She's the robot equivalent of a nurse - although I suppose that's more of a mechanic or a technician. Zelda is an important character in the game, as due to circumstances you will encounter early on, Zelda will be available via comm link to help you on your adventure.Whilst Raistlin robot proved to be a quick design job, Zelda presented me with a few problems at the concept stage. We wanted Zelda to be a fembot, and so vaguely feminine yet still be in keeping with the design of the other robots (Which are anthropoidal, but not of human proportion). I tried to find as many pictures of female robots as I could (google image search is a research godsend!) but they all seemed to just recreate women in metal form - pretty just making a picture of a sexy lady but with silver skin and a few bolts poking out in the right places :). I didn't want to make Zelda into a Sorayama style sexy robot, (she's a functional working robot, she just happens to have a feminine personality programmed in), so I had to come up with a new idea of what would make her look feminine.
After lots and lots of doodles, The key seemed to be her proportions - pushed out chest, slim waist, wide hips (Zelda has a big booty!). On top of that, I added knee boot shaped lower legs, and some pigtail-esque head antenna. Hopefully the end result has an air of feminity about it, although I realise it is still not blatantly 'fembot'.
Despite being a little padded out in certain areas ;) Zelda is extremely light-weight chassis, and part of the tutorial will be Asimov helping her out with some heavy duty work she can't take care of.
Zelda Game Model Render.
Final approved Zelda concept design.
Zelda Roughs: All those years at school doodling in my maths book when
I should have been working were useful training after all!
Centerfold
We need to get the box cover art sent to the printers as soon as we can. Most print works are inundated with corporate holiday season cards at this time of year, and so there can be big delays on anything sent in. I've just started initial design work, although I still need to finish some of the key characters in the game so they can be included in the cover art.We also need to get some new Starscape box covers printed out as they've run out much faster than we anticipated. Certain places we advertise with seem to generate a higher than average CD/download sales ratio. Still haven't quite worked out that one, but I can't argue with the figures - some sites definitely attract a crowd of people who love their hard copies! I'll be changing the existing box design for Starscape - I'd like to put the characters onto the cover, and also have both boxes styled in a similar fashion, so I'm trying to develop a layout we can use for all our box covers. I'm a big fan of box covers from the 8-Bit gaming era, and in particular, I loved the later big box designs that Ultimate put out. They all followed a basic layout, yet looked really individual.
Classic box designs from the 8-Bit era by Ultimate.
Rough layout, cover image still to be decided.
-------------------------
Poo Bear - Programming
-------------------------
Design by Wiki
On a whim, and inspired by the work Starscape players have already put into the wikipedia entry for Starscape, I installed mediawiki. It has turned out to be a really cool way to explore game ideas. Any ideas that we discuss, no matter how small can get their own page. This might start off with a one sentence description, but grow into a full design doc, even with multiple variants of the same design.Since it's also accessible from both work and home, it allows one to quickly add ideas as they pop into your head. Works much better than using a private area of the forum too, since you can lay everything out with contents pages/upload images much easier, and the whole thing seems to have a development friendly layout.
We are building up a nice little repository of game designs and ideas, and are even moving over some of our old design work as it's nice to have all our plans collated into one interlinked space. Sometimes, it's worth the effort to try out new ways of working, the wiki immediately felt like the right way to do things and within a few days has really taken off. If you are working on any game project, and especially one where the design is a collaborative effort, I strongly recommend trying out a wiki system and seeing if it is of any benefit.
Textures Too Good for the Game
Something which rarely crops up with modern games is having textures which are higher resolution than can actually be seen in the game. We had to put mipmaps in quite late due to some scheduling wrangles, but when they went in, we noticed they were a little bit blurry. Fost creates all his artwork at a higher resolution than is needed (we've worked on several projects where the artists were asked to produce higher resolution versions of the artwork towards the end of the project, which left most of them mentally scarred :) ), so it was likely the textures were never being displayed at anything other than their second mipmap level. To test this, we run the game at 1600X1200 (the greater the screen size, the more likely the game will show top level textures) and fill the mipmaps with flat colours. So if you can see the original texture, then it is being displayed at its best, red is the next level down, blue the second mipmap, and so on.If you look at the following comparison image, you can see that only the walls are showing some of the original texture though, and even then it is only when they are very close. The floors will need their texture sizes halving, and the player model looks like it will need the texture size quartering. Whilst this might sound like you will be missing out on the best textures, you would never have seen them anyway. It will in fact improve image quality throughout the scene - allowing the higher resolution maps to come to the fore more often.
Online update
I finished adding the code to let the game communicate with our website which allows the player to unlock the demo version and check for updates with just the click of a button. Most games communicate via TCP/IP or UDP, but when such a connection is first established it will cause the WindowsXP firewall to pop up and making alarming comments. So instead we are using standard web page style requests via port 80 which is much more acceptable to firewalls and they usually keep quiet about it.Automatically updating the game was tricky as it means overwriting files that Windows may have locked because they are currently in use (like the main exe) and handling the fact the update may fail part way through. My approach is:
1. download and unpack the entire update into a seperate location. If it fails then it doesn't matter.
2. exit the game, start up a seperate application allowing windows to release any file locks.
3. copy the update over the game and then delete the seperate update folder.
4. exit and restart the game.
To write the little app that does the file copying and deleting I used some open source software called wxWidgets. Why bother? Well wxWidgets provides free cross platform code for doing all manner of windozey type things so this little app will work on windows or linux or mac. Should come in very handy for the future, always good to be prepared. I wanted to get more familiar with wxWidgets anyway as it allows you to create just about any type of Windows style app you can think of, but has a simpler interface that is easier to learn than Windows, never mind being cross platform. I'll use this for creating future game editors I think.
BTW, I whats the game about, or did I miss an entry?