Raylib on despatcheshttps://icle.es/tags/raylib/Recent content in Raylib on despatchesHugoenThu, 19 Mar 2026 20:01:29 +0000Building Pong with Zig and Raylib #6: Font Size, Collision Bugs, and Refactorshttps://icle.es/2025/07/19/building-pong-with-zig-and-raylib-%236-font-size-collision-bugs-and-refactors/Sat, 19 Jul 2025 08:00:00 +0100https://icle.es/2025/07/19/building-pong-with-zig-and-raylib-%236-font-size-collision-bugs-and-refactors/<p>In this one, we’ll tidy up our Pong implementation by addressing three key issues:</p> <ol> <li>The score font is too small</li> <li>The ball can get stuck inside a paddle</li> <li>Trigger score on edge (not the middle) of the ball going past.</li> </ol> <p>We’ll also refactor score tracking to better match game logic structure.</p> <h2 id="-make-the-score-font-more-readable">🖋️ Make the Score Font More Readable</h2> <p>The score text was a little too small. If you&rsquo;re using <code>dvui</code>, here&rsquo;s how to adjust it:</p>In this one, we’ll tidy up our Pong implementation by addressing three key issues:

  1. The score font is too small
  2. The ball can get stuck inside a paddle
  3. 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.

]]>Building Pong with Zig and Raylib #5: Show Score with dvuihttps://icle.es/2025/07/15/building-pong-with-zig-and-raylib-%235-show-score-with-dvui/Tue, 15 Jul 2025 08:00:00 +0100https://icle.es/2025/07/15/building-pong-with-zig-and-raylib-%235-show-score-with-dvui/<p>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&rsquo;s time to show it on screen.</p> <h2 id="extract-out-game-struct">Extract out <code>Game</code> struct</h2> <p>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 <code>main.zig</code> file, leading the way to add in the dvui scaffolding.</p>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 Codehttps://icle.es/2025/07/10/building-pong-with-zig-and-raylib-part-4-smarter-collisions-cleaner-code/Thu, 10 Jul 2025 15:33:34 +0100https://icle.es/2025/07/10/building-pong-with-zig-and-raylib-part-4-smarter-collisions-cleaner-code/<p>Change of Plans</p> <p>I was going to dive into menus and UI, but after sharing the early version of Pong on <a href="https://ziggit.dev/">ziggit.dev</a>, I got a bunch of helpful feedback. The feedback was the kind that makes you stop and think, <em>ah, right&hellip; I should probably fix that before carrying on.</em></p> <p>So that&rsquo;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 <em>should</em> be done in Zig (or at least, better than I had them before).</p>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 Inputhttps://icle.es/2025/07/07/building-pong-in-zig-with-raylib-part-3-edge-collisions-scoring-player-input/Mon, 07 Jul 2025 12:01:00 +0100https://icle.es/2025/07/07/building-pong-in-zig-with-raylib-part-3-edge-collisions-scoring-player-input/<p>In this part, we round out the core gameplay of our Pong clone in Zig using raylib. By the end, we&rsquo;ve got a working game - with a bouncing ball, paddle controls, and basic scoring.</p> <h2 id="-edge-collisions">🧱 Edge Collisions</h2> <p>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&rsquo;s y-position was outside the visible range and inverting its vertical velocity accordingly:</p>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 Collisionshttps://icle.es/2025/07/04/building-pong-in-zig-with-raylib-part-2-ball-movement-paddle-collisions/Fri, 04 Jul 2025 12:01:00 +0100https://icle.es/2025/07/04/building-pong-in-zig-with-raylib-part-2-ball-movement-paddle-collisions/<p>In <a href="https://icle.es/1-setup.md">Part 1</a> 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.</p> <h2 id="ball-movement">Ball Movement</h2> <p>The first step was to give the ball some velocity and update its position every frame.</p> ```zig self.pos = rl.math.vector2Add(self.pos, self.vel); ``` <p>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.</p>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 Ballhttps://icle.es/2025/06/28/building-pong-in-zig-with-raylib-part-1-setup-paddles-and-ball/Sat, 28 Jun 2025 20:38:29 +0100https://icle.es/2025/06/28/building-pong-in-zig-with-raylib-part-1-setup-paddles-and-ball/<p>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.</p> <p>This post goes alongside <a href="https://youtu.be/ICq2D_na6zc">my video on YouTube</a>, and walks through the early steps of the project: setting up the game, getting something on screen, and implementing the paddles and the ball.</p>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 trianglehttps://icle.es/2025/06/27/under-the-hood-of-triangle/Fri, 27 Jun 2025 08:01:28 +0100https://icle.es/2025/06/27/under-the-hood-of-triangle/<p>In <a href="https://youtu.be/8nA-a5Z1IDc">this Let&rsquo;s Code video</a> on <a href="http://www.youtube.com/@ShriCodesHere"><strong>shri codes</strong></a>, I walk through some of the early systems in place for <a href="https://icle.es/tags/triangle/"><em>Triangle</em></a> - my space ARPG built in <strong>Zig</strong> with <strong>raylib</strong>.</p> <p>For the broader story behind the project - what <em>Triangle</em> is, where it&rsquo;s going, and why I’m making it - check out the <a href="https://icle.es/endeavours/triangle.md">triangle endeavour</a> or the <a href="https://icle.es/tags/triangle/">devlog archive</a>. This post is about the <em>how</em>.</p> <h3 id="-core-systems-so-far">🧩 Core Systems So Far</h3> <p>At this stage, Triangle supports:</p> <ul> <li>Basic player movement and shooting (Asteroids-style).</li> <li>Procedurally generated asteroid fields per <em>sector</em>.</li> <li>Material drops (iron ore) from destroyed asteroids.</li> <li>Automatic recipe unlocking when new items are picked up.</li> <li>Smelting system that converts ore to ingots.</li> <li>Unlocking and queuing up <em>constructors</em> using the crafting menu.</li> <li>A basic UI for crafting and inventory.</li> <li>Configurable keyboard mappings using TOML.</li> </ul> <p>That’s the visible layer. Below the surface, the codebase has carved out some space for more ambitious systems.</p>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

]]>Basic Gameplayhttps://icle.es/2025/05/08/basic-gameplay/Thu, 08 May 2025 10:07:08 +0000https://icle.es/2025/05/08/basic-gameplay/<p>The first goal was to get it working as far as the coding challenge itself.</p> <h2 id="the-ship">The Ship</h2> <p>Spawning the ship itself was relatively straightforward. I only needed three points and <code>drawTriangle</code> from <code>raylib</code>.</p> <p>In the coding challenge, the ship was rotated with the keyboard, but I wanted the ship to point to the mouse so that aiming was straightforward. Rotating to the mouse was trickier — it involved <code>atan2</code> and ChatGPT got me started.</p> <p>The coding challenge video did not worry about time lapsed between each frame, but I wanted triangle to be framerate independent. That involved a bit of jiggery pokery to get working, including determining how much the ship can move within a time frame.</p> <p>Moving the ship was a bit easier, but based on the many videos of the Coding Train that implemented force, velocity and dampening, it was pretty straightforward. Dampening took a bit of trial and error. ChatGPT sent me down the garden path initially with an over-complicated formula, but I was able to simplify it later.</p> <p>Integrating the physics for linear momentum with the one for rotational momentum was also quite nice — it meant that the ship could overshoot the aim when rotating and will correct back.</p>The first goal was to get it working as far as the coding challenge itself.

The Ship

Spawning the ship itself was relatively straightforward. I only needed three points and drawTriangle from raylib.

In the coding challenge, the ship was rotated with the keyboard, but I wanted the ship to point to the mouse so that aiming was straightforward. Rotating to the mouse was trickier — it involved atan2 and ChatGPT got me started.

The coding challenge video did not worry about time lapsed between each frame, but I wanted triangle to be framerate independent. That involved a bit of jiggery pokery to get working, including determining how much the ship can move within a time frame.

Moving the ship was a bit easier, but based on the many videos of the Coding Train that implemented force, velocity and dampening, it was pretty straightforward. Dampening took a bit of trial and error. ChatGPT sent me down the garden path initially with an over-complicated formula, but I was able to simplify it later.

Integrating the physics for linear momentum with the one for rotational momentum was also quite nice — it meant that the ship could overshoot the aim when rotating and will correct back.

The Asteroids

The coding challenge worked with a fixed number of on screen asteroids and they wrapped around. I needed to expand this to:

  • A potentially infinite vertical scroller.
  • Collisions between the asteroids (currently the same as from the challenge, only checks full circle collision)
  • Figure out how to handle asteroids moving out of the screen

The above will be covered in a bit more depth in the next devlog.

The Camera

I also needed a follow camera. Unlike the original asteroids, the ship can move up/down and the camera should follow it.

The current code looks something like this:

```zig /// ship_y: ship's current y position /// ship_vy: ship's y velocity /// dt: time elapsed since last update /// margin: the zone out of which camera is moved /// speed: maximum camera movement speed fn updateCameraY(self: *Self, ship_y: f32, ship_vy: f32, dt: f32, margin: f32, speed: f32) void { const cam_y = self.camera.target.y; const inner_margin = margin * 0.8; // Predict future ship position // TODO: at high speeds, when the clamp goes off, the camera does a little shuffle // It would be nice to fix that const screen_height: f32 = @floatFromInt(self.screen.height); const predicted_y = ship_y + std.math.clamp(ship_vy * 30.0, -screen_height, screen_height); var target_y = self.camera.target.y; var target_clr: rl.Color = .red; const tmargin = cam_y - inner_margin; const bmargin = cam_y + inner_margin; if (predicted_y < tmargin) { target_y = predicted_y + margin; target_clr = .blue; } else if (predicted_y > bmargin) { target_y = predicted_y - margin; target_clr = .green; } if (target_y > screen_height / 2) target_y = screen_height / 2; const t = std.math.clamp(dt * speed, 0.0, 1.0); self.camera.target.y = lerp(cam_y, target_y, t); } ```

It predicts the position of the ship, based on its y velocity. If that’s outside the middle zone, it’ll move the camera at up to the maximum speed. There is some clamping to prevent things flying off at high speeds. It also prevents the camera from overtaking the ship.

This code is mostly hacked together with some help from ChatGPT. It’ll be cleaned up later, once I have a better indication of possible ship speeds, and how/if we’ll zoom in and out as well.

Another important facet to consider with the camera was what to do with the edges. Out of the four edges, only one is infinite.

The current solution is that the camera stops tracking when it gets to the “bottom.” It also does not move to the left or right. The ship, on the other hand is free to move out of the range of the camera. Currently, nothing changes except that the camera does not follow.

Since the thrust works in the direction of the mouse, it’s pretty easy to bring the ship back on to the screen. This feels like the world is big and still out there, we just don’t track what happens out there.

I considered wrapping around on the left and right, but that felt more like the ship was trapped in that zone. I want the feeling of being trapped in vengeance to be more subtle ;)

Combat

Combat is pretty much a mirror image of what happens in the coding challenge, though I didn’t have some of the helper functions. I learned some math :)

Initially, the update loop only handled asteroid collisions. I added bullets as a separate field in the update loop. It then checks each bullet with every asteroid in the active chunks (covered in devlog #2).

If there is collision, the asteroid is split into two, moved apart a bit, and given opposite linear momentum. The bullet also takes “damage” at this point, and can be removed. The damage system is designed to support penetration, which is currently not active.

If the spawned asteroids would be too small, nothing is spawned. Later on, this would be the trigger to spawn a material drop.

Zig / Raylib

Learning zig and raylib was a big part of this. Fortunately, both were a lot of fun to learn and work with.

One thing I found annoying was that the vector functionality in raylib was scattered around as individual functions instead of on the vector struct. While this was understandable, with raylib being written in C, I found it a bit frustrating.

I ended up writing my own Vector struct in zig and the functions that I used as methods on that struct. It was an opportunity for me to learn some vector math as well.

I also encapsulated raylib inside a Canvas struct. I probably still have some rl. calls other places in the code, but the idea is that a canvas is passed into any bits of code that needs it. The main help is that it’ll convert our version of Vector2 to the one that raylib wants.

I am also thinking about how I want input handling to work. I would like to encapsulate that into a separate struct. Right now, I mainly access raylib directly.

Manual testing

While I am a big proponent and fan of Test Driven Development, I was happy enough with manual testing for triangle. I found joy in seeing it work each time I manage to get something working.

I do end up writing tests later, particularly when I got to bits of code that was harder to test manually.

Feel

triangle already feels fun and light. There are some clunky elements to be ironed out, but so far, it feels good :)

]]>