Claim Engine – Resource Generator

The first milestone has been completed

Author’s note: “First milestone for GoldClaim” – actually not quite, as it’s the first externalized milestone. I have dedicated a post for the internal milestones to prevent clutter.

Milestone Resource Generator

First I need to explain the upper layer, which is the claim engine. A major enabler of this engine is actual prospecting as result of deterministic mining. As mining games and simulators incorporate randomness to both mining and prospecting, I wanted to design the level beyond that to give meaning to prospecting and finding resources. Being able to actually read the terrain allows one to narrow down where to dig next. The resource generator is one of the two major modules inside the claim engine to make it happen.

This chapter is a bit technical, but I have some great visuals and the logic I am about to explain is why it makes the game more authentic compared to other mining games. This module presents one of the reasons for me to create this game.

During the early design-phase, the resource generator was simply a nugget generator. Now it not only handles the creation of nuggets, but any other type of resources as well! It does so bi-directionally, meaning it can also be told to recreate an existing resource – this reduces the required memory to both run and save the game. This keeps the runtime memory and save files very small – critical for console performance.

The resource generator is one of the claim engine modules I am building. It’s composed of these modules:

Claim Engine
├─ ClaimChunkRepository -> backlog
├─ ClaimContracts -> on-going
├─ ClaimGenerator -> next up
└─ ResourceGenerator -> what this page is about

Chunk Repository: This one is done lastly when all requirements are detailed enough. The chunk repo just manages the chunks, just like a single block in Minecraft or 7DTD is stored for example. It has a position and has certain properties, and must be managed by a repo.

Claim contracts: Literally software contracts. This one gets too technical, but let’s assume this tells the other modules how they should interact internally and with each other – it even extends beyond this engine which is the beauty of contracts.

Claim generator: Not yet started one, but the next module to be tackled once the resource generator is finished. It’s to create the actual claims in such a way that mining is made as intuitive and gameplay-rich as an indie game should go. The fine balance between utmost realism and non-tediousness for lack of a better word.

And finally the module represented by this page, the resource generator – let’s continue.

The resource generator is capable of handling a biome’s composition, or rather the exact geomorph-type present on that biome to generate resources within that setting. This is what it’s now capable of:

• Resources will reflect the biome, meaning you can even trace back where a specific type of nugget came from
• In GoldClaim, not one nugget will (statistically) be the same
• There’s no AI involved – this is pure mathematical- and art prowess created by a mad scientist
• It supports modding out-of-the-box for new types of resources with simple, intuitive JSON-scripts
• Generated resources can be regenerated using the output JSON, with less than 1 KByte of data (this means great flexibility with both savegames and ability to (re)generate the resources on-the-fly)
• It allows custom textures per resource – I’ve hand-designed all of the resource textures already
• It allows any shape to be generated within the defined threshold, and there are many levers for modders available

Small footnote for modders

Do you like modding? If yes then you might want to read this, otherwise it’s fine to skip ahead to the generated resources as it gets more technical.

GoldClaim will embrace the modding community, to be as creative as possible. A single resource can be regenerated with the tiny JSON script below:

{
  "Version": [1,0,0],
  "Seed": 774548,
  "Guid": "9202b1ca-929b-48d3-9370-cd0c0c4e5acf",
  "ResourceType": 1,
  "GeomorphType": 2,
  "QualityType": 0,
  "Purity": 0.68676215,
  "Quality": 0.5512
}

The seed parameter might seem redundant as there’s a GUID, but it’s solely to feed the RNG (random generator) – I’ve chosen not to infer it from the GUID (globally unique identifier), meaning less complexity. You can use your own RNG, or let the engine handle it.

The types will be made public once the game is released to prevent spoilers for now.

This script enables batch generation within defined rulesets and can be extended with custom textures and new shape definitions. You can literally generate millions of resources, while the engine won’t flinch and still only have a couple of MB (well, compressed) of asset metadata.

The best thing? While in-game, the GUID-dataset is the only required data for the currently visible claim. The actual script is to be called while sluicing, but it’s not until examination (during the gold cleanup) that the regeneration has to take place, and it can be instantiated on a separate thread as well. This means we can go nuts on creating millions of deterministic, unique resource entities and still see it all, for tons of claims even running on the background (e.g. by competitor NPCs). You can even put its unique shape on display in your own home if you want to.

The generated resources

So the question might be how it translates to the game: This little furry desert-rodent below holds something shiny – a golden nugget which is a direct output from the resource generator. The second image displays the actual used nugget among the others:

The resulting nuggets have a flat texture. I will let the game engine account for lighting/specular/shadow FX, just like I did during the post-editing with the jerboa.

Inner workings of the texture variations

Textures are ‘stamped’ out of a large texture map (not an atlas), and the engine can rotate/flip it and apply it to a custom silhouette. This results in additional variations, without the extensive complexity of generating a random texture map per type of material. The engine first generates the silhouette based on geomorph parameters limited by its current biome, determines the quality, size and even whether it’s rounded or angular (e.g. rivers produce more rounded nuggets, where mountains produce angular + perforated ones).

Other generated resources

With the image below I want to demonstrate 4 other resources the engine is capable of producing in its current state, and I can truthfully state that they’re a direct output from the resource generator as well:

It’s already capable of generating more resources, virtually any solid resource. That said, the presence of gold and silver is a given, but simply adding other resources isn’t that simple, as it has to maintain economic balance and integrate with both the biomes and mining machinery. I might do another pass on texturing and lighting/shadows for the 9 current resources, but for now I call this MVP-worthy.

Resources on claims

The game is going to be top-down and mixes both sprites and 3D geometry for claims thanks to the hybrid-approach I’ve chosen. As much as I like to get to that, it’s a bit too detailed for now. What’s important is that when you start a new game, the claims and its resources will be determined at that very moment, which separates it from other mining games:

• Average mining game – They involve having an RNG (random generator) the moment you’re mining/washing. Keeps the logic simple and performance high with random behavior as trade-off. This is the go-to model for large claims, especially in an RPG setting.

• GoldClaim – The engine tackles all: The composition of all claims will be handled deterministically while keeping the memory footprint low. Not events, not stories and not even the game’s difficulty will meddle with it.

I’ve reasoned the difficulty is never about the location/composition of resources. When it’s in the ground, you can trust it will be there. It’s up to your sluicing skills and machinery whether you’ll have it in your pan or tailings. Also, tailings aren’t indefinite waste. This does mean that performance issues will creep up, but like I said, this has been tackled gracefully while even still supporting modding capabilities. The true trade-off was on the development side: More logic means longer design times, implementations and testing.

What we get in return is:

• Enable true motherlodes – my personal favorite
• Prospecting suddenly becomes meaningful
• Accurate balancing -> less post-MVP balancing, less bugs to be fixed
• Decrease ‘reroll’ exploit temptation when acquiring a claim or even mining a chunk in a suspected motherlode

Here’s a visualization of how a claim will actually be generated computationally:

The yellow spheres represent nuggets injected into the 3D-space of a claim, whereas the ellipsoids represents the motherlodes. Note that a higher density of nuggets also indicate the possibility of a nearby motherlode.

Resource generator internals – for the architectural enthusiasts

Messy technical details below, so skip ahead if you want the short version.

In the image above we saw a large claim in wireframe: 100×100 meter grid, 20 meters deep. Every sector is actually locked to already defined parameters, from the very beginning, buried deep in the design documents:

1 sector = 1 chunk. A chunk is 1x1x1 meter, 1500 kg cap if overburden or paydirt, 1000kg fixed if water. While players and machines mine per chunk, the actual contents of a chunk can be less than the weight cap. It’s a composition of dirt, rocks, minerals and precious resources.

I’ve hidden the chunks in the claim above and you can clearly see it’s quite nugget-rich with the nuggets displayed as noise (the tiny spheres) in the paydirt, and 2 large ellipsoids. These are not super-giant nuggets. These are the radii in which gold dust, flakes and nuggets have the largest concentration -> this is what you want to find in a claim. Even I can no longer tell where these motherlodes will occur once I let the engine do what it’s made to do – they can even intersect each other. Also, it will be biome-dependent on whether they’d rather sit deep onto the bedrock, or rather in deep abrasive river pockets.

I believe this alone is a big win for mining enthusiasts like myself, as it makes sense to actually prospect a claim, determine whether you want to acquire it at all at your current stage. But perhaps even more exciting, hone in on the actual motherlode and believing it either is there or isn’t – No real-time reroll randomness manipulating outcomes. A should-be mental switch for enthusiasts as the world won’t be cheating you at all, and like I stated before, not even the game difficulty will change a thing.

The reason this method may not have been applied before, is because it increases the logic immensely and requires extensive mathematics, but it’s more easily solvable using code.

Summary

So to wrap it up: The resource generator is part of a larger claim engine composed of chunk management and deterministic generation logic, capable of placing motherlodes at any place. Anyway, this is how it translates:

• ellipsoids with a certain falloff have to be cast to create the motherlode
• additional richer deposits could overlap others
• the regular resource allocation’s ‘noise’ has to be either deducted from or added to those ellipsoids

Next up: Claim engine

The next milestone is finish programming it. It should be done next month, unless I find an unforeseen dependency which is still allowed to happen at this mixed stage of design and implementation.

Also, kudos to whoever has read this far – I have trouble holding back whenever I can open up on engine internals for a project like this and it will get technical then.

– Litanic