shri-codes on despatcheshttps://icle.es/tags/shri-codes/Recent content in shri-codes on despatchesHugoenBuilding 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

]]>