The USSFC is losing hope and losing the war, but the poorly equipped Legion are losing soldiers fast. This is the desperate last struggle of two clashing armies... This is Crimson Crow.

Report article RSS Feed 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 ninjadave on May 10th, 2010
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.

Cheers!

Post comment Comments
azultain
azultain May 11 2010, 6:43am says:

ah my heart, you stir salt into the wound

+7 votes     reply to comment
moci
moci May 11 2010, 6:45am says:

Good resume. I think we, who have done some (failed) projects already can agree that communication and other things you mentioned indeed are a common problem.

But I think the biggest thing you can learn from projects like this is to start small.

Start with a prototype showing the art style and main character, get an idea for the rest of the game and the game-creation progress.

----

I always found that you were engine hopping way too much. You could easily just switched to something like Unity when you felt that TGE/A/FGAZ/RDR/ was giving you more trouble than you liked.

Too late now of course, but you must learn from your mistakes.

Great article Dave!

+3 votes     reply to comment
ninjadave
ninjadave May 11 2010, 5:57pm replied:

Well it seemed pretty logical at the time, but now looking at it, that was just a silly decision.

+1 vote     reply to comment
evan0605
evan0605 May 11 2010, 12:03pm says:

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!

+1 vote     reply to comment
Elementalist
Elementalist May 11 2010, 12:59pm says:

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.

+5 votes     reply to comment
ninjadave
ninjadave May 11 2010, 5:56pm replied:

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.

+1 vote     reply to comment
Gibberstein
Gibberstein May 11 2010, 2:01pm says:

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 ;) )

+4 votes     reply to comment
ninjadave
ninjadave May 11 2010, 5:54pm replied:

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.

+1 vote     reply to comment
Post a Comment
click to sign in

You are not logged in, your comment will be anonymous unless you join the community today (totally free - or sign in with your social account on the right) which we encourage all contributors to do.

2000 characters limit; HTML formatting and smileys are not supported - text only

Icon
Crimson Crow
Platform
Windows
Contact
Send Message
Official Page
Crimsoncrowgame.com
Release Date
TBD
Game Watch
Track this game
Tutorial
Browse
Tutorials
Report Abuse
Report article
Related Games
Crimson Crow
Crimson Crow Indie Multiplayer Tactical Shooter
Related Engines
Torque Game Engine Advanced
Torque Game Engine Advanced Commercial Released Oct 31, 2007
Related Groups
Indie Devs
Indie Devs Hobbies & Interests group with 1,104 members
Round House Studios
Round House Studios Developer with 2 members