Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

Unity vs Torque

Discussion in 'General Discussion' started by prometh3us, Oct 4, 2005.

  1. prometh3us


    Oct 4, 2005
    Hello everyone!

    I want to start by saying that from what I've seen so far I am very impressed with what Unity can produce. The demos are quite impressive...especially that screen shot of the demo from WWDC. I do not want to start any flame wars here as there are most certainly pros and cons to any toolset. I just have some questions for the community, especially the developers, and am very curious about how people in the crowd feel about Unity versus Torque in particular.

    I have been researching game and rendering engines for awhile now trying to find a full set of development tools and a powerful base upon which to develop and/or quickly prototype (i.e. remove as much coding as possible...not reinvent the wheel) some of the game concepts that I've been noodling over for the last several years. I also want to be able to take take the product to market without any significant constraints so I have looked at both high quality indie tools as well as 'professional' middleware in order to ensure an efficiency of development effort and a studio quality output. (Beauty falls second, a close second perhaps, to gameplay. I just need to ensure that the 1st impressions of the games are positive given the hyper inflated expectations that $10MM+ budgets tend to create.)

    I have experience with and own both Mac's and WinTel so I'm not wedded to a particular platform. I am a developer that has been responsible for creating forecasting and predictive modeling applications for the financial industry for the last 9 years so I lean toward math, AI and coding. I have delusions of artistic skill but realistically figure that I can do enough to rough out a demo and get help from there.

    So I have a few questions:

    • How does the flexibility within Unity compare to Torque? Getting the full source code in Torque gives me a lot of flexibility to expand and/or adapt as needed. However, that obviously comes at a price given the amount of time required to master the code base and create behaviors. How much of a tradeoff exists with Unity?

      Are there any other concerns that you may have had about not having access to the code base directly? It can be technology concerns or simply a question of what happens should Unity not take off as planned and the development of the engine die off a bit? Where would that leave games developed on this technology that need to evolve to new levels?

      Is your use of Unity an economic choice or if you had the budget would you opt for Jupiter or Gamebryo? (I belive they both have rather understanding indie license agreements even though I am under the impression that the actual licence costs for commercial distribution end up being the same if you are successful.)

      Has anyone experimented with multi-player games and investigated the networking aspects in Unity versus Torque? Yes, using .net in Unity opens up the potential to do networking but that is an extremely sensitive area that can take quite a bit of time to develop and debug if you want to be capable of supporting a significant number of players. I could rip the networking code from elsewhere if necessary but having the low level access to do it right seems to be critical. Is there the ability to use any 3rd party networking toolsets? Incorporate external code written in C/C++?

      As far as the modeling tools, is there a preference to using Maya, C4D or Lightwave? Is one easier to integrate into the pipeline? Which one would be easier for an artistically challenged coder to pick up?

      Are there any general constraints on the engine in terms of the type of game that can realistically be developed without asking the toolset to use features in overly 'creative' ways? A RTS like Rise of Nations? A game like SimCity? A small scale (<500) MMO type game?
    I appreciate any feedback since my previous experience with game development is rather dated at this point. I am very excited about exploring my ideas now that I have more time and resources to do so but I would like to choose carefully as I do not want to invest quite a bit of time (MUCH more so than money although some of the price tags make me see stars and than black out) pursuing a suboptimal solution.

    Thanks for any help.

    Best regards,

    P.S. Sorry for the lengthy post!
  2. Joachim_Ante


    Unity Technologies

    Mar 16, 2005

    • While developing Unity we have always tried to keep it very flexible. Thus the component system, attachable scripts etc. With the plugin system you can render your own geometry in opengl. So if you wanted to eg. embed, that should be possible.
      That said, there is always a possibility of us having missed out on something. If that happens, just report a bug and we will try to get it fixed as soon as possible.

      Source code licenses are available on a per-production basis. If you are interested in it, you can contact about it.

      Both of those tools have no rapid prototyping capabilities. Gamebryo doesn't even have a scripting language embedded.
      Both do not focus on workflow in bringing the game together. None of them have a webplayer. They don't have a single click to publish capability.
      They don't provide a fully integrated automatic asset pipeline.
      (This is only the short list of disadvantages)

      There are two types of game development middleware/tools.

      1. The traditional middleware. Many game development companies today stitch a complete game engine together by licensing several middleware technologies. Then building some kind of tools to get all the artwork and code to work together. For this obviously you need source code. It requires a high proficiency in C++ and game development experience.

      2. Complete game development environments
      This is where Unity is. We try to provide a complete environment, which covers everything from getting your art in, scripting, setting up behaviours and publishing the game.

      We chose to go the second path because we want to provide our users with a fluid experience all the way to publishing.

      Source code with the latter is less important for two reasons:
      1. The source code is incredibly complex. The only way to provide a good user experience and get people started real quick is by providing a clean high level API on top of it and hide the 400.000 lines of code below.
      We chose to do this in .NET because it gives us a very good combination of speed, iteration time and flexibility to use multiple industry standard languages.

      2. If you want to get proficient in the source code of any modern game engine and extend it, you need to plan around 8 months to learn all the tricks and get the hang of it. I believe that for most people, the time can be better spent making the game.

      3. By not modifying C++ source code, it opens up for one click publishing. And makes it possible to build a secure web player. Publishing Web Players or Dashboard widgets are incredibly good for advertising your game.

      The biggest concern i see with non-source code based engines is with not being able to fix bugs in the source code yourself.
      We are trying to alleviate it by prioritizing bug fixes above everything else and providing patches quickly.
      If that is not enough, you can license the source code.

      A network layer can either be written using the C/C++ plugin system or on top of the .NET sockets. I know of one guy who is going the .NET socket route at the moment.

      We will provide an easy to use game oriented network layer but we can't say when it will be released yet.
      The most fluid workflow is from maya.
      Cinema 4D works well too but doesn't have a direct c4d importer yet.
      (We are working with them on it)
      Lightwave works fine if you stay away from a few features (eg. don't use multiple texture sets on one mesh)

    Our game development company branch is working on a top down RTS with a lot of characters running around and interacting. You can be sure that if any problems with this type of game pop up during development they will be removed very fast.
  3. lurid


    Aug 28, 2005
    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....
  4. lurid


    Aug 28, 2005
    Remarkable. I believe we said mostly the same thing, but Joachim managed without so much noise ;)
  5. Joachim_Ante


    Unity Technologies

    Mar 16, 2005
    It was extremely interesting to read your post lurid.
    Thanks for that.
  6. dingosmoov


    Jul 12, 2005
    I'm an artist. I own a license of Torque and TSE.
    I thought Torque would be easy, it is not.
    Unity is easy, built how I think.
    With Torque I will never finish a game.
    With Unity I will finish games.

    The only thing that draws me to GarageGames is the hope /promise of getting a game on XBox Live Arcade. That's it. They already have the relationship with the XBox people and that is the single most appealing thing about Torque in my honest opinion.

    For me Torque is like coding a webpage with a text editor. And Unity is like doing it with Dreamweaver.

    Unity is better because it will make you get your game out faster. In a casual game market that is growing into a billion dollar industry, it is better to be first in.

    Seriously, many people made millions during the dot com boom. Then many people tried to get in, but too late they missed the wave. The current wave is casual games, the faster you can get in the better you will be able to cash in. Don't get me wrong I love games as an art form, but I'm looking at it to put food on the table.
  7. prometh3us


    Oct 4, 2005

    I guess that this is why I posted to this group versus the GG board. After reading the forums and seeing how helpful everyone was I guess that I shouldn't be surprised by how thorough and helpful the responses were but it makes me feel good about investing in a product that has the project lead responding in detail and others excited to share their experiences.

    A couple notes -

    • Thanks so much for taking the time to respond with as much information as you did. Know that it is greatly appreciated. I will definitely research the component system in detail as part of my intial evaluation. And knowing that if need be the source can be purchased eases my concerns of using the toolkit as I recognize the immense value of becoming more productive faster. I may touch base with David to better understand how this works.

      Also as a side note I find it very heartening to see that you guys are investing in serious games as I think that you are right and there is a great social need for these type of dynamic learning environments. Many of the games that I have seen in this area are responsible for saving lives. It makes me feel good about doing business with a company that holds these values.
    • Thanks for all your insight! That was a very informative post that I think will well serve people that come to the party later. I think that you presented (based on my limited knowledge) what seems to be a fair evaluation and comparison.

      To be honest the lack of built-in networking is something of a concern but I think that it is something that I already have a good idea how to remedy. Hopefully it shouldn't pose to much of a problem should I invest the time and research diligence required to solve it right. Afterall, just by not having to learn Torque well enough to match development speed with Unity I gain 2 years of development time. :D

      Your comment about having to spend a bunch of time in the core code to get functionality outside of a straight FPS is what really concerns me on both sides. It was very good to know that Unity is supporting an internal RTS development effort as that will help ensure that the 'development' environment remains flexible and adaptable to more than one game style. Not knowing first hand just how flexible the toolset is makes this the area where my concern is the highest and why access to source code becomes appealing. I may not want to dabble in the code of an engine like Torque or Unity if I can avoid it but having the ability to do so if required gives me some comfort.

      I am currently spoiled as the developers that work for me now are much more skilled than I am and I don't have to worry about what I don't see. I know that this is not always the case so tend to err toward open code bases when I want to ensure control of the outcomes. With that said how much of our critical toolset that we use every day isn't open? Visual Studio, Windows, MSSQL, Oracle, at least some of OSX, MS is a long list to be sure.

      While I know that it is probably said quite often I'll risk being cliche and add that I am envisioning some unique game play elements and have a very odd focus for my ideas. It is such that I know that I will have to be very creative in trying to bring these ideas to life and want to ensure that the toolset is flexible enough to adapt to those ends. (Hey I've had to design software for financial services companies...I know about creativity. :eek: )

      The first point on the IDE is well taken here though. Not only having the flexibility to use procedural code where easier and still retain the strength of an OO architecture but the subtle yet important truth that gameplay is key and is really managed quite well through scripting. Really this is where I run into my main concern. As long as the flexibility exists within the toolset through scripting and the component system to support my vision of game design then I'm OK. I just need to invest some time in exploring Unity in detail to understand how extensive the flexibility is and based on the responses I definitely think it is warranted.

      The windows without windows comment made me laugh. Mostly because of the painful truth. I like OS X as a working environment much more than windows. Having a tool like this makes life a lot easier to meet market demand and retain the pleasure of using my G5.
    • Based on the response to your earlier concerns about the XBox Live Arcade from David I'm optimistic that they will be able to address that in the future. Creating as many channels for distribution as possible for the games people create with this toolset only increases their exposure and the potential base of users. Besides, you are right, food is good. I personally find that it makes me much more perky.
    I'm very hopeful that Unity will be the right tool and I'm going to bet a few hundred bucks that it will be. :wink: As soon as I drag my beloved G5 out of the corner it has been confined to for the last year and find a monitor for it that is.

    Best regards,

    Well, by now I have clearly exposed myself for the windbag that I am. Thanks again.
  8. NicholasFrancis


    Apr 8, 2005
    As the director of the RTS, if you have any concerns about how we do things, I'm happy to help - either by mail or on the forums...

    I just posted a few screenshots from our first monthly milestone.
  9. prometh3us


    Oct 4, 2005
    Thanks Nicholas. I will definitely keep that in mind and I greatly appreciate the offer. I looked at the screenies and seems like a lot of character detail for a RTS. Is the plan to show the detail to make the violence more personal? I would be personally interested in better understanding your design goals for the game. I have a couple degrees in Philosophy and took a two courses on Just War theory in undergrad so I find the topic rather intriguing if for no other reason than the immense philosophical, moral and system dynamic complexity involved.

    I just got my Mac back up and running with Tiger now installed. Now I remember why I put it in the corner. Having the opportunity to use this every day makes the transition back to windows for work purposes all that more difficult. :evil:

    btw...If anyone can tell me, what tools were used to develop Unity? Was it all done on Mac's using Mono? What tools? XCode? Eclipse? What was used for source code control? Curious how a best in class company does it's development for a tool like this.

    Best regards,
  10. grobm


    Aug 15, 2005
    I am a guy that works mainly on a mac. I have released two indie games on TGE. TGE is a nice game engine for the $$$. But it requires a lot more learning on the part of the developer. The Books that are published for the Game engine speed the learning curve alot... but I must say. I have been playing around with Unity on mac mac for a week and I already ported most of my current project to the environment. Futhermore, I love the Maya integration!! I do art and code since I am a one/two man show for most of my development.

    If someone wants to develop games on the mac... this is the best solution I have found. After reading three tutorials, I was able to start building/porting the game. The FPS sample really helps... I looked at Unity I think last year but did not find it as useful... the latest changes really help.
  11. rayBLAST-R


    Dec 17, 2005
    Correct me if I am wrong, but I believe Unity was created with a whole different mindset than GG had when Torque was built. Matter of fact Torque was a game engine built for the Tribes FPS under a different company, if anyone remembers that game. Classic implementations for a typical FPS engine were used -well, what I would call standard fare or classic. That is not to say that Torque has not grown into something else over the years. Unity uses a different paradigm. It also filled the hole left by Director and then some. Furthermore, a sort of realization of where Unity's technology can go was made and now it seems to be coming to fruition.

    I look forward to the developments that I am sure are in the works now. Things are going to get really interesting in the next couple years.

    Maybe I've said a lot, or maybe I haven't said anything at all. hmm…
  12. Quietus2


    Mar 28, 2008
    Welcome aboard! You're not the first person to pose such questions, there are a good number of people here who are torque refugees.

    I own TGE and TGEA. I also own Unity Pro.

    At first glance Torque would have more flexibility, being that you're given the source code. In fact I've seen this oft mentioned on the garagegames forums meant to deride Unity and as a 'plus' in the Torque column.

    Unity is very flexible and extensible with it's plugin architecture and the ability to just run with any dotnet dll. Say you found a neat class written in C++ or C# that handles crowd or flocking dynamics. You will find it is far easier to integrate that with Unity than with Torque.

    The fact is you don't really want to go poke around in the bowels of torque, as it hasn't had an enema in the past decade or so. It's a scary sight down in there. I remember poking around in the collision code once trying to get something working, only to stumble upon all these undocumented functions that were comprised of (no joke) two character variables.

    There's also the pages upon pages of code that's just plain commented out. Some of it is just silly such as the infamous, "Insert clever pathfinding code here." Some of it were things they never got working properly during TGEA. Other stuff is just random. A bunch of variables declared in a class but never used. Blocks of code from years ago that's just there but nobody knows why.

    In the Torque community, they lovingly gave this stuff the moniker of "GarageGames Bonus Code."

    If torque were actually clean and well documented modular code it would be a different story. Honestly it's not really even a game engine. It's an in-house fps engine that was never meant for public consumption and it shows. Tbqh, it's garbage and garagegames should pay me for having suffered through it for three or so years.

    Scripting is another misnomer, I wouldn't really call what you do with Unity scripting in the sense you might be used to with torquescript. I can't remember any instance where I could directly manipulate mesh verts or draw GL lines with torquescript. It's just not something you do.

    With Unity, the 'scripts' you create are actual classes that directly interface with the core engine.

    Of course the drawback is that you're stuck with what Unity exposes. For example a number of people are clamoring for upgrades to the version of Mono and PhysX. Others are begging for a voxel terrain engine to give them more flexibility. I'm sure we'll see it in Unity 3.

    That's always a concern no matter what technology you choose. If Unity were to go out of business tomorrow I wouldn't be worried though. I'm sure they would take care of their customer base in some fashion. I've seen many shady business practices from garagegames over the years, not a hint of that from the Unitoids.

    You could use any C# library you wanted for low level networking. You have direct socket access. Or if it's a small enough game just use Unity's version of Raknet. Of course networking in any game isn't an easy task, it'll take some level of competency.

    Torque does have a leg up in this regard, at least if you're looking for basic FPS networking. Torque being an FPS engine, has robust AAA quality FPS networking right out of the box. There is no such beast for Unity. I'm sure people would love to see one.

    Try and jury rig torque's networking to do something other than an FPS and you're back to beating a square peg into a round hole.

    Unity is far less constrained in terms of the type of games you would want to develop than Torque. If you wanted your SimCity or RTS type game and chose Torque, it could be done but boy are you in for a headache. Torque as I said before is great if you want to make the next Unreal Tournament. Any else and you're stuck unwinding a ball of thread. Wait, I don't need and it's code for lava damage or drowning in my sim city clone. That should be easy to remove, not like it's tied in to a thousand other places right? Good luck!

    One thing I didn't see you mention, and is important for most developers, would be the quality of the documentation. Coming from Torque, that for me was a big selling point.

    The easiest thing for you to do, is download Unity Indie and kick the tires. See how quickly you can prototype your game. I think you'll be pleasantly surprised.
  13. n0mad


    Jan 27, 2009
    lol seriously ??? :eek:

    In short, Torque is a niche engine ?

    I have to admit that Unity's workflow is so fast and natural that I tend to forget that quality, and take it as a due.

    For example, I was able to write a clean Character Customizer (change head, body, legs) by my own within 4 x 5 hours.
    I'm no supercoder, and just read the basics of bones vertice manipulation in these forums.
    In 7 days I had a working class that would let anyone change the appearance of an animated char, and just moved on the next task.

    But hell, I'm sure this would have taken weeks if Unity didn't provide me such a clean compile debugger, such a simple documentation, and so fairly organized class methods.

    Actually, I've been working on my game since January 2009. The Unity workflow between conception and production is so logical that now, 10 monthes later, I can translate a pure abstract idea into a working game behaviour in a few hours (for the most complex ones).

    Example :
    Yesterday, lunch time, want to add a feature to my 15000 lines framework :
    if I hold a button for X seconds (customizable), my character flashes X times and enter a mode where I can record a serie of other buttons.
    If I push the same button again, this stops the recording. When recording has been made, if I push those buttons in the same order I entered them, each triggered strike will be X times faster than normal.

    Kind of abstract at first glance, and somehow complex, considering all the classes it depends on ...

    Total time from Mac booting to ingame working behaviour : 180 minutes.

    And once again, I'm no supercoder.
  14. Arcanor


    Nov 4, 2009
    While I did find the 2009-dated Torque vs. Unity comparisons interesting, the original post was from 2005, so I don't think the OP is still making up his/her mind about it. ;)

    At least I hope not!
  15. rayBLAST-R


    Dec 17, 2005

    :D DOH! I would like to know what they decided to do. Now I'm curious. Hmm…