That old TorqueScript debate.....

#1 I'm not a big fan of TorqueScript myself, but for the sake of discussion I'll just throw out a couple of points:

1) You don't have to use it. You could just strip all the script stuff out and do the whole thing C++.

2) It's good for mods since you don't have to distribute the complete source code to your game and as you say "TorqueScript is perfect for those starting from the ground floor"

3) It's generally faster to change a script and rerun the game than to recompile.

#2 Yes, I am well aware of point #1, but if you actually looked into it, you'd see just _how_ much work you'd have to do. Why would anyone want to do that?

Yes, I quite agree about it being great for mods.

And yes again, it is faster to change a script and re-run the game than to recompile that is no surprise, since thats the basis of using a script based engine.

But the fact remains, change for the sake of change is a sordid waste of time. There are lots and lots of comparable engines out there which give you the freedom to do what you want. Heck, even UnrealScript, as daunting as it was in the beginning, took a turn in the past few years because, well, devs kept bitching about it.

For my money, TS could have been built either on top or as a separate layer, leaving the core C/C++ kernel alone. Heck, even C# would have been a good idea because it gives you a _lot_ of flexibility when interfacing to C/C++.

Quite frankly, with all this money they now supposedly have, apart from actually doing proper and professional docs for their engines and tools, I think some resources would be best invested in porting TS to C#. At the very least. The layer calls can all remain as-is so those used to using TS, won't feel alienated.

#3 I'm not sure I follow this. Why can't you simply add anything you want to the c++ without touching the torque script? You don't need to rewrite anthing, all your code can sit in the c++ if you want. The Torque Script can be treated pretty similarly to an ini file. You want to write an AI engine in c++, it is trivial, no need to learn torque script (which by the way should take any competent c++ programmer about 2 hours to learn the syntax, a day at max to figure out the code/script call interface. )

I've written most of my game logic in the script file, it is simply awesome. I love the flexability. Things that are appropriate for c++, like AI, pathfinding routines etc, all go in the engine. But since an RPG requires massive amounts of logic, and developing requires lots of tweaking to that logic, script rules. I don't see any point in porting whatsoever. You have the strength of both methodoligies.

#4 I other words, most of this stuff from 2005 is obsolete due to engine revisions?

[mod snip--personal attack]
Last warning Derek--stop the personal attacks or you will not be allowed to post.

#5 Depends what you are trying to do. If you want to unwind how clients entering your game works, then sure, you're going to need to tear out the script.

However, if you are trying to add ai routines, like in your example? You wouldn't need to touch the script unless you were smart and wanted to make use of the incredibly useful flexability it offered you. Create your code, hook it into the AI player, bam.

And honestly, anything you couldn't tear out from script could easily be funnelled into a callback into the engine, to your nice c++ routines. Like I said, trivial.

Oh, and notice that doc you linked to also said :

Learning TorqueScript when you are a C++ coder is really straight-forward. The syntax is virtually identical and all of the control structures you are familiar with are available (if-then-else, for, while, and switch). It really shouldn't take a competent C++ programmer more than a weekend to get up to speed syntacially with TorqueScript

#6 Thanks for the pointers.

My problem is that, having written most of my own engines from scratch, its a daunting thought to go back in and conform to someone else's idea of things are and should be done.

e.g. I have my own AI, physics & dynamics, interface etc. Our graphics (which is really three engines in one) engine is really whats needing a major overhaul. My game kernel design which supports space flight, planetary flight, first person dynamics, vehicular dynamics and everything in between, wasn't developed overnight. Even the graphics engine, is actually three specific pipelines all seamlessly integrated.

The STE (Space Traversal Engine), handles everything in space and interfaces with AI, dynamics etc.

The PTE (Planetary Traversal Engine), handles everything on the planet and interfaces with AI, dynamics - and a first person engine which has its own character rendering path.

We're on the last legs of our 2008 game (GC: Talon Elite) due for release in March for the PC (XBLA version to follow later in the year). We've - once again - made some dramatic revisions to our rendering pipeline (no DX10 though) as well as the PTE (which now uses GROME data) which is seeing its first major overhaul in almost four years.

The plans is to come up with a new tech strategy for 2008 and beyond and instead of revising, removing and improving legacy tech, start from scratch in some areas (e.g. 2D/3D graphics rendering, scripting etc). So, with that, I decided that it was time to start from the ground up. That meant either doing it all over again and wasting time or get a middleware stop gap.

With middleware, you are locked to various principles which may or may not work with the type of games. e.g. I couldn't very well license Unreal3 or similar engines for my games because, well, they're not geared for games like that. Most of those other graphics engines do a lot more than just baremetal and usually do it wrong. Heck, we have a Reality Engine source code license that I have yet to use!

I have been keeping TGEA at the back of my mind over the years and since I have three months to evaluate a middleware solution and make a decision by the time we ship our next game, I'm not particularly interested in going in a direction thats going to restrict what I can and cannot do, then six months later find that I have to abandon all of it. LOTS of dev teams go through that. I don't plan on it.

Further, I have yet to see _any_ impressive piece of work done with TGEA. That doesn't give me any confidence either.

#7 Well, do you have a TGE licence? The networking and fundamental structure of the engine is unlikely to have changed, so try taking a look and seeing if it suits your needs for things like client logon.

In terms of the graphics, you may very well need to overhaul TGEA, but hopefully you can do it without drastically altering the base structure. I'd say the price of a licence is a small price to pay for one with your resources, why not try it and take a look yourself?

At the end of the day, every engine you licence will require you to work within their design philosophy, otherwise you should just do it yourself. It is a compromise, but the advantage is you don't have to do a lot of it yourself.

Still, I don't think this all requires ripping out Torque Script.

#8 I use ReplicaNet for all my multiplayer needs. I have no need for anything like that in Torque. Nor do I have a need for its Atlas terrain engine.

I agree about the price, but thats not the extent of it though. Forking out $1.5K is not a big deal. I can even get the indie license and upgrade it later to a commercial license if I choose to go forward. The big deal comes in the costs and time associated with coming to the conclusion that you've just, well, wasted n months.

Yes, you are right about having to somewhat conform to a license, but I think you're missing the point. Conformance is one thing (and its inevitable), using an all-or-nothing engine is a whole other matter.

Basically, there are two things I'd like to address: (1) a new graphics engine alternative. One that is bare metal and contains zero fluff. Something like OGRE, but not. Thats not TGEA in any, way, shape or form (2) a new scripting pipeline to replace my legacy homegrown version. For that, I've pretty much settled on LUA+CaLUA.

For experienced developers, choosing an engine is not finger painting. It takes careful thought and planning, which is why I've been watching TGEA for sometime now. For me, it just has too much stuff that I simply don't need or want. Then you think about the good parts. And find yourself stuck in a paradigm shift.

#9 For clarity, if you don't need the networking, the scripting or the graphics layer, what exactly do you want TGEA for? What are you talking about when you say the good parts exactly?

#10 Gareth is correct that there is no hardcoded dependency for using TorqueScript built into the engine. I even talked about that to a certain extent in my article that you linked above.

Dropping an AI engine in and tying it into the existing AIPlayer code would be pretty straight-forward (once you get past the networking bits). If you already have your own networking code to also link in you could mostly bypass even that sticky bit and start with a generic sceneobject to handle your rendering/shaders/materials.

Another thing to keep in mind is that it is also pretty straight-forward to replace TorqueScript with something that suits you better if you are a competent programmer. Josh Ritter replaced it with Python and has even shared that code. He has used this to achieve really impressive results. Meanwhile, Tom Bampton has successfully grafted in BASIC and has been futzing around with using Lua in Torque.

The *main* thing you trade away with getting rid of TorqueScript is the functionality that is built only in TorqueScript (mostly the editors and some of multiplayer connection logic) and most of that is not super difficult to replicate in C++ or some other scripting language.

#11 Hey Matt, Lara and I got married this spring and I'm now Josh Engebretson :)

That resource is pretty ancient... There's an updated Python binding available here.

Torque's scripting interface is actually quite narrow... and the whole everything is a string concept really helps when coming up with a general solution quickly. I have created a C# binding that is *very* similar to the Python one and it worked great.

I don't have a lot of time to ponder this stuff lately... though, I think a Lua binding below the string passing stuff would be extremely powerful and quite efficient.

-Josh Engebretson

#12 @ Gareth

Quote:For clarity, if you don't need the networking, the scripting or the graphics layer, what exactly do you want TGEA for? What are you talking about when you say the good parts exactly?

Perhaps you misunderstood me? Please go back and read what I wrote in my fourth post.

To recap: my primary interest in TGEA was in its renderer. Nothing else. Not TorqueScript. Not the networking kernel. Not the Atlas terrain engine. Thats what I thought TGEA was going to be after it started to evolve from TGE ----> a pure bare metal renderer; which, with the ability to bypass anything that one didn't want.

Sure we could go with OGRE, but its not - IMO - commercial ready, support is largely non-existent and the community, unlike the folks developing, managing and writing tools, assets etc for Torque, is fragment and largely not as professional as those found here.

As I said earlier, there comes a time when you take a look at code (that derived from legacy) that you've massaged over the years (my graphics engine started its last life in DX5. Then heavily revised all the way to DX9) and decide to start with a clean slate. In my case, its the core graphics engine and the script parser. Sure we could develop them both from scratch and kill upwards of a year or so doing just that (I've done that all before - and several times over in fact). But why? Its not like we're going to come up with or do anything that hasn't been done before. Why re-invent the wheel? So, when you take that - and costs into consideration - middleware makes more sense because you then spend time on asset creation and the main important thing: developing the game.

@ Matt

Noted. Thanks.

@ heavy handed mod

Quote:[mod snip--personal attack]
Last warning Derek--stop the personal attacks or you will not be allowed to post.

I still have the original text of what I posted to Gareth. In no way, shape or form was it a personal attack. It was merely a warning based on what he did in the other thread, which (in addition to my response) subsequently got modded out. Yet, in your mod comments you put this bullshit about Last warning Derek--stop the personal attacks or you will not be allowed to post. as if its something I've been doing?!?

Apparently this leetle boys club you lot have going is one tracked minded, single sided and just for you lot. The same sort of thing that happens in most forums where people - even asshats - who behave badly or inappropriately - get a free pass mostly - because they've got tenure. If this keeps up, I'll just leave again.

So, go ahead, ban me.

#13 For the record, the "heavy handed mod" was the only reason you haven't been banned. Now that you've gone that route, we'll take care of it however.