The final year Videogame Middleware module comprised two distinct phases. Firstly, the design and implementation of a middleware component. Secondly, putting together a short Gamebryo game experience leveraging as many middleware components as possible.
Through this process I was able to gain insight into the challenges facing both middleware providers and integrators.
Build Phase
I chose to design and implement an input abstraction layer called HInput. The primary purpose of HInput is to decouple game/application code from specific input implementations. For example, rather than checking whether a gamepad button is down, or a key was pressed, we just query whether a named input was satisfied without needing to know how exactly it was implemented. This extra layer of abstraction gives us the flexibility to:
- Change input schemes without code changes or recompilation.
- Dynamically switch between input schemes at runtime (e.g. we might choose to load a new scheme if we detect that a gamepad was connected). We can mix and match schemes, and different player can use different schemes. All this is completely transparent to the game code.
- Using input metadata, it is possible to allow dynamic configuration of the system at runtime (which is how the HInput Editor works).
HInput also has various layers of complexity in its interface:
- The simplest way of interacting with the system is through the Editor application (written in C#).
- The InputManager singleton [HInput::GetManager()] provides everything you need to use an input configuration to provide input to your game.
- Advanced users can write custom Inputs, InputDeviceServices, and plugins that can be loaded dynamically at runtime, as well as custom GUIs using the InputMetaData stored in the system.
Full source code and compiled distributions of HInput, complete with documentation, example projects and editor application and plugins for keyboard and gamepad are available from Sourceforge. For an overview of the system, please read Getting Started with HInput.
Leverage Phase
In the leverage phase I chose to build a tongue-in-cheek action RPG style demo based on the Gamebryo ‘Kinslayer’ sanple, called ‘Kinslayer-Ville’.
Conversations are all voiced at runtime using Microsoft SAPI. There is also voice recognition to choose conversation options. The Environmentz day/night cycle skydome is supplemented by CIELO clouds. Inventory is with Happy Sacks. LibCT provides the conversations and QuickQuest provides the quest log. Input is through my own HInput input abstraction layer. The opening cinematic is powered by Cinesigner, while FMOD Ex provides 3D positional sound.
