The Community Bonding Period is nearly over, so I would like to take this opportunity to describe the plan I have for the comming couple of weeks.
HDB consists of a set of subsystems that necessary for the levels to work. According to my timeline, I will be dedicating the first week exclusively to building out these subsystems. As described in the hdb.h file, a few of the subsystems are:
- MSDFile: Functions for MSD files
- Game: Main Class that manages the top-level game state
- Draw: Draw Class – needs to implemented using the Graphics API
- Memory: Keeps a track of all the memory being used by the engine
- Map: Loads Maps, Tiles, Characters and other Entities and draws them
- LuaGame
- LuaGlue
- Input: Manages user input
- Menu: The Menu System – the first target after the subsystems have been implemented
From the above description, we can see that certain subsystems like Menu and Game will need to fully implemented, whereas it might be possible to write subsystems like Input as extensions of the ScummVM API. I’ll need to study the ScummVM API a bit more before I can be certain about this.
Application Entry Point
In the original source code, the main hdb file served as the application entry point. Broadly speaking, they serve three functions:
- Include all the required header files at a common place
- Setup Global Variables and Game System Objects for each subsystem
- Drawing the window and initializing the Game subsystem
In order to avoid creating a large amount of global variables in ScummVM, I’ll be replacing the Game System Objects with Singleton classes and each one will be initialized in the hdb files. Also since ScummVM handles the GUI and application entry point by itself, I think it shouldn’t be necessary to implement the window drawing code.
Subsystems
Starting with the Input subsystem: it keeps a track of which if any buttons have been pressed or if the mouse has been clicked, when to update the set of pressed buttons, the minimum time-delay between button presses and defines which physical button corresponds to which logical input.
One thing that is of particular interest here is how one subsystem affects another. Most of the methods defined on the Input Class first check what state the game. So if the game is in the middle of a cinematic, or an NPC interaction, it reacts differently.
However, if the AI subsystem hasn’t been developed yet, it cannot react to it. I intend to build subsystems incrementally, so I will not build features that depend on a particular subsystem until that subsystem has been implemented. This will increase the frequency with which I can test the code.
The Memory subsystem manages all the allocated memory-chucks in a linked list. I’m not entirely certain yet whether to implement this, or let each subsystem manage its own memory.
The LuaGame subsystem defines how the various Lua functions that are used in the .MSM files, and the LuaGlue subsystem interfaces between the C++ and Lua code. I am not as comfortable with Lua as I am with C++ right now, so I would like to test it a bit before moving forward. Also, since HDB is written using Lua 4, I will have to find/write a compatibility file.
Objectives
- Setup the Lua Compatibility File and figure how to properly interface Lua with C++.
- Increase my knowledge of the ScummVM API.
- Plan out how the remaining subsystems will be implemented.
I have started making small additions to the HDB project that I created before the Community Bonding Period started, but these are mostly small changes to test out the ScummVM API.