One Game a Month

Published on 2018-03-08.

I recently committed to submitting to One Game a Month for the remainder of 2018, beginning in March. I’ve been interested in partipating in jams for a long time. More recently, the idea of using constraints to intentionally restrict the scope of my projects has become appealing. This fits naturally with the time limits for jams [1].

I’m not completely new to the idea of developing graphical games and simulations. I’ve worked on a few projects in this area. From memory:

  • When I first decided to develop software professionally, I started learning C++ by attempting a Gauntlet-style dungeon crawler (SFML, C++, circa 2010).

  • I learned the value of using engines as aids to speed development (I would learn their value as reference material much later). I programmed a game called Equilibria for the now-defunct indie team AntEye Games. The project was never completed (orx [2], C++, 2011-2012).

  • I started a text-only game in C where you are a convenience store manager with all the responsibilities that accompany it (ncurses, C++, 2016).

  • I got interested in rendering and started a software 2d/3d renderer supporting wireframe geometry rendering and orthographic projection (SDL, C).

You might notice a trend toward both more abstract ideas and lower-level technical interests.

I’ve started probably 10-20 other less personally significant game-like projects.

It feels like it has taken many years and twice as many unfinished projects for experience and skill to come together well enough to potentially finish some things, so here we are with a proclamation of commitment and a new blog to chronicle the journey.

Here are my personal 2018 jamming rules.

  • No third-party engines. It didn’t occur to me to evaluate game engine choices this time. Instead, I opted to create my own engine to support these projects. This decision puts interesting constraints on freedom of choice; when I want a feature that doesn’t exist yet, I must either develop it and spend less time on the jam idea, or sacrifice it and make the jam idea work without that feature. Constraints aside, each feature added is a learning experience.

  • Only Free software is allowed in the development environment. Note that “free” as used here does not mean gratis and has nothing to do with monetary cost, but rather refers to the freedoms granted to the user by the software’s license(s). This decision is for political/idealogical reasons.

The current toolset for engine development is Arch Linux, neovim, Python 3, SDL2, and OpenGL. Game-specific tools are gimp for image editing and tiled for map editing. This list will change as development continues. Third-party tools will be added, and will also be removed as internal tools are developed.

These posts will document both the engine and the game creation process. I hope what I learn might both be helpful to others and be another interesting point of reflection for 2019 Me.