This is a custom game engine in active development by a team of four. I’m the lead programmer, with a focus on rendering and overall engine structure. The goal is to build an engine capable of shipping a fully functional 2D multiplayer fighting game from the ground up.

This devlog may end up not covering the most fun parts of development, and could go down paths unrelated to actual progress, but it will always focus on the aspects of development that interest me.

Devlog #2 — But what is the game?

May 25th, 2025

I am not core to the gameplay design, or art direction of the project (at least for now until we get closer to implementing game logic). However, I will give a bit of information so this devlog is not completely unrelated to the game itself.

The idea is to make a 2D fighting game. A fighting game was chosen because two of the project members are fully immersed in and essentially only play fighting games. Fighting games, at the most basic level, are not too complex, especially in 2D. They have simple movement and physics and allow you to focus on making unique gameplay elements. Additionally, if we get swamped in development, there is the option to exist on a LAN only level. If you commit to making an FPS game, you have to be fully prepared for a massive amount of networking logic, or the game will never be played. I.e. fighting game players are hardcore, and will find and play your game if it is good.

The art and gameplay is currently centered around a Cyberpunk theme that will tie into the gameplay mechanics (not leaking anything this early on). The running title is Terminal Zero (subject to change). The goal is to make a game with similar base mechanics to Guilty Gear Xrd with style influences from Studio Trigger (Kill la Kill) and the illustrator Lam.

Here is a very early character sketch from our illustrator to give you a taste:

Devlog #1 — A Rant on Build Systems

May 13th, 2025

First things first for the project was getting a build system setup. I’ve been using premake with ninja as my go-to build system setup for a while. Lua is really easy to work with as a config format and I have never needed the features more complex tools offer. However, for this project, I ran into issues that could not be ignored.

To work with ninja, I use a premake add-on to generate the files. Most of the time this was fine, but with this project I needed it to work for other developers and across multiple platforms (against the wishes of most hardcore programmers, I have become an apple laptop enjoyer as I needed access to SwiftUI for a different project). The ninja add-on has many file generation issues that I have encountered before and manually worked around on other projects but I finally decided enough was enough. I searched around for a while but I really disliked the aesthetics of meson, cmake, and bazel. None of them have great readability. Then I discovered that Xmake exists, and is literally just premake but better. Highly recommend. I ditched ninja to use it (although you can still use it if you want) and found no noticable performance differences and now all my building and running could be handled directly through xmake.

For example, this is the xmake section of my config for compiling GLFW. It is super easy to read, and is essentially just an english representation of the library structure. I don’t need a needlessly complex build system making my development harder than it already is. There are definitely cases where complexity is needed, but not in this case.

target "GLFW"
	set_kind "static"
	add_headerfiles {
		"./vendor/glfw/include/GLFW/glfw3.h",
		"./vendor/glfw/include/GLFW/glfw3native.h",
		"./vendor/glfw/src/*.h"
	}
	add_files {
		"./vendor/glfw/src/*.c",
	}

	if is_plat("macosx") then
		add_defines "_GLFW_COCOA"
		add_files "./vendor/glfw/src/*.m"
		add_mxflags "-fno-objc-arc"
		add_frameworks {
			"Cocoa",
			"CoreFoundation",
			"IOKit",
			"QuartzCore"
		}
	elseif is_plat("windows") then
		add_defines {
			"_GLFW_WIN32",
			"_CRT_SECURE_NO_WARNINGS"
		}
		add_links "gdi32"
	end

Another thing that concerns me when setting up a projects build is the structure of third-party dependencies. I am of the belief that a project should compile itself, and all dependencies from top to bottom. I don’t want a build setup that includes the cmake files shipped with that dependency or the xmake feature that allows you to just “magically” include a dependency by name. This obfuscates what is actually being built to make your project work. With Rust, or Go, they have beautiful mandatory systems to handle these compilation issues but in the lawless land of C++ you should know exactly what is happening inside your codebase.