Game Development Community

Any recommendations for alternatives to TGE/TGEA

by Derry Bryson · in General Discussion · 02/05/2008 (9:43 pm) · 48 replies

Given the changes to the TGE/TGEA commercial license that restrict one from producing educational games, virtual worlds (MMO's), simulations, etc. I am looking for alternatives to TGE/TEGA (and furture offers by GG under similar licenses). When I originally purchased and Indie license for TGE, the commerical license was unrestricted as to what type of programs could be implemented which was part of the reason I purchased TGE. While my initial plans can be classed as "games" (hopefully GG agrees? maybe not and they will sue me later?), I have ideas that are obviously restricted by the new GG license. While I like TGE/TEGA, I don't want to waste time learning them and implementing games based on them only to be limited with my future options. I would much rather spend my time and effort learning and developing games on an engine where I can implement what I need and want, even if it is not as easy as TGE/TEGA.

Therefore, I am asking for ideas on alternatives. C4 is an obvious alternative to TGEA, but I haven't found a good alternative to TGE (i.e. an engine supporting lower end hardware). Unity 3D is also a possibility, but requires development on a Mac.

Thanks in advance.
#21
02/08/2008 (8:13 am)
You should be able to develop whatever you want, shouldn't be Garage Games business what you use the engine for so long as your not giving away source or selling the engine as your own competing product.
#22
02/08/2008 (8:20 am)
First off, whatever license it had when you started should be valid. They can't arbitrarily change that after you paid. Period. So, I would not worry so much about that aspect.


The requirements for C4 are actually quite low, though. I also like it a lot.

I have since moved on from TGEA myself and since TGE is so ancient and both TGE and TGEA are dead ends productionwise because torque 2 will be incompatible, then if you have not put lots of work in already it would be foolish IMO not to switch over.
#23
02/08/2008 (9:13 am)
Quote:First off, whatever license it had when you started should be valid. They can't arbitrarily change that after you paid. Period. So, I would not worry so much about that aspect.

They can change it at any new version release, but only for that version onward. Older versions of the software can still be used under the original EULA.
#24
02/08/2008 (9:17 am)
@Stephen: So, you guys basically feel you are doing us a favor? That explains a lot about the behavior of GG.

Please explain to me how making a military training simulation is taking advantage of your "generosity" and making a military simulation intended for entertainment is not?

@Kevin: I would like to agree with your reading of the EULA, but here is a quote from Brett Seyler (from his blog entry) stating GG's view:

Quote:The standard EULAs available through online purchase now permit only games for entertainment. If you're wanting to profit from a simulation, serious game, virtual world, machinima, educational game or other game-not-for-entertainment application of Torque, you'll need to contact us at licensing@garagegames.com for licensing details.
#25
02/08/2008 (10:00 am)
The key words there are "only games for entertainment" and "simulation, serious game, virtual world, machinima, educational game or other game-not-for-entertainment application of Torque". And that's pretty much identical to how the EULA words it.

I just posted about this in Terry's thread, but here is how a court would read the pertinent bits of the EULA:

EULA:
Quote:(e) This license does not permit the use of the Engine for non-Game application such as simulations, training, modeling, virtual worlds, or other non-Game products. Use of the Engine for these applications requires a separate license. Contact licensing@garagegames.com for these applications of the Engine.

How I believe it would be read (please note, this is my educated opinion, but should not be accepted as legal advice - as I said earlier, contacting your lawyer regarding this issue might be warranted):

"This license does not permit the use of the Engine for non-Game applications such as non-Game simulations, non-Game training, non-Game modeling, non-Game virtual worlds, or other non-Game products."

The EULA says "non game applications such as", and then gives a list, and then says that list is not all inclusive, and any OTHER non-game applications would also require a separate license. However, by doing this, it literally only bars NON-GAME applications, i.e. those simulations which are not games, those virtual worlds which are not games, etc. It does not bar GAME applications of these types.

What is a game and what is not a game being left up to the lawyers and judges to decide, I suppose. =P

EDIT: I suspect that what would/will be ruled is that intent is key. I think that this is what GG had in mind, as well. If the product is intended for entertainment and is interactive like a game, it is probably a game. If it is not intended primarily for entertainment (a new tool to train doctors in surgery was an example I used), or is not interactive like a game (Brett mentioned machinima, which would be non-game since it is not interactive, even though it is for entertainment), then it would need a separate license.
#26
02/08/2008 (10:08 am)
Quote:game-not-for-entertainment application of Torque, you'll need to contact us at licensing@garagegames.com for licensing details.

That is a very enlightening line, yes. So "game-not-for-entertainment", ie if you make a game for people to play as, um, a game, it's fine. And if you aren't, you have to go to all the trouble of emailing them and sorting out the exact details because the other areas have some niggly loopholes which have been exploited before.

How about dropping them an email before getting all riled up Derry?

Quote:So, you guys basically feel you are doing us a favor?

Try writing a game engine. Yeah man, they are doing us a hell of a favor. I for one am grateful and would be willing to at least give them the benefit of the doubt enough to drop them a mail before getting upset.
#27
02/08/2008 (10:16 am)
Gareth: I have emailed them.
#28
02/08/2008 (10:23 am)
@ Derry Bryson: Please let us know you find out.

Considering I own all the engines (TGE, TGEA, & TGBP) on a commercial license I would very much like to know what prompted this in the first place. Considering myself and many others have spent thousands of dollars here, it would have at least been nice to have recieved an email or some other notification of this.
#29
02/10/2008 (2:59 pm)
Back on topic...

I've been looking around a lot and using the suggestions that have been provided here. I am seriously looking at building an engine around either Ogre and Irrlicht. Both seem like great rendering engines, but will require a bit of work to make into an "engine". This might be the best option going forward, however, since once everything is in place I could do whatever I want.

I have also been looking at Unity3d, Truvision3d, Cipher and some other commercial engines. I was even looking at Unigine, I would love to license this engine but unfortunately they are raising their prices dramatically March 1st (so buy now if you can afford it!).

I hadn't seen Cipher Engine before and was intrigued because it was an older technology engine (somewhat like TGE) and for my target audience, I want to support lower end hardware. The website didn't look like it had been updated in years, so I emailed them and found out that they are currently working on updates to engine (as listed in the roadmap) and hope to have an updated engine ready by the end February. Can't tell if they'll meet that date, but at least they are actively working on the engine. Can't beat the price at $100 with source code.

Truvision3d also looks good, but no source code. This might not be a problem if I can do what I need without the source code. The price on this engine is also good.

Id tech 3 (i.e. the quake 3 engine) is good as well, but mainly limited by it being a BSP only engine. Also the documentation is lacking. I'm not bothered by the GPL license, since everything I do outside the engine can be proprietary, but doing terrain in BSP seems like hassle (although Valve seems to be doing quite well with it).
#30
02/10/2008 (3:10 pm)
I forgot some stuff in my previous post:

Thanks for the heads up on Delta3d. While the graphics seem to be a little lacking, it's a great resource.

Another similar engine I found is G3D. This looks very good as well.
#31
02/10/2008 (3:58 pm)
@ Derry Bryson: Thanks very much for the info about Unigine. I too wish I could afford that one by March 1st.

I have heard good things about DarkBasic/Pro, but I do not have it myself. Keep us informed as to what engine you decide to go with. I'm always looking for a step up from Torque and I'm always interested in other peoples choices.

Edit: Here's a link I found that includes alot of engines: www.ambrosine.com/resource.html , though I'm not sure of exactly what you're looking for. I hope that helps.
#32
02/10/2008 (4:31 pm)
I'm currently in the process of creating an engine based on Ogre+RakNet+FMOD+PhysX and I'm very happy with these choices. I've got the ultra-basics working for each of these main components, but I'm in the middle of switching the physics engine to PhysX from Bullet (before that I used Newton). I had it mostly working in Newton but the character control just didn't look very smooth, so I switched to Bullet as an experiment, and now I'm dropping that too because Bullet's character controller demo hasn't even been released yet (Bullet is a relatively new project compared to the others). PhysX should be much better, I hope.

Anyway, it's been pretty smooth sailing so far for me. It hasn't taken me very long - about 3 months of effort, including lots of research, and plenty of dead ends. Still, I've made good progress, as my codebase has the following features:

- Ogre rendering engine, supporting OpenGL or DirectX at runtime, and it's very fast. I've not implemented too much in the 3D world yet, but I do have the ability to load scenes directly from Blender (using ".scene" export), plus on-screen FPS and polygon counts, alt-Z to show collision boxes, character models with animations running, etc.
- simple network connect/disconnect with a server process on another machine using RakNet.
- custom camera management system with 4 presets (chase, 1st person, stationary, top-down) plus a saveable setting slot.
- GUI moveable/resizeable windows with alpha transparency, plus functional 4-state graphical rollover buttons (inactive, active, rollover, selected).
- rock solid sound system, currently playing background music files, but it's very simple to use 3D sound.
- customizable input mapping to game functions, including support for up to 8 mouse buttons, any keyboard input (including alt-, shift-, ctrl- combinations), and/or joystick.
- custom display/logging reporter for runtime engine messages.
- Blender scene import.
- I had basic physics working but it's all in transition at the moment and should be working again in a few days.

Anyway, if you're looking for alternatives that's what I'd recommend!

Good luck however you decide to go.
#33
02/10/2008 (8:16 pm)
I made a video last weekend of our Ogre based engine. It's not going to blow anyone away, its the editor that can be run inside the game in a similar fashion to TGE. Were making simple game demo consisting of 3D tiles, and have borrowed some of 3dsmax's translation tools for ease of use. Shift drag to instance geometry in the scene, and rotation snaps for quick 90 degrees with the mouse button. If you use 3dsmax you will already be familiar with the tools.

5mb wmv

www.flow3d.org/ad/speedup.wmv

It's kind of cool and shows you what can be done in a relatively short time.

This week we got the game up and running so you can control the robot with full physics, and can get out of the maze and move around a terrain. We spent about a year building the engine so its been good to actually start making a game with it.
#34
02/11/2008 (7:25 am)
Nice looking workflow, Adrian. Looks like a quick and easy way to work with level design. It's always good to see what you're up to.
#35
02/11/2008 (8:51 am)
The upside of DarkBASIC Pro seems to be how easy it is to expand it through your own (or 3rd party) custom DLLs. It also seems very fast. I've looked at quite a few games that are written with it, and they've never seemed slow, laggy, or choppy. (can't say that about many TGE/TGEA games. Some are down right unplayable, and my system is NOT that old or slow. P4 2.8GHz, GForce 7600 GS)

I'm looking at DBPro because the development time is going to be greatly shortened for the project I'm working on. TGE/A likely has better networking, openGL support, and MAC support, but if the game is so slow and choppy that it's unplayable then none of that matters. More systems than not can (or at least should) be able to handle DirectX 9.0c.

DBPro also has a more flexible terrain system. Things are easier to change on the fly with the terrain and the "mission" area can be a LOT bigger.

I'm still very new with DBPro, but what I've seen so far has me impressed.
#36
02/11/2008 (10:21 am)
I've played a ton of highly unoptimized games in DBP, mainly because the code was unoptimized. The tips and tricks section out of their newsletter should be required reading as it helps with a number of quick and dirty optimizations.

I still prefer Blitz3D's flavor of BASIC to DBP, but that's just a matter of taste.
#37
02/11/2008 (10:34 am)
I prefer Blitz3D over darkbasic too. And it has a lot finished and released games written with it. About 180 now. The biggest problem with Blitz3D is that its DX7, which is great since its a very rich implementation but I'm not sure how long the fixed function materials will be supported in future hardware.

This might mean compatibility issues later as fixed function gets dropped from future generations of hardware.
#38
02/11/2008 (11:06 am)
@Adrian: Fixed function hasn't been implemented in hardware for years. The drivers dynamically create the appropriate shaders based on the fixed function state and go from there. You're not likely to suddenly run into serious compatibility issues using fixed function unless the guy tasked with writing the shader generation code misread the documentation on how a particular fixed function feature is supposed to work (it's happened).

Back on topic, I have no experience with DB or Blitz3D (Mac user), but I've heard good things about BlitzMax and I assume a lot of the nifty development features of BlitzMax carry over to Blitz3D. I still think Unity is the best alternative to TGE/TGEA though.
#39
02/11/2008 (11:28 am)
I really like BlitzMax. It is clean and fun to write. There are quite a few great addons to it as well.
#40
02/11/2008 (11:40 am)
If you want a ready made Ogre solution for C# it might be worth checking out Neoaxis. the author has done a phenominal job working mostly alone with consistent quality and monthly updates.

www.neoaxisgroup.com/