Soo I've decided to go with Python as scripting language for my "educational game engine".
Reason soo for this is that, if I've understood the docs right, is that I can do things like this;
[source lang="cpp"]
class GameObject
{
public:
void Render() { // Fast Render Code here; }
virtual void HandleMessage(Message msg) = 0;
};
[/source]
[source lang="python"]
class GOExample(GameEngine.GameObject):
def HandleMessage(self, msg):
# Handle message in python
[/source]
But so far the only thing I've got working with using boost.python is this;
[source lang="cpp"]Py_Initialize();
PyRun_SimpleString("print \"hello world\"");
Py_Finalize();[/source]
Where do I go from here? How is a script engine implemented? What is the structure like?
Anyone got any good links, tutorials or books on this topic?
PS: Books - prefer Kindle versions.
Python as a scripting language
For an "educational" game engine, I think it would be proper to write it entirely in Python.
I mean, that's what I would do: Write everything in Python, and then, if there are performance problems, write those pieces in C.
Then you can call those C function from Python, via the ctypes module.
I mean, that's what I would do: Write everything in Python, and then, if there are performance problems, write those pieces in C.
Then you can call those C function from Python, via the ctypes module.
Author
Well, the point here is not to write it in python. The game engine is to be written in C++. But since I got time on my hands this summer I tough it would be fun to implement a scripting language like Python.
Thats why I don't want to write the whole game engine in Python.
Thats why I don't want to write the whole game engine in Python.
What is your game engine for, i.e. what does it do? Bolting a scripting system onto an engine is kind of a directionless thing if you don't have some kind of goal in mind for doing this in the first place. This is the origin of the common admonition to write games, not engines; it's very hard to just randomly slop features together and hope for a good engine to fall out of the soup at the end of the project.
If you can't identify a specific thing that you want scripting to accomplish, don't integrate it.
Really the onus is on you at this point: you need a reason to implement scripting beyond "it sounds cool." Once you have that reason, the steps to accomplishing it should be pretty obvious, in that you'll have a target to work towards and you can start moving towards that goal piece by piece.
If you can't identify a specific thing that you want scripting to accomplish, don't integrate it.
Really the onus is on you at this point: you need a reason to implement scripting beyond "it sounds cool." Once you have that reason, the steps to accomplishing it should be pretty obvious, in that you'll have a target to work towards and you can start moving towards that goal piece by piece.
Author
ApochPiQ:
Well, I believe that some of this comes from my missing wisdom on questions like;
Should the script call be able the call the renderer? How much "low-level" logic should the scripts do?
Well, I believe that some of this comes from my missing wisdom on questions like;
Should the script call be able the call the renderer? How much "low-level" logic should the scripts do?
I'm not sure I was clear; my point isn't that you need to know the details of what scripting would do in your engine, it's that you don't have a purpose for it in the first place. If you have a guiding principle for using a scripting language, the answers to those kind of questions become obvious.
I think you're going at it from the wrong direction, in other words. Instead of asking what your scripting system is going to do, ask what it's for. Why would you want to use a scripting system? And "it sounds like fun" doesn't count. You need an actual, solid, technical reason for doing this or it's just going to be a bloated tacked-on feature that doesn't quite work nicely.
I think you're going at it from the wrong direction, in other words. Instead of asking what your scripting system is going to do, ask what it's for. Why would you want to use a scripting system? And "it sounds like fun" doesn't count. You need an actual, solid, technical reason for doing this or it's just going to be a bloated tacked-on feature that doesn't quite work nicely.
Author
ApochPiQ: Sorry for just bouncing with you on this. But this is what I want my script engine to do.
I want to define components with scripting. These components can then be attached to a entity(game object) in the engine.
That way I can define new components without re-compiling.
How I want this to work?
I got a base class in C++ with virtual methods; render(), update(), onMessage()
These methods should then be overloaded in the script.
I want to define components with scripting. These components can then be attached to a entity(game object) in the engine.
That way I can define new components without re-compiling.
How I want this to work?
I got a base class in C++ with virtual methods; render(), update(), onMessage()
These methods should then be overloaded in the script.
OK, that's a good start! Now you have a guiding principle for how you want your scripts to be used. The rest should follow fairly naturally.
Author
Okey, changed over to AngelScript. And got a basic prototype working. Thanks for the guiding 
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
