Introduction and History

Developer: RAS Ltd.
Initial Funder: Iranian High-Tech Industries Center
Project Status: Unfinished due to lack of continued funding

It is never easy to write a post-mortem, especially not when it is for a cancelled project. The fact that you cannot play a final version of your game after almost two years of hard work, even if it is just for reasons of nostalgia, is heart-breaking. Writing about what went right is easy, but we learned a lot more from what went wrong, and so I have decided to publish this document, in the hopes that it will be useful for all aspiring developers out there.

Before I begin to talk about the pitfalls and the lucky strikes of our development process I would like to introduce our game and some of the unique circumstances it was created under. Five years ago I and a number of my freshly-graduated friends interested in game development started fleshing out a game project proposal (basically an extended pitch) for an RPG set in the ancient epic mythology and poetry of the "Shahnameh" (also known as "The Epic of the Kings") and the Zarathustrian Religion. As we resided in Iran, a country where game publishing companies and even development houses were unheard of, we decided to pitch our idea to private investors and governmental agencies (mainly in the culture and IT sectors).

Well... after we got no positive answers during the next year, we parted ways, and each went off to earn some badly-needed cash. We kept our contacts alive though. Having worked in a manufacturing plant as a control systems engineer (I do have some "real" education as an electrical engineer you know! It's not just all games!) and in oilfields and on oil-rigs in the Persian Gulf, I was informed that a governmental agency would fund our project. I decided to leave my *real* job and start with our game project.

The original project budget we had estimated was around 350K USD (which is quite low due to lower wages here), but government agencies are king when it comes to budget cuts, and we could only secure 110K USD (Just consider that Iran has had an annual inflation rate of almost 20% for the past few years!). As a result, many game features had to be cut; a painful decision indeed. With our tight budget, we figured that we will need a tight team, picked from the best of their respective creeds, on a tight schedule. Writing the world back-story (50 pages), main storyline (70 pages) and preparing concept sketches with our newly-hired Lead Artist took about 3 months. During this time, I acted as the designer and preliminary producer because I am the kind of person who knows a wee bit of everything (mythology, writing, game design, 3D and 2D graphics and art, programming, etc) and I shared project management and financial responsibilities with a friend (we were only 3 on the team and it was easy at the time). Once the money flowed in, we hired two artists, a 3D graphics programmer and our support staff.

Following an initial period of researching available technologies, we decided to go for a .NET implementation based on the open-source IrrLicht engine coded in C#. The engine would require a heavy overhaul, but that wasn't a strategic problem: our programmer was confident of knowing the ins and outs of IrrLicht, which is a very clean and neat little graphics engine by the way. 3D Models and animations were to be created in 3DS Max and ZBrush, and 2D art was mainly done in Photoshop. Within another few months, a team of ten wildly enthusiastic people were working on the title which we had named "Age of Pehlivans" ("Pehlivan" is the Persian word for hero). Everyone was absolutely sure that we would create a revolution in game development in our country (Ok! There really wasn't anything going on that was supposed to be revolutionized at the time, but you get my meaning). Those were good times of hard work, brilliant ideas for workarounds, and late-night CoD tournaments, but all good things have come to an end, sometimes too soon.

What went right

Quite early on we noticed that 2D concept art can be outsourced efficiently, at low costs and with great quality. The concept artwork for our game was stunning, well, at least to us. Artists can do great things from a corner in their bedrooms once they are briefed about the back-story and character descriptions. The same goes for sound production and dialogs. Outsourcing sound and voice assets to an established director (in the animation or movie industries) can create great results, and it turns out that many voice-over artists owe directors favors and will provide their services at minimum cost.

Our decision to create a small team of highly-skilled and intelligent developers must be the reason we could actually get on with the work. Professionals in the game development area are non-existent in Iran, but looking back at what my comrades achieved with so little funding still astonishes me. Our team "gelled" and it was a lot of fun watching them at work.

One situation we were extremely afraid of was that the government agency we had been funded by would cut the funds at any stage, due to their lack of understanding of the game development process (i.e. you get to see very little functionality in the beginning.) Much to our delight, however, we could impress them with our concept art and technical confidence (which they were probably mistaking for competence ;) ), at least in the beginning. The fact that they had little knowledge of games and weren't keen on meddling helped the money flow, and yet the lack of oversight caused thereby, might have hurt the project, as none of us were really adept at game development management. Lesson learned: Lack of managerial oversight from your funder/publisher is only positive if you are an experienced and very professional developer.

Another thing that went right was our choice to use an open-source graphics engine. It allowed us to develop extremely user-friendly level and model editors (I have yet to see a level editor accompanying any commercial game that is as easy to use as ours) and create levels efficiently. The other tools we created, such as our event-based story editor and our rule editor were little fiascos of their own, but we shall revisit that subject later. We also added any and all shaders and post-effects we liked, and at any given moment we were able to extend our tools to do whatever we wanted them to do: a designer's dream! There were many other things that went right...but let me depart here...and move to the painful part of this writing.

What went wrong: Programming

1. Right from the beginning, and mainly due to financial limitations, we had employed too few programmers, who were dividing their time among far too many tasks. We had one 3D programmer who was handling the engine code and all the tools, along with the game mechanics, level loading, etc. Another was coding the GUI and event scripts, and our lead programmer was making sure everything is on track and was doing high-level code architecture design and maintenance. The work load on our 3D programmer was too high, and deadlines were often not met as a result.
2. User interface art was developed very late into the project (the last few months) and placeholders are simply not good enough to give you a feel for the shortcomings of the interface. We should have iterated the GUI design, but we didn't.
3. As our environment was very "outdoorsy" we had created over 80 types of grass, bushes, trees and shrubs. We couldn't afford fancy tools like SpeedTreeRT, and we had to create, place/paint and performance tune all of that stuff by hand. This started to turn into a major challenge on our level which was almost 10 SqKm large. In hindsight I believe we could have found an easy way to place all the flora with automated code.
4. We started with the LoD (Level of Detail) and scene management optimization very late into the project. That made our engine and development tools unwieldy once the level started to get populated. (We don't have access to dual quad-core machines with quad SLI graphics in Iran you know!) IrrLicht is in no way optimized for a huge level, and we had left major optimization for later stages. A big mistake...one that we came to regret once we started serious work on the level with our WYSIWYG editor which had to handle all that the engine was fed and then some! On a different note...maybe we should have kept our levels simpler. ;)
5. Particle effects programming was a LOT more important than we had thought initially. Particles were badly underused compared to meshes in our levels. And while our graphic cards were burning hot, the average CPU was happily running at 50%. Once we recognized what a few strategically placed particle effects can do to add some magic to our level, we were already in the dreaded crunch mode.
6. We animated the full cycles of movement and combat for every character. If we had come up with a clever way to use generic code to control some of the behavior of the character bones, we might have saved ourselves a lot of head-ache, and the transitions between animations might have been tighter and smoother.
7. Save/load functions should have been available in the game right from the beginning. Although it is hard to maintain those functions in-sync with data structures that are changing from one day to another, we still should have done it. Our game was compile-able and playable at the end of every day, and yet the save/load capability was missing until testing really started. This was a major cause of problems, as we could not check every asset we inserted along the way, simply because it took too long to get to that point in the game (and yes, we did have development cheats, but that was not enough, and overuse of cheats has a way of not letting you see the real problems!).
8. Our event-based story editor was a huge messy business. Setting zillions of events and commands in a user-unfriendly environment is the last thing a designer wants to do, and it was indeed the last I did, with terrible results. In hindsight, we really should have hired another designer who knew some easily integrate-able LUA or Python. Visual mapping of the game events and story would have been another way to go, but we simply had too few programmers, and were tight on the budget.
9. This might sound controversial, but I believe that our game rules should have been hard-coded from the start, instead of wasting time on trying out all kinds of hand-made semi-scripting tools. Because the rules didn't really change much, and because there weren't too many of them (and we weren't going to re-use them anyways) we should have simply hard coded them (which we did in the end, and with good results).
10. Our initial design called for a huge city in the middle of the map. The result: hundreds of thousands of polygons on the screen, and so many objects, that even our most aggressive culling routines seemed not to be making a difference. The GPU was badly overloaded. This could have been avoided if we had just changed that design decision early on. A lot of painful optimization could have been circumvented in this way, at least in the beginning of the project cycle, when programming resources were so tight. This might be seen as a design problem, and it is one, but it also affected the programming cycle in a negative way...which brings us to the next part...

What went wrong: Design

1. I said earlier that I started out on the project as the designer and producer. In the beginning it made sense to do both jobs, because we were a tiny team, and because the number of produced assets was small. The original planning called for a full-time producer a few months into the project. But then something nasty happened. Something that we should have foreseen: An exception turned into a rule: funding came 3 months late! We had no money but that which we paid our team with. We started taking out loans to keep things going...and in the midst of this, we forgot to hire the producer! We figured we could do it a bit later, but by then, production had tuned into a full-time job for me and the design was lacking the attention it required. Disaster struck a few months later, when we actually did bring in a producer: the assets were so many and so varied, that the producer simply couldn't handle the hand-over. He was stuck with zillions of files and formats he wasn't familiar with, and I was stuck with micro managing every single asset. Game production can do wonders for your memory you know! At some point I was able to quote the exact computer and folder where the last version of a file was located from among 40000+ files. In my case, more memory simply meant less brains and creativity, which was poison for my design tasks. You see...producers are meant to be extremely un-flexible. They must set standards...rules... Designers on the other hand need to be extremely flexible, always ready to cast out their beloved design features and replace them for more *fun* ones. For a big project, a designer-producer simply isn't feasible, or...at least I wasn't.
2. Another major problem I faced as the designer was the scope of our project. RPG's are among the more cumbersome projects to handle. Gamers want them to be huge and beautiful and varied...and so do the designers (who are avid gamers more often than not). You might question our sanity when considering our budget (110k USD), that we even went for an RPG...and you might be right. I have no rationale to offer for our decision, except that "We wanted to do it with our hearts and souls, because we all loved RPG games!" However, even with an RPG, the scope of the project still could have been reduced. This kind of feature-pruning should really happen in the first half of the development cycle, but we lost sight of the scope early on, and the pruning process reared its nasty head during crunch-time! A developer under pressure, forced to cut a feature they have come to love is not a nice sight. He cries and writhes and shouts and curses...Strangely enough, now that I think about it, those moments of destitute were the ones that brought everyone on our team closer to each other like no success ever could. We went through the pain together...great moments for all of us.
3. OK, I am drifting off...this document was meant not meant to turn into a cheap drama script! One thing we noticed, unfortunately too late, was the fact that for our RPG game, side quests which were loosely tied to the main quest could have been very easy to execute. There were almost none of these types of quests. The world could have used a lot more open-endedness and simple side-quests (e.g. one to three level side quests, meaning one to three visits to various NPC's/Locations are enough to solve the side-quest). Most of our efforts were spent on fleshing out the main quest, and that restricted the player a lot.
4. This might sound as if I have joined the "Tolkien-esque" school of RPG design, but IMHO our game should have featured more mini-levels, dungeons, caves and teleports to weird locations. Dungeons are fun to play, and can be a good excuse for rewarding the player with lots of goodies. The fact that dungeons can be created as tiny sub-levels helps the artists, and level-designers to be more focused when working on them. It helps with the frame-rate, as features can be distributed in many smaller levels and locations instead of just one huge map. It also could have solved our "huge-city" problem, which I mentioned earlier.
5. Initially, our story called for 50 unique NPC's, 20 generic characters and around 15 beasts. Late into the game I started to think we could have distributed our resources for better re-playability and more fun. 25 unique NPC's, 25 generic characters and 35 types of beasts would have been the way to go, and it wouldn't have cost us a dime more. Unique NPC's have to be modeled, animated, voiced-over, etc...and they cannot be re-used too often, while beasts can be lots of fun to kill. You might argue that the latest RPG's have hundreds of unique NPC's, and you would be right, except for the fact that our budget was only a tiny fraction of theirs.

   
   Aop Sample Screenshot: There were probably too many
   unique characters in the game (as compared to beasts)

6. Communication problems within the team are a standard complaint in post-mortems. Well, here is one variation you probably haven't encountered before: one of our problems was that I wrote all the design documents in English, assuming that any gamer/developer, even in Iran, would probably know some English, or be willing to learn English really fast! That didn't turn out to be true, and although I tried to make sure the team understood all the technical details they needed, a few did not understand nearly as much as they pretended to. It was shocking to find out at the end of the project that one of our artists had created great environment art without having understood a single word of our back-story. A great indicator of his brilliance, and my false assumption indeed!

What went wrong: Visual Arts

1. Our Lead Artist, although great at creating concept art, lacked technical knowledge of programming and the 3D asset creation pipeline. Unfortunately, at the time it was near-impossible to find an artist who has the necessary leadership skills, along with creative ability and technical knowledge required for game development so we had to make a compromise. Although our 3D artists were tech-savvy, the lack of leadership in the art department could still be felt. Maybe it would have been better to divide the role of the lead artist into those of a lead 2D artist and a technical art director. Unfortunately, we will never find out if that would have worked
2. Because all of our 3D assets and animations were created in 3DS Max, we were in dire need of a good .X exporter. That is hard to come by in the freeware market, and we didn't possess the resources to code our own exporters. That led to time consuming tweaking and multiple trials for each exported object/animation. What we could have done to alleviate the problem was to put strict restrictions and export rules in place before starting the work, but those were developed later, when a lot of time had been wasted already.
   
   AoP Sample Screenshot, You might not notice it in this
   screenshot, but those two characters actually shambled with the same gait.
   That looked horrible!
3. One way to lower a game budget is to re-use models and textures. If done cleverly, this not only doesn't reduce the appeal of the game, but surprisingly gives it a unified look and feel. This is a lesson we learned too late in the production cycle, when many redundant models and textures had been created already. Those strained the graphics memory and wasted many artist-man-hours. On the other hand, I must admit that we did try to re-use some of the animations, which turned out looking disastrous. When a beautiful queen NPC of ours started to lurch around like a dazed thief we knew that enough was enough! As much as we liked it to happen, reuse of animation was almost impossible except for the most generic of characters

What went wrong: Production

• Managers' lack of experience and oversight on the development process, allowing for and not catching any of the development mistakes of the other teams, which also led to a lack of management credibility.
• Managers' lack of knowledge about the game development process also led to their inability to break down the project into meaningful, fixed and tangible pieces of work (mini-milestones), in part, leading to disorientation, loss of motivation and delays.
• Project time was first set at an unrealistic 12 months and then extended again and again to 20 months. This led to skipping many real problems, and redoing a lot of work at later times (sometimes it was simply too late!). Rescheduling wastes a lot of time!
• Lack of regular progress reports, schedule sheet updating and too few progress meetings left everyone wondering where the project priorities and problems were, effectively disabling them to catch problems before they showed up.
• Website/Boxing/Advertising art development should have been outsourced entirely, saving the internal team valuable time in the last months of development.
• Miscellaneous mini-projects not related directly to our game during development, in addition to adding over two months to our development time, left the team disoriented and led to a lot of recovery down-time. These projects included pitches for future games, technology demos, and art books that were only meant to showcase the capabilities of our artists to possible future investors.
• Mainly due to lack of funding, staffing was messy, inadequate and bad at best, leading to constant extended development time and schedule shifts.
• Lack of ability to provide a good development infrastructure (Rooms, network, data security and availability, standards, internet connectivity, air conditioning, cleaning, etc.)
• Bad time management for team members, allowing for some extreme overtimes (sometimes with no additional pay), while others were having extreme under-times. This contributed to demotivation of the team at the end of the project.
• Different payment methods (hourly, fixed minimum, fixed pay) which did not address team member productivity in any justifiable way.

• Marketing and capitalization efforts for the game were not focused and directed, resulting in a total deadlock in both marketing AND capitalization. This was the main managerial failure which put the lid on the coffin for this project.

Conclusion

So what really happened? Why did the project not get funded? That is an issue I could discuss for many pages, but the gist is that we learned that governmental funding in a third developing country is not something you can really count on to run a dynamic project such as game development. This kind of project needs investors with know-how, and a passion to protect their investment. Government employees are famous for not possessing any of those factors. The delays caused by untimely payments, and the compounding of all our own mistakes, didn't help in the process either. Then there was the problem of copyrights too...see...in Iran there are no copyright laws, nor is there any enforcement of IP rights, therefore it is near impossible to get a return on investment for a computer game (that was one reason we opted for governmental support in the first place). Long story short: the project was cancelled, because our own company couldn't take the risk of losses.

Concluding, I must admit that many mistakes were made, and I am definitely responsible for some of them, but writing a post-mortem seems to be the best thing you can do in order to unwind after a taxing project. If anything, it is an attempt to raise everyone on the team to a higher standard of work and professionalism. The recent years have been dark years for the budding game industry in Iran. With all the political games surrounding Iran, and all the sanctions against it, the priorities have shifted from technology and entertainment towards military applications. Sadly, this is foretelling the demise of many start-up companies in this field, but there will always be an enthusiastic few who will try to build a world of their own, with thousands of lines of code and many great artistic ideas.

Creating a computer game is a great project to learn life-skills in and develop a professional attitude towards work, be it programming, art or management, and I have found that those who seriously invest their time in creating games are some of the most interesting people in our to hang around with. I hope this post-mortem was useful, and I hope that my next post-mortem (believe me...there will be more!) will end in a more up-beat tone.

My best wishes for your projects,

Babak.

P.S. I will put a more detailed post-mortem up on my website during the next month or so...( www dot gamedesignideas dot com ). If you are interested you might want to visit.