Torque Modules
by Prairie Games · in Torque Game Engine · 07/02/2003 (1:22 am) · 9 replies
I am designing a Torque editor. I am not going to get into specifics of this now. But, here's a "fun" scenario:
Suppose a group using the editor adds a class to the engine, their own or one from a resource. My guess is that they will want the ability to edit it. How do I facilitate this using the current situation of compiling everything into a monolithic exe? Hand out the code, allowing groups to add their sources to the editor's sources? Bzzzt... This is a craptacular solution ...I am also not giving away the sources.
In order to facilitate people editing their game specifics, I need a package system... A way for groups to compile their game specifics so the editor can dynamically load them... There is no other solution, none.
Torque needs a standard package system using shared libraries... Torque itself should also support this compilation strategy. A clean seperation between what is Torque and what is a specific game sure would be nice, and not just in this instance.
Anyone with ideas? Under the current situation, I don't see anything :(
-J
Suppose a group using the editor adds a class to the engine, their own or one from a resource. My guess is that they will want the ability to edit it. How do I facilitate this using the current situation of compiling everything into a monolithic exe? Hand out the code, allowing groups to add their sources to the editor's sources? Bzzzt... This is a craptacular solution ...I am also not giving away the sources.
In order to facilitate people editing their game specifics, I need a package system... A way for groups to compile their game specifics so the editor can dynamically load them... There is no other solution, none.
Torque needs a standard package system using shared libraries... Torque itself should also support this compilation strategy. A clean seperation between what is Torque and what is a specific game sure would be nice, and not just in this instance.
Anyone with ideas? Under the current situation, I don't see anything :(
-J
#2
The scripting engine is darn powerful and there's very little you really want to modify in the C++ code. At least that's my view. Personally I think the core engine should have everything in it that can't be done in script and let the users make whatever mods they want and package them up. You can certainly replace graphics, guis and add functionality with the scripting engine so I'm not sure what would need to be done to the engine. Essentially you give the users their engine (making whatever mods you deem necessary in code) and let them script everything.
Of course (getting back to beffy's comments) if you have a package that you want to add that does make changes to code then there needs to be a mechanism there. It does get into the dll discussion so either you can expose something in the engine yourself to load a dll to support this or maybe there should be something more exposed in the scripting engine to expose that functionality?
Generally I feel any software should be some kind of pluggable system where you can just add water and make it grow. DLLs do offer this if you take the time to expose the pieces you think will be needed but scripting has it's advantages too. From most of the scripts I've seen here, they could have been completely done in script, without suffering too much hit on frame rate or general performance (unless they were doing something completely new the engine didn't support). I know I've built a test weather system so far and it's completely driven by script. You fire and forget and it runs constantly in the background, updating the weather, visual and sound effects, atmosphere and dynamically changing the terrain where possible.
07/02/2003 (2:54 am)
Same here however I'm looking at the mod option in the engine for this kind of thing. That's essentially what it's meant for. Package everything up into a single dircectory and people can use your "mod" by adding it to the command line with "-mod mymod".The scripting engine is darn powerful and there's very little you really want to modify in the C++ code. At least that's my view. Personally I think the core engine should have everything in it that can't be done in script and let the users make whatever mods they want and package them up. You can certainly replace graphics, guis and add functionality with the scripting engine so I'm not sure what would need to be done to the engine. Essentially you give the users their engine (making whatever mods you deem necessary in code) and let them script everything.
Of course (getting back to beffy's comments) if you have a package that you want to add that does make changes to code then there needs to be a mechanism there. It does get into the dll discussion so either you can expose something in the engine yourself to load a dll to support this or maybe there should be something more exposed in the scripting engine to expose that functionality?
Generally I feel any software should be some kind of pluggable system where you can just add water and make it grow. DLLs do offer this if you take the time to expose the pieces you think will be needed but scripting has it's advantages too. From most of the scripts I've seen here, they could have been completely done in script, without suffering too much hit on frame rate or general performance (unless they were doing something completely new the engine didn't support). I know I've built a test weather system so far and it's completely driven by script. You fire and forget and it runs constantly in the background, updating the weather, visual and sound effects, atmosphere and dynamically changing the terrain where possible.
#3
For the editor, I think the solution may be in only supporting standard Torque features/file formats. Ultimately forcing groups to come up with their own solutions for custom content. This isn't a terrible thing... especially considering excellent (TribalIDE grade) .cs support, and (optionally) tremendous Python support...
I can still dream of a nice package system...
-J
07/02/2003 (3:03 am)
Many additions to the engine require C++ side work... The only way to extend with C++ is to be able to compile the whole darned thing. This is not a good situation. For the editor, I think the solution may be in only supporting standard Torque features/file formats. Ultimately forcing groups to come up with their own solutions for custom content. This isn't a terrible thing... especially considering excellent (TribalIDE grade) .cs support, and (optionally) tremendous Python support...
I can still dream of a nice package system...
-J
#4
You mentioned that you wanted people to be able to add classes to the engine. Essentially changing the way the base engine works or adding to it? You can create classes in script and invoke them in a mod. I'm still now sure specifically what game engine features you want them to be able to modify. Sure, if someone says "I don't like the way the engine renders blah blah blah" then yes, a C++ change is needed. I would just direct them to buy the engine themselves and do it. That's what the role of someone who owns the SDK is. If you're looking to have end users change say the rendering engine, then you're essentially repackaging the game engine for them to modify right? The intent of Torque is not to give users a be-all end-all engine that they can modify to their hearts content, it's to provide users with a game they can modify to their hearts content through scripting and customization.
Like I said though, if you really want them to be able to modify things at that level, you technically could expose the engine inner workings through a wrapper class and provide them with a library to link against (or build your own DLL loader and initialization system). I think that's overkill for even the most die-hard modders though. There's tremendous things people do in Unreal, Half-Life and Quake scripting. The Quake 2 DLL system really hasn't added much in the way of mods that I can see. Just my humble opinion of course...
07/02/2003 (3:32 am)
True but the question is are you trying to provide users with a game engine they can modify or a game they can modify.You mentioned that you wanted people to be able to add classes to the engine. Essentially changing the way the base engine works or adding to it? You can create classes in script and invoke them in a mod. I'm still now sure specifically what game engine features you want them to be able to modify. Sure, if someone says "I don't like the way the engine renders blah blah blah" then yes, a C++ change is needed. I would just direct them to buy the engine themselves and do it. That's what the role of someone who owns the SDK is. If you're looking to have end users change say the rendering engine, then you're essentially repackaging the game engine for them to modify right? The intent of Torque is not to give users a be-all end-all engine that they can modify to their hearts content, it's to provide users with a game they can modify to their hearts content through scripting and customization.
Like I said though, if you really want them to be able to modify things at that level, you technically could expose the engine inner workings through a wrapper class and provide them with a library to link against (or build your own DLL loader and initialization system). I think that's overkill for even the most die-hard modders though. There's tremendous things people do in Unreal, Half-Life and Quake scripting. The Quake 2 DLL system really hasn't added much in the way of mods that I can see. Just my humble opinion of course...
#5
"You can create classes in script and invoke them in a mod." - You can created named datablocks in script. You cannot create classes, nor can you inherit from them. I find TorqueScript extremely limiting... but that's ok.. I have to support it.
I tend to think a bit beyond the target audience ... though, I want the editor to be useful to people doing intermediate to advanced things with Torque. Modding the Torque Demo doesn't cut it.
I think supporting standard Torque features/file formats is likely what I will need to do. I can also go thru the (pain) of packaging good resources into the editor... the stuff would just fail when loading the class instances if a given game was compiled without them.
If I can come up with a slick way of getting people's custom classes into the editor I will... ya never know when lightning will strike.
-J
07/02/2003 (3:40 am)
@Bil: The editor is for Torque developers, not end users of Torque games. I think there was some confusion there."You can create classes in script and invoke them in a mod." - You can created named datablocks in script. You cannot create classes, nor can you inherit from them. I find TorqueScript extremely limiting... but that's ok.. I have to support it.
I tend to think a bit beyond the target audience ... though, I want the editor to be useful to people doing intermediate to advanced things with Torque. Modding the Torque Demo doesn't cut it.
I think supporting standard Torque features/file formats is likely what I will need to do. I can also go thru the (pain) of packaging good resources into the editor... the stuff would just fail when loading the class instances if a given game was compiled without them.
If I can come up with a slick way of getting people's custom classes into the editor I will... ya never know when lightning will strike.
-J
#6
07/02/2003 (3:53 am)
Yeah, I didn't mean modding the game by end users, too ... I was thinking of e.g. giving my AI stuff to ppl who own the SDK so that they can use the dll and customize the core functionality from scripts etc. ... of course, end users/modders could do that, too, but that's not my concern... the point is: sharing "modules" with other dev groups without necessarily giving away all your code...
#7
However I don't see it being hard to add your own DLL loader for people to create their own objects (derived from SimObject) and instantiate them in script. The only problem is you have to provide them with some of the SDK headers. If, like beffy said, the target audience is SDK owners then that's not a problem. If it's end users for a game then that's a problem.
There definately needs to be an easy way to get new features into the base engine, without having to manually patch the code from other peoples efforts.
07/02/2003 (3:59 am)
Sorry, don't know where my head was. I thought you could create new classes in script but I was thinking of variables and functions.However I don't see it being hard to add your own DLL loader for people to create their own objects (derived from SimObject) and instantiate them in script. The only problem is you have to provide them with some of the SDK headers. If, like beffy said, the target audience is SDK owners then that's not a problem. If it's end users for a game then that's a problem.
There definately needs to be an easy way to get new features into the base engine, without having to manually patch the code from other peoples efforts.
#8
@Bil: The problem with a "simple" DLL loader is that the code you are loading has to be compiled and linked first... with a Torque dependency, chart this out... see? :) I absolutely agree with you, a simpler, cleaner, and better way would be great...
@Anyone wondering about Mac/Linux: Indeed, your platform supports shared libraries (aka. DLLs)
For now, I will plan for things to remain the same. They have for this long. I understand that most people just dink with Torque. If someone wants to really make something with it, I want the Editor to actually support them... not just get in their way.
-J
07/02/2003 (4:03 am)
@Beffy: The problem with dll's floating around is that they can become incompatible with a changing engine. If there are bugs (heaven forbid) they can't be fixed by someone who wants to use the code... sometimes code gets abandoned and rots... with no source, the dll is useless in this case. Precompiled sources in this instance are a liability for most projects. I see the value in a module system being in easier/better sharing of source. Most importantly, a package system is much more flexible. @Bil: The problem with a "simple" DLL loader is that the code you are loading has to be compiled and linked first... with a Torque dependency, chart this out... see? :) I absolutely agree with you, a simpler, cleaner, and better way would be great...
@Anyone wondering about Mac/Linux: Indeed, your platform supports shared libraries (aka. DLLs)
For now, I will plan for things to remain the same. They have for this long. I understand that most people just dink with Torque. If someone wants to really make something with it, I want the Editor to actually support them... not just get in their way.
-J
#9
07/02/2003 (4:34 am)
I'm currently working on that things. If you remember a quite old .plan I submit, I show ed the integrattion of Torque in a regular VC++ application. I'm also developping somehow an integrated editor for Torque ;) 
Associate Stefan Beffy Moises
I too wanted to finish my TorqueBot and give it away as a module/dll so that others could use it... but there is no way with the current setup of the engine...
either give away your source so that others can include and build it into their exe or don't give away anything at all... :/
and unfortunately that "exe versus dll" horse has been beaten beyond death in past discussions here ... without any solution as far as I remember...