The setup#

To explain the physics engine within the context of game development, there are typically three main components involved in a physics simulation:

1. Static Body: an object that does not move at all, used for floors, non-breakable buildings or non-movable objects (in our example, it would be the walls of the pinball)
2. Dynamic/Rigid Body: an object that moves and collides with all other objects in the physics world via the simulation of forces and momentum (the pinball ball)
3. Kinematic Body: an object that does not react to external forces, albeit pushing dynamic bodies around and is moved via some programming logic (the flippers)

And how was the ball able to trespass the ceiling of the arena? I have a few ideas, and one of them may be my fault, but baby steps.

How the walls were built is important. Each square block is a different static body, placed each aside another in what was supposed to be a pixel perfect combination of collision polygons, making the trespassing impossible - in theory. But the fact is, I did not build a single polygon, there is non-nullable gap between the walls.

The… Oops! Accident#

Here is my deduction, based on my limited knowledge of how physics simulations work, regarding what caused the ball to clip through the wall:

1. The ball casts a ray on the direction of its velocity to check for any obstacle before its movement…
2. … but it targets perfectly the void between the walls. So it finds no obstacle and continue moving.
3. Once it moves inside the gap between the walls, its sphere detects collision with the walls and - as it can’t be inside another object - its plunges itself upwards to respect the laws of physics and not let two bodies occupy the same space at the same time.

A new astronaut ape is launched into the stratosphere.

Bevy#

I’ve started learning Rust intermittently since 2023, and was not able to use it in a meaningful project. But it is a language in my radar to learn for the future. That future could be now if Bevy weren’t so new to the game engine market, as it is still in the early development stage and lacks a built-in physics engine, with breaking API changes occurring frequently.

But the language itself is charming, mixing a modern and sometimes functional approach in a low-level environment, competing with C/C++.

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(Camera2d);

    commands.spawn(Sprite::from_image(
        asset_server.load("branding/bevy_bird_dark.png"),
    ));
}

This code only render a sprite onto the screen. But isn’t it cute?

Defold#

I stumbled across Defold as an alternative to Godot in a Reddit post, I believe. Its highlights are “free forever”, “easy cross-platform” and “production ready”. And it uses Lua, with an embedded code editor!

It has a good amount of tutorials and it seems like a capable engine, but… I have to admit it, I could not force myself into learning this new interface and understand how the scene files linked together and what are its base classes. It is not what I’m looking for at the moment. I want to have fun creating solutions via code, and that’s where our next - and hopeful - last choice comes in.

LÖVE#

First of all, excelent name, but where does it come from? It seems there is no consensus or definitive story. And second of all, strictly speaking, it is not a game engine, it’s a Lua game development framework. But what is the difference?

A game engine provides all the tools for developing a game, usually providing a GUI (graphical user interface) and a set of tools that facilitates the import of assets and the export of the game itself. A framework is just the library that connects the low level operations - like rendering and input handling - to a higher level code (with a Lua script, in our case) or an easier API access. All the other tools and benefits need to be created from scratch.

And I love the challenge of handling everything myself.

The floating-point arithmetic tangent#

This post has been delayed by a couple of days due to a misconception of mine regarding floating-point arithmetic. What was the problem, you ask? Thank you for your interest, let me explain.

If you would like the broader and more complete knowledge on the matter, read the What Every Computer Scientist Should Know About Floating-Point Arithmetic. It has been linked by almost all posts I found on reddit regarding my problem. Have I read it? No. But I understand the problem and found a solution.

local function rotateTo(self, finalAngle, shouldStop)
    local currAngle = self.body:getAngle()
    local isReducing = currAngle > finalAngle
    local signal = isReducing and self.angularVelocity < 0 and 1 or -1

    if shouldStop(currAngle, finalAngle) then
        self.body:setAngularVelocity(0)
        self.body:setAngle(finalAngle)
    else
        self.body:setAngularVelocity(self.angularVelocity * signal)
    end
end

local function shouldStop(currAngle, finalAngle)
    return currAngle >= finalAngle
end

local function shouldStop(currAngle, finalAngle)
    return math.abs(currAngle - finalAngle) < 0.01 or currAngle > finalAngle
end

Next Steps#

Here is the fun and the hard part. The fun part is to experiment on the possibilities of what can I do as pinball elements. The hard part is not to be distracted too much on improving the current code and creating templates for the next - sure to come - game objects and logic.

Also, I have an excuse to play some pinball games as inspiration. Space cadet, here I come!

Thank you for reading! Have a cookie 🍪

See ya next month!