OSDev.org

Hi everyone,

I'm working on a game engine at the moment (it's all direct3d, sorry opengl fans) and I've just gotten Python scriptability implemented (via boost::python).

I just have a couple of questions.

What sort of things should I expose to the script that is running (eg. SetEntityPos)?

How should I implement AI? At the moment, I'm thinking of having a(nother) class for an AI bot and have level scripts define locations for each one, and a filename of a script which contains the actual AI behavior?

How do I let a script run concurrently with the rest of the engine?

Thanks in advance.

pcmattman wrote:Hi everyone,

I'm working on a game engine at the moment (it's all direct3d, sorry opengl fans) and I've just gotten Python scriptability implemented (via boost::python).

FLAMEFLAMEFLAMEFLAMEFLAME!!!!!

How should I implement AI? At the moment, I'm thinking of having a(nother) class for an AI bot and have level scripts define locations for each one, and a filename of a script which contains the actual AI behavior?

It depends on what type of game this is. Is it a FPS? RTS? For a FPS a finite-state machine (FSM) is the way forward. Simple to implement and with decent states can exhibit complex behaviour. The AI in HL2 uses a (adapted) FSM.

RTS is more suited to a genetic engine or a learning engine.

How do I let a script run concurrently with the rest of the engine?

Thanks in advance.

This is a pain in the arse. It needs to be run in a seperate thread. However, I don't know if boost::python can be -- I tried it with Scheme (via GNU guile), and it did tons of stack stuff which meant it could only be single-threaded and couldn't do anything cross-threads. Which deadlocked my entire engine. Good luck!

JamesM wrote:

How should I implement AI? At the moment, I'm thinking of having a(nother) class for an AI bot and have level scripts define locations for each one, and a filename of a script which contains the actual AI behavior?

It depends on what type of game this is. Is it a FPS? RTS? For a FPS a finite-state machine (FSM) is the way forward. Simple to implement and with decent states can exhibit complex behaviour. The AI in HL2 uses a (adapted) FSM.

I'll look into FSM - it's an FPS. I'll probably just have a section in the level script (which is an INI file) like this: Is it possible to have event handlers in my python script (eg. onDead) and have the engine call these handlers when needed? Or would I need a script per event?

How do I let a script run concurrently with the rest of the engine?

Thanks in advance.

This is a pain in the arse. It needs to be run in a seperate thread. However, I don't know if boost::python can be -- I tried it with Scheme (via GNU guile), and it did tons of stack stuff which meant it could only be single-threaded and couldn't do anything cross-threads. Which deadlocked my entire engine. Good luck!

I don't need concurrency, it just would be nice to have it available as a fallback in case I need it.

Thanks for the help.

Use threads. Start off by putting rendering in one thread and everything else in another. Then as your engine becomes more complex (e.g. implementing a FSM) give this it's own thread too.

Using threading to your advantage has several advantages;

- If one component is taking it's time (some logic loop) then other threads (e.g. rendering) will still continue to function as always. This is most useful on older computers or if you expect intensive operations (such as loading or progressive messhes) to occur.
- If the computer has multiple processors (duel- and quad-core systems are quiet popular these days) then the OS will be able to distribute the threads among processors and increase overall performanace.

The more modular your game engine is, the more stable it is. For example, if you broke your engine into "modules" each running within their own thread (e.g. input manager, script manager, AI manager, video manager) you could add a "module manager" and a messaging system. The module manager will occasionally "ping" the other modules, and if they do not return a response after a generious time-out period then kill the thread and its module, and restart it (and make a log of the error too for debugging purposes). In a correctly designed system, if for some reason one of the modules stops responding, the module manager will restart it and the user should not notice anything at all, or at worst, a small skip in framerate.

As you can see, we can compare the design of a game engine to that of a micro-kernel in an operating system. Designing a stable game engine borrows a lot of the same concepts and different people swear by different designs. Designing a "good" game engine is a lot harder than people think. Companies are willing to spend hundreds of thousands on a game engine, and if it's going to be distributied on millions of systems world wide, they need be sure that the engine is fast, stable, secure, cross-platform (PS/Xbox/Win/Mac/Linux - DirectX/OpenGL with no changes to soure code and no need for special SDKs other than a compiler/linker and a method of deployment), up-to-date feature-wise, and flexible.