Postmortem: Blood and Iron

Introduction

Blood and Iron, as a project, went through more intended results than I care to remember; it was constantly changing, because I was constantly learning and the situation was constantly changing. It was, as a game demo, unsuccessful; as a tech demo, portfolio piece, and learning experience, it excelled, however. Now, two months after the project has finished, I want to take a look back over its development cycle, what went right, and what went wrong. I hope other hobbyists and students can learn from my experience and mistakes, and make mistakes of their own instead of repeating mine.

The Beginning (January - August 2006)

The Blood and Iron team was originally two people: myself, and Jerome, a programmer. After going from his engine, and then to Elder Scrolls: Oblivion and then a Source engine mod, we decided to go for broke, and design an engine around OGRE, an open-source rendering system. I was to take care of all content, and Jerome all programming. We'd meet weekly, and we were enthusiastic, and the future was bright when preproduction finished in the late Spring and production started in the Summer.

The summer was, from a content point of view, quite productive; in fact, more than half the assets were complete by the time school started in the Fall (they were all touched up but mostly done). Programming was a different story (a recurring theme throughout the project); Jerome became harder and harder to deal with, and eventually left the team in a huff, which I had anticipated for about a month but actively tried to fix because he was local, talented, and the best chance I had, I felt.

The Middle (August 2006 - January 2007)

Fortunately, though Jerome left, I found an extremely dedicated, hard working, and most importantly reliable programmer, Aldo Fanelli. Unfortunately, he lived in Italy, and wasn't very experienced, but he made up for it with effort I could hardly match, and this was practically what I worked on 24/7. He also brought along his engine (the Adal Engine, as it came to be called), which was about a year mature, had all the basic functionalities, and was build upon pretty solid technology consisting of open-source components.

The middle half of production was on the one hand quite productive. We had a pipeline worked out for assets, I was learning the engine, we picked up a couple good programmers. On the other, it was more of what's expected from indie teams; missed deadlines, delays, excuses, change of focus, unreliable developers. Help from the other programmers was appreciated, and motivating, but ultimately Blood and Iron ran on the back of myself and Aldo.

The Home Stretch and Finish Line (February -May 2007)

This 4-month crunch time was hellish but rewarding. Great progress was made on the engine, most importantly, my shader writing and Aldo's scripting integration. Issue after issue arose, and myself and Aldo spent many sleepless nights working, sometimes forcing each other to go to sleep because we were sick from exhaustion (he is 7 hours time ahead). We tried to turn it into a game, and realized we couldn't; we needed a few more months at least, if not some re-engineering of some features (such as the physics engine we chose, which was not actively being developed any longer). So, we put together a handful of tech demos, which you can download from www.bloodandirongame.com .

What Went Right?

1. Technology
The Adal engine and its underlying technology and design was one of the strongest I've used. OGRE (www.ogre3d.org ) was absolutely amazing; it is brilliantly designed and capable of anything one wants it to do, it is actively supported and updated, and is mature technology. The Adal Engine, from a logical design standpoint, was equally strong; it was the 'glue' that held together all the other components, such as rendering, physics, audio, etc., so in theory these components could be swapped and replaced without breaking the engine (something that would need to be done with both OPAL and Audiere). It was also designed very well from a logic of use standpoint; Aldo made some very intelligent choices in using Game Commands, which were basically containers for some sort of action for a scene entity. It made absolute sense when working with a small number of entities, and would have made great sense if we had proper AI.

2. Communication
Generally communication is an issue, but learning from previous experience, we had worked out a pretty good system. We had a developer forum, MSN Messenger, a Ventrillo Server, Skype, and most importantly, a Wiki. Of these, Ventrillo and the Wiki were the most important; we had a weekly team meeting on Ventrillo, which was extremely important and invigorating. The Wiki allowed effortless documentation of design and technology, and it lent a solid structure to what otherwise would have been files that are split up, unstandardized, etc. Team Ventrillo meetings and a Wiki are two things I would strongly urge any independent and geographically separated team to implement.

3. Committment
Committment was an issue for the auxilliary team members, but for the core (myself and Aldo) it was consistent and strong for the entirety of the project. This lead to a reliability and consistency to the coding and content, as well as minimal delays in training, and recruitment. This was my Senior Thesis so I was in it for the long haul, but it was very fortunate, and suprising, that Aldo remained as steadfast and active until the end (and even more active towards the end), truly a testament to his character.

4. Content
I was almost the only person working on content. I had a couple artists for a little while who did some decent work, but almost none of it found its way into the final demos. This was what I expected, and I dealt with it; I wanted to concentrate on assets and art and design and not on managing people. The content side of things was successful, as I think we produced some gorgeous looking things.

What Went Wrong?

1. Management
Management turned out to be the biggest problem, which, by the time I realized at the end of the project, was suprising. I consider myself a good leader and motivator, but I did not intend to spend time managing this project, and this left a void. Aldo was very dedicated, but in the same boat as I was; it was on his shoulders to do most code development. In my case, I could cover all the assets, but the programming tasks were just too much for Aldo to handle alone. We did not have a project manager who could recruit and train people, take care of the website, etc. This sort of stuff takes alot of time, and I simply didn't have the time to do it; managing a team of artists and programmers is a full time job and my plate was already full. This void in management limited the team to a handful of members (I would say we peaked at 4 active members), and it made finding new talent extremely difficult.

2. Lack of Tools
Tools are critical to development and we had few, and it made deveopment tedious. I spent many man-days simply debugging XML files that I entered incorrectly. Working at the low-level of things works for small scenes, but at a larger scale, its not manageable. The best tool we had was oFusion which is an OGRE scene exporter, but we had to do a tremendous amount of data manipulation by hand; Programmer's Notepad 2 definately was the mule of the development tools. A greater understanding of these concerns would have allowed us to remedy this earlier, but our changing goals (the next thing that went wrong) and inexperience really bit us in this regard.

3. Changing Goals
Blood and Iron changed incarnations numerous times, eventually turning into tech demos for the Adal Engine. Things constantly changed to reduce the scope of the end result, but content became an issue because the scenes for reduced scope required different assets than I had, so things were bastardized and not optimal. I created many assets that were never finished or used, and on the other end of the spectrum, once the scene had been standardized, I was doing things like creating characters in less than a weekend, and things got very chaotic. Had I said in July 06, or even at the end of my first Senior Semester in December 06, that Blood and Iron was going to be a series of tech demos, it would have turned out far better and more complete than what was eventually done. This was the blessing and curse of the school project; it had a definite deadline, that increased speed of development but allowed less time overall.

4. Programmers and Programming
These are two aspects of the same problem. First, all but a couple of the programmers brought onto the project ended up being dead weight. Lots of people left without any notice, even more came up with excuses, and of the few that were doing work, none of them could really integrate what they were doing into the main development line or bring it to any fruition (such as the half-started AI and logic). Again, this partly stems from lack of management, being unable to find the right people at the right time. The second aspect was the programming, that is, being too much to do. Tools, AI, logic, combat, sound, it was too much for just Aldo. The smartest move made was his implementation of AngelCODE, which allowed me to become a backup programmer of sorts (taking care of combat, cutscenes, and any sort of scripting/triggers, for the tech demos). Progress was made on all these aspects by different programmers, but no one was able to come through where it counted.

5. Acts of God
Somewhat in jest, but we had some downright bad luck with our personnel, though myself and Aldo weren't afflicted. Monsoons knocked one of our programmers offline for the entire Fall and Winter; a civil war knocked another offline for several months; a programmer's father became critically ill and the programmer had to move to take care of him; various members caught severe sicknesses from which they never returned though making progress before that; another programmer was in a car accident and laid up in the hospital from September '06 to April '07. On the other hand, we had no bad hard disk crashes or data loss, and myself and Aldo never went MIA due to causes not in our control.

Conclusions and Advice

Everyone on the team just learned a tremendous amount. Our asses were put to the fire and we ran, far and fast. We didn't reach the finish line we initially thought, but we're proud of the final result, but more importantly, our growth as developers and people. Until you've worked on something like this is difficult to convey accurately the enormity of a task, of working blind on your own project with a small team, and no real precedent or guidance, for a almost a year and a half. I had to do everything that a production team would normally do, and I had to learn how to do everything a production team would do. This isn't a linear process like a 3D animated short; this is a convoluted and extremely confusing and varied process that is different for every game. It gave me insight into things I never would have experienced otherwise, gave me experience with areas of game development a lot of professional artists aren't even familiar with.

If I had to do it again, I would do it completely differently. If I had the proper guidance, I would have done it completely differently. That's probably why I am writing this, so you who are reading this don't repeat the same mistakes, you can build on my experience and see the bumps in the road before they send you careening off course. Advice is everywhere when you look for it, information is everywhere if you keep your eyes and ears open. This doesn't only apply in the abstract sense, it applies in the technological sense (using component-based engine architecture, for example), in the cooperative sense (an active exchange with your and other development teams will teach you lots of things you would have had to figure out yourself otherwise), and an artistic and engineering sense (constantly be picking things apart for how they work).

It will be up to you whether to listen to the advice you receive, you have to weigh whether the places you are getting it from have any authority on the subject and you can vet it based on that, you have to objectively look at your own experience as well when vetting advice. Every few months I had to present Blood and Iron for a jury of faculty at my university. None of the faculty had experience with games and only one had any relevant experience or insight that I could count on. Just always remember that people are trying to be helpful, always be respectful and listen, and if you can get something from debate or discussion do so, but it is oftentimes better to listen and silently consider or disregard.

I hope this post-mortem was helpful, I hope it was worth writing. Its important to stick with what you start; these 1.5 years were often hellish and I often wanted to redo the entire thing, because I would learn and grow so much in just a couple months. If you put your heart into something and really work at it, it will never be a failure; it may not work, it may not be anything like you initially intended, but as long as you are learning, evolving, progressing, there is no higher goal you can strive for.