Project Aftermath

Co-founder & Lead Programmer·2008·2 people·3 min read

A PAX10-winning arcade RTS shipped by a two-person studio on an engine built from scratch — DirectX, C++03 and Lua, with the tools to author it.

Overview

Project Aftermath is a squad-based arcade RTS: four squads, RPG-style progression, and over a hundred weapons, armour and augmentations to equip them with. It was built at Games Faction by two people, on a proprietary 3D engine and toolchain written for the purpose, and won the PAX10 in 2008.

Problem

A two-person studio building a real-time strategy game has a content problem before it has a technology problem. RTS is a genre that eats content — units, weapons, abilities, levels — and there was no third party to produce it and no engine to produce it with. Whatever got built had to make one programmer and one designer productive enough to fill a commercial game.

Constraints

  • Two people, total — engine, tools, content and business
  • No existing engine; commercial middleware was out of reach for a studio this size
  • Real-time strategy: a content-hungry genre for a team with no content pipeline
  • Windows and Steam as the target

Approach

Build the engine and the authoring tools as one effort rather than two, and put Lua between the engine and the game so that design iteration never required a programmer or a rebuild. Then scope the design deliberately to the arcade end of RTS, where depth comes from squad composition and progression rather than from base building and unit sprawl.

Key Decisions

Proprietary DirectX/C++03 engine with Lua as the content layer

Reasoning:

The engine was the smaller half of the problem. Exposing gameplay, unit stats, abilities and progression through Lua meant the designer could iterate on the hundred-plus items and their balance without touching C++ or waiting on a build. For a two-person team that ratio decides whether the game ships.

Alternatives considered:
  • Commercial middleware licence
  • Hard-coded gameplay in C++ with data tables

Arcade RTS rather than a full base-building RTS

Reasoning:

Base building multiplies the content and AI surface enormously. Commanding four squads with deep equipment and progression put the design's depth somewhere two people could actually build and balance, and differentiated it in a genre dominated by much larger productions.

Alternatives considered:
  • Conventional base-building RTS
  • Turn-based tactics, cheaper to build but a smaller market

Build the tools alongside the engine, not after it

Reasoning:

Tooling deferred is tooling never written, and a two-person studio has no slack to absorb a bad content workflow. Treating the editor as a deliverable rather than an internal convenience is what made the content volume achievable.

Alternatives considered:
  • Text and config files with no visual tooling
  • Adapt a third-party level editor

Tech Stack

  • C++03
  • DirectX
  • Lua
  • Proprietary engine

Result & Impact

  • PAX10, 2008
    Award
  • 2
    Team size

Shipped on Windows and Steam and selected for the PAX10 — the ten titles picked from that year's independent submissions. The engine and toolchain built for it went on to carry further Games Faction titles, which is the return that justified writing it in the first place.

Learnings

  • On a very small team the engine is not the hard part — the content pipeline is, and it deserves the same design effort
  • A scripting boundary between engine and gameplay is worth its cost the moment iteration count matters more than raw performance
  • Scoping the design to the team is a technical decision as much as a creative one
All projects