Surrounded by Death Postmortem
May 12, 2009—
How it all started
The development of “Surrounded by Death” started with our passion for first person shooters and zombies! We always wanted to make some kind off mix between tower defence and the invasion of horrifying brain eating zombies. We from Wooglie were developing games on Unity for about half a year now and just recently set up our own gaming site. We read about this competition on the Unity3D forum and we thought it would be an excellent opportunity for us to create a cool game and win prizes with it! So we brainstormed on what to make for this competition. After a long brainstorming session we came to the idea of making a zombie invasion game. We called for help from the Verdun-Online team(which is also a project Wooglie is participating on) to assist us with the art and the sound. Leonidas, Stone Lion joined our team and we then consisted of a team of four enthusiastic developers to make an awesome game for Mac!
The Starting Phase
About a month before the uDevGames competition deadline the development on “Surrounded by Death” actually began. We noted down all the features we wanted in the game using a shared google document. We got quite a list here of all our ideas and the progress. We could show a bit of it but it’s half English-half Dutch. So after we wrote our “design document” we started the actual work. We set up a unity project for “zombie defence” and soon enough the basic FPS coding was done so you could actually walk through an area. We started on working on the bunker and blocked out the level.
The image above shows the first concept/block of the bunker. After the concept was done the actual modeling started and we quickly had an actual bunker you could explore. In the meanwhile We were working on the zombie AI already and made some quick progress. At first we wanted to use a path finding system made by AngryAnt but the publicly available version at that time (0.3b) gave us too many problems and we decided to go for our own home-made path system. This was made with an existing path finding script as base. This base path finding script was made by unity community member StureStone. So far within a week progress or so we got a fully textured (but empty) bunker, and path finding cubes.
We then started on the Zombie model. This caused some trouble with the way the Zombie should be modeled cause we wanted to be able to tear apart the zombies limbs. We solved this problem by separating the zombie in different materials like: Left_arm, Head, Right_foot. By separating those in Blender we can script in unity so that when you shoot on his head the opacity of the head will go to 0% so you can not see the head anymore. This did cause some other problems with the colliders, cause they will stay remain. This issue was solved by simply also removing the collider.
Here’s an in-game shot of the zombie in progress:
With the zombie model finished… the bunker still was empty. Here is how it looked like (Including the zombie with detached limb). This scene really displays the lack of a proper environment.
While the zombie model was done there were still some animations to be improved however, we first continued on the level itself. We’ve made a list with typical things you would expect in a bunker like: beams, tables, barrels and crates. So one by one those were made and put in the bunker to create a actual living but abandoned/scary bunker.
Final Production Phase
With the bunker mostly in place and the basic version of the zombie monster done the main gameplay framework was there. Only the details needed to be filled in. Weapons, created in some quantity were put in and work started on the player-model. We had made some weapon designs and the weapon models were created during the complete creation process. Weapons can be created quickly between major art pieces.This in turn provided a nice change in the gameplay which proved itself in the final version.
The player-model was another challenge because it needed to be created with the specific use of weapons in mind. Studies from recent titles indicated the the level of detail in 3D person character-weapon animation is very low or even totally absent. Thus the playermodel had lower priority since there would only be as much as there would be players — a few against the hordes of zombies. Setting would be a military bunker so a soldier with a gas-mask (in itself frightening and impersonal would provide a base.
In the meanwhile our composer was supplying requested sound effects and music on a ad-hoc basis. This meant that whenever the artists or coders created some new element they put a request for a sound on a list that would usually be completed in a couple of days. Combined with unity’s pipeline for assets this work flow became quite solid and effective.
The coding area continued work on the weapon and FPS system, of which there already existed some pretty nice base version supplied by unity. Putting this in a network perspective there has been some work in the synchronization of the AI across the players. That was the hardest point which had to be programmed correctly. The other activities included the correct display of the animations of both the zombie and the playermodel which had to be blended in. For the zombie there had to be a special climbing window case where a specific animation would be played and the movement had to be different.
Pretty much at the end of the development line there was a good link between the applied art of the zombie/player models the weapons in use and the killing. Some play testing was done in the evenings and iterative major bugs where filtered out by stress testing the possibilities of multiplayer.
We made a good balance of what can be designed in advance and what was designed and implement on ad-hoc and iterative basis. A point of criticism on the development of this game would be the lack of polishing and playtesting to create a smoother gameplay. When the competition deadline was near there were still some big issues that had to be dealth with. More polishing of the final version, to include just that little bit more of tiny features that make the live of the user a bit more pleasant while being swarmed by zombies.
Creating the game went very smoothly. We didn’t have any major problems or underestimations. However, that doesn’t mean the last days weren’t stressy. Most of the work had been finished the last two days. Including most of the gameplay. Building the window barricades is an important aspect of the gameplay and was added only the last day! The challenge on the art side were the animations, and the zombie model. All of this was done by just two artists, so there was a tigth schedule.
This game was made within a month, but it was just a side project between all of our “real lives.” If we’d have to this all again we would probably be able to reproduce this work within two weeks. The asset server revision count was 390 the day we delivered the game.
One of the conclusions we dare to make is that a small Indie team really can create commercial quality games, as we believe we’re getting closer and closer to the A quality. We are not claiming that Surrounded by Death is that close yet, but with some more loving we will be. Smaller teams got a great advantage over large (hard to manage) teams. Our experience is that you’ll get more done with a smaller team, especially at prototype stages. Todays available tools such as Unity now really make it possible for anyone to create a great game.
Where To Go From Here
The game we delivered in this competition is merely a prototype! We will be improving the game and most importantly: we’ll use the new experience to create more and better games! Surrounded by Death will be released on both Mac and Windows, after a lot more polishing and important additions/fixes to the gameplay. Polishing includes optimising the game for lower end hardware; we didn’t even do this yet. We’ll most likely also switch over to the “Path” pathfinding system by AngryAnt very soon. If you are interested in the future development of Surrounded by Death; you follow the progress on the website.