Items: Types & Distribution

Items are at the core of many a good roguelike experience.

While inherent abilities and character traits can play a part, wielding/equipping/using new items is the simplest way to open up different strategic and tactical options. As covered in the previous post, Cogmind takes that to an extreme with the philosophy that you “are” your items. They are the source of all your abilities and most of your HP, and they can be found throughout the surroundings, or blown off other robots for your own use.

In the context of Cogmind, “items” is nearly synonymous with “parts” (components). Aside from matter, all items in the 7DRL prototype are attachable parts, and that will continue to hold true in this new version (except for the possible addition of a few rare and special items for use as “crafting ingredients,” which are now supported).

I’ve just finished compiling the list of parts, which is heavily based on the original list as that was already a good start, if in need of a bit of reorganization. The original 7DRL list consisted of about 400 parts; the new one has more than 600.

That may seem like a lot, but it’s not many when you divide it up among the different types of parts out there.

The lines in each section indicate sub-type divisions.

The number is even less significant when you consider all the possible sub-types of weapons, utilities, and propulsion, each with their own tactical purpose.

Item Types

The four primary categories of parts have been mentioned several times before, but that general classification exists purely to designate which parts are compatible with each slot type. Item sub-types within each category can be functionally quite different from one another.

Power

Power components are divided into Engines, Cores, and Reactors, but these are purely cosmetic differences for low-to-high progression in terms of energy output, making it a little easier to distinguish which are likely to be better.

Propulsion

Propulsion components run the spectrum from slow with good support to fast with little support, though you always have the option to load on more than you can carry at the cost of reducing your speed. (The penalties vary by form of propulsion.) For simplicity’s sake you can’t simultaneously operate more than type of propulsion, though you can mix different variants of the same type--multiple different kinds of hover units, for example.

• Treads: Durable and able to support the heaviest builds, though slower than other forms of propulsion.
• Legs: Good integrity and balanced support-to-maneuverability ratio.
• Wheels: Not very sturdy but easy to obtain from ubiquitous worker robots. Provide fairly good support for their speed, especially when using many at once.
• Hover: Structurally weak, but fast when not overloaded.
• Flight Units: Easily disabled, but extremely fast when not overloaded. Also capable of flying over enemies that are otherwise blocking doorways and narrow corridors.

Utilities

My personal favorite category because there’s so much you can do with them. Being flexible certainly increases chances of survival.

• Storage: Resource containers like batteries (energy), compressors (matter), and part storage (inventory size) to expand your existing capacity.
• Processors: Small computers providing or enhancing a wide range of abilities. Includes most of the tools necessary for information warfare.
• Hackware: Akin to processors, but apply specifically to hacking and are therefore split into a different category so as to be instantly distinguishable on the map.
• Devices: Larger gadgets and systems with a very wide range of special functions.
• Armor: Both generic and specialized protective plating.

Weapons

While you don’t need too many weapons to be get by, carrying a larger variety will enable you to maximize effectiveness in different situations. In any case you don’t want to be without at least one or two lest you be forced to ram enemies, which is not good for your health!

• Guns: Most common class of weapons. Further subdivided by damage type, which each have their own mechanics: Energy/EM/Ballistic.
• Cannons: More devastating and resource-hungry than guns. Like guns, also further subdivided by damage type.
• Launchers: Fire explosive projectiles or EMP bursts, spreading damage over a wide area. Capable of striking each target multiple times, though often not as effective as pinpoint damage from guns or cannons.
• Special: Non-projectile weapons with unique mechanics. Includes flamers, stasis beams, and tools usually for mining and construction.
• Melee: Close combat weapons for physically striking targets. Further subdivided by damage type, which also each have their own mechanics: Impact/Slashing/Piercing.

Once you divide the full item set into this many subcategories, the item count starts to seem a lot more modest.

Item Distribution

In a game this focused on items, how they’re distributed throughout the game is an important issue to tackle. Central to the distribution scheme is the concept of “effectiveness rating,” essentially an item’s “level,” of which there are nine.

In game design in general I prefer avoid simply adding items with “bigger numbers,” emphasizing trade-offs instead. That said, higher-rated parts do usually have bigger numbers and are almost always better than their same-type counterparts (otherwise the label would be useless) to represent more advanced technology. However, number increases are tame enough that common end-game parts are only about two to three times as effective as the earliest parts, and while you’ll generally try to use the most effective parts you can, weaker parts can sometimes come in handy when you simply don’t have the power available to support the latest prototype cannon, for example.

So given that you may find yourself in (or even create) situations in which lower-level parts are useful, to an extent these parts should be available in later levels as well. Plus this will help add to item variation rather than always finding the same few types of items in the same areas.

Technical

The 7DRL item distribution scheme was extremely simple (like everything else in a 7DRL…), but effective. Items were randomly chosen from a pool of those with the same rating as the player’s current depth, with a 50% chance to choose an item with a lower rating. Before choosing the lower-rated item there’s a 50% chance of dropping the rating again, and so on until a final rating is chosen. As the world expands outward the game needs a more complex system, and one that will provide enough control to simplify later tweaking and balancing.

Because it’s meaningful to gameplay as mentioned above, Cogmind is keeping the concept of range-based distribution. In addition to the existing “rating” value, each item also sets several parameters that further define where and how often it may appear.

The first is “area,” which determines what types of maps may generate the item, which can be general (“any”), somewhat specific (“any controlled by a certain faction”), or very specific (“only this type of map”).

The second is “depth,” which determines the formula used to calculate the chance of choosing that item at each depth (if it’s available at all). This ranges from “anywhere” (equal frequency at all depths, for basic/common parts), to “wide” (at-rating depth and the five depths above it with decreasing frequency), to “narrow” (as wide, but only spread across three potential depths).

The third is “rarity,” either common, uncommon, rare, which determines the base value used in the depth formula. During the random selection process, items are not weighted equally. If so it would be impossible to mix items of multiple ratings and parameters in the same pool (which is why the 7DRL took an easy shortcut by first selecting the rating, though that resulted in a oversimplified system). For each map the game precalculates a pool of selectable items and their respective weights.

In the spirit of tweakability, all aspects of distribution are controlled via keywords used in the text file data. If necessary changes can be made directly to the distribution handling code without messing with the data. The data also contains a couple other parameters for balance purposes, namely a limit on the number of a given item which can appear in a single stockpile, as well as a map-wide limit on how many of that item can be generated.