Who wasted there money? :P

#61 From the very beginning of my experience with computers I have always
wanted to "make things", often games but not always. The first pc we
owned came with GW-Basic on a 4Mhz XT with a 4 color display and although
I played many games I always enjoyed making simple text adventures or ASCII
graphics games. Many years later when I purchased my own PC I still enjoyed making
things and/or modifying things. I still remember an old Street Fighter 2 game that
used text files to store the various character animation sequences which I spent
many hours altering and fiddling with.

Since then, of the more well known "game making tools" I have purchased DarkBasic (non Pro version)
BlitzBasic/BlitzPlus/Blitz3d and now Torque. I own an old PC (running Win98, 500 Mhz CPU, 256MB Ram, with Geforce 2MX)
for which I have not purchased or played many games (ie 1-2 games a year) but have spent
countless hours making my own games, or attempts at games (they rarely get finished) and
would have to say that I certainly have "gotten my money's worth" out of each of these pieces of
software - despite the fact that I no longer use some of them.

If anything, the only thing holding me back from using Torque more than I currently do, is
that I often lack ideas as to what to make. I don't expect to make money from any of these
"game making tools" - I bought them because I like "making stuff" (I was also heavily into
Lego as a kid) as a hobby.

Thanks,

Matt

#62 I have been working in software design for 12 years. I am building a game from first principles (not using the example as a base). I have been playing with TGE for 1+ year. These are the things I have learnt.

1) This is a very powerful piece of code, in size probably comparable to a small central office, large router or other mission critical software. In flexibility it is a genuine SDK. You paid $100 for a very good tool worth a lot more!

2) The documentation is all there - just not in the same way that most people expect. Some parts are well documented, some are resources and forum threads so it is not perfect, but the community provides a lot of support.

3) The example code is very complete - which means that sometimes details get lost in the sheer scope of the code, but does mean that everything in the code works and can be studied.

4) Every piece of software has eccentricities, unusual design decisions and sometimes just kludges and strange notations. GG stands behind their code and acknowledges these warts and oddities and provides workarounds most of the time. This is outstanding. I have worked with products that cost a lot more, worked less well and were poorly supported.

What I have found works for me in taming the engine (and the "click" for me of grokking the whole thing was only 4 weeks ago)

1) Pick small things to understand and achieve in one go. I started with the guis, then added gui supporting code, then client side code and so forth.

2) Make a folder or document that you can add to as you learn about the engine and can refer back to. Mine is at a simple level such as message flows for starting the server/missions for multiplayer and single player code. This works for me as I can follow the larger shape and it helps me understand what certain odd looking code segments do. Do whatever works for you as documentation. Post it if you find it useful and think others may find it helpful.

3) Have a doable goal in mind, and a realistic time scale in mind. I know that by the end of March I should have basic single player functionality in my game, and that after that it is a case of adding to it to make the game better.

4) Use the resources: ask questions, search the web, post questions.

Stephen Hagyard.

#63 @Stephen: Thanks. If you need any help or want to talk about your project, my email address is jefft at garagegames.com.

-Jeff Tunnell GG

#64 Yes, it's an excerpt from the EGTGE intro, but hey. I think it applies, so here goes...

I purchased my Torque license August 10th, 2001. License #1160. I had previously played Tribes(TM) 2 and was stoked to find out that the engine that powered this awesome game was going to be released under a very reasonably priced license. So, when V12 (the previous name for the Torque engine) was released, I bought it. At the time, I was working with a friend on a 3D engine of our own (Nascent(TM)). We had written and re-written the engine many times. The current version of Nascent(TM) had lots of jazzy features (Q2 model/animation support, multi-texturing, pseudo-bump mapping, an embedded TCL scripting engine with full access to the C++ core components, a ROAM based terrain engine, game recording and playback, a Limited Physics Engine, Billboards, multi-level collision detection, hierarchical view-culling, , dynamic render scheduling, multiple camera support, yada yada yada...). The problem was that even with all the features we had implemented, there were many more we needed to make Nascent(TM) a well-rounded and functional game engine. To be honest, we did not have a real game plan or a concrete feature list. We often added things because they were cool or we thought we might use them. Torque offered a fresh start, and the opportunity to focus on game design and content creation instead of the underlying technology.

...So, what is the message here?

If you are considering buying TGE, or TSE, or Torque 2D (when it comes out) vs. writing your own engine from the ground up, and then writing a game. Stop for a second, and ask yourself one question,

"Do I have the resources (time, money, etc.) to plough into making both the engine and the game?"

If the answer is NO, then consider one of the aformentioned 'ready' solutions. Certainly, there will still be a lot of work to do, but not nearly as much as writing the engine, and the game.

If you're a lone-wolf or part of a small team, getting TGE, TSE, and/or T2D as well as joining this excellent community will be a very wise decision.

Hall Of Worlds, LLC
EdM|EGTGE

#65 I wouldnt classify spending the $100 on the TGE a wase of money. If nothing else Torque is a brilliant place to start learning the fundamentals of game creation.
However i do feel the following areas need immediate improvement.

1) Full documentation should be included with the download of the TGE. Not a big issue cos it's all here on the website, but i think as a rule any piece of software you purchase should have a help file included.

2) Garage Games employees need to do a major overhaul on all audio aspects of the engine. I mean simple things like sounds getting mixed up, audio emitters not working, sound channels filling up etc etc are just not acceptable in my opinion. Even with a $100 price tag.

That would be all i could pick on. Everything else is either fine as it is or has already (or is in the process of) been fixed.

P.S.

Quote: If you need any help or want to talk about your project, my email address is jefft at garagegames.com.

-Jeff Tunnell GG

Does that invitation extend to everyone else?

#66 Jeff is pretty busy. I would imagine that that invitation covers Stephen, to whom he extended it.

1) The main reason we don't do this is so that people always get the most recent docs. We don't want to have to constantly release new helpfiles especially when we go into the mode (as we will soon) of having multiple changes to our docs every day. The secondary reason we don't do this is to help combat piracy. Especially as we make our technology easier and easier to use, we want to try to limit a lot of things to people who have actual legitimate ownership of Torque. Torque without docs isn't very useful unless you're willing to invest a lot of time in it, so we tend to keep the docs behind "lock and key" to prevent people from simply zipping the whole directory and uploading it to warez sites.

And a lot of useful documentation is in the forums or resource areas, which constantly change...

2) We've been working on this for some time now.

#67 RE Ben,

I can understand point 1 and i agree with the fact that the forums and resources section is filled with useful information that is always changing. The main reason i brought it up was i remember seeing something a while ago that said Garage Games was releasing a help file pack consisting of a book and a cd rom for $30. I guess this is no longer happening from what you said in that last post, but if it were to happen i think it a little unfair to charge $30 for something that is usually included as standard in all software applications.

As far as point 2 goes im very pleased to hear some hard work is being put into this. I can't wait to see the results.

Keep up the good work, i can forsee that in time and with a little effort the Torque engine is going to absolutely kick ass!

#68 @Tim: No, I'm pretty sure it's still going to happen in one form or another. Our plans are fluid and changing but real, official printed documentation has always been on the list. "charge $30 for something that is usually included as standard in all software applications." - Most online-only software packages don't have free printed documentation.

@Dave:

On the off chance that Jeff is no longer actively reading this thread (his last post was about two months ago)...

Just about everyone involved with the company (barring the accountant and the cleaning lady) has read through the console log at least once every month or so since GG started. We've never identified it as something that's costing us sales... but familiarity breeds blindness. What's in the console log that we should be aware of?

#69 If that isn't a flame bait posting, Jimomighty. Sounds like your bitter over not being able to make a game on your own. So you bit off more than you could chew. But it's no reason to go off on a flame war. There are many folks here who are more than happy that they were able to get a AAA game engine and source code for only a $100 license fee.

#70 I took the long way around getting to the Torque engine. I am glad I did. I can appreciate Torque all the more for it. There is no better indie engine on the planet. Period.

-Josh Ritter
Prairie Games

#71 I purchased TGE about a year ago as an alternative to the crap that Conitec produces. The only problem was I had become proficient in the A5/A6 scripting languages, and had to lay Torque aside for nearly a year to "forget what I had learned", about the other engines way of doing things.

Honestly if you are completely new to programming then TGE is not for you, while the scripting engine has alot of power, the core of the game is really meant for a MultiPlayer FPS style game, and you really need to get under the hood so to speak to get any new functionality from it. This requires dabbling in the magic that is C/C++ coding. However there really is no reason to be afraid of the engine code, pick up a book like Sam's Teach Yourself C++ in 24 hours, or C++ For Dummies type of book, and get comfortable and familiar with the language, it won't bite you.

As I said I purchased over a year ago, I set it aside to clear my mind of another scripting language (If you've ever moved from one programming language to another I think you know what I'm talking about here), and when I came back I found I could understand MOST things simply by reading the source. From there you just need to have a new and original Idea and start thinking of how to implement it via the tools you have at hand.

#72 Hey Dave,

Jeff has seen those errors. Jay has seen those errors. Benjamin has seen those errors, as has almost everyone else in the company except maybe the accountant. I feel like you're... accusing? Implying that this is somehow a secret, a shameful thing which I or other GG employees are keeping hidden in order to hurt the company, or perhaps out of an inability to admit wrong? I tend to take comments about Torque personally because I feel that, second to Jeff, I'm the person next most responsible for Torque's proper operations. But I want to approach this on an open, positive, professional level.

I agree, an absolutely clean log is a good thing, but some of those errors are necessary for debugging (Could not locate texture: demo/data/shapes/player/base.lmale is printed by the resource manager as it tries to find specific files; the multiple searches occur at a higher level so there's no good way to suppress the messages that won't also kill off REAL errors), some are benign in the particular context of the demo (Error: shape demo/data/shapes/crossbow/ammo.dts-collision detail 0 (Collision-3) bounds box invalid!), and so on.

The SM_startMission errors are interesting but don't seem to be actively causing any harm. If someone wants to fix them, I'll happily merge the fix, but I have things much, much higher on the priority list to deal with, like TSE's terrain. Code which varies from demo app to demo app and which does not impede proper execution of the demos is really hard to classify as crucial to fix.

You also missed a few bits of "normal" spam relating to datablock parameter validity checks, some low level (but very cryptic) network status events, and so on.

Some level of spam is acceptable. We would rather err on the side of too much error reporting than too little.

I would love to have a constructive conversation about ways to improve this aspect of the engine.

What are your thoughts on how we can restructure the way that the resource manager and texture load code interact to reduce the amount of console spam? Are there any ways that you have used to more accurately measure "silent failures"? While Jay has a good idea of what sort of people buy the engine, we find it difficult to determine when a "lost sale" is from a broken or failed demo, or when it's from a lack of interest, funds, or just a better suited product coming along.

As far as model sanity checking, do you feel that it would be better to distinguish between errors and warnings more distinctly within the engine? Should the export process be provided hints about what sort of use a model will be put to, and do sanity checking there? Or should "bad" models cause an assert, forcing them to be fixed?

What sort of techniques have you used with your team to minimize the amount of console spam that occurs? Do you have any automated tools, or do you simply eyeball it? Or does "clean" not mean minimal? I think that this context provides an excellent example of how one man's spam can be another man's crucial information. What about temporary debug information? Do you have any policies around this?

Do you think a more complex interface to console logs would be useful? For instance, providing means to filter the visible error/status messages? The console already provides visual cues as to the relative importance of each message; do you think that there should be more cues, and if so, what sort of cues would be best suited?

#73 Dave,

My flame bait posting was not directed at you, but rather the parent of this thread.

Thanks.

#74 @Ben: For what it's worth, I happen to agree with Digital Dave on the presense of the errors/warnings in the demo...especially the ones about lmale images, etc.

You are absolutely correct--the warnings need to be generated for debugging purposes. We don't want them suppressed! However--the demo doesn't even have the lmale stuff (left over from a while back, Tribes I think), and I'd suggest that the references to it in the script be removed, or the files be made available as part of the demo :)

When warnings/errors are generated due to changes made by the purchasers, that's their responsibility, but the "demo" should have all warnings "handled" before distribution. It's a minor point in the very long scheme of things, but it is a bit of a nag. There are a couple of different mentalities when it comes to logs and error/warning reporting, and I think that DD and I happen to fall in the minority, but what may be a bigger one than people think: Warnings should never be ignored.

Personally, I feel this applies to the source code itself--again, there are a couple of mentalities, but IMO at least when you hit make clean;make you shouldn't see any warnings at all on stock code...disciplined coders shouldn't ever let code that issues warnings be released whenever humanly possible :) (and suppressing them doesn't count!--if the compiler is warning, 95% of the time it's a valid one).

#75 Not wasted in the least, at $100.00, it's a couple hrs. of my professional time. I could not have pumped out the delivered product in a couple hours time...;). Time/space; all relative, to your current velocity and perspective,;).

...try to think of it in terms of an 'investment'....might not need it today, but it's 'standing by' ready to go...and when needed, will function.

I only consider 'waste' that which goes into the rubbish bin...and out to the street for collection, never to be used again. I don't know of anyone that'll throw out their license to spite their face, ahem, sorry for mixed metaphors, ;).

#76 It has been an excellent investment for me, no doubt about it. If I never manage to make an Indie game, I have at the very least gained a much greater understanding and appreciation of engines in general. Also, it has given me some very good insights to our engine here at work, and why we do what we do as well as why we can't do what a lot of us artists think should be a no-brainer! That alone is worth - I'll just use the cliche - it really is almost priceless to gain a greater understanding and appreciation of what goes on with the engineers.

Tools-wise, part of me wants to rant, but the other part thinks I just have to get organized and make my own pipeline. Everything we have at work is proprietary *when it comes to getting it actually in the engine*, but standard as far as content generation goes. So, what I take away from that is in a very real sense the process is halfway in place already. I can still work in my texture app and modeler of choice and I do have options for exporting when I'm ready to get it in-engine. My point there is that the process is often dictated by circumstance anyway, so if there was an art pipline shipped in place with Torque it might not suit people and you're back at square one.

I have not yet begun to actually try and implement a new game, but that's largely lack of planning on my part as I've seen plenty of resources and threads here to implement just about any feature I've considered. Now, whether or not I have the skill to plug them in is another matter, but I've seen so many people write out clear step by step instructions that I'm willing to bet I could get it done "with a little help from my friends". (Sorry couldn't resist the music reference.)

So to wrap this up, I'd have to say that it's $100 well spent if you're involved in any aspect of game development, if for no other benefit than a better understanding and appreciation of the engine development process as a whole. And of course, you have the full-on advantage of a licensed AAA engine when you do decide you're ready to do the Indie thing!

Regards,
Don Hogan
Senior CG Artist
Retro Studios, Inc.

P.S. I usually don't use a "formal" signature like that, but I felt like if I was going to make such bold statements, I should be clear about my perspective on development. Just wanted to make an anti-ego disclaimer. ;)


Edited for clarity.

#77 Personally purchased TGE quite some time ago, unfortunately the original project I purchased it for went belly-up. It sat around dormant for quite some time. Another project popped up, and I went off seeking an engine that would suit my neets -- an established and easily extendable GUI system within OpenGL, and platform independant. After much searching I found nothing until I rediscovered Torque. Since then I have been hacking around in the codebase, removing/modifying most of the 3D 'junk' into 2D equivilents. The end result I hope for is something very usable for interface oriented games.

Very worth the money.

#78 Well, not sure if any employees are watching this thread anymore, but I figured I would go ahead and write something anyways.

First let me say this is not a rant, I think the money I paid for Torque was well worth it. However I can relate to the original poster (that I haven't touched Torque in awhile), and this is what I've gone through...

I bought Torque back in Dec 2001 (wow, I can't believe it's really been that long), and I used it for about a year and a half to two years. At first I started just getting familiar with the engine, then I played with the scripting and helped on a project while I was working on my own. But alas I left it at the end of 2003 and haven't really stopped by much since (occassionally I would stop by to check out the dev snapshots though).

The biggest problem was trying to rip out everything that was already there and trying to add different functionality. I wanted a gutted out version of the base player class (I forget what it's called), which had a lot of fps stuff in it that I didn't need. The other thing that I couldn't get was a different terrain. I wanted to create a terrain with perlin noise, change the look of the water, and using an algorithm like soarx.

But after having trouble doing the above, I started looking for alternate routes. I looked at cipherengine and eventually found ogre. I started playing with ogre for awhile and used it for a year, and while I didn't have problems with the base entity class and found some things easier to do, the way that the engine is layed out made the implementation of the terrain a little bit more difficult.

Alas, I'm now looking into openscenegraph and I'm really liking it.

I really like what GG has done and I'm all for supporting their effort to help independant developers (since I am one). But I just haven't found TGE flexible enough to support what I need to do. I also found it a pain to try to remove everything from the engine that doesn't belong.

I like the c++ motto: you don't pay for the stuff you don't need.

#79 I think what it comes down to (and we are seeing this quite a bit with T2D right now as well) is that at such an attractive price, people come into TAP with different expectations, and since it is so cheap, everyone buys it and then wants those expectations met.

The fundamental issue is that people want some of what TAP offers, but not necessarily all of it. For example (not picking on you Lucas, you are just the most recent that demonstrates my point):

Quote:The biggest problem was trying to rip out everything that was already there and trying to add different functionality. I wanted a gutted out version of the base player class (I forget what it's called), which had a lot of fps stuff in it that I didn't need

Instead of gutting it, why didn't you simply create your own new class inherited from Shapebase and implement what you wanted? Nothing requires you to use PlayerBase at all.

As it turns out, you almost guaranteed had to implement your own GameBase, ShapeBase, and then XXXBase for your player requirements in other engines or SDK's, and most probably spent at least an equal amount of time to reach full implementation than you would have inheriting ShapeBase and rolling your own in TGE.

TGE, T2D, TSE--none of these are perfect solutions to every single project/developer, and they can't be. But regardless of what people say about SDK's ease of "not having to strip out things I don't want", all you are doing is coming from the other direction: now you have to add in all the things that TAP does.

Again using the above example--if you don't like the FPS player base, then simply never spawn a player, and it's stripped out. Now just proceed with implementing a new class just how you want it.

#80 Just wanted to say TGE is the best $100 (or 55GBP) I have ever spent... I learn loads each day. :)