BounceEngine
27 Apr 2021Introducing: Bounce
My last game engine, geas petered out after a while. I was dissatisfied with the ‘feel’ of the game, and wasn’t a fan of the way many things were implemented. I felt primarily there was a lot of bugs, and it wasn’t very ‘tight’. I got bogged down with unimportant refactoring and I spent too much time on tooling. There was also a growing issue - I was blurring the line between game engine (a reusable library enabling game creating) and the game itself.
All that qualitative non-sense boils down, mostly, to poor management on my part of the project. So I took some time out.
Here we are 4 months since my last commit to geas, with a new project. I’m re-creating the engine, from scratch. This resulted in Bounce - a 2D game engine written in C++17 using OpenGL for rendering.
Physics
I started by writing the physics engine, I wanted it to be both flexible with regards to shape and accurate in terms of real-world physics. I developed a system where objects were defined by mathematical functions. In this way, the closest point between objects could be found very simply by minimising the distance between the functions.
The result, is quite satisfying.
This worked for collision between continuous functions. However, a rectangle was formed by four line functions and collisions commonly form on a corner - this was an edge case that proved difficult to sort and the functions were scrapped in favour of meshes.
Mesh Collision
A mesh - a collection of N 2d coordinates forming a shape - was used to calculate collisions by interpolating between points on the mesh to determine collision location. However, this proved slow and unscalable owing to the large number of points necessary to represent circles.
Heterogeneous Collision
I wanted to avoid mixing different methods for collision - like having a mesh collider for describing some shapes and functions for others. This heterogeneous approach could work really well - but it would add complexity. I’m not re-creating existing tools like Unity. The goal here is to keep things tight - I am going to avoid adding extraneous features that could be done without.
Its all circles? Always has been.
Circle collisions are the absolute easiest thing - the distance between surfaces is simple centre to centre distance less the sum of the radii. This is a fast and easy method for collision detection.
This method is not without limitations - if everything is a circle then moving along a flat surface is not possible (without approximating the surface with an obscene number of circles). Thus, this method is not suitable for platformers. Perfect for space shooters though and that’s good enough for now.
Bolting on some UI, and mucking about with fragment shaders results in some interesting patterns…
Stop messing about, where’s the code?
The code is on my github.
Questions? Comments? Get in touch on Twitter!