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.

Links

• YouTube Video
• Let’s code devlogs
  • #1.1 - Getting Started
  • #1.2 - Theming & More Buttons
  • #1.3 - Wiring & Finalising
• Prev: Under the Hood of Triangle

It loved to watch the birds, to race galloping creatures below, often pretending to lose.

One morning, not unlike many others, it was resting atop a mountain watching the sun rise, basking in the warmth of the sun and the twittering of the birds.

It’s funny how much can change in a moment.

It was now drifting in silence surrounded by what looked like asteroids. The warmth of the sun felt like a distant memory. How many moments had passed in between? It did not know.

Beyond the asteroids, far in the distance, it could make out vague shapes. Amongst them, one it almost recognised - a segment of a shattered sphere. The ship recognised the ocean, now spilling into the black of space. It had once felt the mist from that ocean, many years ago. It would not skim that ocean again.

It slowly became aware of the structure - gargantuan, black, looming in the dark. It hung weightlessly above what was once the ship’s home, barely visible, quietly consuming the remains. Methodically, mechanically, it tore through the wreckage, scattering crumbs into the void - rocks, dust, fragments of what once was.

The ship found itself drifting in silence surrounded by what looked like asteroids.

There was no asteroid belt here before.

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

The Real Stuff Behind Making a Game

Making games is hard! Making games independently is harder. When you’re doing it solo, it’s harder still.
It’s juggling health, money, and energy - not to mention motivation.

I’ve spent over 20 years in tech, running a company, building stuff like megabus.com’s ticketing system.
After burning out and dealing with some tough health issues, I’m struggling with even the idea of picking up freelance work or hustling like I used to. I have about 3 months of money left, so I need to be smart.

On the positive side, I’ve got the experience - in dev and solo work - to see this through,
I just need to figure out a sustainable financial path.

What I’m Doing Now

Here’s my current rough plan to keep triangle moving without burning out:

1. Building Community

I’ve been posting devlogs and videos, but haven’t really focused on building a following or community. I loathe the “like and subscribe” crowd, so I don’t want to be doing that. I want to focus on adding value.

It’ll take me longer, and that’s ok - I have to figure out the finances, but that’s a separate problem.

I want to keep doing what I’ve been doing. Devlogs, videos, sharing and collaborating. I’ll have more time for a bit as well since the main project I was working on has now been canceled.

I also want to make some improvements to this site to link things up a bit better and make it a bit easier to find things. That’ll have to happen on a “little bit here and there” kind of basis though.

2. Going for Grants

I’m looking at funding from places like Creative Scotland that support mental health and creative projects.
triangle isn’t just a game - I’m trying to express something real, and I’m trying to communicate that clearly.

3. Maybe a Kickstarter

Further down the line, I might run a Kickstarter -
but only if I can find the right piece of work that adds real value for everyone involved: myself, the game, and potential contributors.

4. Patreon / Ko-fi - But No Paywalls

Once I have enough of a following / community (5k - 10k subs), I could set up Patreon (and/or maybe Ko-fi), but no paywalls - I don’t like them. I want to invite people who want to support and join in, and participate.
Everything stays public - devlogs, updates, builds.
Supporters get perks like name credits and priority access.

4. Loans Only If I Have To

If I really need it, I’ll consider a small loan to get through a crunch -
but only if it helps hit a real milestone, not just to stretch things out.

Other Stuff I’m Doing

I’ve also started a coding video channel, Shri Codes.
It’s a way to share bits of the process behind building triangle, maybe other excursions and the things I’m learning along the way.

This blog is where I write devlogs, ideas, and rambling thoughts -
it’s turning into a bit of a central hub that connects everything else I’m doing. I have a bunch of other things that I’ve done in the past (and am working on now) that I’d like to put on here as well. Of course, that takes up time too, and I’m not sure how much real value that will add.

If You Want to Follow Along

You’re welcome to follow along on whatever platform works for you - no pressure, no strings.
I love collaboration and would really value your thoughts, whenever you feel ready to join in.

If you have advice, experience, or just want to say hi, please do. It means a lot. I’ll take every bit of encouragement and support I can get.

As a starting point, my keyboard layout is colemak, and I doubt that the controls I use would suit the majority of players.

I am putting off a UI based config management option down the road (did I mention that I do not enjoy GUI work?). As such I’ve been pondering alternative configuration options.

Platform independence

Before I even get to that, the first problem I need to solve is a way to determine the location for the config files independent of the platform.

Fortunately, known-folders came to the rescue and provided an easy to use framework that can be used to determine the various relevant locations for multiple platforms.

Locations

There are three real locations of relevance for triangle

• The binary / package
• Config, technically, split into two
  • user (or in Windows parlance, the remote dir, and can be shared across computers)
  • system (in windows parlance, local, and is specific to that system)
• Save Data

User & Game Config Files

With that sorted out, the next bit is to identify the relevant config files. I expect that triangle will continue to use these, and will eventually just get a UI config option as well.

User Config

There are two main bits of user configuration

• Preference like controls
• System details like resolution

I am currently unsure when it’ll support system config.

Game Config

There are two bits of config that the game will store. One set of config is to remember game choices the user has made.

Remember Player Actions

For example, it will be useful to show the user details of changes to the game since they last played. To do this, we need to track the last set of changes that the user saw.

The game will show a notice on startup about its extremely early access status, and provide an option for the user to hide that in the future. We need to save that somewhere too.

Telemetry

The second bit of config is metrics. While a lot of games will simply send telemetry information directly to the developer, player privacy is really important to me. I recognise that I will get far less data because of this, and that there will be a bit of survivorship bias with the data - but I feel that privacy is more important.

The way I want telemetry to work is that it will all be saved in a human readable telemetry file in the config file location.

The data is stored only locally, and is never automatically sent. The player is welcome to use this data for themselves if they wish and also share at their discretion. The information will be stored in a human readable format that should be as easy to understand as possible - no data dumps.

The location will also store logs (if enabled).

Setting Config

In terms of allowing the player to manage config, there are a couple of challenges:

• Providing enough documentation that it is easy to do
• Allowing for updates, particularly to the addition of new keys

To tackle this, I am going to provide an annotated template file with all the config options. The user can create a separate file based on this with only the config they wish to override.

It will be tricky to change how particular parameters are configured. E.g. If a single value key needs to switch to an array. I’d be loathe to sprinkle the code with checks for legacy keys/formats. We’ll play it by ear.

I considered updating the config file automatically, but this would discard any comments the user had added. While I could offer an option to merge changes in, it’s not straightforward enough to implement just yet.

Format

I’ve been considering toml and yaml for this, with zig-toml and zig-yaml respectively.

zig-yaml seems to be more active (more stars, forks, issues and pr’s and currently also the more recent commit).

I am also more familiar with and prefer yaml.

However, it does not currently support default values. I would like the user to have to specify only the config they’d like to override. zig-yaml currently expects all the keys to be defined if you want to parse it into a struct.

#85 should bring it in, but I could not get it to work

So, I tried out zig-toml and the test worked the first time.

src/toml_with_defaults.zig

Using the config

The final part is to use the config.

Loading config

All config is loaded at startup and attached to a Config struct, which is in turn part of a Context struct that is passed around.

src/load_save_config.zig

User config (controls)

This one involves a little translation as we need to know the rl.KeyboardKey for each mapping to be able to detect it.

I use a std.StringArrayHashMapUnmanaged(rl.KeyboardKey) to map the string to each key

src/load_save_config.zig

Game Config

As a starting point, we’ll probably only have one config entry here - the last time the news was marked as read by the player.

We’ll store this as an i64 and loading it is exactly the same as above.

The main difference with the Game config class is that on writing any value, it will also save it to disk.

I ran into a bug where the api for serialization was broken. There is (currently) a pending pr #33 to resolve it

One of the challenges of using emerging language and ecosystem is that you’re more likely to run into bugs. One of the great joys of working with such ecosystem is the greater opportunity to contribute and get involved!

Links

• YouTube Devlog
• Prev: Crafting Machines

Crafting in triangle should be a mix of random number generation (rng) and deterministic. Crafted items will have a random set of mods. However, like in Last Epoch, you can extract the mods of the items. These can then be placed into another item.

It feels like mod crafting would be an interesting way to approach crafting in general. Unlike in the Last Epoch, the extracted mods aren’t just combined back together.

What if each mod retains its values? What if you could combine two mods together to upgrade or reroll them?

When you insert a mod into an item, what if it destroyed the mod that you were replacing?

Tiers

All materials, items, and mods have tiers. Factories will only process items of their tier or lower. A Tier 1 smelter cannot process a Tier 2 material and a Tier 1 constructor cannot craft a Tier 2 item.

I am currently mulling over the idea of having nine tiers.

Items (a.k.a Buildings? Machines?)

I’m toying with the idea of the tier determining how many mod slots it could have. A Tier 2 item would have two mod slots and a Tier 5 item would have 5 slots.

This provides a natural power curve, even if the mods themselves do not have tiers.

All items will also have up to one implicit mod. This mod will be item type specific. e.g., for smelters, it will be smelting rate

From a concept perspective, there are probably buildings, or some kind of structure that can be slotted on to the ship.

Perhaps buildings are a better name for them than items.

Slots / Hardpoints

I see two kinds of slots on the ship

• Interior slot: Machines like the smelters will go in here
• Exterior Slot: Weapons, Armour, Hull Extensions etc. could go on to these.

Mods

Currently mods also support tiers, but I am wondering whether the power creep could become exponential, combined with the additional mod slots. There may be good ways to mitigate it though, which will only become apparent once some of these mechanics have been implemented.

Another reason to skip tiers on mods is if that means that the player ends up with far too many mods in their inventory.

There are a couple of key areas in which I am thinking about deviating from other games (like the Diablo series, PoE 1/2, Last Epoch etc.)

Local only

Each mod applies only to the item it is on. A firing rate increase on your smelters won’t do anything - since they don’t fire. A smelting speed increase on your weapon will likewise have no effect. It would make sense to extract or replace the ineffective mods.

If you have two weapons attached, and one of them has a mod that increases firing rate, that will impact only that weapon.

No Prefix / Suffix mods

There is no classification of mods as prefix/suffix or limits of each type. You can have full attack mods on if you like. Considering the previous restriction, it makes more sense to stack attack on weapons and defense on armour.

Machines

There are a few factory based machines I have in mind so far.

All these machines will have a rate at which they will complete their work. I have been pondering whether higher tier machines will complete lower tier work faster.

Smelters

The standard refinery. It will convert ore and scrap (obtained when enemy ships are destroyed, and from scrapping items) into refined materials.

Constructor

Converts refined materials into items of Tier 1. For Tier 2 onwards, I am considering taking items from the previous tier plus a refined material of the new tier. E.g. to craft a Tier 2 factory, it could take 2 x Factory Mk. I + 30 Tier 2 materials (whatever that turns out to be)

This could keep the recipes easy to understand and reason about. It also provides one use for poorly rolled items.

Disassemblers

These function similar to the Foundry in Last Epoch, at least with regards to extracting all the mods from the item.

I haven’t decided how deterministic it will be. Will it extract all items or could some be damaged in the process and maybe turned to scrap?

Scrappers

These are a bit like the trash bin. If crafting requires lower tier items, these might not be necessary. TBD!

Foundry

This would be the machine that could do mod crafting. I am still a little foggy about how or if this machine could work.

Should mod crafting involve risk? Like combining two mods to maybe create a higher tier one - or failing and getting scrap?

What about rerolling a mod by sacrificing another mod?

All ideas accepted :)

Augmentor

The Augmentor could be the final step in the pipeline - letting you insert or fine-tune mods once you’ve refined or crafted them.

This machine will work instantly so that it doesn’t tie up the items currently in use. It would allow you to modify items up to its own tier.

triangle

With machines slotted directly onto the ship, triangle becomes a living, drifting factory - salvaging, upgrading, refining, evolving, fighting, and surviving!

Other posts

• Companion vlog for this post
• Prev: Materials & Pickups
• Next: Coming Soon

Drops

As a starting point, when asteroids are destroyed, they will drop materials. I’ve also been pondering whether materials could drop when they split. It makes logical sense, but I want to get a better sense of pacing before diving into that question.

Currently, only iron drops. I started off by finding a sprite sheet with reasonable looking sprites and then started integrating them in before I decided to just stick with shapes — so iron drops are little blue circles.

PS: you haven’t seen the Shape code, but you get the gist.

These drops are managed by a MaterialField that keeps track of all the dropped materials. They are given a low linear velocity, and no rotational velocity (it’s a circle, so you wouldn’t see it anyway).

They do not interact with collisions to avoid them being bumped off the screen or you having to chase them down.

At some point, they could also be optimised to only update if they are on screen. Assuming the player will pick up most of them, this may not be necessary.

Pickup

I also “installed an attractor” on the ship such that if it gets close enough to a material, it’ll pull it in. When it’s close enough, it’ll be “picked up.”

It is a physics interaction, so it is possible to slingshot the material and have it fly off the screen (it’s happened to me). It feels like a sun interaction and you are in control of it, so I am inclined to leave that in.

Once it’s close enough, it’s picked up, and added to an inventory.

The attractor also feels like an upgrade that can be crafted later.

Smelting

Crafting Panel

For smelting, I started by sketching out a straightforward UI. I’ll admit up front that I don’t enjoy UI work, but in earnest I started on it, and I got as far as displaying the panel itself and I got tremendously bored.

I decided to make material refinement prioritisation automatic, at least for the time being. It would always prioritise the most valuable material that is in the inventory.

Actually, that’ll remove some factory micromanagement without removing the feeling of agency from the player.

It’ll mainly be a problem if the player has run out of lower tier materials and they have a large amount of higher tier items in the inventory. I figure let’s wait until we have some playtesting before we worry about it. The system currently only drops one material and it can be refined automatically.

Refining

All materials and items will have a tier, starting with iron at 1. To be able to smelt a material, you’ll need a smelter at a minimum of that tier. For example to craft iron, you need a minimum tier 1 smelter (which is fine since 1 is the minimum tier anyway). If you wanted to smelt a tier 3 material, you’ll need a minimum of tier 3 smelter.

The ship starts with a Tier 1 smelter and will always have a tier 1 smelter. This smelter cannot be modified, removed, or destroyed. The same is true of some other factories, which will be covered in the next post.

The first iteration of refining took the total capacity of all smelters at each tier, and would convert a portion of the materials from ore to ingot. It used floating points to track progress. If it would take four seconds to convert one ore to ingot, over one second, it’d transfer 0.25 from ore to ingot.

The display only showed integers, so there was a bit of floor and ceil to be able to show consistent numbers.

I didn’t like this way of doing things. It felt icky — hacky — but it was simple enough and it works, for now.

Other posts

• Companion vlog for this post
• Prev: Procedural Asteroid Fields
• Next: Refineries, Constructors and other other factory types in a world without conveyor belts.

• An asteroid field that feels infinite
• Natural-looking distribution and density
• A safe starting area for the player

Spawning Asteroids

I explored strategies for spawning multiple asteroids on screen without overlaps and avoiding the player’s starting zone. Initially, I considered a brute-force collision check for each spawn candidate, but quickly realized it wouldn’t scale well with many asteroids.

I decided to split the screen into a grid. If the maximum radius of an asteroid is r, then each grid would be 2r x 2r, and would be able to accommodate asteroids at their full size. The asteroid size is determined randomly, with a minimum size. It also offsets the center of the x by a random amount, up to a maximum of r.

In theory, this means that if two adjacent cells spawn the full size asteroid and offset in the “wrong” direction, they could start off overlapping. I’ve not seen this happen yet, likely because the full size asteroids are not that common.

The grid has an additional offset in the x axis for each row. With this offset, even if every asteroid was placed at the x center of each grid, they would not look uniform.

Finally, for each grid cell, there is some further randomisation that determines whether the asteroid will get spawned at all.

In hindsight - there might be more randomisation than we need. It works well though.

The asteroids are also given a low starting velocity, both linearly and rotationally.

Even if asteroids do overlap on spawn, the physics will correct it through the collision detection.

Spawning the Ship

The code for this part is a little icky right now. It checks the y position of the ship and avoids spawning asteroids in any grid cell that overlaps the starting location.

Of course, this should only matter for the asteroids spawned on the starting screen. The rest of the asteroids don’t need this check. It works just fine though - for now :)

Making it “Infinite”

I pondered the best way to make it feel infinite without risk of slowdowns and issues. A quadtree was an obvious answer. However, it felt too complicated since I’d never written one before, and I was worried about how I would move each asteroid between each section as it moved. (Spoiler alert: I should have just used quadtrees, and intend to move to it later.)

In the meantime, I wanted to build something which felt simpler, which was basically to create chunks of asteroids, with each chunk being a little larger than the size of the screen.

The system could then, based on the current y position, track just the current, previous, and next chunks, and process only these asteroids.

When I got it working, it was pretty ok. The main problem I had now was the asteroids leaving the screen and never coming back.

After I’d implemented this, I ended up watching Coding Challenge #98: Quadtree, and boy did I feel silly about being scared about quadtrees. They were promptly demystified and felt like a much simpler solution than what I have here - so I’ll add that to the list to change.

Asteroids Drifting Offscreen

One of the problems was that the asteroids would drift offscreen. Because I wasn’t updating all the asteroids, they’d never come back on to the screen. In fact, even if I updated all the asteroids, the screen would eventually clear. I believe this was because there is a lot of offscreen space (mainly on the left and right of the screen) that the asteroids could fly off to.

I tried various ways of wrapping the asteroids around after they hit a few hundred pixels past the edge. I didn’t want it to look like a wraparound, and pretending like the screen was about twice the width helped.

However, the problem was now with the asteroids slinking out the bottom of the screen (and the top too), and there wasn’t an easy way to tackle those.

In the end, I ended up using an attractor, which I placed on the center of each chunk.

This worked surprisingly well that I didn’t even need the horizontal wraparound.

I had also ended up making the Chunk struct a little heavy, and I ended up refactoring it. While refactoring, I overoptimized it to only update asteroids on the screen. This “fix” meant that asteroids off-screen aren’t attracted to the center of the chunk anymore, and the screen ends up clearing again. Something to fix later - maybe when I implement the quadtree.

Debug Panel

There were various points when I was trying to track down issues that I reverted to my habit of printing stuff out - but that was a nightmare because it was printing the same thing in each frame.

Eventually, I got into the habit of displaying stuff on screen and drawing different colours etc. I then wanted a way to see things easier and toggle some of the debug features. To do this, I needed a GUI.

I looked at raygui, which looked good but probably too basic for me. I don’t enjoy GUI work and I figured something a little more fleshed out would help.

I had already looked at dvui before and it looked like it could be a good candidate.

Integrating it into triangle was pretty straightforward - at least once I figured out how to add it to build.zig.

Next Steps

Right now, the field feels big enough (around 15 chunks), but not truly infinite. I’m thinking of implementing a circular buffer - say, 8 or 10 chunks - where old ones are recycled as the player moves forward. If a player backtracks, most asteroids will have drifted off anyway, and replacements will blend in just fine.

I’ll probably tackle that - and maybe finally add a quadtree - soon.

Next up: crafting systems and how I’m handling material drops and recipes.

Other posts

• Companion vlog for this post
• Basic Gameplay
• Next: Materials & Pickups

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:

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 :)

Other posts

• Companion vlog for this post
• Prev: A lone triangle vs the universe
• Next: Procedural Asteroid Field

One of the activities to pass time while healing was playing a lot of ARPG’s recently, particularly PoE 2 and the Last Epoch. I’d even had a few ideas about how I might do things a little differently. Since my brain capacity was pretty low, these games with their repetitive nature and easy dopamine hits were really enjoyable.

I found the gameplay a bit fragmented though, and having to follow guides was annoying. I had been mulling over the idea of making something which flows, and supports your decision making. It’s not about giving the player answers, but about providing the player the most relevant information in an easy to digest format. They still get to make the choices. I struggled to identify what mattered - guides were easier.

I did wonder if there was an easy way to just say - “use this build from this guide” so that it would save me from all the tedious clicking :/

All this left me wondering if I could build something that captured the fun while keeping you in the flow. I even looked at how complicated it would be to make an isometric game. Too complicated for me was the answer.

Factory games, one of my other favourite genres felt a little too mentally taxing. Otherwise, I would have dived into Space Age.

I have also been bingeing on youtube videos and discovered a fantastic channel - the Coding Train.

I’ve been almost religiously watching the Coding Challenges playlist and I have been loving it. I love how he makes 2d graphics programming seems so easy and approachable. I used to be so intimidated by all the math.

There was a slow confidence building in me that maybe - just maybe I could build a game.

Coding Challenge 46

Last night, I was watching the one about remaking Asteroids. He made it look so easy and fun. How he puts those asteroids together felt so clever - neat! I could do that. Actually, I could make that really interesting.

For a little while now, I’ve been wanting to try out one of the challenges, tied in with playing with zig, which has also been on my radar. I’ve largely worked with higher level languages like Java (and golang more recently). I’ve always been fascinated by C, and C++, but never quite got into it. Zig represented a more fun and modern version of C that I could enjoy. I also really liked how explicit and simple zig feels.

It feels like a perfect opportunity to feed two birds with one scone. I could try and replicate what he did in that video in zig.

A little bit of research on graphics/game libraries in zig revealed raylib to be the best candidate for my needs. While a C library, it has zig bindings, there is plenty of documentation, albeit not necessarily in zig - but that was ok.

I could see it in my mind - a field of asteroids, pew pew pew, asteroids break apart. Destroyed asteroids would drop resources. Oh you could have factories on the ship and build your armoury - weapons, armour, scanners - everything. That would be an interesting twist - you don’t pick up loot - you build it.

Each item would still have randomised mods, but you could extract them like in Last Epoch and use them in other ones - I have a lot of ideas.

Story

In terms of the story, I’ve been pondering the destructive nature of capitalism a lot lately and that felt like a good metaphor to bring in here - it just connected.

The planet where the triangle belongs has been destroyed by a corporation - not necessarily maliciously, but in a bid to extract it of all valuable resource.

I have this image in my mind of something called a “Mill” that the planet is put through. The remnants create an asteroid field in which you find yourself.

The game essentially starts off with seeking vengeance. Victory - at least over the corporation - is not possible. You can get stronger, much stronger, and you can get to a place where you can beat the waves with relative ease - but the waves never end!

I have been pondering a softer ending, a choice that the player can make, when they’ve had enough - but I’m reluctant to give that away.

On pondering this. I realised this could also be a quiet metaphor for depression. Having been through it in my life, I could feel a connection. What if the triangle is indestructible?

Actually, that would improve the flow - no game over screen, and no respawn. All the machinery and installations on the ship could be destroyed, but the core of the ship - that always remains. You can always keep fighting.

Gameplay

Scavenge

Starting off in an asteroid field, you’re able to scavenge materials. The ship starts off with a smelter, a factory, and some basic power. You can refine materials and construct buildings to get stronger.

Each sector will get more difficult. I thought about being able to travel vertically and horizontally, but in the end, I decided to make it a vertical scroller. A two dimensional map might be more interesting, but it also brings annoying choices, particularly in terms of wondering whether you should have gone another way.

By putting the game on some form of rails, you have a smaller context to think about - and you can focus on fun. I am reminded of Raptor: Call of the Shadows, a game that I loved in the 90’s.

Raptor had shops, but I want to do a super simplified factory aspect. Every upgrade should feel earned — constructed, not found. I want to feel that progress is made entirely by the actions of the player.

There will still be randomisation, but it will be limited to the mods that are spawned on the items that are constructed. The player gets to decide what items to build.

I want the crafting to be as deterministic as possible, but while also keeping it interesting.

Figuring it out

There are no (traditional) tutorials or help sections. This decision will put a lot of pressure on getting the UI/UX intuitive and easy to use. However, it will also help maintain flow and keep every bit of progress feeling earned.

Items will have descriptions and details so that the user can make choices, but it is about experimentation and exploration. I would also like a component, something like a computer that can be installed. The idea is that this can do analysis of items and mods and give you details of clear and easy to understand benefits and disadvantages. Not just what attributes change, but how it will impact gameplay. I can’t be perfect, but it must be accurate, and be able to provide enough information to be able to decide whether it’s worth a try.

The intention is that this computer can act a bit like the guide that you would otherwise google.

Each sector increases difficulty, but is infinite in itself. After traveling for a bit, you will be offered an exit. If you keep going, exits will be offered at regular intervals - but you can just keep going.

You are dropped into a universe and every step is up to you to figure it out.

Aesthetic

I can hear the synthwave tracks that play in the background already (it could be because I’ve been listening to a lot of synthwave recently). It feels right and thematic to the original Asteroids.

The graphics, at least initially is going to be simple and shape based, again thematic. I’ve been pondering whether and how the graphics would get updated as you get through the sectors. The start of it is going to be black and white with little hints of colour. As you progress, you’ll get more and more colour and the vibrancy increases, sometimes in leaps and bounds. It could be a metaphor for the journey of recovery.

The sound effects should also have a strong 80s vibe. I want it to feel like you’ve been transported to the 80s but if it happened in 2025.

triangle

As a name, at least for the time being, I’ve settled on triangle. It is a passion project - I have a vision and a strong idea of how I want to feel playing it.

At its heart, triangle is about (re)building - a game where every piece of progress feels personal.

I would like to share it with the world and am looking for feedback, thoughts ideas and supporters.

If the idea or any of the concepts resonate with you, I’d love to hear from you.

Other Posts

• Next: Basic Gameplay

Updates

2025-05-31: Added devlog #0 on youtube
2025-05-21: Added an itch.io page