[back]

Clap: a 3D game engine in C

linux-build www-build macos-build windows-build

What is Clap?

Clap is a lightweight multiplatform 3D game engine that aims to “do more with less”, meaning procedurally generating/postprocessing things that it can, instead of purely relying on static assets (not that you can’t utilize a static asset pipeline with it). The name comes from the koan (probably) that posits the question – what is the sound of a clap with one hand, and I needed a word that starts with a “C”, because it’s written in C. Yes, I’m aware of the colloquial meaning of clap.

Clap exists for 5 years now, though with dormant stretches -— the longest being over a year. Most recently, it powered a full game jam title in Ludum Dare 57, the entirety of which lives in demo/ldjam57 of the main repository.

Clap takes care of:

More detailed and technical feature list should be somewhere on the v0 release page.

Clap runs on Linux, Mac OS X (arm64, x86), Windows x64 and in a browser. That last one is especially important: the WASM/”HTML5” build is not an afterthought, but a first-class citizen, and (maybe having to cut corners here and there) will remain such.

Show me!

Right here is a live demo of our Ludum Dare 57 game. And a whole lot more live demos and executables. There are a few screenshots at the bottom of the page; more screenshots here and a whole youtube video:

Watch the video

So, C?

Yes, it’s written in C. There are several reasons for this:

One could say that it’s also the most portable language, but technically, C++ till take the cake there. Some platforms, while having a C compiler, lack the most rudimentary C library, so one has to compensate. And when I say “it’s in C”, I mean C23 with GNU extensions, in other words, it builds with modern GCC and Clang. Porting it to a platform that’s locked on C89 will probably require pre-processing by some kind of a custom sparse-based uglifier.

Yes, I’d very much like to have closures and maybe function overloading, but then I’d be forced to make use of other C++ features, STL etc. Better enums, pattern matching are sure cool, but from this distance they seem similar to a fully realtime raytraced reflection on the surface of a counter in “Oh Deer Diner”: cool for about 30 seconds, but then you need to get on with things and it becomes completely irrelevant.

But Rust!

Nope. I’ll be done with the game logic while a Rust programmer is still proving to the borrow checker that he’s not a potato. Eloquent counterarguments like “skill issue” are all addressed in this excellent writeup. If you happen to be a competent Rust programmer and a game developer, I tip my hat in your general direction (while keeping its mutable reference to myself). All the power to you!

Having said that

There’s obviously GLSL and cmake, which for better or worse are programming languages. Objective C is very much in the cards. Besides that, Clap leans heavily on ODE, ImGui (via cimgui), meshoptimizer, which are all written in C++. Most of them provide a C API, though. And no, there is no promise that in the future bits of C++ won’t emerge.

Why is Clap?

The reason it started was my fondness for “Breath of the Wild” (the wait for its sequel at that point was already bordering on ridiculous) and curiosity as to what it would take to make tech that can do that, but without the benefit of having hundreds of developers. I went into it completely clueless. Today, I am aware of all the things that are missing from Clap to make it BoTW-worthy. And at the same time, the priorities have shifted. I played other games since.

Today, Clap exists for

The roadmap, such as it is, is shaped with these design principles in mind.

Besides being educational, it has the enormous advantage of giving me complete control of every aspect of the engine when we’re, for example, gamejammin’. And it’s also ridiculously fun.

How to Clap?

The easiest way is always to dive right in, grab one of the demos and start tinkering. There’s a CONTRIBUTING document that covers the basics. The basic idea is to write code that’s self-evident and doesn’t require comments, which tend to go out of sync with reality. That said, using comments is encouraged —- as is adding them to existing code, which can also be a good way to learn the system.

API

There’s no API of the kind that one would expect of a library, as of this moment. This will change. This is not a top priority right now, because there are perfectly workable ways of getting your code to link with Clap, either by adding your game to demo/ directory and having all the benefits of all the includes, compiler flags, linker flags etc for free, or you can add Clap as a submodule to your game and have more or less the same level of convenience.

The API that is there is in a permanent state of flux. This is very unlikely to change. Every time you fetch a new version, you’ll likely have to fix up some things. Kind of like ImGui keeps its users on their toes by breaking its API between minor releases every few weeks. It’s completely normal. Every time this happens, it’s an opportunity to learn something new.

Versioning and release process

There are no good versioning schemes in existence. Some are better than others, often due to how they tie in with the release process. Therefore, I went with the simplest thing: versions that increase monotonically from v0 ad infinitum. There may be occasional version-looking tags, like v0-pre1: these are not versions or releases; their purpose is to mark a milestone in development, for example: this is where we are going into the next game jam.

There is no release process: features and bugfixes can be added at any time. A sufficient amount of new features since the previous release may trigger a release. A standalone fix for a monumental engine breaking / retina scorching bug may trigger a release. It took 5 years to get to v0. The next one may be next month.

If you like weird and wonderful things

v0 release

Screenshots

(basename f) (basename f) (basename f) Screenshot gallery

[back]