// Load weapons script file
if (LoadScript( pScriptEngine, "common.as", MAIN_MODULE ) < 0)
{
pScriptEngine->Release();
cout << "Failed to load script file." << endl;
Pause();
return -1;
}
// Load weapons script file
if (LoadScript( pScriptEngine, "weapons.as", MAIN_MODULE ) < 0)
{
pScriptEngine->Release();
cout << "Failed to load script file." << endl;
Pause();
return -1;
}
// Load main script file that runs in synch with the game loop
if (LoadScript( pScriptEngine, "main.as", MAIN_MODULE ) < 0)
{
pScriptEngine->Release();
cout << "Failed to load script file." << endl;
Pause();
return -1;
}[/quote]
So is it better to create an additional module for each creature in a game, or should I have only 1 module and have unique "main functions", based on each creature's name?
Creature1Main()
{
}
Creature2Main()
{
}
etc.
One Module Per Entity, Or One Modual to Rule Them All?
Author
What the best way to go about this? I have some code from an old tutorial and they are loading all the files into one module and then calling function names from that module.
That is one way to go about it. The design you presented has the advantage of allowing you to easily save individual classes to disk as compiled bytecode
with the downside being that you have to import from another module when you want to access another entitiy's functions for whatever reason.
Another way is to have your classes inherit from an interface or canned entity class that holds a reference to an internal game object that has events propagated to it..
The upside is easy management and referencing to game objects. The downside is that to save the bytecode, you need to save everything to disk as one
big blob. This leads to significant code duplication and while on the PC platform this is not that big of a deal, on consoles this could lead to problems.
Perhaps Andreas can consider looking into giving us the ability to write bytecode to individual script sections in a module to disk?
with the downside being that you have to import from another module when you want to access another entitiy's functions for whatever reason.
Another way is to have your classes inherit from an interface or canned entity class that holds a reference to an internal game object that has events propagated to it..
The upside is easy management and referencing to game objects. The downside is that to save the bytecode, you need to save everything to disk as one
big blob. This leads to significant code duplication and while on the PC platform this is not that big of a deal, on consoles this could lead to problems.
Perhaps Andreas can consider looking into giving us the ability to write bytecode to individual script sections in a module to disk?
I prefer 'one module per entity type', but there is really no one-answer-fits-all. You have to weigh the advantages with each approach against the disadvantages and see what matters the most for your game/application.
Using one module for each entity is definitely not recommended, as each entity would keep its own copy of the bytecode and global variables.
Compiling one module with all the script code is similar to what you do with an ordinary C++ application, and you would have free reign of how different parts of the script code interact with each other. In this case you would likely create a different class for each entity type, where all implement a common interface (much how you would design a C++ application).
Using one module per entity type puts some barriers between entities that must be bridged by the application, for example by implementing a messaging system. However, it really helps you think of the scripts as plugins, where you can very easily replace a single script without impacting the rest of the scripts. Having each entity type in a separate module also helps a lot during development if you implement hot-loading, i.e. the ability to recompile a module without having to restart the entire application.
FYI. I implemented a small sample game, that is available in the SVN (part of the upcoming release). There you can see how I implement 'one module per entity type'.
Using one module for each entity is definitely not recommended, as each entity would keep its own copy of the bytecode and global variables.
Compiling one module with all the script code is similar to what you do with an ordinary C++ application, and you would have free reign of how different parts of the script code interact with each other. In this case you would likely create a different class for each entity type, where all implement a common interface (much how you would design a C++ application).
Using one module per entity type puts some barriers between entities that must be bridged by the application, for example by implementing a messaging system. However, it really helps you think of the scripts as plugins, where you can very easily replace a single script without impacting the rest of the scripts. Having each entity type in a separate module also helps a lot during development if you implement hot-loading, i.e. the ability to recompile a module without having to restart the entire application.
FYI. I implemented a small sample game, that is available in the SVN (part of the upcoming release). There you can see how I implement 'one module per entity type'.
Perhaps Andreas can consider looking into giving us the ability to write bytecode to individual script sections in a module to disk?
You mean like obj files that would then be linked into the final program? It's an interesting thought. I'll put it down on my to-do list for further analysis.
[quote name='_orm_' timestamp='1316456964' post='4863456']Perhaps Andreas can consider looking into giving us the ability to write bytecode to individual script sections in a module to disk?
You mean like obj files that would then be linked into the final program? It's an interesting thought. I'll put it down on my to-do list for further analysis.
[/quote]
Sort of. What I mean is that if we have different script sections that correspond to different files, such as is the case with the CScriptBuilder, you could tell the module to just return the bytecode for that section:
// I can't remember the name of it right now.
CScriptSaver* saver = new CScriptSaver()
module->GetBytecodeForSection("Engine/Actor.ang",saver);
saver->WriteToDisk();
This could let us load individual pre-compiled sections without having to resort to a ginormous binary bytecode blob.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
