Random Parts in My Cogmind?! (Patreon)

Okay so things are a bit behind schedule. Beta 11 is supposed to be mainly about a new faction, and then there was the whole Garrison thing, and then the whole Garrison+W thing, and more recently a whole... other thing that's beyond the original scope, like really beyond xD

So the new faction of course needs to have new tech, and for a long time I've had a general idea of what this new tech would be, adding at least two new big mechanics to the game. But then I had this idea for a third, and it's kinda wild, but decided this is the best opportunity to try it out, so that's what I've been working on, and since it's still not out yet, I should at least start talking about it here so you know what's up.

By design Cogmind has always had static items. You learn about them as you discover them for the first time, and their stats are familiar so you can build around them and know what kinds of parts are available, and where. Robot builds are static for similar reasons, enabling you to gradually build knowledge of the world and be able to plan around it, while at the same time also needing to look up stats less and less as you play, since you already have an idea of what something can do, and whether or not it's a part you might want, or an enemy you need to use particular tactics to deal with. There's enough content out there for the variation to exist in *what* you encounter, rather than making each  thing unique for uniqueness' sake.

Well, as long as we don't go overboard with it, I do think it would be fun to experiment with randomized parts. Not just spawned everywhere, mind you, but only available through specific means, and definitely limited in terms of scope, like other bots won't be able to use them. This is because Cogmind's architecture was of course built on the foundational assumption that parts have static values, so... yeah I've had to get really creative to work around this limitation!

Under the Hood

Normally at startup Cogmind loads all the game data, including item stats, and references it during play. As with most games, each "instance" of an item (for example each Assault Rifle you have attached, or in inventory, or on the ground) does not store a complete set of stats. Instead, it will store a subset of values that might change, like its current/remaining integrity, because they all have the same max integrity and we don't need each of them storing that separately, right? For that value we can just check the reference data, since it doesn't change anyway.

Items only storing a small amount of variable data is a pretty clear obstacle to giving parts unique randomized stats. The solution (or, uh, crazy workaround) which will require minimal changes elsewhere in the game is to reserve a number of slots in the item reference data and allow them to be modified as well. This theoretically enables randomized parts to work pretty much seamlessly as far as the rest of the architecture goes, but naturally comes with its own limitations. Modifying underlying reference data simultaneously modifies every instance of the given part, regardless of where it is, hence my earlier mention of limiting these to use by the player only, and even not allowing them to be dropped, since that could lead to just way too many of these things bloating the database.

This approach also requires saving some relevant item reference data along with the player save, which wasn't required before all this. Anyway, I'll likely do a somewhat more detailed writeup on the architecture of this sort of thing later, but wanted to provide some background.

The Scrap Engine

Where do these random parts come from? They're created, by a utility. Not just created, either, but modified as well.

The "Scrap Engine," which I think is what it's called, operates sort of like the Field Recycling Unit with its three settings: inactive, active, and COLLECT.

While COLLECTing, it eats parts from the ground, and while active it disassembles them into components and reassembles them into new parts based on those. Although results are based on the input, the process is not deterministic, so it's not a full "crafting" mechanic in that sense.

Also it can only create power sources, propulsion, and weapons, but not utilities--utilities are not all that interesting when it comes to this kind of mechanic, so they will be left out and the other areas are where it will (hopefully) shine.

There are certainly quite a few more nuances related to this mechanic, and the intentions behind its design, but we'll get to those eventually. At this point it can't yet even create or modify weapons, which will be the most complicated category to implement.

As a test case I originally started with power sources, since they are the simplest part with the smallest number of stats. (It's often a good idea to start with simple cases when working out how to build the foundation for a new system in the first place.) Here's an example I shared on the Discord a while back when I first got it working:

Don't worry about the numbers right now--the system hasn't been balanced yet, as I'm first just trying to get the implementation and behavior correct. As you can see it also generates a new name for the part, which can be fun and sort of hint at where it came from, or in some cases its functionality.

Randomized propulsion is now operational and I'm ironing out some details there before moving on to... weapons, oh my.

The actual way you're supposed to gain access to this feature has not yet been added to the game, so the next build will just give it to you for free early in the game, around the depth where you could have it, and let you try out the possibilities and see where and how it works and doesn't work.