Post tutorial RSS If it had to be done all over again...

A postmortem on Crimson Crow. Why it ran into problems, and how most problems could have easily been prevented.

Posted by on - Basic Management

Crimson Crow was undoubtedly a very ambitious project. We ran into a lot of technical issues and general management issues near the end. Most of which could have easily been avoided, and a few that couldn't be easily dodged.

I feel bringing up some of these issues might help developers currently struggling in similar areas.
Lets hope so:

Problem #1: Torque Game Engine Advanced

When I reviewed the Torque Game Engine Advanced, the engine was doing fine with Torque 3D in alpha/beta.
I didn't think anything of it because the previously 'phased out' engine was still usable.
Then, in November of 2009, GarageGames officially dropped their support of TGEA and the original TGE.
T3D also used a new model format, Collada. Meaning the DTS shapes and exporters were tossed in the process. (For good reason, since Collada is a better file type. Still, it didn't work for us.)

March rolls around and no one on the team can export props properly except me. Looking around for any exporters was a waste of time since the DTS format was dropped a long time ago.

Old model types in an unfinished test level.

This was an unavoidable problem and it had a major impact on development. As everyone knows, we spent months researching other engines but eventually kept with TGEA. It was a shortcoming we were going to have to live with.

Lesson Learned: Some problems can be entirely out of your control, you can't expect the unexpected but you can see some signs along the way. This could have been helped a little if we prepared a bit more, but honestly there was not a whole lot we could do.

Problem #2: Previous engine hopping

We first used the Torque Game engine, switched to TGEA, back to TGE, tried to modify it, then switched back to TGEA, attempted to switch to T3D, then kept with TGEA.

Confusing? Yes it really is. While the torque engines are similar and some stuff transfers over, most of the programming had to be re-done, before it was really ever getting anywhere.

For example, Iron sights were never truly working until this year, about 2 years overdue.

The 'actual' working iron sights, finally finished in January.

AI was re-done two times. Because of our heavy core game-play changes, some of the major code the game was built on was heavy changed in mid-process, and usually re-changed again.
Code wasn't the only thing affected. 'Many' of the models were designed for TGE, which uses 128-256 resolution textures. TGEA uses much higher resolution.

The result was a horrible mix-up in code and a weird clash of low res models combined with high res models. The only proper way to fix the models and textures was to redo them, which is something no one wanted to do.

Lesson Learned: All this could have been fixed if we kept with the same engine from the start (or at least after the first switch) and a proper game design document.

Problem #3: Who does the props?

Our previous prop artists made virtually every prop we needed but unfortunately never had time to get the UV map set up. Turns out, everyone who was ever in our team disliked getting these UV maps set-up.

The mapper was constantly e-mailing me, asking for more finished props. Since no one else wanted to, I decided to put the code aside and do it myself.
Not including buildings or maps, I ended up texturing about 80 props, a large part of those I modeled myself.

Old bridge map called 'Red Brigade'

Sure this worked great for the time, but I didn't do things correctly. Most of my props were just not great.
A few months ago we finally put the idea together of placing all our art in a shared folder, and having it properly organized with the original texture and original un-exported model so anyone can edit each others work.

Sounds great! Problem is: I didn't have the originals. My old computer which crashed had them.
The only proper way to fix the in-game models was to replace them. So who wanted to re-make 80+ prop models?

Lesson Learned: Keep the original models where they are accessible or saved in some sort of organized shared folder. If you run into a problem where things need to be re-exported or just generally edited, its better to not have it all rely on one person.

Problem #4: Animations

This was a major problem for a long time with no real easy fix.
We didn't have any animations. Well, we didn't have an animator.
That sounds like an easy fix. Why not just hire an animator? Turns out they would have to learn the very weird and difficult system of Torque only to try and use the exporter that didn't work for anyone else on the team except me.

We had the animation videos, references, concepts... So I did the next best thing I tried animating myself. In the end, I never got animations working.

Inside of a building in the Harbor map

This is honestly the reason you would never see videos of gameplay or any releases. Quoting myself, if we could get the exporters working properly from the start, we could have had a release by now.

Lesson Learned: Getting the essentials for a project to work right away is a good idea. This is honestly a problem that should have been dealt with years ago, before TGEA was tossed aside.

Problem #5: Feature creep

Feature-creep is a common problem in any project. New ideas simply kept creeping up on us, and we just spent a lot of time on things we didn't need to.
I would call our problem changing-feature-creep. As we stated before, we've gone through 8 different game modes. This, once again, could easily been solved with a concrete idea and game design document.

These constant changes couldn't really be attributed to any one thing. Ideas can change as they go down the road.

Showcase of props in a room in the Gull City map

In fact ideas are bound to change at least a little. In retrospect, there should have been a point where I drew a line that said 'This is good enough, we can make changes AFTER a release'.

Lesson Learned: Stick with your original idea. The idea has to sound just as good 3 months from now as well as 3 years from now. If you plan and your idea is simple enough, you won't have to go as far as we did trying to get a first release.

Problem #6: Communication

Communication is a big thing for a team. We honestly didn't communicate effectively. Specifically, the team didn't effectively communicate with each other, since everyone would usually end up talking through me.
No one on the team wanted to compromise with their ideas. One member wanted a 'zombie' fighting game and didn't like the concept of anything else. Another wanted to throw all the 'zombie' ideas away completely. Out of all the gun concept we created (I counted over 100 weapons a long time ago), I can only think of one that was actually used. Only one character from concept was 3D modeled and kept.

Tork, who never actually made it in-game

The conflicting ideas made things hard to manage. Since I was usually caught as a middle-man, team members in the past would have pushed their ideas on me to try and sway the entire project. This led to a lot of upsets and arguments. Fortunately the past few months have had a lot less of this, since most of the core members became a lot more collaborative.

Lesson Learned: Don't let anyone get caught as a middle man. Let the team get all their ideas down and share it with each other. Maybe even argue a little, but once all the ideas are on the table, some real good ideas can start to take shape.

Problem #7: Deadlines

Deadlines just seemed obvious. We really tried incorporating this a long time ago when we had some pretty strict crunch lines set. Unfortunately, for whatever reason, members would let these deadlines pass and would feel down when they couldn't get it finished.

I honestly think it came down to members sharing their ideas. When someone had an idea, they would tell me about it. I would then tell another member about the idea and what they need to do to get it working. A little retrospect showed that sometimes the person who was making the idea work wasn't who wanted the idea to work in the first place.

A building in Gull City

This should have been solved with a little better communication. I think if members would talk to each other and have a compromised deadline, then things could be done in a timely fashion.

Obviously this ties in a lot with communication. Another oversight was members sometimes don't understand how long something can take. I'm a prime example of this, as I sometimes estimated things to be much shorter than they actually would be. This played a pretty big role in several major landmarks, such as a working player, iron sights, and playing online.

When I am the only one assigning deadlines, I would miss huge pieces of information and that would drastically sway the deadline date. As a result, team morale suffered.

Lesson Learned: Team members should compromise on a deadline with added insight of the team leader, not solely the leader. Nothing should be under-estimated, as sometimes things run into a lot more problems than originally thought.


If I had to redo it all over again, this is what I would have done:

  • Create a VERY simple game design document calling for no more than 1 weapon and 1 map (Crimson Crow had around 27 weapons modeled and textured) with full knowledge that more would be added on after a release.
  • Base the models off of concept, rather than somehow having two very different styles of each. (Very few weapons were directly made from the concepts. Out of several character models, only one was from concept as well.)
  • Put every prop organized into a folder, along with the original texture and an FBX file.
  • Spent a few months learning how to use every little part of the engine as well as testing features, and picking up ways to optimize along the way.
  • Invited various watchers to closed developer alphas to get some ideas and what to fix.
  • Hack the backstory and use only one main character. (Crimson Crow has around 28 central characters, after which we decided to only use 4 in-game, which was still too many.)
  • Somehow have an art style based on the comic that Crimson Crow was originally based on. (Crimson Crow once was aimed for a black/white/red style that was later dropped.)
  • Let the team debate and finally decide on key issues. (Crimson Crow was usually swayed by who was doing most at the time.)
  • Effectively use deadlines. (Thinking on it, very few deadlines for Crimson Crow were hit.)

So there you have it. We hope that this helps some developers.



ah my heart, you stir salt into the wound

Reply Good karma Bad karma+7 votes

sorry to hear this. CC looked bad ***. i hope you can keep most of the files, models, textures, animations, etc. b/c we might be able to produce something for PC distribution in the near future after (AMS) finishes its current iPad, iPhone, and first PC casual game. if you ever want to talk, let me know. thanks, and good luck in your adventures!

Reply Good karma Bad karma+1 vote

It's great that you can look back and recognize what your mistakes were, so that you can avoid them on whatever your next problem may be. What's even better is that you're willing to be completely open and honest to your fans, sharing what it was, in the hopes that they can understand and also, perhaps, learn something themselves.

Thank you for this very enlightening document, and I think many people can learn from this.

Reply Good karma Bad karma+5 votes
JustDaveIsFine Author

Now that I can finally step back and look at it all, things are much more clear. Fortunately I think I won't into half these problems if I start another project.

Reply Good karma+1 vote

On this:

* Let the team debate and finally decide on key issues. (Crimson Crow was usually swayed by who was doing most at the time.)

This is why I believe mod teams more or less have to be dictatorships. If you don't have one strong vision for people to follow, it see-saws from one design dead-end to another. It's also why the team leader needs to work their balls off ( thus earning the right to make the decisions by merit of doing most of the work ;) )

Reply Good karma Bad karma+4 votes
JustDaveIsFine Author

I should re-phrase that. I should say teams should debate on key issues then stay with it, if there are any debatable issues that are not covered in the game design document.

We didn't make an official design document until about 15 months after we started, so obviously we had a 'lot' of debatable issues.

Reply Good karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.