Developer Diary #24

[Mike]

Design

Oops, as some have pointed out, we missed a month of the Dev Diary; sorry about that. But, in our defence, we have been working incredibly hard on getting the game finished, rather than just slacking.

As I'm sure you're aware, the Project Aftermath is indeed finished and available to buy. Yay! It's been a lot of hard work, especially over the last few months, but it's very satisfying to see the listing in Steam and know that people are playing your game.

So, what's happened since the last diary? Well, the trip to PAX went very well, as you may have seen from Lee and Mal's news posts:
http://www.gamesfaction.com/forum/index.php/topic,50.0.html

Not only was it very well received, the show was also useful from the point of view of watching new people play it. After Pax was done, we made a few changes to the tutorial and demo to better cover concepts that people had trouble with. When you've been working on a game for two years, it can be very easy to forget that some of the concepts you've come to regard as second nature are pretty novel to those who've not seen them before.

Another big thing was the introduction of voice-overs for all of the in-game dialogue. Even though we'd trimmed down the dialogue as much as we could, there was still quite a bit, especially in the tutorial and the first couple of missions, and important instructions were getting lost in the midst of battles. Fortunately, we were able to find a couple of very talented actors who were willing to sit in a tiny booth and read out the lines I'd lovingly written in crayon.

Once I had the raw recordings, it was a fairly simple, if time-consuming, job of cutting them all into individual lines and then treating them with various effects to make them fit into the game world. The end results have been well worth it, as it's far easier to follow what's going on when the action gets busy now.

With that complete, the game as a whole had really come together, and a lot more playtesting took place, to see how the many items in the game all interacted with each other. We have over 100 equippable items, as well as 15 power levels that the Heroes can be set to, and between 1 and 9 units in each squad. All of those options have a corresponding cost, which has to be correct for the in-game "strength" of the option. We've been working on this part of the game on and off for a few months, going through phases of testing and tweaking to try and get them feeling right. In the run-up to release we did another round of testing and made some changes to plug loop-holes that we discovered.

We also took another look at the demo. A few months back we made a demo to submit to the PAX committee, but we'd decided that it was too confusing for new players, so wasn't a good demo for general use. To that end, we decided that the best thing to do for the demo was to just use the Tutorial and first mission from the full game, as they were designed to ease the player into the new game concepts as they played. This seemed like a very logical idea, so we stuck with it for a while, but when we showed that demo to some new people, it became clear that we'd gone too far the other way - the concepts were all explained well, but it wasn't exciting enough. The missions worked fine as the start of the game as they were a small part of the whole and so could afford to take their time. But a demo needs to be far more immediate and attention grabbing, and be a better indicator of the kind of action the player can expect from later on in the game. We kept the Tutorial as it was but made a much more action-packed demo mission and, in order that players who skipped the tutorial would know what they were doing, we used the comic system (see the last diary) to create a brief summing up of the concepts and controls.

What's next now the game is out? We've got some more ideas for extra features and polishing that we'd like to do. For example, I did a big push to get more unique sounds into the game, but the last pass of testing showed up areas that would benefit from even more. We also want to add extra features to the leaderboards to make them even more detailed and fun.

As well as all that, we obviously have to publicise the game as much as possible. As a very small developer, word of mouth is going to be very important to us so, if you like the game, make sure you tell as many people as you can.

Further off, the plan is to create a multiplayer version of the game. All of the game's systems have be designed with multiplayer in mind, and I'm already thinking of new game types that should continue the theme of innovation and fun that we've started in the single-player game.

We'll keep you posted on that though; this isn't the last dev diary by any means. But for now, we hope you enjoy Project Aftermath - it's been a lot of hard work, but it's all worthwhile if people enjoy the end result.

[Mal]

Sorry Mike, I'm back on the Diaries! 

Someone over at XSIbase replied on a post about the game, asking for a bit more information about the work flow/generating artwork. That is quite a large subject but I though I'd start by offering an overview. If anyone has specific questions please jump right in!

Project Management.
Separate projects
I created a project for each type of asset, characters, buildings, vehicles, furniture, promotional etc. This prevents projects from getting cluttered, and is a good practice IMO for general house keeping.

Scenes
When creating models I usually create them in a separate scene, export the final model and Import it into a final scene with all the assets of that type. (Our models aren't so heavy that XSI can't handle these scenes) I've done this to view all the models together and to batch export from a single scene.

Models
As well having the scenes with final assets I export a model of each assets as well. This mainly serves as a backup against scene corruption and it is always useful have a model for importing into another scene as reference. This has saved me on a few occasions where for some reason opening the material manager would freeze the app. A quick drag and drop of the models from the Browser in a new scene and I'm back up and running with a working material manager.

Textures
I chose to keep all my textures outside of the projects. I have a PSD directory with sub directories for assets of each type. We also have the final game textures directory. So I work with the PSD files in XSI until the models and textures are completed, then drag the final texture to the rendertree.

SVN repository
Outside of XSI the projects, PSD files and Game directories are managed with Tortoise SVN. I use this for backing work and to share work between the office and home.

Asset creation.
Buildings
I've modelled all my assets in XSI, and use the roadkill plug-in for a lot of my UV work, it is a good starting point most of the time. Once the UVs are neatly laid out my usual route is to create a Rendermapped Ambocc file. I use these as a basis of my texture work in Photoshop along with a stampUV texture.

Characters
Because there is reuse of the character models, I split the bodies into head, upper body and lower body and used referencing to import the models into the various scenes. If I need to tweak the models or UVs I'd go back to the reference model and then those changes propagate through. I used two main rigs for the Heroes/Enemy leaders and Troopers/Enemy grunts. I kept the naming conventions and default translations of the control rig the same (even though the heroes have a dog leg) so I am able to use clips on both rigs with minimal reworking (although in practice I've not wanted to do this that often).

Material library referencing
I tried to use the material library referencing, but found this to be very problematic and eventually abandoned it. This meant I had to revert to making scripted changes to materials, executed through a batch process.

Tools and Exporting.
Exporter
We have use the dotxsi exporter to get assets out of XSI. We then batch those assets to our own model format, which strips out any unwanted data. I've written a few scripts to speed up the export process and enable batch exporting. Actually I've written quite a few scripts over the past two years to ease many repetitive processes. But I wasn't being very cleaver with how I packaged them, which meant I sometimes didn't have updated scripts at home. In the end I created a work group kept up to date via Tortoise SVN. The scripts are all packaged as a plug-in making keeping on top of versions and changes much easier.

Custom data.
Using the dotxsi exporter meant we needed a solution for getting extra information out of XSI. For example, with the character animations, the game engine had no way of knowing when an animation should start or end/loop or not. I was able to resolve this by using Custom Parameter sets. Again using a script, I could read the animation mixer clips to create a Custom Parameter for each animation, setting the start and end frames. As the naming convention for the animations were fixed, I could also use a string search in the script to set up the looping flag. Example being, if the string started with "walk_" the loop flag was set in the Custom Parameter for that clip.

Locators for effects
Many of assets required a node which the effects system could use to generate an effect. I simply used a locator for this with a naming convention.

Environment Lighting
The game engines lighting model uses a Lightmap for shadows. EarthSculptor generated this for the landscape but it had no way of importing models. We thought we may have to write a shadow renderer into our Level Editor but this would take a lot of programming time which we just didn't have. In the end we created some batch scripts to import all the dotxsi models required for a level and a .obj landscape from earth sculptor into XSI and use mental ray to render the shadow map.

Other tools
To view the dotxsi exports we created our own viewer, which can load and position multiple models/load animations for character models and test animation blending. The game levels themselves are put together in our level editor, it uses a visual scripting language we created in lua.

I think that's it for now!