I’ll take a stab at the questions - my background is very similar to yours: I have about 8 years professional business programming experience (mostly C++ and Java) and about 15 years playing around with games programming (I had a beta quality raycast/heightmap renderer ready just after Doom I hit).
I spent a great deal of time over at GarageGames and got to know the TGE engine pretty well (enough to feel like I could implement whatever I wanted, given enough TIME).
I spent about a year whittling down a few game designs to finally reach a point that I felt I could design and finish something with a very small team (me). I was in the middle of prototyping my idea with TGE when I first read about Unity and downloaded the demo for a peek. I set a goal that if I could prototype my game by the time the demo expired, I’d buy the Pro license to go ahead with implementation. Its a good chunk of change compared to TGE, but my reasoning was that if I could finish a prototype within 15 days (rough edges and all), that’s a good bit better than I’d managed so far with TGE, working a full time contract during the day (half a prototype done in a month). By GG standards, I’m no TGE guru, but programming-wise I got the impression I’ve got more experience than most. Most of the TGE gurus have been with the engine for 2+ years and could probably prototype something just as fast in TGE as I feel I could with Unity now (after a month, I think?).
I was planning to post something like this over in GG forums, because I feel its pretty objective, but it occurred to me that objectivity is not something you want to hear about in the forums of an established community (even though I wouldn’t have said that Unity is perfect yet!) and I didn’t have the time and energy to defend my review.
My biggest concerns follow your first question: How does the flexibility between the two compare? My counter question was something like this: How much of Torque’s flexibility will I need in the first 2-3 titles I might end up shipping?
I think roughly the flexibility you get in the Torque products can be stated something like this (assuming the implementation effort is not a factor to consider, which is a rash consideration!):
- can integrate 3rd party libraries into core code (my plan doesn’t rely on this, so I can’t advocate Unity’s plugin architecture simply because I haven’t looked yet)
- can modify core rendering code
- can port to other platforms
- can throw away or reuse foundation code for any component
- can focus on optimization specific to your game
With that there are a few negatives as well:
- steep learning curve (TGE has a huge codebase to familiarize yourself with if you truly want to master it)
- if something in your core code breaks, guess who gets to fix it (and how many permutations of hardware that could break it are there?)
- Mac-specific code has been mostly treated as an afterthought (though I think the upcoming release should have some fixes towards that)
So I think I’ve established that Torque is a good solution, but perhaps not optimized for smaller teams/timelines. Evidence that supports this in my view is that most of the interesting 3D projects over at GG are spending considerable time reworking physics code, rendering code, etc. If you’re going for a straight FPS, TGE almost works out of the box (aside from AI, more complex physics, and a few little bumps and niggles). If you diverge from that path, you WILL spend time in the core code. The art pipeline is useable, though I think it has a higher barrier to entry for art and sound guys than it should for quickly prototyping.
Whew! Ok - that was mostly giving some background. I tried not to go too deep, but give my impressions as objectively as possible. GG has a great product, but I think the ease of use is a bit oversold in their forums.
With Unity, you’ve just lost out of the box networking. If that doesn’t cause your heart and mind to shut down, it only gets better after that. I’m an (somewhat critical) optimist by nature, so keep in mind that I believe Unity is an evolving product, and any weakness I see, I believe will be corrected (which is why I backed that up with a Pro license purchase). Unity’s greatest strengths from my perspective, and roughly in order of value:
- rapid turnaround on core fixes. I rank this one higher than “features” partly because it is such a new product, but I hope it stays this way! Its a big leap of faith for me as a programmer to put so much trust in another group of programmers. I read around a good bit (even searching for posts from before Unity’s release when one of the Unity programmers was arguing with another programmer about some idealistic bull. Thus far, most propaganda has remained consistent which is a good sign from most programmer types).
- Good physics - since 99% of games need some kind of physics support (even simplistic) and physics are not such a simple thing to implement…
- Windows support, without windows: To stray a bit again, my first computer was an Atari 800XL. The Atari ST was inconceivably cool. A window into the computers DESKTOP! I didn’t even know they had desktops! Then Windows 3.1 came out, Ohhh, that’s just like GEM! Hahahaha. Anyway, I’ve been bitter ever since, but money convinced me I can get along with them (see, people have to PAY me to be a windows programmer - I’m glad Unity guys are kind of masochists. Does that make me sadistic?). Anyway, I believe they have a great deal of self-loathing, and will continue to provide good Windows run-time support, good luck guys!
- art pipeline - if you’ve got Maya, you’re golden (with native support). I use Lightwave, so I have to click the damned “export” button. Well, there are no converters in the middle ;). Also, there is proper support for Photoshop PSD files, like most professional apps should support in development stage. If you’re working on tweaking a texture, you don’t want to have to flatten and export it every time you darken the color a bit. Just hit the save button and switch apps.
- the IDE: even GG sells implementing most/all game functionality via scripting. As a programmer, used to setting up builds, building things and waiting for it I can’t believe how happy I am to connect an empty script to an actual game component, double click the script, edit the code and see what it does IMMEDIATELY. No datablocks, no file management, etc. This has to be the single biggest time-saver for me. I started out intending to write most code in C# (because of my C++ background), but quickly realized that Unity GIVES you an OO-oriented view of things for free, even using a functional programming language (like Javascript). When you connect even a single function to a Unity GameObject, you are in a sense extending it. Of course in some situations (overall game logic/management comes to mind), C#'s true OO nature is good, but in the general case, I like this Javascript way.
- the IDE (part 2): dropping game objects into the world. Although there are a lot of parallels between TGE and Unity in this case, Unity has the better implementation IMO. Within Unity and TGE you can dynamically update and place things, but with TGE there are some restrictions that will cause you to exit TGE and restart it (because TGE’s world editor is in-game while Unity allows the world editor in-game and from the IDE, whose lines are nicely blurred anyhow). Although functionally you could argue that in both cases you must stop the game to make more than minor changes to objects/behaviors, Unity does not force you to leave one environment and enter another to make these changes. At least for my addled brain, context switches slow me down and I don’t like them. There are lots of workarounds in TGE for some of these differences, but you have to dig deeper and implement engine-level changes to make it truly comparable.
- the IDE (part 3): Everything follows this GUI approach. Not sure yet how you want levels to be laid out? No problem. You can easily work on levels separately from game logic in the IDE, each as a separate entity, where each one is completely disconnected from others, or shares common assets. If you have a game level that doesn’t fit your physics/control model very well, you can tweak things in that level and propogate changes back to all others. Or you can just throw it away and start on it again without disturbing anything else. Internally, you can refer to your levels by index (or name, I believe) - just increment a counter, don’t worry within one level what the next is named. When you build your app, you specify in which order the levels are arranged and in general that’s that.
Anyway, I got a little carried away, but realize almost any review of any software product is as much subjective as objective. With software oriented towards creative ends, as long as its capability is measurable and you can determine that it WILL do what you need it to do, emotions tend to determine how far you will be able to take it to your destination. My reasons for choosing Unity over Torque at this juncture are practical: time. If I had limitless time, or a time gzipper or something, I might decide that I’d use Unity for prototyping everything, and Torque to implement because then you can go crazy and code all day for years. Then you have time to teach yourself all the rendering techniques, all about different drivers, all about physics, etc. Since I have very limited time (and more and more because I believe Unity will evolve beyond even its current state of beauty) I’m going with Unity for at least a few games because I believe it will help me complete them (not in the sissy holding-hands kind of way, but more like the instrument play-me kind of way).
For the first time since I started selling my soul to the capitalist regime of the USA, I started believing I will finish MY game - and even my fiancee started believing recently (whoo! I’m approved to buy another software license to get some better models in the game!).
OK, someone better switch this microphone off bef…
