Python Scripting

deathsong12 · 2014 Aug 11

A friend and I are looking at the Doomsday Engine as the basis for some stuff we're playing with, and we'd like to be able to do some scripting in Python. We've had success embedding the interpreter in other engines in the past, but looking at Doomsday's modular architecture, we're not entirely sure where Python would best fit. Should we confine it to our game plugin, or would we be better off extending libcore?

DaniJ · 2014 Aug 11

Doomsday has it's own built-in scripting language called Doomsday Script, which has a few similarities with Python. (Note that the wiki is a little out of date, as for 1.15 we are introducing a system for weakly-typed OO inheritance.) Doomsday Script is interwoven with the Doomsday architecture itself, providing immediate access to things like the engine's definition database. I would strongly urge you to consider this rather than attempt to bind another scripting language (like Python).

You might want to give the interactive script console a try:
- open the taskbar
- click the > button on the far left
- enable Doomsday Script

deathsong12 · 2014 Aug 11

DaniJ wrote:

Doomsday has it's own built-in scripting language called Doomsday Script, which has a few similarities with Python.

Our motivation for using Python in this case is to gain access to Python's overwhelming library support. Reinventing the wheel is a bad idea, I understand, so perhaps we could expose Doomsday Script or its functionality to Python?

DaniJ wrote:

Doomsday Script is interwoven with the Doomsday architecture itself, providing immediate access to things like the engine's definition database. I would strongly urge you to consider this rather than attempt to bind another scripting language (like Python).

I will strongly consider it. If the documentation is out of date, even a brief overview of what's currently possible with this scripting will be very helpful. We're looking first and foremost to replicate map-level scripting like ACS, which I understand that Doomsday Script can easily do. Looking through the documentation and the proposal, these features are mentioned but never demonstrated. I'll look at the examples provided with the source and do my best to figure things out.

skyjake · 2014 Aug 11

deathsong12 wrote:

Our motivation for using Python in this case is to gain access to Python's overwhelming library support. Reinventing the wheel is a bad idea, I understand, so perhaps we could expose Doomsday Script or its functionality to Python?

To provide some background, I chose to implement a custom scripting engine in Doomsday so that it can be integrated fully and seamlessly with the rest of the engine with minimal overhead. For example, one key component is the de::Record class from libcore that acts in several key roles in the engine nowadays. Also, we are free to modify the syntax of the language to suit our needs. While we approach version 2.0, scripting is further being integrated elsewhere in the engine subsystems (Tracker issue #1608).

Please note that Doomsday Script is far from finished — I'm developing it further as needed based on where it is being integrated in the engine. One practical thing to note is also that it has very little in the way of optimization in the runtime: several operations do things less efficiently than they should (unneeded copies of values, etc.). Compared to Python with it years of optimization, this is a definite downside.

If the documentation is out of date, even a brief overview of what's currently possible with this scripting will be very helpful.

The best place for an overview of the features of the language is the kitchen_sink.de script in the tests/test_script app.

At runtime, with the console in Script mode, you can use the dir() command to get a list of all the currently provided built-in modules (because they are automatically imported into the console's process):

$ dir()
=&gt; &#91; App, Config, Core, Defs, DisplayMode, Input, Path, SavedSession, Style, Version,
    __file__ &#93;
$ Version
=&gt; BUILD:   1318
   CPU_BITS:64
   DEBUG:   True
   OS:      macx
   STABLE:  False
   TEXT:    2.0.0 (Dev) Build 1318
   VERSION: &#91; 2, 0, 0, 1318 &#93;

The packages net.dengine.stdlib and net.dengine.stdlib.gui contain the (very small) Doomsday Script standard library as it exists today.

We're looking first and foremost to replicate map-level scripting like ACS, which I understand that Doomsday Script can easily do.

Map-level scripting is already in our plans and its called "XG 2.0". (XG 1.0 was/is Doomsday's old way of "scripting" what functionality lines and sectors have in maps.) I see map-level scripting as a very valuable feature, so any help provided in this area would be quite welcome. In practice, I see the following tasks need doing:

Creating bindings for all the necessary map operations, e.g. spawning mobjs and manipulating sectors, controlling music and playing sounds.
Adding a Record owned by Map that gets saved to savegames, so that map state variables etc. can be kept here.
Adding a game session level Record for storing state variables for the current game. Also needs to be in savegames.
Manipulating existing mobjs in the map: I've recently already added a Record for each mobj, where one can store mobj-specific variables and functions. This should derive from a Game.Object class of some sort (that doesn't yet exist) that contains script functions for manipulating the mobj via scripts. (A similar mechanism is used to access files from scripts, using the built-in Core.File class.)
In the native game code, triggering script functions in specific situations like when a mobj gets damage, crosses a line, hits a wall, triggers a switch, etc.
The scripts for a game or a map need to be stored somewhere. This could be a traditional WAD lump or (more preferably) part of the package metadata that contains the map.
For XG 2: implementing a library of line and sector types using scripts.

I am happy to assist in any way if you wish to implement some of these features.

Python Scripting

Comments