Switching engines can be considered a fatal move in terms of development. When a project is designed for a certain engine, simply flexing what you have for an entirely new engine can be difficult and time consuming.
This article is specific to Martin_Berger's question on our previous engines, before we switched to our current engine. Specifically why previous engines didn't work for us, and why we moved on.
Our very first engine was Torque Game Engine, which put bluntly was a modified version of the Tribes 2 engine. When Crimson Crow's development started, Torque Advanced was still 'behind the scenes', and Torque was a fairly popular multi-platform engine.
Development overall was fine. Torque was a flexible and pretty robust. Not to mention multi-platform, so it had a lot going for it. Knowing a lot of Linux gamers, this was something well worth keeping.
Unfortunately, Torque was even by then, old. Many shader techniques, model formats, and so on were just old. One of the biggest hits to the side of development was the fact normal maps were not supported. This was upsetting for the artists on the team, and so a decision was to be made.
The jump to Torque Game Engine Advanced wasn't a difficult one. The general model format, .DTS directly transferred over. BSP architecture called .DIF files just needed simple relighting.
Yet we ran into a lot of problems. At the time, Torque Advanced did not run on Vista. Even more so, there was no known ways to run the game in any Linux distribution.
Another large problem was lighting. Lighting was baked in but for some reason took extremely long times to fully light. In average cases, lighting took 30-40 seconds. That number increases to several minutes, and would sometimes have to relight every time a map was loaded.
Lastly, Torque Advanced was poorly documented since most of the known documentation was created for the original Torque.
Progress was shaky. The team was shakier. With so many problems development slowed, and so we made a jump back to Torque original. Luckily it was updated, since the last time it was around.
The team was hesitant on jumping to an older engine, so we came up with a clever idea.
To prove we could effectively make the original Torque look just as good as Torque Advanced, Warlord and I built up a new version of Torque original and without the team even knowing, displayed screen-shots used with the older version.
A few weeks later, we announced the transition. The article was fairly popular, and so we must have done something good.
Torque original was much smoother again this time around. But this time we ran into a whole new problem, we were pushing the engine too far. Articles recommended 128x128 or even 256x256 resolution textures to keep the engine happy. We had over a dozen 1024x1024 resolution textures for environments. Not even including high resolution characters and weapons!
Development pressed on for awhile and eventually a team talk was much needed. Normal maps were still out of the question, and that still put a damper on the artists.
Torque Advanced later announced Vista support. Since we did it before, we knew we could certainly do it again, so we hopped over to Torque Advanced.
Torque Advanced had more articles this time around, and much better lighting times, had normal map support but no specular map support. We roughly coded something in, but decided against it since it just didn't work well.
At this time, Torque 3D was coming out of beta and into full release.
Just like we did in Torque original, we began hitting walls in Torque advanced, and Torque 3D became all too tempting.
One problem was that Torque Advanced offered no support for specular maps. Another was that only two members on the team could save models in the game, because new exporters were needed. With the announcement of Torque 3D and with everyone jumping on board, it seemed the creators of the exporters gave up. (Oh, and Torque and Torque Advanced had all support dropped officially.)
Then, with the announcement of UDK, a lot of pressure was on. Now the team 'knew' there were very good and free choices and 'knew' Torque needed to be left behind.
Unlike previous engine jumps, going to UDK is new everything. We couldn't just drag and drop models over, BSP architecture needed to be completely re-made, even textures had to be made in a different format.
The work was daunting, and we knew this would put us back in development.
The biggest problem was that our only programmer didn't know much about UDK's style of code. Jumping to the engine seemed cloudy, and so we finally decided against it.
In order to make an effort, we 'decided' to switch to Torque 3D.
This was a botched decision. We were only using the demo to test the engine. After we announced we would use the engine, it suddenly dawned on development that we needed the full source to get what features we wanted to incorporate done.
A large influence on suddenly going against this was from e-mails. We received some strong objections to Torque 3D from IMs and E-mails. All were very civil, and made strong points against the move.
After a short talk, the team decided to head back to Torque Advanced.
An important decision in the process of this all was the most unexpected.
The death of Crimson Crow.
We announced failure in May and decided to just give up for the time being. It didn't take long for a few of the members, to gather up and revive the whole thing.
FoTacTix made an effort to talk with developers of professional engines. After some discussion, Chrome was agreed upon.
In retrospect, its much easier to see what you want in an engine when you know exactly what you want.
Picking out an engine is never a menial task and should never be regarded as one.
Some good general questions to ask would be:
- Does it support basic features your team need? (Normal maps, collada format models, large scale maps, ambient occlusion, etc.)
- Is the engine well documented with up-to-date documentation?
- How successful are other projects using the same engine? (Generally speaking, if other people have problems with certain aspects of an engine, you may too.)
- How does it stack up against other engines of it's class?
- How expensive is the engine, combined with the tools the team will need and the exporters?
It my opinion, its a poor decision to compare Torque to Chrome because they are both on different levels. Value wise, the original Torque engines (Torque and Torque Advanced) were pretty good value overall and you got precisely what you paid for. Since I had a partial experience with Torque 3D, I can't give a full review since I never got too in depth with the engine.
Either way, I hope this helps Martin Berger!
If anyone else has any specific questions, feel free to ask. Cheers!
Well chrome looks pretty badass so goodluck.
This is a very very good article. Personally, I have gone through this myself with past projects. Take a look at my team's game, Grand Heist for example. I believe we might have started developing around the same time as you. In fact, I started developing the game on Torque Game Engine Advanced many years ago. Throughout development, we switched to 3 different engines (Basically because I kept listening to my team a bit too much and following everything they said. Our team used to be a bit too democratic in that sense). Each time, we ultimately lost more and more fans. If I've taken anything from the experience, it's this; BEFORE you make any content what so ever, you need to compile a list of the features you'd like in your game. Search (Or build if you have the know-how) for an engine that suits your needs. Think you found the right one? Well keep searching because there is bound to be more engines that have what you are looking for.
guys, guys , guys. UDK.
The documentation is massive, the results are proven, and you don't have to cry about missing normal maps ever again :)
Ah, you simply misunderstood this.
We had someone ask about our previous engine selection, so I typed this up explaining all our transitions to our current engine Chrome.
I edited the first part of the article to be more specific. I'm surprised I didn't mention what the article was specifically before.
Sorry for the confusion. :)
I didn't misunderstand anything. I read your article and you guys were / are flip flopping like crazy. You mentioned you tried UDK but couldn't wrap your head around it so quit and moved on to something else. My advice is to re-trace your steps, find someone who knows unrealscript (really it's much like Java) and buckle down and pump something out. There's a billion youtube videos and very handy Video training modules for UDK, with more being created each day. After all, there's a reason big companies pay millions of dollars for epic's tech ....
You make some very good points here.
Though we don't plan on making any more engine hops for a very long time now, if any.
I'm all for Chrome, even though Unreal Engine looks top since it's latest update and has all the tools and info. Instead of getting ripped off by EPIC, you will actually be able to keep your money and use it for a follow up project. If Unreal was the best solution, games like Overgrowth and Natural Selection wouldn't need to use custom engines.
Of course I'm not all knowing like Santa, but I think Chrome works with CC on the spot, while Unreal would have meant a lot more tweaking from the start. Considering the CC style the Chrome engine can deliver very well.
Techland was very gracious to let us use their engine, that said I think we've been doing well with it so far.
I can't say engine X is better than engine Y. Both UDK and Chrome have their advantages and disadvantages. Both are very well documented and neat engines.
What I can say is that we're dead set on continually using Chrome, we've done far too much engine hopping in the past and I sincerely hope we won't do so again.
We've invested a lot of effort into what we have together right now and stepping back for another major change could really hurt what we have going for us right now.
Both Overgrowth and NS2 were started quite some time before UDK became available in such a form as it is now for a couple of months...
Nice read. I'm programming engines from scratch myself and I've restarted quite a few times, always taking a slightly different direction. I thought I was the only one! :P
I wish you all the best of luck!
Good Article, this shows people how much work goes into choosing engines. Sometimes it's best to just stick but try work around limitations, all eninges have something wrong.
Nice article,
The only gripe I got with everything you said is this line....
"Does it support basic features I need? (Normal maps, specular, etc.)"
You do not NEED Normal maps and spec maps, this day and age they are nice to have, but they still need to be done properly. Spec maps can be sone quite quickly and easyily as long as you have carefully planned how your building up texture layers....Normal maps are another matter. In my opinion people who add normal maps for the hell of it are neive, you are doubling maybe tripling artwork creation time, since most,if not all the major artworks in the game will need a high poly model made, then baked to the low poly....this takes along time to get right and looking good. (main charcters,wepaons, large static meshes/objects etc) some more minor stuff you can get away with putting through the Nvideafilter/Crazybump, which looks half arsed if done on major objects.
Im still in the camp of people that says a well painted texture still looks as good as a model with a well painted diffuse but badly implimented normal and spec maps.
Also gameplay should always come before Graphics.....and yes im an artist :).
My 2 cents....good luck with the project.
John
@Bronco
Spec maps were important for the look we were trying to obtain. Also, on the torque engine, this was not easily accomplished. We had to embed the spec maps using an older version of superpng as torque did not support the commonly used TGA format. This photoshop plugin also only worked on 32-bit versions of Photoshop.
Normal maps would have helped us get some "pop" on all the flat buildings and low poly models. Torque didn't allow for us to have high poly models. Even with normal baking, (high to low poly) there wasn't that much of a difference or it just didn't look right. Also there are several professional studios that use crazybump. It can take some work to get the right look, but I'd say it is a damn good utility. Xnormal is also a great tool, but not as user friendly. :)
@AJ
I'll consider firing our long time programmer who started the project and bring in a new guy next time around ;) jk. Perhaps you know unrealscript?
I do , but it's something I've learned over the course of a few years working with Unrealtech. I have very little programming background - which goes to show that it's a pretty accessible language. Anyway, if you're set on Chrome that's cool - but I do think you should have given UDK a longer shake, once you get down the basics you can prototype so rapidly it's mind-blowing.
Well to be honest, I didn't mean to say normal maps is a must have.
Our development team felt that was a needed feature, but I mean to say that when searching for an engine you should find out if it supports basic features your team requires. Maybe collada format, or dynamic lighting, or ability to create large scale levels.
I'm a programmer, and sometimes I don't see much of a need for normal maps. We originally incorporated normal maps on a massive scale for the second round of Torque Advanced.
Since most of the architecture was BSP static lighting format, diffuse textures could not be baked in. Also adding too much detail to BSP architecture caused many collision errors. You'll see in a lot of our older screen-shots, buildings were very flat. Basically big blocks.
We figured normal maps would do tremendous good to help with our block buildings.
Collision boxes and shading were iffy in Torque sometimes, especially around default (.dts) models. We could have created models and bake a very nice diffuse, but the results were a collision box that let bullets pierce it, no shadow, or sometimes let you walk through.
This was the big reason when Torque 3D came out, .dts files were thrown away for Collada.
We eventually came around to baking in an Ambient Occlusion into the standard lightmaps, which led to what the 4th screen-shot shows with subtle shadows behind objects.
In a nutshell, I'll correct what I what wrote by adding more examples. :)
nice article! I hope you do stick with Chrome as it is a fine looking engine. Good luck with the project as I have been looking forward to it for a long time.
I had almost the exact same experience. Torque was really really hard to work with from a model creations standpoint. I've moved on to UDK and couldn't happier.
How can you get a free chrome license?
You'll need to talk directly to Techland for anything relating to licenses.