Home / Minor / Core Engine / Developing the public API

Developing the public API

Posted on

Public API == Boring API

The public API has to be light weight, easy to use and most of all it should be a very expandable system. However, it is also something that is not that much effort to create nor too interesting to build. As my horribly UML diagram skills will proof in the following diagram! 😀

Lua Engine
Figure 1. The Lua engine design.

The idea for the working of the API on the engine side is simple:

  1. Module creates instance of LuaLibrary.
  2. Module obtains LuaEngine instance from core engine.
  3. Module calls LuaEngine::loadLibrary() on obtained instance supplying created instance of LuaLibrary.
  4. LuaEngine calls LuaLibrary::load() on supplied instance.
  5. LuaLibrary assigns it’s libraries and functions to LuaEngine.

Boring boring and more boring…

The final bit of the LuaLibraries is slightly less boring then the header might suggest, but remain nothing too special. As the Lua engine has been designed to run asynchronous to avoid Lua blocking too much when for example performing a simple sleep. This however poses an issue for modules that require a function to be called in lua… The latter is possible through a simple queing system, however putting such a system in LuaEngine itself, would not be very extendable, and therefore not too feasable…

The solution is simple though! As all it takes is giving the individual LuaLibraries this responsibility for themselves, this simply requires a function in the lua engine main loop that ticks all libraries when the lua engine ticks (Not equal to the game engine tick as asynchronous!) to let the LuaLibrary now that it can now safely work its magic (See my horrible UML skills in figure 2! 🙂 ).

lua engine
Figure 2. The Lua engine tick.

 

Top