Gamedev on despatches

Building Pong with Zig and Raylib #6: Font Size, Collision Bugs, and Refactors

Sat, 19 Jul 2025 08:00:00 +0100

In this one, we’ll tidy up our Pong implementation by addressing three key issues:

The score font is too small
The ball can get stuck inside a paddle
Trigger score on edge (not the middle) of the ball going past.

We’ll also refactor score tracking to better match game logic structure.

🖋️ Make the Score Font More Readable

The score text was a little too small. If you’re using dvui, here’s how to adjust it:

```zig const font_size: f32 = 64; var label_options: dvui.Options = .{ .color_text = .white, .font_style = .title, }; label_options.font = label_options.fontGet().resize(font_size); dvui.label(@src(), "{d}", .{score}, label_options); ```

Thanks to code sample from milogreg

You may also need to adjust the width and height of the container if the larger font gets clipped. In our case, font size of 64 felt about right.

🧱 Fix the Ball Getting Stuck in the Paddle

When the ball moves too far in one frame, it can land inside the paddle and bounce back and forth infinitely.

This trap happens because we just multiply the x-velocity with -1 to reverse direction.

One way to fix this is to only trigger the bounce if the ball is moving toward the paddle. For example:

```zig const crossing_x = switch (self.which) { .right => ball.vel.x > 0 and ball.pos.x + ball.r >= self.pos.x, .left => ball.vel.x < 0 and ball.pos.x - ball.r <= self.pos.x + size.x, }; ```

Thanks again to code sample from milogreg

This ensures we don’t apply the bounce logic when the ball is already inside the paddle.

Another (potential) way to fix this would be to change the collision logic to fix the x direction based on whether it’s the left or right paddle.

🧮 Trigger a Score When the Ball’s Edge Crosses the Screen

Previously, we checked whether the ball’s center (ball.x) crossed the screen edge. Particularly with the ball being bigger than the paddle, this caused issues when the top/bottom of the paddle hit the ball.

Game.zig

```zig if (self.ball.pos.x + self.ball.r > self.screen_width) { self.left_score += 1; self.ball.reset(); } if (self.ball.pos.x < self.ball.r) { self.right_score += 1; self.ball.reset(); } ```

This triggers the score as soon as the edge of the ball crosses the screen bounds.

🔄 Refactor: Move Scores Out of the Paddle Struct

Storing the score inside the Paddle struct is convenient but semantically odd

paddles shouldn’t own scores. Instead, let’s move them into your Game struct:

Then, pass the score explicitly to the rendering function.

You can find the updated code in Game.zig.

✅ Bonus Fix: Make Score Display Use Paddle Play Area

We now compute each paddle’s play area (a dvui.Rect) and use it to position the score label, keeping layout logic more re-usable.

We add a play_area field or method to our Paddle struct that returns its side of the screen. This makes the rendering logic clearer and more flexible.

⏭️ What’s Next?

Next episode: adding a pause menu to Pong, based on what I just built for my other game, triangle. We’ll add basic Resume/Quit options and freeze game state mid-play.

Escape to Menu

Tue, 15 Jul 2025 17:12:46 +0100

One of the key bits of functionality I want in a sprout build is the pause menu.

After a bit of working it out, I ended up with this plan:

Until now, hitting Escape would just exit the game immediately. Not ideal. triangle needed a proper menu: something that pauses the game, gives players a chance to resume or quit intentionally, and maybe even shows a bit of useful info.

So that’s what I’ve been building. The menu now:

Pops up when Escape is pressed (as long as no panels are open).
Pauses the game,
Shows a few buttons: Resume, Quit, Contact, and Config Path

Ordering

At first, I was a bit confused as to why I was not able to see the menu. I was under the (mistaken) impression that dvui would always draw last.

Once I switched things around to always draw dvui at the end, I could see the menu.

Pause/Resume

Since we use the frame time to determine how much time has passed, pausing was simply a case of setting that time elapsed to zero.

In fact, it skips the update call altogether. One thing I noticed while I was doing that was that the camera movement code happened in render. While there is a particular logic to that, it’ll need to be moved to update (later), at which point, render will also not require the elapsed time.

Resume was simply a case of letting “time flow” again.

Logging

I thought logging might be useful — but writing to file or supporting runtime filtering requires a custom log handler. While it’s probably doable, I didn’t want to dive into it just yet. For now, I’ve left it out entirely. Maybe a separate debug build is the better option anyway.

Contact

I set up a form at tally.so and ChatGPT helped me write a tiny bit of code that opens a browser to that form.

I’ve not tested this on Mac/Windows and would appreciate any feedback (when a sprout build is available.)

Quit

We now have a quit button that will quit the game. The game will also currently quit if you hit q. I’ll unmap this later.

Config path

The config location is also displayed. The path can be selected and copied - so that the player can navigate there easier to be able to override controls etc.

Final

While perhaps not as pretty as the sketch (credit is more to tldraw than me), it is functional.

Next steps are to get a dialog working with some basic information, including a changelog and possibly a roadmap.

Building Pong with Zig and Raylib #5: Show Score with dvui

Tue, 15 Jul 2025 08:00:00 +0100

In this episode, I finally add a score display to Pong using DVUI, a native Zig UI framework. The scoring logic was already in place - now it’s time to show it on screen.

Extract out `Game` struct

One of the structural changes I wanted to make to tidy up the code was to pull out the game logic into its own struct. This change helps to declutter the main.zig file, leading the way to add in the dvui scaffolding.

This refactor pulls the update and render logic into a Game struct, which helps declutter main.zig and sets up a better foundation for UI work.

Game.zig

```zig pub fn update(self: *Game, dt: f32) void { self.ball.checkEdgeCollisions(self.screen_height); self.ball.update(dt); self.ball.checkPaddleCollision(&self.left_paddle); self.ball.checkPaddleCollision(&self.right_paddle); if (self.ball.pos.x > self.screen_width) { self.left_paddle.score += 1; std.debug.print("scores: l: {d}, r: {d}\n", .{ self.left_paddle.score, self.right_paddle.score }); self.ball.reset(); } if (self.ball.pos.x < 0) { self.right_paddle.score += 1; std.debug.print("scores: l: {d}, r: {d}\n", .{ self.left_paddle.score, self.right_paddle.score }); self.ball.reset(); } if (rl.isKeyDown(.w)) { self.left_paddle.moveUp(dt); } if (rl.isKeyDown(.s)) { self.left_paddle.moveDown(dt); } if (rl.isKeyDown(.e)) { self.right_paddle.moveUp(dt); } if (rl.isKeyDown(.d)) { self.right_paddle.moveDown(dt); } } pub fn render(self: *const Game) void { self.left_paddle.render(); self.right_paddle.render(); self.ball.render(); showScore(self.screen_width * 0.25, self.left_paddle.score); showScore(self.screen_width * 0.75, self.right_paddle.score); } ```

Add dvui dependency

Let’s fetch the dependency, adding it to build.zig.zon:

zig fetch --save git+https://github.com/david-vanderson/dvui.git

Then, in build.zig, we also need to declare it:

```zig const dvui_dep = b.dependency("dvui", .{ .target = target, .optimize = optimize, }); const dvui = dvui_dep.module("dvui_raylib"); ```

and then add it as a dependency:

```zig exe.root_module.addImport("dvui", dvui); ```

Add `dvui` to game loop

We also need to initialise dvui in the main loop.

main.zig

Import

```zig const dvui = @import("dvui"); const RaylibBackend = dvui.backend; comptime { std.debug.assert(@hasDecl(RaylibBackend, "RaylibBackend")); } const ray = RaylibBackend.c; ```

Initialise

```zig var gpa: std.heap.GeneralPurposeAllocator(.{}) = .init; const allocator = gpa.allocator(); defer _ = gpa.deinit(); //-------------------------------------------------------------------------- // init Raylib backend // init() means the app owns the window (and must call CloseWindow itself) var backend = RaylibBackend.init(allocator); defer backend.deinit(); backend.log_events = true; // init dvui Window (maps onto a single OS window) // OS window is managed by raylib, not dvui var win = try dvui.Window.init(@src(), allocator, backend.backend(), .{}); defer win.deinit(); ```

Pre-render

```zig // marks the beginning of a frame for dvui, can call dvui functions after this try win.begin(std.time.nanoTimestamp()); // send all Raylib events to dvui for processing _ = try backend.addAllEvents(&win); ```

Post-render

```zig _ = try win.end(.{}); // cursor management if (win.cursorRequestedFloating()) |cursor| { // cursor is over floating window, dvui sets it backend.setCursor(cursor); } else { // cursor should be handled by application backend.setCursor(.arrow); } ```

Show Score

We can now show the score using dvui.label with positioning hardcoded to about 25% and 75% across the screen. There may be a better way to position it but it works well enough for now.

I had to generate an id for the label so that they were unique. I generated it the x-position using @intFromFloat().

Game.zig

```zig pub fn render(self: *const Game) void { self.left_paddle.render(); self.right_paddle.render(); self.ball.render(); showScore(self.screen_width * 0.25, self.left_paddle.score); showScore(self.screen_width * 0.75, self.right_paddle.score); } fn showScore(xpos: f32, score: u8) void { const id: usize = @intFromFloat(xpos); var right = dvui.box(@src(), .horizontal, .{ .rect = .{ .x = xpos, .y = 50, .w = 50, .h = 50 }, .id_extra = id }); defer right.deinit(); dvui.label(@src(), "{d}", .{score}, .{ .color_text = .white, .font_style = .title }); } ```

Closing

As always, things took a bit longer than expected, but by the end:

The game’s structure is cleaner
DVUI is wired up properly
Scores now show up on screen

Shoutout to milo_greg on ziggit.dev for loads of really valuable feedback and tips. That kind of thoughtful review really helps.

Building Pong with Zig and Raylib - Part 4: Smarter Collisions, Cleaner Code

Thu, 10 Jul 2025 15:33:34 +0100

Change of Plans

I was going to dive into menus and UI, but after sharing the early version of Pong on ziggit.dev, I got a bunch of helpful feedback. The feedback was the kind that makes you stop and think, ah, right… I should probably fix that before carrying on.

So that’s what this episode became: a collection of fixes, tweaks, and small refactors that clean up the code and align things more closely with how things should be done in Zig (or at least, better than I had them before).

🧼 Naming Matters

I’d originally named my files paddle.zig and ball.zig - lowercase, snake-case. I had tried to find the guidelines around this, but turns out I only got half the story. If a file implicitly defines a struct via top-level fields, it should be named in PascalCase. So, Paddle.zig, not paddle.zig.

It’s a small thing, but one that helps be a bit more idiomatic - and avoids confusion when others are reading it.

(now to make the same change across many more files in triangle)

🛠️ Default Field Initializers (and When Not to Use Them)

Another thing I learned: structs that aren’t used as config objects shouldn’t use default field values. Instead, they should have an init constant that represents their starting state.

I’d missed this distinction, and both of my types were using default values incorrectly. So I cleaned that up and added the values into the init method. It’s a subtle change, but it keeps config objects and plain data objects conceptually separate - and makes it clearer which parts of a struct are supposed to be overridden.

✨ RLS, Please

One of the comments suggested I lean more into Zig’s Result Location Syntax - where you define the type on the left-hand side and let Zig figure out the rest.

I’d been using a mix of styles. Nothing broke, but consistency helps. So I swept through the code and updated those as well.

```zig //main.zig var left_paddle: Paddle = .init(Paddle.size.x * 0.5, .left, screen_height); var right_paddle: Paddle = .init(screen_width - Paddle.size.x * 1.5, .right, screen_height); var ball: Ball = .init(.{ .x = screen_width * 0.5, .y = screen_height * 0.5 }); ```

🎯 Fixing Paddle Collisions on the Y Axis

Now for something more visible: my collision detection logic only checked the center point of the ball along the y-axis. That meant if the ball clipped the paddle at the edge, it was sneaking through.

The fix was simple: add/subtract the ball’s radius in the y-axis check. Much better.

```zig const colliding = ball.pos.y + ball.r >= self.pos.y and ball.pos.y - ball.r <= self.pos.y + size.y; ```

You can actually see the difference in-game - that satisfying little thock now triggers when it should, even on corner hits.

(now I just need add some sounds - I’d forgotten about that)

🧽 `isColliding` Should Only Collide

Previously, isColliding also handled coloring the paddle red when it detected a hit - a debug leftover that had no place in the final function.

I stripped that out and left isColliding to do just one thing: return whether there was a collision. If I want debug visuals again later, I’ll wrap this in another function.

```zig // Paddle.zig pub fn isColliding(self: *const Paddle, ball: *const Ball) bool { // which edge do we need to check const crossing_x: bool = switch (self.which) { .right => ball.pos.x + ball.r >= self.pos.x, .left => ball.pos.x - ball.r <= self.pos.x + size.x, }; if (!crossing_x) { return false; } const colliding = ball.pos.y + ball.r >= self.pos.y and ball.pos.y - ball.r <= self.pos.y + size.y; return colliding; } ```

🔀 Movement Logic Encapsulation

Paddle movement was scattered, and the logic for moving up/down lived inside main.zig. I pulled that out into proper moveUp and moveDown methods on Paddle.

It reads cleaner now:

```zig //Paddle.zig pub fn moveUp(self: *Paddle, dt: f32) void { self.move(-100, dt); } pub fn moveDown(self: *Paddle, dt: f32) void { self.move(100, dt); } ``` ```zig // main.zig if (rl.isKeyDown(.w)) { left_paddle.moveUp(dt); } if (rl.isKeyDown(.s)) { left_paddle.moveDown(dt); } if (rl.isKeyDown(.e)) { right_paddle.moveUp(dt); } if (rl.isKeyDown(.d)) { right_paddle.moveDown(dt); } ```

…and it keeps the input logic in main, but the movement logic in the paddle - where it belongs.

📐 Resolution Independence

Some values were hardcoded (like setting y = 200 for paddle start position), while others used getScreenHeight() and getScreenWidth(). I refactored to make everything use actual screen dimensions, converting i32 screen height values to f32 where needed.

It was a bit fiddly, but worth it. Now Pong should behave properly regardless of window size.

Closing

So, yeah - not the flashiest episode, but a satisfying one. Lots of small things that feel better now that they’re fixed. And it’s a reminder that sharing early (even rough work) is usually a good idea. You never know what you’ll learn.

Next time, we will get into UI. I’m planning to bring in DVUI and show a basic score display, a pause menu, and maybe some options for reset and quit.

Until then, thanks for reading (and watching) - see you in the next one.

Building Pong in Zig with Raylib – Part 3: Edge Collisions, Scoring & Player Input

Mon, 07 Jul 2025 12:01:00 +0100

In this part, we round out the core gameplay of our Pong clone in Zig using raylib. By the end, we’ve got a working game - with a bouncing ball, paddle controls, and basic scoring.

🧱 Edge Collisions

We already had paddle collision working, but we needed the ball to bounce off the top and bottom edges of the screen. That meant checking if the ball’s y-position was outside the visible range and inverting its vertical velocity accordingly:

```zig pub fn checkEdgeCollisions(self: *Ball, screen_height: f32) void { if (self.pos.y < self.r or self.pos.y > screen_height - self.r) { self.vel.y *= -1; } } ```

There was a small detour where I realised screen_height wasn’t giving the expected value - using GetScreenHeight() directly from raylib helped resolve that.

🏁 Scoring System

Once edge collisions were in place, it was time to detect goals. If the ball passed the left or right edge of the screen, the opposing player got a point. We also need a reset() method to the Ball struct to return it to the centre after each goal.

```zig pub fn reset(self: *Ball) void { self.pos = self.home; self.vel = .{ .x = 250, .y = -50 }; } ```

For now, let’s print the scores via std.debug.print, but this sets the stage for UI integration.

```zig if (ball.pos.x > screenWidth) { left_paddle.score += 1; std.debug.print("scores: l: {d}, r: {d}", .{ left_paddle.score, right_paddle.score }); ball.reset(); } if (ball.pos.x < 0) { right_paddle.score += 1; std.debug.print("scores: l: {d}, r: {d}", .{ left_paddle.score, right_paddle.score }); ball.reset(); } ```

⌨️ Player Input

Finally, we wired up keyboard input to allow paddle movement. We used IsKeyDown from raylib, and made sure movement was frame-rate independent by scaling it with dt:

```zig pub fn move(self: *Paddle, y: f32, dt: f32) void { self.pos.y += y * dt; } ```

Left paddle uses W/S, right paddle uses E/D. Simple and responsive.

```zig if (rl.isKeyDown(.w)) { left_paddle.move(-100, dt); } if (rl.isKeyDown(.s)) { left_paddle.move(100, dt); } if (rl.isKeyDown(.e)) { right_paddle.move(-100, dt); } if (rl.isKeyDown(.d)) { right_paddle.move(100, dt); } ```

✅ What’s Working

By the end of this episode, we’ve got:

Ball bounces off top and bottom edges
Scoring when the ball passes a paddle
Ball reset after each goal
Both paddles are fully controllable

All that’s missing now is a visible score, a win condition, and maybe a simple menu.

Building Pong in Zig with Raylib – Part 2: Ball Movement & Paddle Collisions

Fri, 04 Jul 2025 12:01:00 +0100

In Part 1 we set up the basics: a window, paddles, and a ball. In this episode, we go one step further and get the ball moving 😉, add paddle collisions, and make everything frame-rate independent.

Ball Movement

The first step was to give the ball some velocity and update its position every frame.

```zig self.pos = rl.math.vector2Add(self.pos, self.vel); ```

We also fixed a small oversight: the ball and paddles were being recreated every frame inside the game loop. Moving their initialization outside meant we could actually observe state changes between frames.

Frame-Rate Independence

Raylib provides GetFrameTime() which returns the time in seconds since the last frame. Multiplying the velocity by this dt value ensures that the ball movement stays consistent across different frame rates:

```zig const vel_this_frame = rl.math.vector2Scale(self.vel, dt); self.pos = rl.math.vector2Add(self.pos, vel_this_frame); ```

With that, the ball now moves at a steady speed, no matter the frame rate.

Paddle Collision (X-Axis)

Next up: detecting collisions between the ball and paddles. I considered writing a standalone collision checker, but ended up keeping the logic within the Paddle struct itself.

To simplify which edge to check (left or right), I added a which field to paddles - an enum with values left and right. That made the conditional logic much cleaner.

To debug collisions, I added color switching: when a paddle detects a collision on the x-axis, it flashes red.

```zig pub fn isColliding(self: *Paddle, ball: *const Ball) bool { // which edge do we need to check const crossing_x: bool = switch (self.which) { .right => ball.pos.x + ball.r >= self.pos.x, .left => ball.pos.x - ball.r <= self.pos.x + size.x, }; self.colour = if (crossing_x) .red else .white; return crossing_x; } ```

Paddle Collision (Y-Axis)

After confirming horizontal collision detection, I added vertical bounds checking. This just involved verifying the ball’s y-position is within the paddle’s vertical range.

```zig pub fn isColliding(self: *Paddle, ball: *const Ball) bool { // which edge do we need to check const crossing_x: bool = switch (self.which) { .right => ball.pos.x + ball.r >= self.pos.x, .left => ball.pos.x - ball.r <= self.pos.x + size.x, }; if (!crossing_x) { self.colour = .white; return false; } const colliding = ball.pos.y >= self.pos.y and ball.pos.y <= self.pos.y + size.y; self.colour = if (colliding) .red else .white; return colliding; } ```

Bounce Logic

With detection in place, we added bounce logic to the ball. If a collision with a paddle is detected, we flip the x-component of the velocity vector:

```zig pub fn checkPaddleCollision(self: *Ball, paddle: *Paddle) void { if (paddle.isColliding(self)) { self.vel = rl.math.vector2Scale(self.vel, -1); } } ```

What’s Next

That wraps up part 2. In the next episode, we’ll handle edge collisions (top and bottom), scoring, and input management.

Thanks for following along!

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Sat, 28 Jun 2025 20:38:29 +0100

Before continuing development on Triangle - my larger, arcade ARPG, factory game, I wanted to take a step back and build something small and familiar. Pong felt like the perfect choice: quick to prototype, easy to understand, and a good warm-up before diving deeper into raylib again.

This post goes alongside my video on YouTube, and walks through the early steps of the project: setting up the game, getting something on screen, and implementing the paddles and the ball.

Why Pong?

Sometimes, before getting deeper into a project, it helps to do something simple just to get your hands moving again. I hadn’t written Zig in a couple of weeks, and wanted a fast feedback loop to:

Get back into using raylib-zig
Have a bit of fun
Remind myself why I made certain decisions in the first place

Project Setup

I’m using raylib-zig for this. You can scaffold a new project with:

```bash ./project_setup.sh ```

You could also use zig init and then add the dependency in manually if you prefer.

Drawing the Playground

The Pong “arena” is simple:

Two paddles
A ball (currently static)
A center dividing line
Placeholder for scores

Implementing Paddles

The paddles have:

A position (top-left corner)
A fixed size
A simple render function

```zig const std = @import("std"); const rl = @import("raylib"); const Paddle = @This(); pos: rl.Vector2, pub fn init(x: f32) Paddle { return .{ .pos = .{ .x = x, .y = 200, } }; } pub const size = rl.Vector2{ .x = 25, .y = 100 }; pub fn render(self: Paddle) void { rl.drawRectangleV(self.pos, size, .white); } ```

It might have been nice to be able to have the paddle calculate more of its own values, but the more I think about it, the more it makes sense to keep the logic in paddle simpler.

Ball Placeholder

To wrap things up for this session, I added a static ball in the center of the screen. It has a radius, position, and velocity fields ready to go. Rendering is straightforward:

```zig const std = @import("std"); const rl = @import("raylib"); const Ball = @This(); pos: rl.Vector2, r: f32 = 16, vel: rl.Vector2 = .{ .x = 0, .y = 0 }, pub fn render(self: Ball) void { rl.drawCircleV(self.pos, self.r, .white); } ```

What’s Next

This was mostly about warming up, but the next episode will tackle:

Adding velocity to the ball
Basic collision detection with paddles

I’ll try and think about simplifying paddle logic, especially the awkward symmetry between left and right.

You can find the full source code on GitHub.

See you in part 2!

Under the Hood of triangle

Fri, 27 Jun 2025 08:01:28 +0100

In this Let’s Code video on shri codes, I walk through some of the early systems in place for Triangle - my space ARPG built in Zig with raylib.

For the broader story behind the project - what Triangle is, where it’s going, and why I’m making it - check out the triangle endeavour or the devlog archive. This post is about the how.

🧩 Core Systems So Far

At this stage, Triangle supports:

Basic player movement and shooting (Asteroids-style).
Procedurally generated asteroid fields per sector.
Material drops (iron ore) from destroyed asteroids.
Automatic recipe unlocking when new items are picked up.
Smelting system that converts ore to ingots.
Unlocking and queuing up constructors using the crafting menu.
A basic UI for crafting and inventory.
Configurable keyboard mappings using TOML.

That’s the visible layer. Below the surface, the codebase has carved out some space for more ambitious systems.

🗂️ Code Structure Overview

Here’s a quick tour of the key directories and their purpose:

`blit/`

Handles all the 2D rendering abstractions - bounding boxes, shapes (including triangle fans 😉 and circles), and canvas drawing. Wraps raylib for better namespacing and type control.

`phys/`

Physics system. body.zig implements basic movement, collisions, and inertia. Still minimal, but usable.

`combat/`

Still early - only bullet is implemented, and is used to destroy asteroids. Placeholder for upcoming systems like health, damage, and targeting.

`items/`

This module forms the backbone of the crafting system. Items are tied to recipes, and recipes are triggered via pickups or crafting actions. There’s a lot more to unpack here - likely its own devlog soon.

`notifier/`

Manages in-game UI feedback. When you pick something up or unlock a new recipe, this is what shows it. Notifiers are scoped - one for inventory, one for crafting - and show up on either side of the screen.

`ship/`

This module contains the ship related logic, including movement, and the logic for constructing smelters and other buildables. Eventually this will handle assembly chains.

`asteroid`

These files should be refactored into its own module, and should contain the asteroid itself, as well as sector, a chunk of space - asteroids, entities, bullets, etc. This is the closest thing to a “level” in Triangle. It’s procedurally generated, and you can eventually travel from one sector to the next.

`diag/`

Code to support diagnostics & logging

`game/`

This module should get a bit of refactoring as well, moving some of the files from the root into its own module

config: Takes care of user control bindings and input overrides via a TOML config file.
notifier: supports collecting notifications across multiple channels.
save: Just scaffolding for now - no save/load logic yet, but it’s a placeholder to group serializable components together.
context: container struct to support dependency injection.

`ui/`

Holds in-game panels like crafting and inventory. Needs cleanup and consolidation.

🧪 What’s Missing

A lot of the systems are stubbed out, but not yet wired in. For instance:

power is empty (future energy system)
The canvas currently wraps raylib without adding much - that will likely change as UI complexity grows.

🧶 Threads I’ll Pull Next

These are the next things I’ll either build or record:

Improving the coding structure. I’d like to improve organisation and am considering extracting a re-usable library out of it, mainly so I can tinker with other smaller game projects.
A rudimentary menu system
A build+deploy system to generate early test builds
Possibly a contact/feedback form directly in-game or on the site

I’ll be releasing this in what I’m calling a “Sprout” build - a playable seed, a form of extremely early access. Feedback and collaboration is really important to me and I want to get this out there as soon as there is the tiniest spark of “life.”

If you’d like to follow the journey, you can watch the video devlog

[UE4] Unreal Engine & miniupnp

Sun, 28 Feb 2016 10:11:15 +0000

This post covers how to integrate pnp into an unreal project using miniupnp.

The first step is to clone the project from github

The module that we are interested in is the miniupnpc and in that directory, there is another directory called msvc and this contains the solution file for Visual Studio. Open this and if you have a more recent version of visual studio (which very likely do), it will want to upgrade everything. Let it go through the upgrade process.

Building the project now will most likely fail due to a missing file miniupnpcstrings.h . This file needs to be generated and the way to do that is to run a script in that folder called updateminiupnpstrings.sh. You will most probably need something like cygwin to for this script to work as it a unix shell to work

Once the miniupnpcstrings.h has been generated, we also need to follow some instructions for Unreal Engine for Linking Static Libraries Using The Build System, particularly the section on customizations for targeting UE4 modules.

From the project properties page, choose configuration manager. From the Active Solutions Platform, select new and type in or select x64 and save it. You have to do this for only one of the projects.

Building of the static project will fail since it can’t find the lib which is now in x64Release as opposed to just Release. The exe is not required for integrating with Unreal Engine, but if you want to complete the build, just fix the path in Project Properties -> Linker -> Input.

You should choose the release build instead of the debug build and you should now be able to build the solution from visual studio. It did pop up some warnings for me, but the build completed successfully.

The rest of the instructions are from the unreal engine documentation about integrating static libraries, starting from section about Third Party Directory

[UE4] Source Control

Tue, 15 Dec 2015 10:35:17 +0000

As with any software project, it is important to use some form of source control solution. For most software projects, there are a number of good solutions out there. However, in the world of game development, most of these are not viable since they won’t handle binary files very well, and unreal engine (as most games) will have a large amount of binary resources.

Perforce is a good tool for small teams since it is free for teams with less than 20 developers.

Another thing that can be confusing is what files/folders to add into the source control. Generally, we do not want to include any files which can be auto-generated (e.g. builds) or are transient (e.g. logs). You should generally include the following folders into source control

Config
Content
Intermediate/ProjectFiles/.vcxproj\* (the .vcxproj.user file may not be relevant if there are multiple developers)
Source
.sln
/.uproject

I found it odd that the project file is in the intermediate folder since one wouldn’t intuitively think to include it in source control

[UE4] Intellisense Errors and USTRUCT

Mon, 16 Feb 2015 16:55:32 +0000

The Intellisense feature of Visual Studio, while useful is quite different from the compiler and on occassion produces false positive errors. According to the document about Setting Up Visual Studio for UE4, this can happen for few possible reason

The IntelliSense compiler (EDG) is more strict than the MSVC compiler.

Some #defines are setup differently for IntelliSense than when building normally.

C++ compiled by IntelliSense is always treated as 32-bit.

However, there is also the case where the Intellisense is just plain wrong. USTRUCT() structures are just such a case. You will find that Intellisense complains about definitions with the structures defined as USTRUCT.

This may not be a big deal, except for the fact these fales positives makes it difficult to spot actual errors and I like to see a clean workspace with no errors (not even false positives). Fortunately, there is a workaround. You can include the USTRUCT definitions only if it is not being compiled by Intellisense.

Fortunately, it is just the GENERATED_USTRUCT_BODY() line that is the culprit. To get these errors to go away, instead of that single line, use the following

```c++ #ifndef __INTELLISENSE__ /* Eliminating erroneous Intellisense Squigglies */ GENERATED_USTRUCT_BODY() #endif ```

That’ll make those pesky squiggly lines to disappear and give you a nice clean workspace :-D

[UE4] Getting Sprint to work (C++)

Sun, 25 Jan 2015 13:29:21 +0000

Getting Shift to sprint in the Unreal Engine 4 is very easy. There are technically two ways of doing it.

Change the scale down to say 0.5 and then increase it to 1.0 for sprinting
Change the MaxWalkSpeed for walking and sprinting.

I prefer the second technique because it will keep the code simple enough and continue to function as expected with analog controllers.

Lets start by adding the input action bindings

Edit -> Project Settings -> Input -> Bindings and add an action for Sprint with Left Shift for the key.

All the code is in the Character class.

Within the header file, there are two blueprint variables for the WalkSpeed and SprintSpeed so they can be modified easily.

We also override the BeginPlay() Method. This is used to default to Walking.

Add the following to your character header file

```cpp /* The speed at which the character will be walking */ UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Character) uint16 WalkSpeed; /*_ The speed at which the character will be sprinting */ UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = Character) uint16 SprintSpeed; virtual void BeginPlay(); protected: /* Enables Sprinting for the character */ void EnableSprint(); /* Disables Sprinting again */ void DisableSprint(); ```

Add the following to the constructor so we have defaults

```cpp AMyCharacter::AMyCharacter(const FObjectInitializer& ObjectInitializer) : Super(ObjectInitializer) { // Other code // Set the default Defaults ;-) WalkSpeed = 250; SprintSpeed = 600; } ```

Plug in the Sprint action to the methods by adding the following lines into the SetupPlayerInputComponent method:

```cpp InputComponent->BindAction("Sprint", IE_Pressed, this, &AMyCharacter::EnableSprint); InputComponent->BindAction("Sprint", IE_Released, this, &AMyCharacter::DisableSprint); ```

And implement the rest of the methods

```cpp void AVSCharacter::BeginPlay() { // Ensure the player starts with Walking DisableSprint(); } void AVSCharacter::EnableSprint() { CharacterMovement->MaxWalkSpeed = SprintSpeed; GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Black, TEXT("Sprintin")); } void AVSCharacter::DisableSprint() { CharacterMovement->MaxWalkSpeed = WalkSpeed; GEngine->AddOnScreenDebugMessage(-1, 5.f, FColor::Black, TEXT("Walkin")); } ```

[UE4] Getting Multiplayer Player Pawn AI Navigation to work (C++)

Mon, 25 Aug 2014 15:52:34 +0000

Unreal Engine is an awesome piece of technology making it easy to do almost anything you might want.

When using the Top Down view however, there is a hurdle to get over when trying to get multiplayer to work. This is a C++ project solution to this problem based on a BluePrints solution.

The basic problem stems from the fact that

“SimpleMoveToLocation was never intended to be used in a network environment. It’s simple after all ;) Currently there’s no dedicated engine way of making player pawn follow a path. " (from the same page)

To be able to get a working version of SimpleMoveToLocation, we need to do the following:

Create a proxy player class (BP_WarriorProxy is BP solution)
Set the proxy class as the default player controller class
Move the camera to the proxy (Since the actual player class is on the server, we can’t put a camera on it to display on the client)

The BP solution talks about four classes - our counterparts are as follows:

BP_WarriorProxy: ADemoPlayerProxy
BP_WarriorController: ADemoPlayerController (Auto-created when creating a c++ top down project)
BP_Warrior: ADemoCharacter (Auto-created when creating a C++ top down project)
BP_WarriorAI: AAIController - we have no reason to subclass it.

So, from a standard c++ top down project, the only class we need to add is the ADemoPlayerProxy - so go ahead and do that first.

The first thing we’ll do is rewire the ADemoGameMode class to initialise the proxy class instead of the default MyCharacter Blueprint.

```c ADemoGameMode::ADemoGameMode(const class FPostConstructInitializeProperties& PCIP) : Super(PCIP) { // use our custom PlayerController class PlayerControllerClass = ADemoPlayerController::StaticClass(); // set default pawn class to our Blueprinted character /_ static ConstructorHelpers::FClassFinder PlayerPawnBPClass(TEXT("/Game/Blueprints/MyCharacter")); if (PlayerPawnBPClass.Class != NULL) { DefaultPawnClass = PlayerPawnBPClass.Class; } DefaultPawnClass = ADemoPlayerProxy::StaticClass(); } ```

Our Player Proxy class declaration

```cpp /* This class will work as a proxy on the client - tracking the movements of the real Character on the server side and sending back controls. */ UCLASS() class Demo_API ADemoPlayerProxy : public APawn { GENERATED_UCLASS_BODY() /** Top down camera */ UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Camera) TSubobjectPtr TopDownCameraComponent; /* Camera boom positioning the camera above the character */ UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Camera) TSubobjectPtr CameraBoom; // Needed so we can pick up the class in the constructor and spawn it elsewhere TSubclassOf CharacterClass; // Pointer to the actual character. We replicate it so we know its //location for the camera on the client UPROPERTY(Replicated) ADemoCharacter* Character; // The AI Controller we will use to auto-navigate the player AAIController\* PlayerAI; // We spawn the real player character and other such elements here virtual void BeginPlay() override; // Use do keep this actor in sync with the real one void Tick(float DeltaTime); // Used by the controller to get moving to work void MoveToLocation(const ADemoPlayerController* controller, const FVector& vector); }; ```

and the definition:

```cpp #include "Demo.h" #include "DemoCharacter.h" #include "AIController.h" #include "DemoPlayerProxy.h" #include "UnrealNetwork.h" ADemoPlayerProxy::ADemoPlayerProxy(const class FPostConstructInitializeProperties& PCIP) : Super(PCIP) { // Don't rotate character to camera direction bUseControllerRotationPitch = false; bUseControllerRotationYaw = false; bUseControllerRotationRoll = false; // It seems that without a RootComponent, we can't place the Actual Character easily TSubobjectPtr TouchCapsule = PCIP.CreateDefaultSubobject(this, TEXT("dummy")); TouchCapsule->InitCapsuleSize(1.0f, 1.0f); TouchCapsule->SetCollisionEnabled(ECollisionEnabled::NoCollision); TouchCapsule->SetCollisionResponseToAllChannels(ECR_Ignore); RootComponent = TouchCapsule; // Create a camera boom... CameraBoom = PCIP.CreateDefaultSubobject(this, TEXT("CameraBoom")); CameraBoom->AttachTo(RootComponent); CameraBoom->bAbsoluteRotation = true; // Don't want arm to rotate when character does CameraBoom->TargetArmLength = 800.f; CameraBoom->RelativeRotation = FRotator(-60.f, 0.f, 0.f); CameraBoom->bDoCollisionTest = false; // Don't want to pull camera in when it collides with level // Create a camera... TopDownCameraComponent = PCIP.CreateDefaultSubobject(this, TEXT("TopDownCamera")); TopDownCameraComponent->AttachTo(CameraBoom, USpringArmComponent::SocketName); TopDownCameraComponent->bUseControllerViewRotation = false; // Camera does not rotate relative to arm if (Role == ROLE_Authority) { static ConstructorHelpers::FObjectFinder PlayerPawnBPClass(TEXT("/Game/Blueprints/MyCharacter.MyCharacter_C")); CharacterClass = PlayerPawnBPClass.Object; } } void ADemoPlayerProxy::BeginPlay() { Super::BeginPlay(); if (Role == ROLE_Authority) { // Get current location of the Player Proxy FVector Location = GetActorLocation(); FRotator Rotation = GetActorRotation(); FActorSpawnParameters SpawnParams; SpawnParams.Owner = this; SpawnParams.Instigator = Instigator; SpawnParams.bNoCollisionFail = true; // Spawn the actual player character at the same location as the Proxy Character = Cast(GetWorld()->SpawnActor(CharacterClass, &Location, &Rotation, SpawnParams)); // We use the PlayerAI to control the Player Character for Navigation PlayerAI = GetWorld()->SpawnActor(GetActorLocation(), GetActorRotation()); PlayerAI->Possess(Character); } } void ADemoPlayerProxy::Tick(float DeltaTime) { Super::Tick(DeltaTime); if (Character) { // Keep the Proxy in sync with the real character FTransform CharTransform = Character->GetTransform(); FTransform MyTransform = GetTransform(); FTransform Transform; Transform.LerpTranslationScale3D(CharTransform, MyTransform, ScalarRegister(0.5f)); SetActorTransform(Transform); } } void ADemoPlayerProxy::MoveToLocation(const ADemoPlayerController* controller, const FVector& DestLocation) { /** Looks easy - doesn't it. - What this does is to engage the AI to pathfind. - The AI will then "route" the character correctly. - The Proxy (and with it the camera), on each tick, moves to the location of the real character - - And thus, we get the illusion of moving with the Player Character */ PlayerAI->MoveToLocation(DestLocation); } void ADemoPlayerProxy::GetLifetimeReplicatedProps(TArray< class FLifetimeProperty > & OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); // Replicate to Everyone DOREPLIFETIME(ADemoPlayerProxy, Character); } ```

We’ll now cover changes to the Player Controller. We’ll rewire it here to ask the proxy to move, which will in turn ask the AIController to find a path and move the real player character.

This involves changing the SetMoveDestination method to call a server side method to move the character. When the character moves, the player Proxy will automatically mirror the movements.

In the header file, add the following function

```cpp /*_ Navigate player to the given world location (Server Version) */ UFUNCTION(reliable, server, WithValidation) void ServerSetNewMoveDestination(const FVector DestLocation); ```

Now let’s implement it (DemoPlayerController.cpp):

``` bool ADemoPlayerController::ServerSetNewMoveDestination_Validate(const FVector DestLocation) { return true; } /* Actual implementation of the ServerSetMoveDestination method */ void ADemoPlayerController::ServerSetNewMoveDestination_Implementation(const FVector DestLocation) { ADemoPlayerProxy* Pawn = Cast(GetPawn()); if (Pawn) { UNavigationSystem* const NaDemoys = GetWorld()->GetNavigationSystem(); float const Distance = FVector::Dist(DestLocation, Pawn->GetActorLocation()); // We need to issue move command only if far enough in order for walk animation to play correctly if (NaDemoys && (Distance > 120.0f)) { //NaDemoys->SimpleMoveToLocation(this, DestLocation); Pawn->MoveToLocation(this, DestLocation); } } } ```

And finally, the rewiring of the original method:

```cpp void ADemoPlayerController::SetNewMoveDestination(const FVector DestLocation) { ServerSetNewMoveDestination(DestLocation); } ```

Finally, in terms of the character class, the only change is really to remove the camera components that we moved to the Player Proxy which I shall leave to you :-p

Gamedev on despatches

Building Pong with Zig and Raylib #6: Font Size, Collision Bugs, and Refactors

🖋️ Make the Score Font More Readable

🧱 Fix the Ball Getting Stuck in the Paddle

🧮 Trigger a Score When the Ball’s Edge Crosses the Screen

🔄 Refactor: Move Scores Out of the Paddle Struct

✅ Bonus Fix: Make Score Display Use Paddle Play Area

⏭️ What’s Next?

Links

Escape to Menu

Ordering

Pause/Resume

Logging

Contact

Quit

Config path

Final

Links

Building Pong with Zig and Raylib #5: Show Score with dvui

Extract out Game struct

Add dvui dependency

Add dvui to game loop

Import

Initialise

Pre-render

Post-render

Show Score

Closing

Links

Building Pong with Zig and Raylib - Part 4: Smarter Collisions, Cleaner Code

🧼 Naming Matters

🛠️ Default Field Initializers (and When Not to Use Them)

✨ RLS, Please

🎯 Fixing Paddle Collisions on the Y Axis

🧽 isColliding Should Only Collide

🔀 Movement Logic Encapsulation

📐 Resolution Independence

Closing

Links

Building Pong in Zig with Raylib – Part 3: Edge Collisions, Scoring & Player Input

🧱 Edge Collisions

🏁 Scoring System

⌨️ Player Input

✅ What’s Working

Links

Building Pong in Zig with Raylib – Part 2: Ball Movement & Paddle Collisions

Ball Movement

Frame-Rate Independence

Paddle Collision (X-Axis)

Paddle Collision (Y-Axis)

Bounce Logic

What’s Next

Links

Building Pong in Zig with Raylib – Part 1: Setup, Paddles, and Ball

Why Pong?

Project Setup

Drawing the Playground

Implementing Paddles

Ball Placeholder

What’s Next

Links

Under the Hood of triangle

🧩 Core Systems So Far

🗂️ Code Structure Overview

blit/

phys/

combat/

items/

notifier/

ship/

asteroid

diag/

game/

ui/

🧪 What’s Missing

🧶 Threads I’ll Pull Next

[UE4] Unreal Engine & miniupnp

[UE4] Source Control

[UE4] Intellisense Errors and USTRUCT

[UE4] Getting Sprint to work (C++)

Extract out `Game` struct

Add `dvui` to game loop

🧽 `isColliding` Should Only Collide

`blit/`

`phys/`

`combat/`

`items/`

`notifier/`

`ship/`

`asteroid`

`diag/`

`game/`

`ui/`