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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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'.

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.

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.

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.

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.

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!