Game
On this page I'll share some progress about my game, which is currently in development from late 2025 and probably to 2031. It's difficult to describe the style and genre of the game right now since it's in a very early stage and things might change and move around.
For now, I'm refining the collision detection system and putting things in place, which allows me to create an ingame level editor. So I can create levels, without touching the codebase.
I must add, that this game is written without any game engine. It's built on Raylib as a high-level graphics, audio, and user input library. So a lot of stuff an engine usually provides, must be implemented by me.
I'm not using a game engine here, because they solve a very broad problem and come with stuff I might not need, thus bloating the project. Additionally they often limit you to a very specific programming language or you have to deal with some sort of FFI.
Lastly: at some point you need access to the source of the engine, to clear assumptions or change things. But then you're involved learning this codebase rather than actually working on your game.
Building the game without a game engine allows me to really tailor the code to specific problems and focus on building the game, without getting roadblocked by code which I have zero experience or knowledge of.
Progress: Collision Detection
Every game needs some sort of collision detection. Depending on the shapes you decide on, it might get more complex. If you build everything around circles/spheres, the collision tests are very, very easy and every computer is capable of calculating those within a very low frame budget.
If you're adding axis-aligned rectangles, it's also quite easy. But what if you want to rotate those rectangles? Well, then you have to do a bit more calculations.
Thankfully, smart people figured this out. Most of the time you get away with the SAT (alternative source). And for even more complex shapes, there's the GJK in combination with the EPA.
In some cases you might need both, but this really depends on the kind of shapes you'll use. The best thing is to keep the shapes as simple as possible.
The book "Real-Time Collision Detection" by Christer Ericson provides good insight about the whole topic.
Screenshots
Now that I talked your ear off, I can provide some visual material. It's not a lot in this stage, since most stuff happens under the hood, but I can show a few things.
Contact Points / Manifolds
The orange circle - in the middle of the screen - with the green and pink spheres, is the player. The green sphere is the direction of the cursor, where the pink sphere indicates the facing direction of the character (East, West, North, South).
Slightly towards north-west from the player there's an orange capsule and a green rotated rectangle. Both are touching each other. That point in between them is called "contact point" or "manifold". A manifold is a data structure which holds information about exactly where the contact point is and the direction of the contact. Which is important later to resolve the collision - for example to apply physical forces.
Down below that, there's a yellow polygon. This is a visual representation of what the collision system "sees". So the edges correspond with the shapes which are colliding. You can see that two of the yellow lines have the same angle as the edges of the colliding shapes.
Multiple Contacts between Different Shapes
The system must be capable of testing collision between different shapes. So here you can see the contact points (white circles) between all of them.
Actual Camera Angle
This is the actual camera angle of how players will experience the world most of the time. The exact angle might vary and will depend on the game mechanics and visuals.
Broad Phase
When testing a lot of objects for collision, you want to filter out objects which are not close together, so you don't waste compute on performing more expensive tests. This is called "Broad Phase". Whereas the "Narrow Phase" corresponds to actually testing the collision, with more expensive algorithms.
The idea is, that you give your shapes a bounding volume (short: BV). A BV is a simpler shape over your complex shape, which is simpler and faster to test.
To determine which object could collide we build a bounding volume hierarchy, which is (mostly) a binary-tree structure. This allows us to eliminate entire groups of objects for which we don't have to test collision.
Mind you, that this technology might not be necessary for every project. It kinda requires some "load" to be really effective. So if you have a lot of static objects and not so much to test, this approach might be overkill.
Broad Phase: Different View
Video
Here's a video (24 MB) which shows the collision system in action - without the broad phase yet.