Crafting on despatcheshttps://icle.es/tags/crafting/Recent content in Crafting on despatchesHugoenFri, 27 Jun 2025 08:29:59 +0100Managing Configurationhttps://icle.es/2025/06/08/managing-configuration/Sun, 08 Jun 2025 21:47:05 +0000https://icle.es/2025/06/08/managing-configuration/<p>Before making the game available for playtesting, I wanted the player to be able to configure the game to some degree.</p> <p>As a starting point, my keyboard layout is <code>colemak</code>, and I doubt that the controls I use would suit the majority of players.</p> <p>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&rsquo;ve been pondering alternative configuration options.</p>Before making the game available for playtesting, I wanted the player to be able to configure the game to some degree.

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.

```zig const known_folders = @import("known-folders"); const maybe_config = try known_folders.getPath(allocator, .roaming_configuration); if (maybe_config) |config| { defer allocator.free(config); std.debug.print("roaming config path: {s}\n", .{config}); } ```

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

```zig const std = @import("std"); const Controls = struct { forward: []const u8 = "w", craft: []const u8 = "q", inventory: []const u8 = "e", }; const User = struct { controls: Controls = .{}, }; test "load partial toml config" { const toml = @import("toml"); const allocator = std.testing.allocator; var parser = toml.Parser(User).init(allocator); defer parser.deinit(); const source = \\[controls] \\craft = "s" ; var result = try parser.parseString(source); defer result.deinit(); const config = result.value; const default = User{}; try std.testing.expectEqualStrings(default.controls.forward, config.controls.forward); try std.testing.expectEqualStrings("s", config.controls.craft); } ```

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

```zig user: User, game_path: []const u8, game: Game, pub fn init(allocator: std.mem.Allocator) ConfigError!Self { const maybe_config = known_folders.getPath(allocator, .roaming_configuration) catch { return ConfigError.UnableToDetermineConfigLocation; }; if (maybe_config) |config| { defer allocator.free(config); // user config path const full_path = std.fmt.allocPrint(allocator, "{s}/triangle/user.toml", .{config}) catch { std.debug.panic("oom", .{}); }; defer allocator.free(full_path); // game config path const game_path = std.fmt.allocPrint(allocator, "{s}/triangle/game.toml", .{config}) catch { std.debug.panic("oom", .{}); }; return .{ .user = loadConfig(allocator, User, full_path), .game_path = game_path, .game = loadConfig(allocator, Game, game_path), }; } return ConfigError.UnableToDetermineConfigLocation; } fn loadConfig(allocator: std.mem.Allocator, ConfigType: type, path: []const u8) ConfigType { var parser = toml.Parser(ConfigType).init(allocator); defer parser.deinit(); var result = parser.parseFile(path) catch { log.warn("unable to read config file: {s}", .{path}); return .{}; }; defer result.deinit(); return result.value; } ```

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

```zig const Input = struct { keymap: KeyMaps, pub fn init(allocator: std.mem.Allocator) Self { var keymap = KeyMaps{}; for (default_keybindings) |entry| { keymap.put(allocator, entry.name, entry.key) catch { std.debug.panic("oom", .{}); }; } return .{ .keymap = keymap, }; } const KeyMap = struct { name: []const u8, key: rl.KeyboardKey, }; const default_keybindings = [_]KeyMap{ .{ .name = "a", .key = .a }, .{ .name = "b", .key = .b }, .{ .name = "c", .key = .c }, }; } ```

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.

```zig pub fn markNewsAsRead(self: *Self) void { self.game.news_read = std.time.timestamp(); saveConfig(self.allocator, self.game, self.game_path); } fn saveConfig(allocator: std.mem.Allocator, Config: anytype, full_path: []const u8) void { const path = std.fs.path.dirname(full_path) orelse "."; std.fs.cwd().makePath(path) catch |err| { // creates parent dirs if needed log.warn("unable to save: {any}", .{err}); return; }; var file = std.fs.cwd().createFile(full_path, .{ .read = false, .truncate = true, }) catch |err| { log.warn("unable to save: {any}", .{err}); return; }; defer file.close(); var writer = file.writer().any(); toml.serialize(allocator, Config, &writer) catch |err| { log.warn("unable to write to config file: {any}", .{err}); }; } ```

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

]]>Crafting, Mods, and Machineshttps://icle.es/2025/05/20/crafting-machines/Tue, 20 May 2025 14:27:00 +0000https://icle.es/2025/05/20/crafting-machines/<p>In this post, I want to explore the crafting system in triangle, especially how mods, tiers, and machine interactions could create depth without overwhelming complexity.</p> <p>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 <a href="https://lastepoch.com/">Last Epoch</a>, you can extract the mods of the items. These can then be placed into another item.</p> <p>It feels like mod crafting would be an interesting way to approach crafting in general. Unlike in the Last Epoch, the extracted mods aren&rsquo;t just combined back together.</p>In this post, I want to explore the crafting system in triangle, especially how mods, tiers, and machine interactions could create depth without overwhelming complexity.

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!

]]>Materialshttps://icle.es/2025/05/13/materials/Tue, 13 May 2025 12:07:00 +0000https://icle.es/2025/05/13/materials/<p>In triangle, everything should feel earned - so all items are crafted, not found. I am also a big fan of factory / automation games. How much of a factory sim can we squeeze into an ARPG (or on to a triangle for that matter)? Let&rsquo;s find out!</p> <h2 id="drops">Drops</h2> <p>As a starting point, when asteroids are destroyed, they will drop materials. I&rsquo;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.</p>In triangle, everything should feel earned - so all items are crafted, not found. I am also a big fan of factory / automation games. How much of a factory sim can we squeeze into an ARPG (or on to a triangle for that matter)? Let’s find out!

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.

```zig var shape = Shape.initCircle(7); shape.move(pos); shape.colour = .blue; ```

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.”

```zig pub fn pickup(self: *Ship, material: *Material.Drop) bool { const magnet_sq = self.magnet_range * self.magnet_range; const pickup_sq = self.pickup_range * self.pickup_range; const dist = self.pos().sub(material.body.pos()); const dist_sq = dist.magSquared(); if (dist_sq <= pickup_sq) { self.save.inventory.addMatDrop(material); return true; } if (dist_sq <= magnet_sq) { // pull it towards us material.body.applyForce(dist.scale(self.magnet_force).sub(material.body.lvel)); } return false; } ```

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.

Crafting Panel Sketch
Crafting Panel Sketch

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.

]]>