The Scrap Engine

Last time I wrote about item variants and randomization in roguelikes, and how Cogmind is purely based on a large set of static items, but more recently I’ve been running an experiment to play with not-so-static items. The entire mechanic revolves around a single new utility: the Scrap Engine.

A new utility is born.

The Scrap Engine operates like the Field Recycling Unit in that in addition to the normal inactive and active states it can also be cycled to COLLECT mode, during which it will “eat” items at the current location. These items are presumed to be disassembled and added to the Engine’s resources in order to be mixed with others and reassembled into new “constructs,” the name for a new category of randomized items. Instead of creating new ones it can also use these resources to modify existing constructs. Although in both cases the results are indeed based on the inputs, the process is not deterministic, so it’s not a pure “crafting” mechanic in that sense.

Constructs can be power sources, propulsion, or weapons. Utilities are generally defined almost exclusively by their effect and its degree, and due to the architecture (that again!) cannot even combine effects (this one is most definitely impossible in Cogmind, unlike the workarounds that enabled randomizable item stats without too much trouble), so no utility constructs, but in the end this is probably for the better due to number of other reasons I won’t get into here.

I was really unsure any of this would work at all, since internally it’s quite complex and therefore hard to gauge what outcomes are possible and whether they’d really fit into Cogmind, which has a pretty strong focus on design balance. In fact, I was unsure throughout the entirety of building the system, which made it rather challenging to work up the motivation to power through a lot of what needed to be done (I normally need to see a clear goal to help with that!).

As with building any complex system, I took the safer route of starting simple, using power constructs as a first test case since they involve the smallest number of variables. Of course that might make them a little less representative of the kind of system we’d need later, and therefore require more changes down the road (spoiler alert: it did :P), but at least it would be easier to wrap my head around this crazy feature while working on the building blocks.

Creating a construct and modifying one are two rather different processes.

Construct Creation

Construct creation requires multiple unique items as input, which is both more interesting and makes more sense since we’re trying to create something new but based on existing parts (which comes in handy as a baseline for proper balance!).

The first iteration simply averaged together the stats of all the input items. This might seem deterministic, though wasn’t necessarily easy to control since the Scrap Engine requires multiple different items to be loaded as resources, but might only use some of those to create a new construct.

Still, simply averaging stats could be more predictable than I wanted, not to mention generated less interesting results by creating items which were basically “neither this nor that” without much chance for real unique qualities that stand out, so I later changed this process to also have a chance to completely ignore a particular input source for the purposes of a single stat calculation.

An example of a new power source created when the Scrap Engine combined a Reinforced Fission Core with a Hybrid Antimatter Reactor, showing the stats of both items alongside those of the resulting construct. Mass, integrity and heat generation values are more or less averages, but fortunately here the hybrid power’s lower energy supply did not factor in, while the total storage capacity was increased.

As you can see it also generates a new name for the item, which can be fun and sort of hint at where it came from, or in some cases its functionality. More on naming later.

Construct Modification

Despite the added randomization, new constructs are not going to be amazingly unique items, for sure, or where the system shines. Modifying constructs is where things start to get crazy.

Like creation, modification generally requires having multiple unique input parts available among the Scrap Engine’s resources. However, the more varied results of modification stem from two primary factors:

• Only some individual stats or properties are chosen to be modified, leaving others unchanged. This can result in much wilder combinations not seen in any of the handcrafted static items.
• Having a greater number of slots occupied by constructs increases the power of buffs, and also decreases the effects of debuffs.

Taking our “Antimatter-Fission Reactor” created before and modifying it with another mid-game reactor that has some significant benefits but also drawbacks to balance them ends up doing nothing to our construct but giving it a much better power supply rate without the drawbacks of the original (which itself has zero storage capacity and is rather heavy). Of course this “Fission-Heavy Reactor” could have turned out much worse if only the negatives were applied, or more middling if multiple stats were modified at once.

While eating certain items gives the player a decent amount of control over what to expect from an initial construct’s creation, that control is decidedly more limited during modification, which is where things get interesting. Controlling the general direction of modification is still possible, given experience with the system, but it’s an overall swingy process that can make a build quite powerful for a time, only to eventually become weaker later on.

Playing this somewhat chaotic style is akin to riding a wave of power, working to creatively survive the downturns to rise again and crush the opposition. In that way it’s actually quite similar to Cogmind’s general premise, losing parts only to rebuild and come back stronger, but for experienced players the troughs of those waves are not usually as deep due to superior tactics and strategy, whereas a construct-based play style will force most runs to ride those waves both deep and high.

No these things are totally not held together using duct tape, regardless of what duct tape Dave here says! (Sketch by Zyalin, a throwback to the old piece featuring a derelict perched atop giant makeshift legs.)

Multislot Constructs

To maintain balance, multislot items used to create or modify constructs have their stats divided by their number of slots, so their “multislotness” is not a property they can transfer normally. Instead, each time a construct is modified it has a chance to expand in size, with that chance falling the larger it grows.

In fact, power and propulsion constructs can only grow in order to increase their effectiveness--having more than one at a time is not possible. This was a very early decision in the design process when I realized that possessing too many unique constructs at once would lead to the same issues I described as potential negatives of having a randart-like system of numerous variables to be familiar with mixed with Cogmind’s gameplay of frequently changing parts.

It’d be fine if there were only a few such equipment slots, but in theory player builds will eventually top out at 12~15 construct slots, which is a lot of items with procedurally shifting stats to keep track of. Too many. Then there’s also the issue of having to ensure propulsion is of the same type for it to be usable simultaneously, which would be a lot crazier if they’re all individual constructs that are changing left and right, and there isn’t even control over which of them undergoes modification. (Hybrid propulsion styles are already possible through the construct system of stat merging, anyway, even if it’s just combined into a single construct.)

Basically there’s no reason to add all that extra complication, so multislot power and propulsion it is.

Hm, fast and tanky?! This screenshot is from a recent run of mine plowing through Armory with a treaded exoskeleton moving at a good clip (84!) due to being boosted with a bunch of combat hover units.

Weapon constructs can expand, because multislot weapons are cool, but more than one is possible and even sometimes desirable, both for handling different scenarios and also to allow a construct build to tweak its weapons looking for better candidates to retain and improve (sometimes they can get so ineffective it might be smart to start one over?). Plus some tactics work better with numerous weapons.

This two-slot cannon construct carried me through a couple floors in my last stream. Five projectiles, all with respectable damage and 9% blast crit?! The main drawback is clearly the massive heat generation, which had me running multiple cooling systems and/or injectors, and still sometimes backing off from larger fights to cool down. But it sure shined when something needed to die fast, especially with a Kinecellerator attached :D

As usual the player can always choose to not evolve extra slots of a certain type, or use non-construct parts to block slots they don’t want constructs to use either for creation or expansion.

Construct-Related Mechanics

Aside from multislot expansion there are actually quite a few nuances to the design that were required to keep constructs fun and balanced…

• As mentioned before, having more constructs results in better mods. This reflects the concept that all such parts are interconnected with the Scrap Engine and other constructs.
• For that reason, removing (or even just losing) a construct also damages the Scrap Engine itself! This puts a cap on what could otherwise be a cycle of tedium by repeatedly eating items and modifying constructs seeking better results.
• Fortunately the Scrap Engine can transform into an armored version of itself by eating armor (so there is a use for some utilities in here, after all!), and also repair itself by eating more armor in that state. This mechanic is vital since the entire build revolves around this utility so it needs to be maintained throughout an entire run! If the armored version is eventually “destroyed,” it reverts to the normal version, giving more opportunity to armor it up again.

All armored up!

• Constructs themselves can also be repaired, a side effect of any modification (35% of max integrity each time), and having constructs eventually take damage is inevitable, so construct evolution is in turn inevitable due to the repair/modification process. This reinforces the “chaotic wave of power” design described earlier.
• Like the armored Scrap Engine reverting to its unarmored version, “destroyed” multislot constructs are not fully destroyed! Instead the construct loses a slot and turns into a smaller version of itself. This is an especially important factor with regard to power and propulsion constructs, which can only improve by growing, since otherwise there’s the chance to suddenly lose all propulsion at once and a need be ready for that at all times, a huge drain on resources. Cogmind part losses need to happen gradually so there is ample opportunity to recover or change tactics before the situation gets even worse.

A powerful 3-slot cannon is shown here in the log being reduced to a 2-slot cannon, so you don’t completely lose your primary source of firepower that might have been carefully “crafted” over time. The replacement is somewhat damaged as well, but it’s better than being totally gone!

• Constructs gain immunity to effects that can otherwise outright remove parts, such as severing or thievery, since good constructs are hard enough to build and maintain as is, so losing one in this way would be pretty devastating.
• Construct weapons are also immune to misfires caused by system corruption, since that would be unnecessarily unfair since they can’t safely be removed in situations where misfiring would have potentially disastrous consequences.

Strategy

Having playtested this new mechanic for a while, I’ve found that it comes with many interesting new strategic considerations, a whole new play style which can be both fun and challenging in its own ways.

Like when to leave some slots empty for a chance to grow an existing construct, since in multislot form they gain a further bonus to their stats as per the normal rules of handcrafted multislot items to make up for their other drawbacks.

Or thinking about when and what to eat, when to create new constructs, or try to modify some, or hold off completely and have the Scrap Engine save its resources for later (leave it off), or even store some resources separately in inventory in order to feed it later as part of a lone batch.

There’s also the balancing of such a build’s constructs and the benefits they bring (especially in greater numbers) against the use of normal items, which are swappable… and predictable :P. How many slots to devote to utilities vs. construct-supporting slot types? The former don’t contribute to construct effectiveness, but are the most versatile slot and useful for any build. Also there’s the fact that the Scrap Engine itself occupies two of those utility slots.

Should one evolve or reserve an extra non-construct weapon slot for swapping potential? On that note, one aspect not yet mentioned is that weapon constructs are only built from guns and cannons, thus excluding launchers and special or melee weapons. The latter categories are excluded from the construct system for having too few relevant variables or results that wouldn’t balance properly, but as normal parts they can still be quite useful during most runs so leaving room for swapping one in might be important depending on strategy or preference.

QoL/UI Features

Any big new feature is likely to need some UI love, so for proper testing including game feel and convenience I added a few new relevant interface bits.

One useful behavior is to highlight all edible items while the Scrap Engine is in COLLECT mode by intermittently blinking them white.

Highlighting visible construct resources while collecting them with the Scrap Engine.

Technically the set of valid targets is a consistent subset of item types, so given time the player will know what they can and cannot collect, but this feature helps learn applicable targets to begin with, and being able to parse the visible map to see all such items at a glance also comes in handy when there are many items scattered about.

One of the more typical but important parts of any new feature is audio feedback, so I added a range of sound effects (in some cases more than one for additional variation since they’ll be repeated a lot) for collecting items, creating constructs, and modifying them. Sure there’s the log messages recording these events, but the audio for a log message is not specific to a given action, so for important actions it’s nice to have unique sound effects for extra reinforcement.

At this time I realized the Field Recycling Unit had been relying purely on the message log to report item collection, so while at it I also added a sound effect for that one so it stands out when you leave it on and it chomps down on that really nice item that was sitting on the floor just the previous turn ;)

The most important supporting UI feature was something I didn’t even plan to implement at first, to add to the “mystery factor” (at least in test builds, where the Scrap Engine was originally code named the Mystery Engine :P). The idea was to not have any built-in way to know what items had been eaten so far, and therefore not really be sure what resources were currently or still available to the Scrap Engine when turned on. But players could (and would) make note of things they were eating if I didn’t find a suitable way to include this in the UI, and if we’re including it we may as well reveal what actually remains, since obviously the contents have a bearing on the potential results, and it’s nicer to at least have some basis for planning with what is already a chaotic mechanic.

Behold, the contents of the Scrap Engine revealed!

The Scrap Engine inventory temporarily appears any time its content changes, e.g. due to item collection or using some to create or modify a construct, and also whenever the Scrap Engine is toggled to COLLECT mode, making that a manual method to force it to appear. There’s a new config setting to adjust the duration it remains visible each time it appears, or turn it off completely.

(I’m sure some players might want this particular window to be something persistent and separately toggleable, but as an item-specific mechanic I’d prefer to keep it automatic if possible, especially since the list can often be rather long and the only place to fit it is over the map view.)

Through observation the list can also be used to learn that the Scrap Engine will only hold up to ten items worth of resources (i.e. ten items) of a given type before collecting new ones starts to replace old ones in first-in-first-out priority. So with enough collection it’s also possible to avoid using the contents and instead replace old items with better new ones if desired. More strategy! This could come into play if for example a lot of low-quality items were picked up during an emergency but ended up not being necessary, or a good construct build was simply maintained for so long that other items originally collected around the same time have already been outclassed by newly available ones.

Construct Naming

While it may seem to be of secondary importance, in fact part of my original drive to make this whole concept work was the potential I saw in creative naming possibilities. I had hoped that the naming of constructs could feel as cool as the names generated by Cogmind’s seed system, a random mashup of item names resulting in some really evocative stuff. “ReactiveArmageddonRifle,” “HypercooledWeaponHammer,” “GodChainStabilizer,” “AerolevSuspensionInjector,” “TacticalProtonAccelerator…” I want to use one of those!

Alas, we’re not quite going to get that level of cool out of construct names, as I’ll explain below, but I do think they’ll be pretty fun. I actually ended up using a somewhat different naming scheme for each type of construct, depending on their needs…

Having started with power constructs as a test case, and being inspired by the seed generation system in the first place, the underlying naming system for these was built in the same manner, breaking apart names of constituent items and merging them to create a new name.

Of course we’re going to need a suffix to represent the type (engine/core/reactor), and also have to obey overall item name length limits so it fits in various UI locations while also being reasonable to read, so I decided to stick with only up to two words pulled from source items. For example a Nuclear Core and Deuterium Engine could combine to create a Nuclear-Deuterium Engine; later modifying it with various Ion Engines could randomly replace “Deuterium” with “Ion” to create a Nuclear-Ion Engine construct. Overall it’s nice for the construct names to reflect what items went into their creation/modification.

In the case where source items are all variants of the same class of power source, such as many Ion engines, instead of the result being an Ion-Ion Engine, which is pretty weird, the naming process would convert it to “Multi-Ion Engine.”

The only other special case for power constructs is the addition of a “Cld.” (cooled) prefix if overloadable, so that the name itself carries this useful piece of information like it generally does for normal power sources. This is an important reason we can’t really have crazy construct names--we’re going to need that space to include meaningful info! (unlike the seeds, which are pure fun and often nonsensical)

An overloaded Multi-Particle Reactor in the parts list. You can also see the ‘&’ character in front of its reference letter, as a reminder that it’s a construct and cannot be removed (akin to the ‘:’ character for processor-like parts, but here an even more special case).

This naming approach was satisfactory for power sources, but the propulsion situation adds new complications.

Right away I decided that all propulsion constructs are dubbed “exoskeletons,” a term generic enough that it can theoretically refer to any form of movement (while sounding cool!), and the actual type of movement appears as a prefix at the beginning, e.g. Flying/Hovering/etc, since we do need that info to be obvious from the name. This gives us the naming format “[type] [unique] Exoskeleton,” where [type] is excluded if legged (kinda the default form of an exoskeleton).

As for the [unique] part of the name, propulsion unfortunately could not make effective use of the seed-like “break down and recombine names” approach. There are too many propulsion items containing either no useful words, or only words that that aren’t reasonably compatible with this system insofar as it’s used to build constructs. So I had to design an alternative for that component, and decided I’d just specify applicable words manually. For example Arm. Treads can contribute the word “Armored,” and Hvy. Siege Treads can contribute the word “Siege.”

(I originally preferred the seed-like system’s method, because it’s dynamic, and once coded shouldn’t require any more attention to content since it will automatically include names from new items as they are added and used--basically less data to work with and worry about, but having a good final result is of course more important, and it’s not like tons of items are being added all the time anyway.)

Propulsion construct names don’t use “Multi-” like power sources do. If duplicate words are all that’s available from the given sources, the name will just leave it at a single word, rather than inserting any kind of hyphenated solution.

This Hovering Siege-Myomer Exoskeleton is pretty fast for its support. Maybe it has other drawbacks… or maybe not!

Note that in some rare cases it’s theoretically possible to fail at assigning a name to a given construct from its source material, in which case it’ll just be called a “Power Construct” or “Construct Exoskeleton,” though additional modifications will eventually rename it.

Weapon constructs have an even more involved naming scheme, being the most complex of the constructs and therefore ideally conveying even more relevant info through their name. The format: [optional prefix] [damage type] [unique] Construct/[G/C].

Construct/C would be a cannon, /G a gun, referring to their type since even though gun constructs can technically become even more powerful than cannons, the difference can have a bearing on at least some mechanics like gunslinging, knockback, and blasting matter off targets.

Again because many weapon names include words that can’t be effectively detected by an automated system, I used the new data option added for propulsion to manually define associated words where applicable, so that’s where [unique] comes from, pulling only one random word to use there since we often don’t really have room for more. The pool of relevant words to choose from is actually weighted by the rating of their source items, and limited to using only those which match the resulting construct’s damage type, altogether an attempt to increase the relevance of a choice while still allowing for some outliers.

I thought it’d be a good idea to reference the damage type in the weapon name itself, but didn’t want to be too repetitive about it, so instead use a list of words related to a given damage type, and pull randomly from that. So an EM weapon might directly insert “EM” for that section, or instead use “Charged” or others.

The prefix at the beginning of a name is optional, but special characteristics of many normal weapons in Cogmind are reflected via a prefix, so I think doing the same with constructs is a good idea. They’re helpful, could be cool, and don’t take up too much space since they’re all abbreviated.

These are assigned whenever there’s some aspect of the weapon that stands out, ranking all potential prefixes that reflect properties which meet a minimum threshold, similar to the point system used by the build classification system first described here, but applied instead to common weapon prefixes.

So a weapon gets a certain number of points towards the Precision prefix based on its positive targeting modifier (if any), compared to points towards Hypervelocity earned via penetration, and so on. Some prefixes sound like they could be based on relative values, for example “High-powered,” in which case its degree is determined by weighing it vs. the average damage of all other other non-construct weapons of the same damage type.

Regardless of degree, certain properties override all other prefixes since they reflect important core behavior: these include guided and spread (arc) weapons, and any that fire multiple projectiles.

Deadly construct weapons! Construct builds overall feel somewhat weaker and less reliable early on, but get progressively stronger into the late game as long as they can be maintained.

Into Beta 12

This has been a pretty huge detour from the main plans for Beta 12, though at least it’s looking increasingly likely this could actually work?

I don’t have any hard player data with respect to this new mechanic since none was included in the scoresheet yet, but the initial idea was to get anecdotal feedback anyway--details and more nuanced balance changes could come later once this feature is established.

For a while it felt like this might end up reserved for some weird special event mode where it’s forced on the player with slightly different rules, though after seeing others toy with it, and playing with it myself, I’m getting more confident there could be a place in Cogmind’s next version to include the Scrap Engine (in terms of design, that is, because lore is actually where it first came up anyway so fitting it in there isn’t an issue). There’s still a need to see people using it in a wider range of scenarios, which I’m sure I’ll see in the meantime while working on other parts of Beta 12.

In any case, building new construct combinations, and dealing with the consequences one way or another, has been a fun experience.

I’ve streamed some construct build playthroughs of my own, in which I talk about the design and strategy while testing it out in actual runs. The first is here: