To Script or Not To Script
by Pisal Setthawong · 03/15/2007 (4:41 pm) · 5 comments
Another long ramble LOL
During the last few weeks, I've been in the process of gradually of phasing out my heavily modified TGE v1.4 after my last project has been completed. The project has gone out well, though I have to say due to IP and ownership issues, at times it is bewildering. Anyway since the that project is completed, and things are quite stable and done with, I thought it would be a good time to start upgrading the tools in the arsenal with the latest codebase of TGE v1.5 along with integrating the ArcaneFX toolkit which I find a very interesting addition to TGE.
As my old TGE v1.4 was heavily modified with numerous patches that are done by the community, and along with many of my own hacks, the process to port the existing code into the current code base has quite been a hassle. Let me explain - it has to do with the main question - To Script or Not To Script. In many of the discussions in the forums, there are usually huge discussions on this topic. In many cases, though scripting engine solutions exist, some developers has adviced on implementing some of those modification inside the game engine core to speed up the process. In many senses that is a rather valid argument as what is inside the core is typically magnitudes of time faster than what is a scripting approach. In complex scripts, it certainly makes good sense to implement it in the engine.
Anyway, talking about those modifications, in my old v1.4, I had done a myraid of core changes from jumping, camera, Cg implementations, etc. In addition to that I had a lot of interesting scripting solutions, that includes appending the StaticShape class with many of the behaviors in the AIPlayer class by using scripts. It isn't that elegant, pretty slow, but it does server a number of purpopses the AIPlayer class couldn't do. Well I could go on and on about the different changes, but let me just go to the conclusion.
Regarding the comments on trying to script the least as possible, and try to implement equivalent methods/functions in the core, though it increases in speed, one of the biggest issues that I've faced and I think should be worth a mention would be from the part that it is quite difficult to recall what and where you have changed the core engine. Coupled that with possible changes in the core, getting your new mods into the new engine is quite tedious. Its easy to forget small snips of code that doesn't cause anything diabolic, but could cause irritating bugs in the long run. To give a clue, it was a problem about not commenting the code changes properly, and when the merge happened, some code were missing.
Talking about the issue before, I do think that is quite a good issue to note that do make code changes with care. Keep track of them. At the moment, I have a book noting all the changes done and lines in which the changes are done. In addition, frequent update into a version control system with additional notice is a good thing to do. One last thing that I figured out was that submitting your own resource does help in the long run. Though its easy to think its pretty much a tiresome and thankless task to submit resources, one of the useful things I found is that its a good place to recall what you have done. I did get some pointers from an old resource I did (which I found numerous mistakes later LOL), and it did help alot. So in conclusion, its good to submit resources. I want to just ramble again and comment all the great authors out there.
Regarding the scripts that were used in the previous project, it has been a hell of an easier task to integrate with the new version. As the scripts did not change between the different TGE versions, most of them work directly except those that requires certain core features that were added seperately, or globals that were missing or not used. If there was a good plan in seperating scripts into files, or basically having a good physical file hierachy, things simply are much better :)
Hmm... after a somewhat long rambling, what is my conclusion? As usual, I like to say if you have to pick between black and white, pick grey. Why? Its better to be flexible and appreciate all the good things each extreme of the solution brings :)
Oh well, after a long blog, how are things going along? More of the same. I'll just list out a few things:
1) I've finished upgrading my TGE to the newest with the feature list that I need for the next game. I'll probably post the screenshot sometime when the first few mock scenes of a few new planned game. Nothing earth shattering, but anyway, I'll keep the community updated about strange new quirky things I'll be up to. As noted, I'm a peculiar person, and I guess it can't be hidden :P
2) written a small graphic engine that I plan to use when teaching Computer Graphics next semester. Its made out of SDL, OpenGL and I'm planning to add shader support, though I'm still divided between supporting Cg or GLSL on it. Nothing big, but I just wanted to repackage the code to make it easier to explore the different algorithms and steer away from GLUT. Looking back at the few days of muddled programming, it was exhilarating, but I still wonder is it really worth doing it LOL
3) Finally received some funding for extending my lab. Finally! I'm pretty irked by using old outdated computers.
4) Finalized plans to study for my PhD, though still planning between accepting the scholarship (and being tied up to the university) or either fund myself just incase a future opportunity knocks on the door. I don't know why I should bolt the comforts of the academic world, but... who knows :P
Hope things on your side of the world are doing well. Keep updated!
During the last few weeks, I've been in the process of gradually of phasing out my heavily modified TGE v1.4 after my last project has been completed. The project has gone out well, though I have to say due to IP and ownership issues, at times it is bewildering. Anyway since the that project is completed, and things are quite stable and done with, I thought it would be a good time to start upgrading the tools in the arsenal with the latest codebase of TGE v1.5 along with integrating the ArcaneFX toolkit which I find a very interesting addition to TGE.
As my old TGE v1.4 was heavily modified with numerous patches that are done by the community, and along with many of my own hacks, the process to port the existing code into the current code base has quite been a hassle. Let me explain - it has to do with the main question - To Script or Not To Script. In many of the discussions in the forums, there are usually huge discussions on this topic. In many cases, though scripting engine solutions exist, some developers has adviced on implementing some of those modification inside the game engine core to speed up the process. In many senses that is a rather valid argument as what is inside the core is typically magnitudes of time faster than what is a scripting approach. In complex scripts, it certainly makes good sense to implement it in the engine.
Anyway, talking about those modifications, in my old v1.4, I had done a myraid of core changes from jumping, camera, Cg implementations, etc. In addition to that I had a lot of interesting scripting solutions, that includes appending the StaticShape class with many of the behaviors in the AIPlayer class by using scripts. It isn't that elegant, pretty slow, but it does server a number of purpopses the AIPlayer class couldn't do. Well I could go on and on about the different changes, but let me just go to the conclusion.
Regarding the comments on trying to script the least as possible, and try to implement equivalent methods/functions in the core, though it increases in speed, one of the biggest issues that I've faced and I think should be worth a mention would be from the part that it is quite difficult to recall what and where you have changed the core engine. Coupled that with possible changes in the core, getting your new mods into the new engine is quite tedious. Its easy to forget small snips of code that doesn't cause anything diabolic, but could cause irritating bugs in the long run. To give a clue, it was a problem about not commenting the code changes properly, and when the merge happened, some code were missing.
Talking about the issue before, I do think that is quite a good issue to note that do make code changes with care. Keep track of them. At the moment, I have a book noting all the changes done and lines in which the changes are done. In addition, frequent update into a version control system with additional notice is a good thing to do. One last thing that I figured out was that submitting your own resource does help in the long run. Though its easy to think its pretty much a tiresome and thankless task to submit resources, one of the useful things I found is that its a good place to recall what you have done. I did get some pointers from an old resource I did (which I found numerous mistakes later LOL), and it did help alot. So in conclusion, its good to submit resources. I want to just ramble again and comment all the great authors out there.
Regarding the scripts that were used in the previous project, it has been a hell of an easier task to integrate with the new version. As the scripts did not change between the different TGE versions, most of them work directly except those that requires certain core features that were added seperately, or globals that were missing or not used. If there was a good plan in seperating scripts into files, or basically having a good physical file hierachy, things simply are much better :)
Hmm... after a somewhat long rambling, what is my conclusion? As usual, I like to say if you have to pick between black and white, pick grey. Why? Its better to be flexible and appreciate all the good things each extreme of the solution brings :)
Oh well, after a long blog, how are things going along? More of the same. I'll just list out a few things:
1) I've finished upgrading my TGE to the newest with the feature list that I need for the next game. I'll probably post the screenshot sometime when the first few mock scenes of a few new planned game. Nothing earth shattering, but anyway, I'll keep the community updated about strange new quirky things I'll be up to. As noted, I'm a peculiar person, and I guess it can't be hidden :P
2) written a small graphic engine that I plan to use when teaching Computer Graphics next semester. Its made out of SDL, OpenGL and I'm planning to add shader support, though I'm still divided between supporting Cg or GLSL on it. Nothing big, but I just wanted to repackage the code to make it easier to explore the different algorithms and steer away from GLUT. Looking back at the few days of muddled programming, it was exhilarating, but I still wonder is it really worth doing it LOL
3) Finally received some funding for extending my lab. Finally! I'm pretty irked by using old outdated computers.
4) Finalized plans to study for my PhD, though still planning between accepting the scholarship (and being tied up to the university) or either fund myself just incase a future opportunity knocks on the door. I don't know why I should bolt the comforts of the academic world, but... who knows :P
Hope things on your side of the world are doing well. Keep updated!
#2
I'm due to look at my PhD soon too, but cant think what to concentrate on.
03/15/2007 (9:11 pm)
Pisal, I definitely feel your pain. I've started various engines in the past to support various modules I've taught. I'd go for using Cg myself, if nothing else than the PS3 connection.I'm due to look at my PhD soon too, but cant think what to concentrate on.
#3
Now, I do 90% of my work in script. Basically, I can just get something up and running quicker in script. I have found, working on a design that rapidly changes as I iterate, scripting is the best. I'm making an RPG, but I haven't nailed down the exact details of things like stats and how they work. Having the code that handles combat in a script file for instance means I can quickly adjust it when I need to.
It tends to be game-logic type stuff that I script. Comparing a characters weapon skill to his armor rating to determine damage done is not something that needs c++ speed.
Its up to the coder to judge the needs of the system I guess. I am working on an effects/buffs system that needs tight timing control and ghosting across the network, so thats 50% c++ with script callbacks to actually modify the characters stats in script.
03/16/2007 (8:45 am)
I have found script to be amazingly useful and productivity enhancing. When I started with TGE, I made almost all of my changes to the c++.Now, I do 90% of my work in script. Basically, I can just get something up and running quicker in script. I have found, working on a design that rapidly changes as I iterate, scripting is the best. I'm making an RPG, but I haven't nailed down the exact details of things like stats and how they work. Having the code that handles combat in a script file for instance means I can quickly adjust it when I need to.
It tends to be game-logic type stuff that I script. Comparing a characters weapon skill to his armor rating to determine damage done is not something that needs c++ speed.
Its up to the coder to judge the needs of the system I guess. I am working on an effects/buffs system that needs tight timing control and ghosting across the network, so thats 50% c++ with script callbacks to actually modify the characters stats in script.
#4
So, how does this relate to C++ vs script? For myself I draw the line like this:
1. If it is not speed critical I do it in script.
2. If it is speed critical I may test it out in script, then implement in C++. But, I make anything I can that configures, starts, stops, etc the functionality accessible by script.
Here is an example of 2:
1. I have created widget that displays and grid with cells for the Conway Life Program.
2. The conway life algorithm is implemented in a separate sim based object. Speed is the primary reason.
3. All the data is stored as sim objects that are put in a simobjectlist.
Benefits:
1. The data can be saved using normal sim object save commands.
2. The data is not bound to a graphical widget.
3. The grid can be used to display data for completely different versions of the algorithm just by changing the sim object that talks to it.
So, while I have created C++ object based stuff it is very flexible and can be used any way I dream up beyond the initial intent of the object in the first place.
03/16/2007 (6:52 pm)
A conscious separation of responsibilities. When I create a control system for a factory there is a split of responsibilities for different pieces of the system. For instance: a process controller and a human machine interface (HMI) have distinct responsibilities. The process controller controls the process with the information it has. The HMI monitors and allows processes to be started/stopped and setpoints changed. However, the HMI is NOT allowed to do control. The reason is the process controller is orders of magnitude more reliable than the HMI that is (unfortunately) often based upon a Windows system. So, I have had to draw the line where the process controller does the control and does not need the HMI to operate. In one control system I even made the control panel feed directly into the process controller so that you could control the system without the HMI at all! That system was the most like a video game I have ever installed and was a lot of fun.So, how does this relate to C++ vs script? For myself I draw the line like this:
1. If it is not speed critical I do it in script.
2. If it is speed critical I may test it out in script, then implement in C++. But, I make anything I can that configures, starts, stops, etc the functionality accessible by script.
Here is an example of 2:
1. I have created widget that displays and grid with cells for the Conway Life Program.
2. The conway life algorithm is implemented in a separate sim based object. Speed is the primary reason.
3. All the data is stored as sim objects that are put in a simobjectlist.
Benefits:
1. The data can be saved using normal sim object save commands.
2. The data is not bound to a graphical widget.
3. The grid can be used to display data for completely different versions of the algorithm just by changing the sim object that talks to it.
So, while I have created C++ object based stuff it is very flexible and can be used any way I dream up beyond the initial intent of the object in the first place.
#5
Thanks for the feedback on the Subversion Repository layouts and etc! There is a lot to learn at usual, and I appreciate the time spent on explaining about how to setup the repository properly :)
@Frank and Gareth
Thanks for the comments! The more we think of it, its pretty interesting topic I do reckon :)
@Phil
I'm thinking about Cg also. Seems that I'll have to add more libraries to the project LOL p.s. Good luck with your studies. You are definitely more qualified than I am and I'm sure you'll have no problem if you decide on where to go :)
03/17/2007 (4:28 am)
@Tony Thanks for the feedback on the Subversion Repository layouts and etc! There is a lot to learn at usual, and I appreciate the time spent on explaining about how to setup the repository properly :)
@Frank and Gareth
Thanks for the comments! The more we think of it, its pretty interesting topic I do reckon :)
@Phil
I'm thinking about Cg also. Seems that I'll have to add more libraries to the project LOL p.s. Good luck with your studies. You are definitely more qualified than I am and I'm sure you'll have no problem if you decide on where to go :)
Torque 3D Owner Tony Richards
What is the difference between the game engine and the game?
When you're only coding a single game it's a rather difficult question to answer. Everything you write / modify is written in support of your game, but only a subset of that would qualify as a game engine enhancement.
For instance, say you want a shoulder mounted heat seaking rocket. How much of that should be in the engine and how much of it should be in the game? If you only want one shoulder mounted weapon and only one guided projectile, it's still unclear.
Now, enhance the statement... you want vehicles with heat seeking missiles, a non-vehicular shoulder mounted heat seeking missile, and a shoulder mounted mortar cannon.
With these requirements, it's easier to take a step back, put on your game engine hat and say:
"Ok, my game engine needs to support weapons that can be mounted to vehicles as well as players. The engine also needs to support multiple projectile types, including seeking as well as non-seeking types."
Then you can take off your game engine hat and put on your game making hat and say:
"Oh, cool... with these engine capabilities I can make my player's shoulder mounted heat seeking missile work correctly."
As you gain more coding experience these questions will tend to answer themselves.
But not to worry... if you're only making a single game then you can't get the answer wrong.... just do whatever is the easiest.
Now, on to the other question that you didn't ask:
How do I keep a more accurate record of the changes I make (and more importantly, keep track of the changes Garage Games makes) to the engine?
Two words: Version Control Or you could drop it down to a single word and simply say Subversion.
Take one my FPS games as an example... I started working with TGE 1.4, a month or so after I started I added TGE 1.5, then a few months later I added AFX. Between each of these versions I had made significant code changes to both the engine as well as scripting.
Although you can do this with nearly any version control system, (Perforce, for example, works quite well), I love the way you do it in Subversion.
Start with a directory structure like this:
\labels
\branches
\trunk
\vendor
Add the vendor drop:
\lables
\branches
\trunk
\vendor
\tge_1_4
\vs2005
\engine
\lib
... etc
Now, once you've checked it all in, copy everything from tge_1_4 to trunk.
\lables
\branches
\trunk
\vs2005
\engine
\lib
... etc
\vendor
\tge_1_4
\vs2005
\engine
\lib
... etc
Now you can start making your code changes in the trunk area. Don't touch vendor area until you get your next drop from GG.
Ok, so a few months later you've been coding in trunk, you have your changes all checked in and you want to get the latest from GG. First, grab the vendor\tge_1_4 and make a new branch called vendor\tge_1_5. Download TGE 1.5 from GG, extract it and copy over vendor\tge_1_5. Now, before you check this in (and this is an important step), use the SVN switch statement and switch to your trunk (or the branch you created for the purpose of this merge in case things go wrong).
What this does is figures out all changes made by GG between 1.4 and 1.5 and applies those changes to your current version.
You might get a few conflicts that need to be resolved, but you can easily use Tortoise SVN's graphical three-way merge / conflict resolver to show you the changes you made, the changes GG made and the best guess SVN made to attempt to resolve the changes.
Voila... unless you've completely refactored portions of the game engine, you should be up and running in just a few minutes...
After you've got it working, check everything in, switch back to the TGE 1.5 vendor drop, re-copy all of the TGE 1.5 from GG into it and check it in. Now you're ready to integrate the next vendor drop (like AFX or something).
You could also do the same thing (with fewer steps) using SVN's branch / merge capabilities, but it takes a bit more thinking / explaining and would be difficult to explain in text without a specific example and some screenshots.
This method works quite well, especially when you're keeping track of TGE 1.4, 1.5, AFX 1.5 plus service packs from them, plus the TGE modernization toolkit, etc... Every time you get a new code drop it only takes you a few short minutes to merge everything in.... it was awesome when GG used CVS because then you could grab new code drops every week, but alas, that's a different story.
This method is also a great way to merge in resources from this website... if you've kept track of TGE / major releases (1.0, 1.1, 1.3, 1.4, 1.5) and you have all of the branches in your version control system then you can easily take any resource no matter which version it was intended and drop it in, switch to your current version and resolve any conflicts...
I'm not saying this method is 100% fool proof, but it's significantly easier than manually keeping a written track record of all of the game engine changes you've made... why not let the computer do it for you?