TorqueScript vs C
by Michael Lattanzia · in Technical Issues · 07/20/2007 (7:19 am) · 4 replies
I've been working on development of a Turn Based combat game for a few weeks now, and an interesting question has come up that I'm hoping some people can help with. I've been doing pretty much everything in script (except the stuff that CAN'T be done in script, such as modding some camera stuff and object selection). I've started to think of ways to do some things that I've scripted in the C++ language instead, and the question is when is it better to modify the engine code versus using scripting? Does anyone have general guidelines they follow for when to modify the engine source instead of just scripting the same thing?
The reason this came up is because I'm working on an RPG style game, and I'm going to need ways to store lots of information such as character information, inventory, spells/abilities, etc. I started working on spells first and I began by creating script arrays with all the information needed by the spells. I used ScriptObjects to sort of simulate a spell class to store the information, but I started to wonder if it wouldn't just be better to create an actual spell class in the engine and access it from the console. The same goes for player information... I started by just adding variables in script to the player objects, but I started to wonder if perhaps it would be easier/better to modify the engine code to include the variables and any new member functions internally with console methods for accessing them instead.
Anyway, if anyone has any opinions, I'd love to hear them.
The reason this came up is because I'm working on an RPG style game, and I'm going to need ways to store lots of information such as character information, inventory, spells/abilities, etc. I started working on spells first and I began by creating script arrays with all the information needed by the spells. I used ScriptObjects to sort of simulate a spell class to store the information, but I started to wonder if it wouldn't just be better to create an actual spell class in the engine and access it from the console. The same goes for player information... I started by just adding variables in script to the player objects, but I started to wonder if perhaps it would be easier/better to modify the engine code to include the variables and any new member functions internally with console methods for accessing them instead.
Anyway, if anyone has any opinions, I'd love to hear them.
#2
07/20/2007 (7:55 am)
Well I had 2 reasons for wanting to use the C++ source rather than scripting for some of this. The first is that I need a list of data, and it seems easier to be able to use a C++ class so I can traverse the list and such easier than I could trying to write it all as a script. The second reason is that it would be harder for a player to modify the spell list, which should only be changed if the game itself updates. 
#3
With experience you'll soon learn the types of functions that are always worth coding in C++
07/22/2007 (4:25 pm)
The only reason to move to C++ is performance really so whilst you're learning I would say script everything and then when you come to test your game then look if you have any performance problems if so then then find out which script functions are slowest and look at moving them to C++.With experience you'll soon learn the types of functions that are always worth coding in C++
#4
but computers are rilly fast, so unless your list is very large and you're processing it very often,
script will probably perform fine. "very often" usually means something which is happening automatically more than once per second, say. if processing the list is triggered by user action such as opening their spell inventory, then it's not as big a deal.
there's a few options for lists in script:
* SimSets (or SimGroups) are pretty good at storing lists of ScriptObjects. They don't store plain old data, tho. Just objects.
* The array notation, eg %myList[%myIndex] is allright, altho you have to keep track of the size of the array yourself.
* Tab-delimited fields in strings can be used with GetField(), SetField(), and GetFieldCount(). eg, GetFieldCount("this is my first fieldand this is my secondand so on") would return 3.
* I believe there's a resource out there somewhere to bring arrays to script.
re security,
if your game is multi-player, the server should always be vetting each user's actions. just because the client says it casts fireball doesn't mean they're allowed to.
for a single-player game, the user essentially can hack the server as well as the client, so that won't do you much good. but you can still get a little edge by only distributing the compiled .dso versions of the script files, and not the .cs originals. there are still ways for a moderately knowledgable user to modify the script, but it raises the bar slightly.
but in the end, it's obviously your own call. for my money, i think you'd probably make more progress on your game by just doing it in script and waiting until either performance or security actually become a problem, and then looking at moving it into C.
my 2cents.
07/22/2007 (6:49 pm)
Michael - yes, lists in C are more performant than lists in script,but computers are rilly fast, so unless your list is very large and you're processing it very often,
script will probably perform fine. "very often" usually means something which is happening automatically more than once per second, say. if processing the list is triggered by user action such as opening their spell inventory, then it's not as big a deal.
there's a few options for lists in script:
* SimSets (or SimGroups) are pretty good at storing lists of ScriptObjects. They don't store plain old data, tho. Just objects.
* The array notation, eg %myList[%myIndex] is allright, altho you have to keep track of the size of the array yourself.
* Tab-delimited fields in strings can be used with GetField(), SetField(), and GetFieldCount(). eg, GetFieldCount("this is my first field
* I believe there's a resource out there somewhere to bring arrays to script.
re security,
if your game is multi-player, the server should always be vetting each user's actions. just because the client says it casts fireball doesn't mean they're allowed to.
for a single-player game, the user essentially can hack the server as well as the client, so that won't do you much good. but you can still get a little edge by only distributing the compiled .dso versions of the script files, and not the .cs originals. there are still ways for a moderately knowledgable user to modify the script, but it raises the bar slightly.
but in the end, it's obviously your own call. for my money, i think you'd probably make more progress on your game by just doing it in script and waiting until either performance or security actually become a problem, and then looking at moving it into C.
my 2cents.
Torque Owner Jason Lee