01. Design
The Alben engine is a means to play boardgames over the net.
The engine is a 2D application, that is, the game map and counters/cards are seen from above.
A module is a specific implementation of a boardgame.
The developer of a module uploads a module so that others may download it to play a specific game on the game engine.
An important design goal is to make the engine flexible enough to develop a large range of games. The module developer must have the means to change any visual and functional aspect to make a specific game.
An equally important design goal is to make running a module safe. A module developer must not be allowed by mistake or design to read/write the host file system in any way.
The Alben engine makes use of Lua to give the module developer the freedom to change any visual and functional aspect. A module is nothing more than a Lua script.
To allow this a sandboxed version of Lua is necessary. I have found that Luau provides such a sandbox.
Lua does not provide GUI functionality. Such functionality must be added as exposed C functions to Luau. This ensures that it is the game engine that does the actual calls to the GUI library in a safe way.
The game engine will be written in part C++/C and in part Luau.
The C++/C part will be everything the module designer can not change. This includes to compile and load of the module script, core utilities like communication with the server, loading and saving games, throwing dice and the UNDO functionality. And it will contain the actual calls to a GUI library.
The Luau part will consist of templates for maps/counters/cards and their attributes. The templates can be changed by the module developer. The Luau part will also provide game-state functionality, i.e. a representation of the game that is independent of its visual representation. This is used for UNDO functionality and may also be use to develop an AI opponent.
A sketch of the engine and a module is given below. Note that the module and engine overlap.
A module will be both new script made by the module developer and script provided by the engine. The difference between the two is hazy because everything can in principle be changed.
For simple modules hardly anything more should be needed than a specification of maps and counters/cards. The game engine must provide a set of defaults that make developing modules easy.
There is no 'meta-language' for specifying maps, grids, counters, attributes and so on. The module is the script itself. This simplifies the design but it also demands scripting knowledge and good documentation on how components are made.
It must be possible to have a short loop between changing the script and seeing the result. This will ease module development.
I have made a simple C++ program that does a few interesting things. First it creates a Luau state (or virtual machine). Then it compiles and loads the script of a very simple module. Then it exposes a C function called window() that creates an application window using GTK. Then it starts the execution of the script. Finally it calls a function in the script which in turn calls window() and starts the GUI event loop.
Compile/link (in my environment):
CPLUS_INCLUDE_PATH=/usr/include/gtk-3.0:/usr/include/glib-2.0:/usr/lib/x86_64-linux-gnu/glib-2.0/include:/usr/include/pango-1.0:/usr/include/harfbuzz:/usr/include/cairo:/usr/include/gdk-pixbuf-2.0:/usr/include/atk-1.0;export CPLUS_INCLUDE_PATH
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu;export LD_LIBRARY_PATH
g++ -Wall -o test test.cpp -L/home/me/luau/build/release -lluauvm -lluaucompiler -lluauast -lisocline -lgtk-3 -lgio-2.0 -lgobject-2.0