Procedural Levels
Every LFoM level is generated on the fly at mission start. Each level is configured by a series of TOML structures. TOML documents can be designed with embedded JavaScript. When the level is initialized: the TOML + JS document is preprocessed with EJS. The result is a clean TOML document which can be further processed and fed to the server runtime environment.
The key advantage of this system is that we can design procedural levels that are different each playthrough while also keeping the server runtime configuration system static.
Choices
When making a game you are faced with a nearly unending sequence of choices. Every choice branches off into more. In this blog we'll talk about some of the choices that were made while building LFoM.
The web browser is the target platform for LFoM. The game will not be ported to other platforms. We care about near perfect support for keyboard, mouse, touch screens, and all screen sizes. For minimum hardware spec: we test on an iPhone SE 3rd gen, and a Galaxy A23. We test Firefox, Chrome, and Safari browsers.
Why web browsers? Freedom and choice for both the developer and consumer. In the year 2026: the web browser is a very capable platform and we believe it is underutilized for gaming.
Visuals matter a lot, but they don't have to. When making a game you must pick your battles: we care about crisp particle effects, gore, physics, and sound effects. Everything else can take a back seat.
Technology matters a lot, but it doesn't have to, and it doesn't matter at all if the game isn't fun. The game's technology choices are rooted in the idea that if we give ourselves the option to write performant code, we will always have a path to implement the features we care about.
When choosing a technology for a game you can decide to use a game engine, and you can decide not to use one and instead rely on smaller, less opinionated software libraries. LFoM took the latter choice. 60% of our source code is written in C: an Emscripten compiled WASM front end app, and an LLVM server side runtime which has a few POSIX dependencies and C99 features. The graphics pipeline is built on top of SDL2. The audio engine is built on top of the AudioContext API.
SDL2 is a great piece of software that is widely used, but using it for graphics rendering is not ideal for LFoM. It will be phased out.
Fully dynamic light sources will land before the project hits beta. SDL2 will need to be swapped out beforehand. It's not clear what will replace SDL2. SDL3? maybe, something else? maybe.
Last Fight on Mars is undergoing active development. The game will begin open alpha testing later this month.
Alpha can mean different things to different games. For LFoM alpha means a few things:
- Incomplete lighting system
- Placeholder art
- Incomplete level design system
- Missing language translations and accessibility features
- Missing gameplay modes, achievements
- Some visual glitches and other minor bugs