Game Jam Framework

Over the past year or so I’ve done several game jams and really enjoyed it; I’ve based each of the games on a simple set of C++ library code I’ve been working on. I’ve kept intending to switch to Unity, but it never ends up happening; truth be told, although I can get a lot more done with Unity, I just have a lot more fun working in plain C++ with my own systems, and each accomplishment just feels so much more earned when I’ve done it more or less from scratch.

To that end, I’ve been working a bit on improving the framework code (‘engine’ is far too generous a word) that I’ve been using for the jams and for other hobby projects, including the GPU Game of Life and Pacman parody projects I’ve posted here, as well as all of my Ludum Dare and Indie Speedrun entries so far.

I’ll post about my progress here occasionally as I work on it. It’s not likely to be hugely interesting–more just a chance to get some thoughts down as I’m working on it. This first post is a summary of what I’ve got so far. Be ye fairly warned: much boring nerdery lies ahead–

My guiding principle in working on this has been to make it as simple and pleasurable as possible for me to write small-to-medium-sized projects; much of what I’ve done has been focused on that goal. There are a lot of things I’ve done that are tremendously inefficient. Some of them I intend to optimize, but others I’ll likely leave as-is for maximum flexibility. After all, the projects I’m creating with this aren’t going to be tremendously complex. Performance is a minimal concern, while ease of development is crucial.

A few of the more notable features:

  • A resource loader front end inspired by XNA’s that’s designed to make it as easy as possible to load resources. The implementation is internally clunky, but the interface makes loading resources into a handle (including reference counting, avoiding duplicate loads, support for resource load parameters like shader macros, etc.) as simple as this:
    auto example_tex = resource::load<texture*>( "textures/example.dds", optional_parameter_blob );
  • Basic 3D support, including a model loader built on top of the Open Asset Import Library, and a basic forward renderer with ambient, point, and directional lights (currently using Mikkelsen’s Torrance-Sparrow implementation).
  • A fast sprite renderer, using texture arrays and structured buffer instancing to blast potentially thousands of sprites onto a frame at high framerates. It’s in the early stages and is missing a lot of functionality, but it’s already really fast. (I know I mentioned I don’t care much about performance, but this is a situation where I thought being able to draw truly extreme numbers of sprites at once could be interesting for a jam. Plus, it was just fun to write.)
  • A basic input wrapper to make reading single keystrokes, held buttons, and mouse movement easy.
  • Simple FMOD wrapper (sound playback, streaming music).
  • A math library wrapping DirectXMath (the XM* functions) in easy-to-use classes (with operating overloading where natural).

A lof of the above still needs some work, and there are some major features on the todo list:

  • Gamepad support using XInput.
  • An input mapping system to map raw keyboard/mouse/gamepad input to in-game actions more naturally.
  • A tiled deferred renderer (ported from another hobby project I did in 2012).
  • Eventually, hopefully integration with Box2D for 2D physics and PhysX for 3D physics.
  • Screen space effect chain (at least HDR/tonemapping/bloom, motion blur, depth-of-field, color grading).
  • Some kind of basic animation support–at least rigid-body animation to start.

My mercurial repository for the engine code is public: http://bitbucket.org/otresnjak/eph-engine. I’ll continue to update it as I add new features. It’s missing the front-end code you need to actually compile/run; I’ll make that repo public as well once it’s a little prettier.