Just bought the SDK and... well... SDK it aint...

#1 You would want to do any gameplay related things in script and any rendering,networking,etc. in C++. If you don't want it to be moddable just release the .dso's instead of the .cs's I'm probably not the best one to explain this especially cuz i'm really tired so i'm hoping someone will post to clarify for you. I don't think you wasted money.

#2 No one said that it was an API it is a full blown ENGINE it is advertised as such. SDK means software development kit.

the correct question is "why would I want to do something in C++ when I can do it in script"

plainly put there is for all practical purposes NO way to NOT USE THE SCRIPTING facilities. It is an intregal part of the engine. To understand the engine you HAVE to understand how the demo scripts work. It is that simple.

The engine is pretty tighly coupled and not componentized at all. That is changing slowly.

Torque is a complete game engine and NOT an API.

#3 If you would like to start from scratch, delete everything from the game directory. You now have a bare starting point. You will need to implement a subclass of the Game class to get things to work - boilerplate initialization code will be found in the DemoGame class. Congratulations! You should now have a very basic window popping up. If you delete everything in the example directory you will have a basic starting point, though you may want to create a main.cs file for script execution to start in.

You have a basic starting point! If you want to be truly free of demo code you can also delete about 50% of what's in the gui directory.

You now have a copy of Torque with no editors and curtailed scriptability. There are no vehicles. You will have to roll your own classes if you want to actually display anything. The input subsystem is in script, so you have some very interesting coding ahead before you'll be able to bind any commands again. The code behind objects that can update themselves was in the game directory, too, so you can rewrite the sim layer while you're at it... As well as the code to determine what objects should be in scope.

#4 If you want to be really pure, you should probably blast most of the terrain and editor directories, too. After all, the demo app uses them... They're not really part of the "core" engine, just extras. The interiors have assumptions about gameplay, too, so knock those out - the engine will be happy without them. The scripting system is obviously extraneous, too, since all real developers only ever use C++ for their coding - get rid of console and parts of sim.

That leaves the net code, the resource manager, 3space, collision library, audio library, some rendering helper functions, and the scenegraph. Now, 3space is clearly unnecessary as we can simply import an already written 3ds renderer to meet our needs, so you can blast the ts directory. At this point, the collision code is useless because there's nothing that depends on it, and you could get just as good results using ODE's native primitives, so knock that directory out, too. Audio is a not very good wrapper around OpenAL - might as well just write your own, better one, so that can go, too. The dgl directory is just rendering helper functions, which are clearly irrelevant to the core functionality of the engine - some state management, texture management, and line drawing functions, so toss that.

The scenegraph is, compared to OGRE, trivial, so you can blast that one, too. You could probably write your own raycaster and have it run faster, too.

Um... There's the resource manager, but that's not going to be much use since there's no code to load it with. If you rewrite it you can do efficient background threaded loading, too. You can write your own PNG loading code, and roll your own model formats - DTS and DIF are pretty stuffy by now, so it'd be a good breath of fresh air to the engine.

Of course, that will probably necessitate blasting most of the exporter and map2dif code - no big deal, though, since you've removed their dependencies.

Let's see what we have left. Um... There's a nice memory manager and profiler. Those are good building blocks, as are the platform layers. There's some streamed file I/O stuff, too, that could be worthwhile. But you don't have to use any of that, so you could probably rip that out, too.

The net code is neat, but you probably don't need it - it's very complex, and pretty obtuse in places, and it's better to start simple, so just leave the net stuff in platform and blast the rest. That way you can send UDP packets across the wire as needed - no sense doing anything more complex.

Ok, so now you have some of the platform layer and some obscure data structures from the core directory. Oh, and the math libray, which is nice, too.

Of course, if you don't want to use those, you don't have to, so you can toss the math lib and roll your own math code - no problem there. The data structures are probably too obscure to be useful, and the platform code... well, that's just a duplication of the existing platform SDKs for linux/windows/max, so blast that, too.

Hey, there's nothing left. Well, cool, that shows you just how much value Torque adds! Not really worth a hundred bucks...

#5 Repeat

Quote:Torque is a complete game engine and NOT an API.

It is however, possible to rip out the "game" directory form the source. But then you have to write your own code to clue everything together (which I assume is what you wanted to do anyways).

But torque is not an interface (the I in API :|). You dont just initialize parts of torque. I think this probably needs to be stated more clearly when people are buying the engine.

Look in the resources however, there are a lot of tutorials lately that strip torque down to its bare parts (in scripting) and then work up again.

Also, scripting is just the right way to make a game. It allows you to edit scripts and test while the game is running, and it allows you to create game logic outside of the engine code where it doesnt belong. It is also much more flexible than C++, and allows rapid development.

EDIT: doh Ben beat me to it :P

#6 My point here is that Torque has no basic starting point. You can trim it down and replace bits and wok with it to your heart's content. The demo app is there to give you a starting point, so you can avoid the complexity of writing your game from scratch. All the intricacies that have to be dealt with to make a solid game are there waiting for you to learn from.

This is not modding. You are changing the very core of the engine, not just a surface layer. You have full rights to what you make, unlike what Halflife and Unreal take from you.

If you want to play with rendering technologies and engine architecture, this is probably not the best vehicle for you (though it can be used to great effect - look at what Matthew Fairfax is doing, for instance). If you want to make a game, though, it's one of the very best options out there, for any price.

#7 Good to see another TBS fan! I just bought Torque a month ago, and it does take some time to get used to. The Torque script is certainly intertwined with the engine. A good starting point is this:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5086

That basically strips the FPS down to the bare minimum.

You can also look at the MinApp tutorials, starting with:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5091

While some script is required, it's not really necessary to write your game in it. That is the line you'll hear most often, but I tend to think that's because FPS games don't require a lot of game code (lots of graphics, physics and network code, but that's done in the engine anyway).

I've been putting all my game code in C++, and just defining a few functions in the script language for calling into it (for setting up the parameters and starting the game).

Personally I've been sticking to 2D so far - haven't tackled the whole 3D thing yet. For the scale of TBS game that I want to make, I'd rather it be in 2D anyway (makes the display a lot easier to understand). So all I've been doing is creating a custom GUI control for displaying my map (take a look at engine\gui\guiBitmapCtrl for a good starting point).

So far I've written a game of Checkers, and got it working over the Internet. (Just as a learning tool - I figured Checkers was a nice simple game that covered the basic requirements of a TBS game).

It does take a while to get a hang of Torque, but since you have the source code, it is possible to do whatever you want with it, and eliminate what you don't. I short-circuited whole sections of the network code to reduce it down to what I needed ...

#8 Glen has good advice by and large. Listen to him. :)

#9 Ok, i wasnt trying to say the engine isnt worth a hundred bucks, it certainly is, one can just look at the volume of code and tell that... what i mean was did *i* waste a hundred bucks on a product that isnt want i thought it would be / wanted it to be... i thought torque would be like most of the other stuff ive used, a collection of class libraries that encapsulated the stuff i DONT want to re-invent (accessing directx, network code, physics/math, etc)... at which point i would bust out my editor and start banging out code, like i have in the past... the difference being when i needed say, a physics function, i would just pull it in and use/extend it as needed, rather than have to go hunting around for an open source implementation...

secondly, on the issue of modding, and losing fanbase... i dont expect to HAVE a fanbase... i dont even WANT a fanbase... i dont expect to ever release anything i make in any form to anyone... i embarked on this to 1) write a game to give me something to do in my spare time, 2) hone my skills by attempting something way outside the area i normally deal with professionally, and 3) to possibly, eventually, wind up with the kind of thing *i* would want to play... that being an old-school style turn-based strategy game with all the shiny pretty graphics of today... it isnt intended for public consumption nor rapid/easy modification...

ben, i wasnt trying to set you or anyone else off, i was just trying to ascertain whether it was even possible to remove the FPS from the engine... i didnt realize that the engine is the fps is the engine, and in all honesty if i had realized that, i wouldnt have purchased the software... what i was hoping for was the engine with no game attached, a boilerplate engine initialization, and (distinct from those) a sample implementation of the engine in the form of a game that i could refer to as needed for a practical example of how to cobble together the pieces for my own game...

the problem is, based on my digging through the code and (unsuccessfully) attempting to get to that boilerplate state, i am beginning to realize that id probably spend more time stripping away and/or retooling the fps/engine to get to the point i need to be in to start building my game than i would if i just started with a rendering platform like ogre and built from the other direction... im not thrilled at the prospect of trying to integrate disparate third-party libraries for sound/physics/input handling etc or alternately having to roll my own, but i cant see how that would be any more time consuming or difficult than trying to find, isolate, deconstruct, and implement the same features from the torque codebase, especially when it seems everything is pretty well dependent on everything else to a degree which might make it even impossible to do so...

i didnt go into this entirely blind, i exchanged email with ricko(?) wherein i expressed my misgivings about what i thought might be a problem with how i wanted to use the engine... "The Torque would be perfect for a 3D Turn based game. Check out Orbz and Strategem while not exactly what you are doing each are great examples of turn based play using the Torque.
Question: scripting While you could do everything in C++, you will find that scripting save you a ton of time and runs nearly as fast as the C++ code since it is compiled into byte code before being executed. I would recommend using the scripts."

(cont)

#10 Based on these comments i figured any misgivings i might have would not be too difficult to get past, and given that there are already turn-based games using torque, i figured it would be worth my while to pop for the engine and see if i couldnt port what work i already had into it... the problem is, i just flat cant see how to get there from here as it were... the engine seems clearly geared towards fps development, and i can see how one could pretty rapidly import terrain and meshes and get something basic up and running without too much effort... i just dont think that will be the case with what im wanting to do, and i wish it had been more clear before i purchased the engine...

in particular, access to the member-only docs would have been hugely helpful in my decision-making process... before i even checked out the release from cvs i started to get a sinking feeling when i began perusing the docs...

im going to whack away at it for another day or so just to see if i can get to the point where i can put together a simple scene, light it, render it, overlay some kind of 2d elements and make it respond to some kind of input, but im afraid if i cant get to that point im just going to have to chalk it up to a lesson learned...

#11 Marble Blast, Tennis Critters, Think Tanks, Orbz. There has not been a fps released with the Torque yet. These are shipping games that were created in very short time periods.

If you don't fight it, you can make a game of any type in a short time period. Sounds like you want to do it a different way though...

#12 Tim - I never mentioned FPS... :)

All the things I mentioned in my little rant were things that would be useful for _any_ sort of game. Torque is a _game_ engine, not a physics/math/graphics/network library.

As Jeff says, all the games released with Torque have been non-FPS. I myself am writing a little turn-based game in my spare time. In my case, the "FPS-ish" aspects of the engine, like having a player class that can run around, has been a boon, cuz I can use bots for your characters and avoid having to do much in the way of pathfinding, use the existing framework for weapons, etc... Very easy to prototype it in. Eventually I'll rewrite that part of things, but for now it's great.

But I've seen a lot of stuff done in Torque, like top down penguin games, horse riding games, tic tac toe, board games, golf-like games, "physics games" (where the gameplay is based around a physical element, like the movement of balls through a tube maze, flight sims, both the realistic (of helicopters) and the whimsical (Bitshifter)...

In fact, I've seen only three first person shooters, Boomball, Lore, and Legends.

And then there are all the products that Dynamix released off the codebase that weren't FPSes - I know of a snowboarding game and a hunting game. Of course, there was Tribes, too, but I think my point is clear - Torque is not an FPS only engine.

You can make any game you want in Torque, probably more easily than you could have made it outside of Torque.

RickO was entirely accurate in his comments. You can easily make a turn based game in Torque (it took me a man-week or two to get my turn based game working solidly), and scripts are very helpful (all of the published Torque games are extensively scripted).

Just look past the demo app to the code behind it and make it do what you want. This is not a black box product. You get _everything_.

#13 Hey Ben,

I have to say your rant at the top was one of the most useful posts of I have seen. You just summerized the engine in a clear and conscise fashion. Now I have a much better idea of how it all fits together.

Thanks, Ben
ps. Just incase. That was not a joke. It really was very helpful to me.

#14 This is going to be a multipart post, to get around size limits.

Much of what you describe in your first post is accomplished in Torque with the in-game editor. You can make changes in-game and see them immediately. There are resources to allow on-the-fly script changes as well. The only part of the workflow that requires you switch applications is creating shapes (.dts files) in a 3D modeler (Max, Milkshape, Lightwave, Blender) and creating interiors (.dif files) in a level editor (QuArK), and any texture editing.

For a turn-based game, the in-game editor is a better starting point for the game itself, since it contains object level selection, a mouse pointer, and menus. You can get into the editor with F11 when a mission is loaded, but if you want to use the editor as the foundation for a TBS, the following is an ersatz starter kit.

Hack starter.fps/server/scripts/game.cs:

function GameConnection::onClientEnterGame(%this)
{
   commandToClient(%this, 'SyncClock', $Sim::Time - $Game::StartTime);

   // Create a new camera object.
   %this.camera = new Camera() {
      dataBlock = Observer;
   };
   MissionCleanup.add( %this.camera );
   %this.camera.scopeToClient(%this);
	 %this.camera.mode = toggleCameraFly;
   %this.setControlObject(%this.camera);
	 %s = pickSpawnPoint();
	 %this.camera.setOrbitMode(%s, %s.getTransform(), 10.0, 50.0, 100.0);
	 //%this.camera.setTransform(pickSpawnPoint());

   // Setup game parameters, the onConnect method currently starts
   // everyone with a 0 score.
   %this.score = 0;
}

This suppresses the spawning of the FPS player avatar (the Orc) and attaches the client to a camera orbiting the spawn point (the camera can orbit any object however).

To make this work, change the following function to return a spawn point object instead of a transform (again, this function could return any object for the camera to orbit):

function pickSpawnPoint() 
{
   %groupName = "MissionGroup/PlayerDropPoints";
   %group = nameToID(%groupName);

   if (%group != -1) {
      %count = %group.getCount();
      if (%count != 0) {
         %index = getRandom(%count-1);
         %spawn = %group.getObject(%index);
         return %spawn;
      }
      else
         error("No spawn points found in " @ %groupName);
   }
   else
      error("Missing spawn points group " @ %groupName);

   // Could be no spawn points, in which case we'll stick the
   // player at the center of the world.
   return 0;
}

#15 You'll also likely want to get rid of the bot running around the level.

Find the following lines from starter.fps/server/scripts/game.cs and delete them so that the AIManager isn't activated.

// Start the AIManager
    new ScriptObject(AIManager) {};
    MissionCleanup.add(AIManager);
    AIManager.think();
    ...
    // Stop the AIManager
    AIManager.delete();

Now, you've eliminated the FPS player avatar, the bot, and gotten the camera to orbit an object (perhaps your game board, or a spawn point situated above the board). The following will send you in to the editor instead of the FPS screen.

In starter.fps/client/scripts/serverConnection.cs, change the following function:

function GameConnection::initialControlSet(%this) {
	echo ("*** Initial Control Object");

	Editor::create();
	MissionCleanup.add(Editor);
	Editor.open();
  EditorGui.setEditor("World Editor");
	EWorldEditor.renderMissionArea = 0;
	EWorldEditor.renderObjHandle = 0;
	EWorldEditor.renderObjText = 0;
	EWorldEditor.renderPlane = 0;
	EWorldEditor.renderPlaneHashes = 0;
	EWorldEditor.axisGizmoActive = 0;
	return;
}

This will disable many of the editor-centric graphics so that your interface somewhat looks like a game. Some stuff like objText you might want to turn on and hack at later. You are still actually in the editor, but this will give you a sense of whether this is a better starting point for a TBS.

Remember that the .gui files are also code (as are the .mis (mission) files) which therefore can be loaded and edited in a text editor. There you can customize the elements of the gui for a game rather than an editor.

You can probably start cleaning up code at this point to get rid of scripts (and even source) that isn't used in your game, but in my experience you should leave files around until you're absolutely certain they will be no use. Several times I've had to go back to CVS to pull down a file I'd deleted prematurely.

#16 I claimed this was ersatz, because you really haven't gotten a game out of this (and there are still plenty of rough edges to address). But you don't have an FPS any more either.

It's also important to realize that objects continue to 'tick', even while the editor is active (it is truly an in-game editor).

So now you can use a .dif, .dts or even the terrain to make a game board. Use .dts shapes to create game pieces. About the only time you are forced out of the in-game editor is to create or change art assets, or make source-level changes to the engine.

Making a TBS within a general graphical simulation engine also opens cool possibilities like animating the game pieces, adding particle effects, adding 3D representations of game actions (e.g. a projectile to represent one game piece attacking another). You could make actual dice for a game using rigid body physics with some hacking of the vehicle code. Etc., because there is plenty of general horsepower there available for things other than moving an Orc across the hills.

But even at this point, you should be able to mock up a game pretty quickly, once you have created and exported all the art assets (models, levels and textures).

#17 Wow, thats cool.

Well I must say I have learned a lot from this post.
Thanks Ben, after reading your comment I had a much better idea on how to look at the code found in game directory and all the other ones. That greatly improved my knowledge of torque.

Also Brad, thanks for the tutorial. I have been reading through the scripts at each section and comparing them to yours.

Its starting to make sence. Very cool.

Later, Ben

#18 Tim,

It seems to me your basic problem is that there is a lot to learn with Torque. Unlike OGRE Torque is a * complete * game engine with a scripting language. Seems to me you're the kind of guy who likes to do it yourself. You know make your own wheel instead of using the one thats allready there, and maybe thats why you bought Torque. Scipting is not a bad thing. Scripting is your friend. You have two basic choices.

1. Walk away and chalk it up to lessons learned and go back to OGRE or build your own game engine.

2. Take a deep breath, go to your happy place inside your mind and relax. Writing script is nothing more than a way to keep you from having to recompile the engine with every change. Think of using property files that the engine reads to have certain settings. Scrpting allows you to dymanically set these values. You dont really need more than just a few basic files. Brad has taken the time to tell you which ones.

Take a look here at why a scripting language is a good idea and it will give you a good frame work to see how and when to use it.
gamestudies.cdis.org/~amatheson/writing/LUA-Part01/Part01-section02.html

#19 Anyone remember the resource (or creator) for in-game script editing? I can't think of any keyword searches that won't return hundreds of matches ("script", "editor", etc). I mentioned it above and wanted to provide a pointer to the resource.

BTW, here is a screenshot with the script changes above in place, showing a 4x4 game board hovering above the Orc village (click for larger version).

#20 Brad,

Here's My favorite links on TGE Scripting:

www.gamebeavers.org/files/TGE_Console_Cmds.rtf
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2212
www.egotron.com/torque/old_script.html


String Stuff:
www.garagegames.com/mg/forums/result.thread.php?qt=2735
www.garagegames.com/mg/forums/result.thread.php?qt=11691