Official development blog
[ Latest Cogmind Release Notes: Feb 2026, "Unchained More" ]

ASCII Particle Effects

By Kyzrati | Published: March 15, 2014

With item stats out of the way, it’s time to start fleshing out item-related content. To that end progress is being made on three different fronts: Item art, weapon sounds, and weapon particle effects.

Procedural particle scripts are a great time-saving substitute for hand-drawn animations. They also lend a unique visual appeal to the otherwise minimalist-informative interface of a static grid-based world. All weapons will have their own particle effect, so you can pretty easily discern the type of weapon being fired (sound will also help in this regard) and we no longer require “X attacks Y” log messages--if you must have all the juicy details they’re still available via the separate and optional combat log.

When the old 7DRL version was born, it simply imported a large library of particle effects along with the X@COM engine. Due to time constraints all I could do was spend a few minutes recoloring a few of them, so in the end many weapons used similar effects. A few months back I took some time off coding to rewrite and expand that particle collection, giving it a greater variety of styles tailored to Cogmind. Because the final weapon list was not ready at the time, the designs carry generic labels--now it’s time to tweak the particles and assign them to specific weapons.

The current “official” set of generic particles so far contains:

  • 7 ballistic projectiles
  • 12 lasers
  • 4 plasma blasts
  • 5 rockets
  • 7 special launchers
  • 24 explosions

You can tell I’m fond of explosions ;)

These numbers indicate different “styles,” not an absolute number of effects, because a recolored variant of any given style can be created by adding a single line of script.

Here’s a composite screenshot showing a few different projectiles and explosions:

cogmind_particle_effects

A missile, explosion, plasma, and EMP blast.

The animations look better in motion:

cogmind_weapon_particle_effects_1

Minigun, followed by cannons and lasers.

cogmind_weapon_particle_effects_2

Lasers, plasma, and flamer.

cogmind_weapon_particle_effects_3

Rockets/launchers and explosions/EMP.

Like everything else Cogmind, the particles are controlled entirely via external text files like this one:

cogmind_explosion_scripts

The highlighted area is a script defining a single incendiary explosion. (click for full size)

The result of the script highlighted above is this explosion:

cogmind_incendiary_explosion

The base color of the explosion can be anything, as set in a single script variable.

Technical

Recoloring, or creating multiple variants of the same particle with slightly different behaviors, is simplified by templates. You can see them in the scripts above listed as red text containing the values to substitute. (Note: All those “TK”s are there because I haven’t yet associated them with any specific weapons.)

Just before the engine parses particle data, it checks for templates and automatically generates all applicable variants of each type of particle. Thus particle designs can be abstracted to their most general form (without specifying color, for example) for maximum reusability and minimal copy-pasting.

With regard to weapons, in most cases templates are simply used for recoloring particles. Templates are technically capable of substituting any kind of parameter--other behavioral adjustments such as particle speed and lifetime are more often used for creating multiple variants of interface animations.

From an implementation perspective, the coolest new feature of the Cogmind particle engine is that it can be dynamically loaded! This is a huge time saver. All particle data can be reloaded at the press of a button while the game is running, meaning we can tweak and edit particles in the text files and see the results immediately in game.

A lot of interdependent factors determine what a particle effect looks like, so creating/changing one can take a few tries. Having to make a best guess and restart the game with every tweak was getting really, really annoying, not to mention slow.

Posted in Art | Tagged , , , , | 2 Responses

Balance

By Kyzrati | Published: March 10, 2014

Balance is one of the most important determining factors behind the “fun” of a game. Games that are balanced just right tend to create situations that keep you on your toes and allow you to barely scrape by, while also ensuring that you don’t feel outnumbered and helpless (or completely unstoppable) every step of the way.

Imbalanced games on the other hand are rarely fun, except maybe for those players who enjoy frustration (and in the case of those few games which are designed with the intention to create imbalances, but they’re beyond the scope of this post).

Being so important, balance should naturally be considered in every part of a game’s design from mechanics (ex: are ranged and melee combat equally viable?) to data (are these tools effective enough to overcome the challenges that appear in this part of the game) to even overall experience (is the game an endless string of tiring encounters without giving the player time to rest their mind/fingers?). Most of the mechanics in Cogmind are known to work well, having survived plenty of playtesting at the 7DRL stage. Now we’re moving on to content.

As mentioned before, items (parts) are at the heart of Cogmind’s gameplay, so that’s where balance deserves the most initial attention. It’s also therefore the first part of the game content which is being shaped.

Balancing any game (though even more so deep games) is very much an iterative process. There are so many moving parts that even a “final” data set will be tweaked based on how later developments affect gameplay and according to unforeseen emergent results discovered only through extensive playtesting.

Here I’ll lay out the general steps taken to get Cogmind where it is today.

From End to Beginning, and Back Again

I like to begin by defining ranges of data that will shape the final player experience. So first we have to determine what that experience should be. How many encounters should a player have in a given area? How long should a single battle last? How many average opponents should the player be able to confront without too much trouble? How many should be necessary to challenge the player? Defining, and then answering, these questions is the crux of what I like to call “teleological game design.”

With specific answers in mind we can start to play with numbers that will achieve our goals. The use of data “ranges” is important since it allows us to examine what happens at both extremes: Initially we only care what happens in the low-level early game and high-level late game--once those are working we can easily extrapolate the progression in between. Working with min/max values enables us to more easily understand and contain the experience within those confines, to be sure it will meet the goals we set earlier.

To illustrate I’ve unearthed a relic of the 7DRL2012 era:

cogmind_7DRL_notes

Notes from the Cogmind 7DRL.

Okay, that’s not the best illustration of my point here, but I only have a few pages of those notes left and thought it’d be fun to share them ;)

Those notes are actually making horizontal comparisons of propulsion types to ensure each is viable in some way, further informing the next step: The real data ranges used to create the original 7DRL data can be seen below in digital form.

cogmind_7DRL_data_ranges

Reference data used to create items for Cogmind 7DRL in 2012.

A slightly modified form of this list exists for the new Cogmind, but most of what you see there still holds true. So where did the numbers come from? Me answering the original questions, then trying out a few key reference numbers and extrapolating the rest to reach the goals.

Professional game designers use spreadsheets for this kind of thing, but I wasn’t going to spend my precious 7DRL time fooling with anything but source code, so I relied on simple brain-powered calculations.

That said, with more time I have since gone back and created a spreadsheet tool that enables me to quickly see how certain data changes affect the answers to my questions.

cogmind_data_spreadsheet

Spreadsheet of key values for predicting results to aid in designing/confirming data.

Yellow fields are input, dirty yellow fields contain “stepwise” calculations, and green fields show the output. I played around with it for a bit, but haven’t yet had a strong need for it since the new data set is heavily based on the old one, which as stated went through lots of playtesting already. The spreadsheet is very much incomplete at the moment, since at the time I was only really looking to get “no. turns to kill” calculations for enemies given certain Cogmind loadouts. I will probably revisit it later when working on enemy robot builds, but at that point the game itself will also be outputting calculations based on actual designs.

Balance is, in most cases, “measurable” if you can figure out the right equations, abstracting out as many non-essential variables as possible in the process. But as much as I seem to be preaching number crunching and spreadsheets here, I still prefer to go on gut feeling when I think I can get away with it ;)

The Real Thing

Armed with our data ranges, it’s time to move towards creating actual game data.

For this step I always rely on templates. The value ranges can be used to define a template for the lowest- and highest-level item of each type, and a table is formed extrapolating templates for all items in between. Cogmind uses a simple linear progression (over a rather short range, too, to ensure that older parts are often still viable later on).

cogmind_item_templates

Item templates. Some of them, anyway.

These template values do not necessarily match any given item, but serve as reference points for the items-to-be, keeping us aware of where each item fits into the original goal scheme. Essentially we’re remaining as loyal to the data ranges as possible, since we know those should be balanced. The danger here is if the ranges were wrong in the first place, everything’s going to be wrong now, but if they were right, then there isn’t a whole lot of tweaking to do! Assuming our templates are correct, many individual template values can still be adjusted to make each item unique without undoing the overall balance.

Now we have a huge table of boring nameless templates. Time for some of those cool items we know we want.

I don’t just dive in and start applying templates here. In the case of Cogmind, it’s more important to first look at the overall distribution of item technology and make sure the progression fits each level thematically. All items originate from the simple but effective Master List.

cogmind_item_master_list

An excerpt from the Cogmind Master Item List.

The list indicates what level each item will be (i.e. what template to start with) and whether it’s considered a prototype (‘*’), among other things. It’s nice to have a separate list for this purpose since distribution is very important, and this is a way to clearly normalize that distribution without being distracted by all kinds of other data that defines items.

Finally we take that list and start creating items using the templates as reference points.

cogmind_items_xt

Item Data. At the top you can see some of the weapons from the Master List. Utilities, at bottom, don’t make use of regular templates since they are too unique.

I like to leave the original templates in the final list for reference, and they also do a good job of visually separating each level to make parsing much easier.

Now I’ve touted the advantages of a tab-delimited table format for game data before, but here’s an example of where it really shines. During the initial item creation process there are a lot of vertical comparisons going on. The ability to glance up and down a column to make sure the new item’s values are properly relative to those of same-type items, different-type items, items with the same special feature, etc. is invaluable. The cross-comparisons wouldn’t be as necessary if we stuck closely to the templates in every case, but that would also result in a pretty boring set of items.

So I just completed the data for about 600 base items that will appear in Cogmind. It was much easier following several days of extended play sessions, since with the game context fresh in mind I could always ask myself “Would I want to use this? Why or why not?” and tweak accordingly. (I should mention here for anyone who doesn’t know that I was able to play the game before doing this data set because 400 of the items already existed for the 7DRL--i.e. I’ve been through this process for Cogmind once before, but I’m doing it all over again to make sure it’s what I want.)

When it comes down to it, if while playing there are frequent difficult choices between multiple items as to which should be used immediately, which should be carried along for later, and which should be left behind for the recyclers, then I’ve succeeded. Of course the information to make that choice should ideally be available to the player--said “difficultly” comes from trade-offs. In Cogmind there are a lot of trade-offs. This is doubly so because you aren’t limited by “class” or “race.” You can literally equip and use every single item in the game, including anything your enemies use!

Now that item balance is done*, next up is all their particle effects, sfx, and art. Oh my.

*Haha, we all know that balance is never quite done.

 

Update 220311: If you’re interested in learning more about balance work, including plenty of charts and even videos, I have more recent coverage of my reviewing and updating of Cogmind’s balance after ten years of development.

Posted in Design | Tagged , , , , | Leave a comment

Playing Your Own Game

By Kyzrati | Published: March 5, 2014

You finally did it! You made the game you always wanted to make, and now you get to play it!

It’s funny that the reality can be quite different, at least for a certain kind of developer and/or project.

Many worthwhile game ideas start out with a simple “Wouldn’t it be cool if…”, so you spend forever making it a reality, and the end product is a work of passion that hopefully doesn’t betray the previous months or years of sweat and tears.

cogmind_box_art

One day on a virtual shelf somewhere. The closest I’ll ever get to a 3D game ;p

I bring this up now because for the past few days I’ve been actually playing Cogmind, and am again reminded that playing your own game is a very different experience from playing someone else’s. Even if it’s that “dream game” you’re making because no one else will, while it may be fun (Cogmind definitely is!) it’s difficult to fully immerse yourself in the game world and play it for what it is. This is true of any work of art (yes, games are without a doubt works of art), though more so with games because they are often very long-term ongoing projects.

One can’t help but notice every little feature that could be fixed or improved. There’s simply no time to “play.” I recall Tarn Adams (of Dwarf Fortress fame) having said something to that effect before, and suspect the bigger and “dreamier” the project the more likely this is to be the case, given the depth and all the moving parts. Stopping every few moments to jot down notes, dive into the code, or think about what’s going on behind the scenes is not what the player should be doing!

You’re also so close to the project it can lose that appeal of “new content discovery.” Fortunately with roguelike development some of that appeal is regained through the randomness of procedural generation. Repeatedly playing the exact same maps when developing a static game would be pretty boring.

Fixin’ Stuff

These recent sessions are a bit of an exception to the topic above because at this stage I’m playing specifically to examine balances between the various systems. I was fooling around with spreadsheets for a little while (more on that in the next post), but there’s no substitute for straight up playtesting considering all the factors involved. So in the past few days I’ve played more than I ever have before. Back in the weeks following 7DRL 2012 I started up the game thousands of times to test features, but only truly played two or three full games!

This round of playtesting used the good old 7DRL data set. The purpose was twofold: Check which stat ranges needed major adjustments, and decide more specifically how to properly fit melee combat into the gameplay experience.

The primary known issue, and the target of most of the tweaking, was the somewhat broken propulsion system. The mechanics work fine, but the data values made hovering and flying rather infeasible compared to the other forms of propulsion. They’ll work now, though flying fast will still require careful management of resources, and may only be an intermittently available option since you may have to refit yourself with heavier gear to survive certain areas depending on what the RNG throws at you. Light builds will be a lot more viable with allies around, but I’m not testing the game with allies just yet.

In a normal game you were also overweight almost all the time regardless of your propulsion, which made that status fairly meaningless. All propulsion now supports a lot more mass, but most also have a slower base speed to keep the system balanced.

Melee combat, a.k.a. “Cogmind gets bump to attack,” should be pretty fun. It’s slower and limited to close range only, but quite powerful with some special effects/mechanics that have been described before. A good volley of guns and cannons will be preferable in many cases, but certain builds could emphasize melee combat, and it is always good to have a melee weapon as backup for the low resource requirements and fact that as less intricate systems they are more likely to survive to the last when your other weapons are being targeted and destroyed. The last couple test games were spent hacking pieces off enemy robots using weapons with cool names like “MELEE_S4″… (since the 7DRL had no melee combat).

For the record, my first run after more than a year away from playing Cogmind took me 80% through the game, all the way up to the impenetrable difficulty barrier that is the research level (due to poor balance that was never fixed--the 7DRL didn’t have any significant content updates, just fixes and new GUI features). That’s another thing about playing your own game: You’re generally really good at it because you know how everything works. (I’m betting that Thomas Biskup not being very good at ADOM is an exception to the norm here ;)

The next step is to finally generate some templates for handling item stat progression, then start designing those items! That’s another practical reason to insert a period of playtesting at this point--to refresh my memory and give some context for assigning suitable values.

Posted in Design | Tagged , , , , , | 2 Responses

Items: Types & Distribution

By Kyzrati | Published: February 28, 2014

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.

cogmind_item_types

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.

Posted in Design | Tagged , , , , | Leave a comment

You, Cogmind

By Kyzrati | Published: February 23, 2014

Here we are six months into this blog and there hasn’t yet been a post dedicated to the game’s namesake robot!

Unlike a majority of roguelikes you don’t start the game by selecting a race, class, or anything else. You play Cogmind, more or less a “naked robot core,” and are quickly defined by what components you attach while traveling around. (If you don’t know about components, catch up by reading the post outlining the game’s core concepts.)

The lack of a character creation process is both a boon and a drawback. Games are quick to start and restart, and the game is much more dynamic as you’re forced to “think on your feet” by solving problems using only what you find. At the same time, by not making your own character you don’t start with that immediate sense of attachment from having created something right off the bat. And honestly character generation can be the most fun part of some games (I am guilty of spending more time “rolling characters” than playing some games ;p). This is not one of those games. But trying to appeal to everyone in the crowd will just result in a horrible game, so no char gen.

There is even little permanence in whatever build you scrap together from component stockpiles and the remains of your enemies, and not just because you’ll find better parts to upgrade. Part integrity is essentially your “HP,” so 1) you’ll be destroyed fairly quickly without any parts covering you and 2) in order to spare you an untimely death your parts will be blown off one after another.

So your “HP” is at the same time your ability to generate energy (power sources), move (propulsion systems), fight (weapons), etc. (utilities). You lose and gain protection and capabilities in tandem, meaning the more you expose yourself to combat the less “capable” you become until you can find new parts to attach. At this point even “useless”/sub-par parts can be more useful simply because they offer protection. I imagine not enough 7DRL players realized the implications of this mechanic. Who cares if you don’t need/want that wheel sitting over there--if you’ve got the space pick it up and strap it on to block shots!

Thus combat is also the catalyst driving the dynamic nature of the game, sometimes forcing you to adapt to a new set of parts found at the last minute while surrounded by an enemy patrol. Parts are actually fairly easy to come by, even if you have to salvage used/damaged ones left in the twisted remains of your enemies. Survival is a question of staying effective long enough to find the exit without being overrun and losing to attrition, though that’s easier said than done since a situation can quickly cascade into a complete mess if you’re not careful.

You can also avoid all this by doing your best to stay away from combat (always advisable, since it’s dangerous in the long-term and usually not required).

On the subject of build permanence, aside from the optional stealth approach there are numerous other mechanics in place to keep you equipped with the parts you’re particularly fond of. For one, parts are generally found in stockpiles containing multiple identical copies, so you can carry spares with your limited inventory space (expandable via parts, of course). Protect entire categories of attached parts (e.g. “weapons”) by shielding them (essentially parts that shield other parts). When you do lose a favorite part, if you have the schematic (obtained via hacking or analysis) you can build one yourself at a fabricator. Hacking terminals may also enable you to locate specific types of items elsewhere on the same map.

It’s important to remember that basic parts are always available from enemy robots, so you’ll never be without those. Need a flight unit? Shoot down some of those flyers! Want a cloaking device? Hunter-class robots carry them. Every robot is built to a certain specification, and you can salvage any of their parts (those that manage to survive destruction, that is--another case against explosives).

cogmind_ascii_7DRLsprite

No one knows what Cogmind looks like, nor do we have to because it’s ASCII (or highly symbolic in the case of sprites--7DRL example above). It would be difficult to visually represent the huge number of possible permutations (in a pleasing manner, anyway). Your imagination does the job just fine.

Design

Although completely by coincidence, it was perhaps inevitable that three of the four part categories reflect the basic RPG stat trichotomy: propulsion is your dexterity, utilities your intelligence, and weapons your strength. (Power, the odd one out, acts more like a resource as it powers the other three.) A Cogmind build can emphasize any of these three to fit your traditional RPG archetypes:

  • Rogue: With an emphasis on propulsion you can close quickly with an enemy for melee combat, or, more importantly, escape many a dangerous situation by simply outrunning pursuers. You can get really fast with the right parts, though it can be difficult to maintain them since you have to forgo a lot of protection and firepower. Being very fast is naturally the best way to try a stealth approach.
  • Mage: Utilities provide the versatility to deal with a variety of situations: buffing, de-buffing, transmutation, defense… That and “knowledge is power”--sensors, ECM and other information warfare-enabling parts all fall under utilities.
  • Fighter: Little explanation required. Big guns. Or lots of little guns. Either way: Destroy stuff.

Interestingly, I prefer to allocate most of my slots to utilities, just like I enjoy playing mages in fantasy games for their versatility.

cogmind_cparts

Hypothetical list of parts from the original mockup. Your list of parts does a better job of representing you than any picture.

Progression

Cogmind does not earn XP. There are a lot of advantages to this model, the most apparent and welcome being the fact that grinding is pointless. Yay!

Good game design ensures that the player isn’t forced to do something non-fun just to achieve their goal, yet many games do just that by making grinding a means to an end, even in the “better” cases barely keeping your attention along the way by dropping loot in the form of a zillion different items with minute differences.

A lack of grinding also keeps the focus on your goal, which is ultimately to escape to the surface (we’ll talk a bit about the world in a much later post). It also makes stealth an even more viable strategy, since XP rewards otherwise tempt you to confront every enemy you see, even if it will be a boring encounter with a predictable outcome.

So how do you improve over time?

You evolve.

I won’t go into it here (or anywhere really because it’s part of the story to be uncovered), but your “core” is actually evolving as you move upward. Each time a handful of base stats will increase by (mostly small) predefined amounts, but the key change will be that reaching each new level gives you two new component slots, and at that time you choose what category they belong to. So you can decide you want extra propulsion slots to move faster or support more weight, or extra utility slots for increased versatility, or extra weapon slots because you like firing 6, 7, 8… guns at once, or extra power slots because you use energy-hungry parts.

This opens up a host of new opportunities and combinations within an already familiar system, and as your character progresses it’s still parts that do the most to define “you.” In traditional terms, progression is therefore centered around gaining equipment slots, sort of like taking a stereotypical RPG and saying you grow a new arm when you level to hold yet another weapon, or another leg to run faster, or another brain to… think more? By the end you become what amounts to a six-armed, five-legged, three-headed monstrosity with four hearts. Or whatever ;)

Posted in Design | Tagged , , , , | 2 Responses