I’m embedding Python into my game. The scripts will be used to define the character AI, how entities react to game events, etc — this means there’s going to be a script for every type of entity in the game.
Each script will have a function like createEntity() or something which will return the constructed entity. What would be an efficient(ish) way of calling these functions (remember, there’s one in every entity’s script).
My initial thought was to do something like what you see below, however, I’m unsure as to how efficient this is. For example, what happens with the imported hero module after I run that string? Does it remain loaded in the main module? If that’s the case, that’s problematic since I’m going to be importing lots of scripts for all the entities I might need to add to the game world.
boost::python::handle<> result(
PyRun_String("import hero\n" "createEntity()\n",
Py_file_input, main_namespace.ptr(), main_namespace.ptr())
);
// Then extract the entity from `result`...
What suggestions do you have?
Your question does not specify whether space efficiency (i.e. memory), time efficiency, or labor efficiency is most important to you. Merely because you are considering a hybrid C++ / Python application, I assume that labor efficiency is a significant factor. Because you are developing a game, I assume that there will be some part of it that has a need for extremely tight execution speed.
Perhaps this approach will strike a balance. Make all the user interaction (input and output, including any networking) C++ based for minimum latency. You might place this in its own thread or process. Given a high level event from the model, like a character moving, this code very quickly updates the screen and the network. Given a user event, or an event from the network, it sends a message to the model.
The game model, which can be asynchronous to the view/control, would then be in Python for your convenience and so you can take advantage of functional programming etc. You could use shared memory or a similar IPC mechanism between the two and start them separately if actually embedding an interpreter is inconvenient.
While certain AI applications are CPU-intensive, and therefore it may be tempting to go back to C or C++ for them, I would advise doing that as a final step, in response to clear responsiveness issues in interpreted code, if you do it at all. You may even want to follow this line of thought with the graphics also, since nowadays most graphics processing is delegated to the video hardware, if you have a way to make the library calls you need from Python code.
Though I am not a game developer, I have been around and I have seen few situations in which the (nowadays) microseconds difference between single equivalent C and Python operations is perceptible to users. Perceptible performance problems are nearly always due to other factors, such as disk I/O, network latency or inefficient algorithm implementations.