sketches of a game engine - mostly reflections on object orientation and how to structure different components of the engine
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
cmake/Modules
examples/Minimal
hephaestus-lib
CMakeLists.txt
Makefile
README.md

README.md

Hephaestus Library

My design goal for the Hephaestus library was to create a set of loosely coupled or even independent components rather than developing a large, monolithic game engine. One the one hand the library is supposed to provide toolkit classes and functions for general common operations with a high degree of reusability; on the other hand there are components which do not provide much functionality in themselves, but define a template for how the game classes should be organised.

Big words for a small library, I know. But these were initially my thoughts when I started working on this project. The library in its current form is far from complete, but it is usuable (see Examples below).

Design Fundamentals.

Much of the design philosophy behind Hephaestus lib follows Gold's great book about object-oriented game development and even some components follow very closely the concrete design ideas laid out in his book. A good example is the sound resource management. The following dependency graph illustrates how various components contribute functionality to the subsystem.

A Bundle is an interface for managing collections of game data files (sounds, textures, ...). The only implementation of the Bundle interface (currently) provided by the library is the (development friendly) DirectoryBundle which implements a Bundle is the files contained in a given directory. Bundles can be attached to a file server which manages a queue of load Requests for specific Resources. Loading the actual bytes into memory, which describe a resource, can be done by components which are agnostic of the concrete type of the Resource (here FileServer / Bundle ), instantiating the Resource however requires information about the type of resource (a texture resource needs to be uploaded to the GPU, while a sound resource might go into a sound buffer on the sound card). This information is passed into the FileServer via the LoaderFactory which produces Loader that contain exactly this resource-specific information. Templating the Resource, ResourceManager and Loader classes allow for adaption to specific resource type while allowing a large amount of code reuse. The SoundManager manages in addition to Sound resources SoundInstances which describe (resource-counting!) uses of specific sounds in parts of the game. Concrete implementation are provided for the OpenAL sound library as OpenALSounds (short sound effects which are completely contained in a single sound buffer) and OpenALStreams where large OGGs are partly decompressed on-the-fly and streamed into a set of interchanging sound buffers.

Examples.

SuperAsteroids

SuperAsteroids is my take on the classic 1979 arcade space shooter. The asteroid is actually read in as an SVG and breaks into randomly generated pieces when struck with a laser beam, allowing the player to shoot them “to vertices”.

Some gameplay footage of me failing horribly at my own game can be seen here.

Night & Day

Night & Day is a sketch of a puzzle platformer inspired by Sparpweed’s amazing game. Hephaestus engine uses internally Erin Catto’s Box2D as a physics simulator engine.

Some gameplay footage can be seen here.

Dependencies.

The following libraries are needed to successfully compile the project

References.

Ideas from the following references contributed substantially to the development of the library