Official development blog


Cogmind is a game about robots, so it’s about time we talk about them (finally!).

It’s taken quite a while to get to this point because robots are built upon the game mechanics and items (and to an extent, the story), so holding off on this central element enables us to consider the full range of options when designing them. In a few special cases items were created to support a specific robot concept, but plenty of unique robots emerged from the existing item set given the huge range of available parts. And I don’t mean superficially “unique” as in simple stat modifications like “extra +2 damage here!” or “more armor on that one!” Enemy robots differ significantly in their loadout and behavior, and will thus require different tactics to deal with.

Last week I finished off a majority of the designs and data entry for the new robots in order to continue pushing ahead with world building, a process which got bogged down with unknowns in the encounter system (since we didn’t have all the robot designs in place yet).

Anatomy of a Robot

First some background.

All robots are composed of a “core” and any number of attached parts. A robot is destroyed by destroying its core, which may even require only a single hit in some cases, though it’s more difficult to hit a core while it’s covered by parts. You often end up destroying some parts first, causing the robot to lose whatever functionality those parts were providing.


A mockup blueprint for the H-66 Slayer, a class 2 Hunter robot. ASCII art shown for parts is that for the various parts from the game, but there are no composite images like this one in game. (No art or visualization is planned for robots; I put this together specifically for this post, drawn in REXPaint.)

Note that although it would seem more realistic and even add greater tactical options, you cannot target specific parts, as that would make the game too easy--just disarm everyone, or target their propulsion system and run away! (Solutions such as making weapons more difficult to hit/destroy would imbalance the part systems.)

The core+parts system is no different from yourself, the Cogmind, as all robots follow the same rules. From an implementation perspective this is usually the best way to go about handling the player in a roguelike (it’s also much easier to balance a game in which more of the content is directly comparable, rather than asymmetrical). With Cogmind in particular, it allows for much tighter game design since you can cannibalize other robots for parts. Any of them. If they can do it, so can you. This even applies to some of the very interesting special effects.

Base Classes and Subvariants

I’d rather leave most of the content to player discovery, but seeing as the prototype has been in the wild for a while and played by many, I’ll use that as a starting point for the discussion.

Essentially I’ve imported all the same base classes from the 7DRL:

  • Watcher: Unarmed surveillance bot that warns nearby combat robots to enemy presence.
  • Swarmer: Small flying bots that work in larger groups to overwhelm intruders.
  • Grunt: Basic gun-toting front-line combat robot.
  • Sentry: Slow heavily-armored guard bot.
  • Hunter: Fast and deadly robots that work in pairs to track down threats with a vengeance.
  • Programmer: Track down rogue bots and corrupt them using electromagnetic weaponry.
  • Behemoth: Large war machines tasked with guarding high-value locations.

Each class has its own ASCII letter, ‘w’ for watcher, ‘s’ for swarmer, etc., using upper case for any that are considered “large” (easier to hit), e.g. ‘Y’ for sentry, ‘B’ for behemoth. Actually, this time around you’ll also find that a few really large robots even occupy multiple spaces, like the behemoth (four spaces--a 2×2 square; read more). Fleeing through a narrow corridor or doorway is now a valid way to escape them :)

Several sub-variants exist for each of the classes where better variants are constructed from similar but better parts, and often lead squads, if applicable, or simply appear on later levels. There are on average three variants per class, distinguished by color on the map, and of course by name everywhere else. Taking the watcher as an example, early in the game they appear as the W-16 Scout, then later on as the W-25 Informer and W-44 Eye. The prefix before each robot name tells you 1) the class (letter) of the robot and 2) their relative threat level on a scale from 1~99. Watchers themselves cannot harm you, but are dangerous because they’ll attract much more unwanted attention. Beware higher numbers.

Cogmind doesn’t belong to any class--you’re obviously not quite like them, a premise explored by the story.

Named NPCs are all unique robots as well.

More Classes, and Variety

In addition to the above list, there are eight new base classes for combat robots. The cool thing is none of them use normal “guns,” i.e. it’s not a case of simply adding many more shades of “attacks for X damage.” Thus much of the expansion since the prototype has been in terms of variety, not simply expansion for expansion’s sake.

True roguelike design should embrace elements and content that promote new interactions and emphasize tactical differences rather than the grindy hack-and-slash of your average RPG. While Cogmind has its fair share of numbers and stats to pore over, in the end I want the game to be more about strategic calculation, not mental math with stats. You don’t have to worry too much about the details, just be sure to put yourself in the right position and make choices that reflect what you’re best at and you’ll generally come out ahead. When playing the 7DRL I could do quite well without closely examining all the stats, instead simply using the highest-rated parts I could find and basing my decisions/actions on the strategy most suited to those types of parts. This will no doubt frustrate some players who do want to calculate everything in detail. (For that there is an optional console to see a breakdown of every attack calculation, if you must.) One advantage of this kind of design is that it makes the game a lot more accessible than it might otherwise appear. [/aside]

Back to the new classes… I won’t list them here, but know that there are robots with a melee focus, or a special kamikaze-like attack, or who hold you in place and study your composition and loadout (for devious purposes, mwuahaha), and more.

Support Robots

There were plans to include at least one kind of “support” robot in the 7DRL, but they were cut due to time restrictions. Now they’re definitely in, and there are a few different classes. Support robots have no combat capability of their own, but serve to boost or assist allies in some way. Gaining them as followers is a good way to improve your own survivability without attracting the attention that raising an army of lethal robot killers would ;)

Non-Combat Robots

One thing you don’t often see in roguelikes, or at most only in small numbers, are creatures that don’t have an impact on combat. On one hand we can attribute this to the premium on letters and map space in ASCII roguelikes, as well as the genre tendency to minimize “fluff” in boiling gameplay down to its most essential elements.

But Cogmind’s setting is not your average dungeon in which every denizen is out for blood. It’s a subterranean complex supposedly inhabited by a robot civilization of sorts, so even if just for atmosphere we need it to actually be inhabited. Fortunately we can always populate the maps with thematic robots that both have a purpose and serve as fluff.

You can already see this in the prototype (7DRL), with tunnelers excavating new areas, workers clearing debris, recyclers cleaning up the aftermath of a battle, haulers carrying parts around, builders reconstructing walls and doors… These robots will generally ignore you and go about their business.


Engineers at work, or “Hey! I just blew that up!” (Yes, they will seal you behind a wall if you are in the way.)

If you can gain control of them, you can also have them work for you doing whatever it is they normally do: carry extra parts, build walls to block off areas, dig new tunnels…

In a pinch, non-combat robots are also an easy way to farm parts. The parts won’t be the best, but it’s nice to know you can easily get access to at least a basic power source, or wheels, or utilities like a hauler’s storage unit, a recycler’s tractor beam, a tunneler’s seismic analyzer, a builder’s structural scanner, etc.


Destroyed robots leave behind salvage, which comes in two forms: matter and parts.

The ambiguous “matter” is used as the ammo for ballistic weapons and most explosives, as well as a resource consumed to attach new parts (fuse/link them to the core). The amount of matter remaining when a robot is destroyed depends on its class and what weapons it was hit by (not just “destroyed by”--it’s a cumulative effect). Blasting robots to pieces with explosives will leave much less salvage than pinpoint targeting with lasers, or even better, corrupting the target’s system with EM projectiles. This is one way for the game to limit the use of explosives (besides the obvious “he’s using explosives send in everything we’ve got!”), since powerful explosives require a lot of matter to use, but in turn you’ll receive less matter for using them too frequently.

Parts dropped by destroyed robots will usually be somewhat damaged, but are nonetheless a great way to to augment (or at least restore) your capabilities after an encounter. This is pretty much required, actually, since you won’t always find enough stockpiles of fresh parts when you need them. Nor is there unrealistically dropping of random parts from robots--they can only drop what they themselves use (and still have at the time of destruction). Thus with only a few special-purpose exceptions, all robot designs are static, enabling you to know what to expect when confronting a given type of robot, and also hope that certain useful parts will survive their destruction. I love taking cloaking devices and targeting computers from downed hunters (see first image), and I almost always track down a hauler early on to expand my inventory capacity.


Taking out a U-05 Engineer, which leaves behind some matter (‘%’) its structural scanner (‘!’) and light ion engine (‘*’).

Static robot designs help solve a common problem with roguelikes: relying entirely on random drops (which are usually not type-weighted in any way) can have the player feeling like they are completely at the mercy of a merciless RNG in terms of loot. Like that wizard who just never seems to find a staff. Randomness is good, but not when you have zero control over your destiny and it happens to kill you by denying access to fundamental items. Shops are occasionally used as a way around this (giving you a choice of items from among many), but that’s only half a solution because their stock is still random. This is really more of an issue in games that have a huge range of potential items, and Cogmind is one of those games, so I like that the player has a semi-reliable way of obtaining essential parts.

Posted in Design | Tagged , , , | 2 Responses


Most roguelikes, and the vast majority of RPGs/item-heavy games in general, have consumable items. From a design perspective this makes a lot of sense since consumables are the easiest and most direct way to indicate that effect X can be achieved Y number of times. They’re also a logical way to enable the player to “find” (and carry, etc.) a limited number of abilities which are not necessarily linked to their character, adding a lot more dynamic potential to the gameplay.

The Cogmind prototype (7DRL) did not include consumables, initially because keeping a 7DRL simple is a good way to ensure finishing, and consumables happened to be among the underdeveloped features cut from the design. Sci-fi equivalents of potions and scrolls, things like “coatings” and “software programs,” are also not very appealing to me given the game world.

On rebooting development last year there were yet more reasons to leave out consumables. I like the game’s strong focus on parts--nearly every item in the game is a part Cogmind can attach, and consumables would really muddy up the existing inventory. A proper implementation of consumables would probably even require an entirely separate inventory system because their size and effects would make them so much unlike other parts as to be incomparable. Comparability is important when dealing with inventory use and weighing item effects/usefulness during the design process. One very common way to reconcile item comparability in roguelikes is to use weight, but in Cogmind the inventory doesn’t use item weight as a mechanic at all, and only uses space/volume to a small degree. I’m certainly not adding more inventories just for consumables.

Besides, Cogmind’s general mechanics already include a lot of the “dynamic potential” that consumables are able to provide, especially since you lose parts so frequently. Any item can be destroyed while you are using it, a mechanic very unlike those in most other roguelikes, one which overlaps with consumables. In a sense all parts are consumable.

Last year I did, however, add a new mechanic that simulates consumable items more closely by essentially accelerating the rate at which an item is used up: deterioration (see last section), but honestly I haven’t used it at all yet. I do really like it as a mechanic and think it fits well into the game, there just aren’t enough items yet to expand into that category. Perhaps it will find more use in a future expansion, but for now most of the game’s item list is complete (there are 630).

But Didn’t You Just Say…

And now for the main event!

Well, over the past couple days when I was supposed to be working on maps, I instead spent them adding a few consumables. Not deteriorating parts, mind you, but something more directly resembling traditional consumables: single-use parts.

One is a “disposable” weapon, where the part is the projectile itself; some have crazy special effects that involve trade-offs; others become a permanent part of you. All are very rare and unique so I won’t be giving you any details :). They’re also generally recognizable since they fall into a new sub-category of items that I can’t tell you about, either (spoilers and all…).

Like other special items, they’re not dropped randomly, but are instead found in prefab areas (though of course the locations of these areas are randomized).

So why add them? For one they’re either extremely powerful (well beyond what a normal part is capable of), extremely useful (offering unique benefits no normal part is capable of), or offer new tactical possibilities, which you may decide you need/want to have when tackling the end game, especially if you decide to go after a boss.

They are all late-game items, and very limited since you’ll only find a handful during a given playthrough. There aren’t many types in all, but they do run the consumable effect spectrum from buffing, attacking, escaping, to the all-encompassing “special effect.”

I like how they’re implemented as actual parts, which fits well in the game both mechanically and according to the lore (the latter you’ll have to wait and see). As parts you’ll still have to attach them to use them, but they take effect and disappear immediately after connecting them to your core.

Okay, I wasn’t planning on going into details about the new consumables, but I need an image for this post! So here is Cogmind attaching a Terrabomb, which instantly vaporizes all wall and earth over a huge radius. Lots of potential uses for this one…


Activating a Terrabomb.

Other Consumable-like Features

Two other previously unmentioned elements are consumable in nature, and while neither has been implemented yet, I’m pretty sure both of these features will be a thing.

The first is secret single-use hacking commands. There won’t be many of these, but I’d like to have NPCs provide you with a few that can be later used to achieve special effects. You can, after all, type in anything you want at any terminal (see the section on manual hacking for an example). This is an interesting take on “consumables that can only be used in a certain location.”

The other is dynamic terminal passwords. By destroying Operators, robots that oversee local activity, you may obtain their terminal password which can, within a certain time limit, be used to improve your chances of successfully hacking a terminal. Each can only be used once, though, before the system will catch on to you and change the passwords immediately.

A Note on Progress

This past week I got seriously side-tracked, which I’m sure will happen more and more as the end of development nears (it’s not “near” but it is “nearing,” ever so gradually =p).

Last week began with work on a new category of randomized map content (room-based encounters), but before I could continue I had to finish deciding what kinds of encounters were necessary, then while beginning to implement those I needed to define more clearly the remaining robots missing from the roster, so I started on that and couldn’t quite finish because some of them were NPCs and would make use of special items that hadn’t been added yet, so I started adding a couple of those and figured I might as well do all the ones I can think of…

So here I am adding consumables--ha, pushed all the way back to item development! There are not too many of them, but each one takes a good bit longer to implement than a normal item since they are unique and have special behaviors (i.e., more to code). They’re certainly lots of fun, at least.

Next week I should be back on track with robots, and then finally get back to map encounters…

Posted in Design | Tagged , , , , , | 6 Responses

Cogmind Roadmap: Year 1 and Beyond

About one year ago I launched this new blog to provide updates on Cogmind’s development. 1,533 hours later development is still chugging along. Yes, I keep detailed stats about where time is allocated and plan to share those figures and more in a (much) later post, but today I want to write about the first year with regard to the planning that goes into a long-term indie project, as a way of reviewing both where we’ve come from and where we’re headed (1.0 of course!).

First, take a moment to look at the past year, in the form of all the images that have appeared on this blog so far:


Images from the past year of Cogmind development as shown on this blog (click for mega size).

First Roadmap

Development (re)started in July 2013 when I wrote an expanded design doc (1,320 words for the 7DRL became 18,000 words). After some time spent cleaning up the mess that was a hastily coded 7DRL, the next few months were spent adding support for basic mechanics that were missing from gameplay: guided weapons, salvos, overloading, multi-tile robotsmelee combat, large parts, factions, burnout, momentum, EM disruption, hacking, and machines. These were new systems fundamental to the updated game that could be implemented in any order I felt like, thus this period was mostly spent coding down a long list of mechanics--overall a pretty free-form phase of development.

Development time for individual items like those listed above can be measured in days, but the next phase would move into major components and require an ordered approach. You don’t want to start work on the world generation before a good chunk of the content is ready, or build robots before most of the parts are designed. At this point I also needed to know about how much longer development might take. Enter the first roadmap:


Cogmind’s very first roadmap, which didn’t appear until after about six months of development.

Estimated time required for each component is measured in months, with the total expected time for completion at the bottom. The date the roadmap was written appears at the top.

The Cycle

Every couple weeks or so I revisit the roadmap to check that development is proceeding on schedule. Rather than update the roadmap over time, I update a new copy of it in order to keep old states for comparison, making it possible to track when and where the pace of development differs greatly from estimates, if at all.

Looking back at the first half year of roadmaps, I’m pleased to see that my estimates were fairly accurate:


The first half year of Cogmind roadmaps.

Keep in mind that this is only a high-level general roadmap. Most of the intermittent planning stages are spent writing and organizing extensive medium- and short-term to-do lists which are referenced daily/hourly.

Because frequently pausing development of a major feature is an inefficient use of time, newly discovered bugs and necessary little improvements are collected on to-do lists for later and handled in between major features. These lists tend to grow significantly and while this phenomenon is not explicitly shown in the roadmap, it is taken into consideration for the time estimates--always pad your estimates!

Four Phases

Looking at the process so far, and what still lies ahead, three phases of development emerge from the data:

  1. Mechanics: The initial roadmapless phase where basic functionality is designed and coded. A period of very code-heavy development.
  2. Content: Create objects based on all available mechanics. A data-heavy phase without much coding.
  3. World: Build the game world using content from the previous phase. A mix of equal parts data manipulation and coding. Lots of iteration is necessary to reach the intended experience, and algorithms are tweaked to fix inadequacies in the results. (Development has recently been shifting into this phase.)

So what happened to the fourth phase?

It actually belongs at the front--phase 0. Ideally development of a new game begins with a so-called “vertical slice” of the game experience to make sure the long period of development will be worth it. At the simplest level this is a prototype that proves the core mechanic, and I already had this in 2012 with the 7DRL and therefore didn’t revisit it. This is actually a small cause for worry because the new hacking mechanic, a pretty major element, has never been tested as part of the whole! (The ability to have allies is another game changer, but I’m less worried about that.)

The Last 10%

Most developers have heard the saying that the last 10% of a game is 90% of the work. Now I haven’t by any means reached the last 10% just yet, but the principle is nonetheless already taking some effect.

After a year of work there’s already a mechanically sound, mostly bug-free experience with dozens of robots, many hundreds of items, hundreds of pieces of ASCII art, a thousand sound effects, a fully-animated interface, blah, blah, blah… but no game! Every day I literally remind myself “still so much to do…”

Looking back at the first roadmap, nine months from December is… now! There are several reasons for this.

Firstly, because there are many variables in development and I don’t want to waste time planning too far into the future, the last 25% of my original roadmap was either oversimplified or missing important features.

My roadmaps also don’t take into account real life delays, things like vacations, family issues, the occasional freelance job… You’ll notice that the provided selection of roadmaps ended just before May. The string of good examples ends there, as that’s when I put development on hold for five weeks to deal with some other obligations. Another week in July was reserved for family, and several weeks will be eaten up come October, and probably December, too.

I’m luckier than most full-time devs in that I have relatively low operating costs and don’t need to set an absolute release date, but having a roadmap is still essential for staying on track, and of course helping answer questions like “WHEN CAN WE PLAY IT?!”

So when can we play it…?

Now that we’ve definitely moved into the latter half of development, it’s time to revisit the roadmap and make sure it’s accurate based on what we know now.


The latest development roadmap (ordered).

As you can see I’ve switched from months to weeks as we break larger features into smaller chunks for the final run. While using days as the unit of measure would enable more accurate individual items (some may take less than one week, some more), there’s no reason to bother with that level of detail since it’s difficult to predict--might as well fudge it and let the values average out in the end.

Adding in some previously missing elements also increases the total time required. Based on the roadmap, and knowing that at least four weeks later this year will see no development, the absolute earliest we’ll see a pretty complete game is March 2015. Game development sure does take a long time!

Current Progress

I’ve been wanting to make a prettier and more detailed public progress graph available on a new Cogmind site, but haven’t gotten around to building the site yet (hopefully soon). Instead I’ll just post the chart here for now.


Current development progress, rendered of course in Cogmind’s UI style :)

Yeah, it looks full of big holes, a result of the disproportionate amount of time required by individual items (some of those bars represent week-long projects, while others took an entire month), and also because the mechanics and much internal work are underrepresented.

Also note that some remaining components will be outsourced: Sprites and ambient map sound/music. Those don’t even appear on the roadmap, as much of the work would be done in parallel anyway.

Release Schedule

So March 2015 it is? Not exactly. In fact, I’m still aiming for a first release this year. Still debating how to handle the whole release issue…


What state should a game be released in?

I believe a free game should be released as soon as it’s playable. This gives the developer immediate feedback from interested players and the game can grow around them. Heck, if Cogmind were free I’d release it right now since it’s already playable and fun even without a complete game world.

The issue becomes a little trickier with a commercial product, especially when you want to reach the largest possible audience in a market flooded by more and more games--many obscure games don’t get a second look so the first impression is pretty important, be it by media or by players themselves. Releasing too early is putting a greater portion of the results in the hands of chance.

Cogmind is more than just a roguelike dungeon romp, but you won’t see that in the game’s current state. By the time it’s done there will be a story, lore, NPCs… While it’s currently very “playable” in the game sense, the intended experience is simply not anywhere near complete. I hope that when people see, or play, the game they can see a greater range of what it has to offer.

So I can at least say that it won’t be released now.


There are two options I’m considering for how to start releasing.

One is as a demo for a Kickstarter campaign. Still not sure if I should bother with that route since it would postpone 1.0 even further, though it would give the game greater exposure (while implying that “it’s not done yet”) and bring in more money that could be spent on better audio-visual components. I almost want to do this simply as an elaborate excuse to get myself a Cogmind T-shirt =p

The other is simple alpha funding, which itself could go one of two ways. Either initially sell only through my own site without trying to reach out to a larger audience, gradually getting into the market and expanding exposure as necessary, or wait a little longer and go for a bigger early access release on multiple platforms.

Dammit, WHEN?!

“When it’s done.”

Haha, just kidding. Little roguelike dev joke there.

Each of the “hows” might have its own slight affect on the first release date. KS would be earliest, small-scale alpha would be later, and full-scale early access would be latest. I’d like to think that any of these options would see the game out there somewhere in a November-December time frame.*

*Fake fine print: No promises.

Posted in Uncategorized | Tagged , , , | 9 Responses

Projectile Penetration

At this stage of development I wasn’t planning on adding new mechanics, but projectile penetration has been hovering around on my to-do list ever since early playtesting showed the game would really benefit from a way to shoot through objects.

The ability to simultaneously hit an entire line of enemies, or even fire through obstructions to hit a target on the other side, really does add a lot of tactical depth. An additional mechanic also enables yet another category of weapons with meaningful variety (<--a key requirement when adding any “new stuff”). More on the new weapons below. Penetrating projectiles will also be a great addition for the Hunter class robots, which are so crazy aggressive they’ll start shooting as soon as they detect you, even while you’re behind a wall or on the opposite side of some obstruction. (You might remember them from the 7DRL if you got far enough.) Their combat AI type is literally named “INSANE” =p


Each weapon specifies a maximum number of obstructions its projectiles can penetrate, along with a separate chance to pass through each consecutive obstruction. For example the basic Coil Gun can penetrate up to two objects, the first at a 60% chance, and the second at a 30% chance. A third object after that would still take damage, but the projectile would stop there. If any chance fails along the way, the projectile does not continue beyond the point of impact, even if it destroys the object.

You don’t have to destroy something to penetrate it--the mechanic is completely independent of damage, meaning you can now even fire through walls to hit targets on the other side without taking down the wall itself. I’m sure players will find some creative ways to screw with the AI that I’ll have to address later… but it’s fun!


A majority of projectiles cannot continue after striking their first target, and of the original item set only ballistic weapons of the slug-firing variety (e.g. Gauss Rifle) were given a chance to penetrate one or two obstructions. However, these are not a very reliable way to penetrate a target. At best you can hope to get lucky with them.

New variants of those ballistic weapons are designed specifically for penetration and thus much more reliable. They carry the “Hypervelocity” designation, and may penetrate up to three or four obstructions--meaning some can hit up to five targets!


Hypervelocity variant of the Coil Gun.

Hypervelocity weapons exchange damage capability for penetrative potential, but make up for the lack of collateral damage with a greatly increased chance of a critical hit due to passing through an object.

In a related development, critical hits now destroy props, too (not just robot parts/cores), otherwise this new category of weapons could endlessly fire through machines to hit targets on the other side without ever scratching the machine itself, which looks weird and doesn’t make sense (props are normally destroyed only when a single damage application reaches an integrity threshold, making it impossible for weak weapons to chip away at a stronger obstacle to eventually destroy it).


The line-of-fire visualization for aiming got a little update since obstructions may not necessarily block a shot anymore. It will now assume maximum penetration for the given weapon(s) and highlight any penetration points in blue.


Aiming a Hypervelocity Coil Gun at the Watcher on the other side of a Matter Pump. In a best-case scenario, the projectile will penetrate the entire pump.

The entire path is considered valid (green) if there is enough potential penetration to reach the intended target. This new feature minimizes the need to count spaces.

Some example situations:


Firing through enemies. Eventually I just shoot right through them at the Fusion Modulator, which explodes.



Firing through an Atomic Centrifuge at an incoming squad. I’m at an advantage since they won’t shoot their own machines.



Locating a pair of Grunts on the other side of a wall via simple sensor array, taking one out through the wall with a Hypervelocity Railgun.

Posted in Mechanics | Tagged , , , | 10 Responses

Non-Interactive Machines

Non-interactive machines were first discussed in the context of the object placement algorithm of the previous post. But there is plenty more to cover.


We can’t simply pick random machines for any and all maps. The types of machines on a given map should reflect the theme of that map, be it storage, factory, research, etc.

Our goal in developing a selection system is to minimize effort while maximizing both variety and logicality of a map’s content. It would be a lot of work to list every possible machine for every map type. The better solution categorizes machines by their “theme” (e.g. mining, matter, energy, processing…). Then each type of map can designate one or more “machine themes” from which to choose its machines.

Mines, for example, pick from the “mining” and “matter” themes; factories select “matter,” “energy,” and “production” machines. This enables maps with overlapping themes to draw from overlapping pools of machines. The selection pool is weighted, so machines themselves can also specify how common they are (with a separate frequency value for each placement location: room, hall, and junction).

Gameplay Impact

Although dubbed “non-interactive,” these machines actually serve as more than just a way to flesh out the atmosphere.

Tactical Positioning

Their very presence breaks up large spaces with destructible obstacles. However, depending on the size of the machine this may only be a physical barrier rather than a visual one, because machines only partially obscure FOV.


Notice how FOV is not completely blocked by the machines.


Even more deadly (and fun!), is that some machines may explode.

For all the ASCII debris fans, even non-explosive machines send out flying debris when a piece is destroyed.


Chipping away at a pair of Electrolysis Chambers.

Some machines may send out different colors reflecting their nature/use, such as this Matter Pump.


Damaging Matter Pumps (the in-game color of matter is purple).

Interactive machines do not explode, but their debris animation can also be a little different, such as sparking from a terminal.


This terminal fades to gray once disabled, since it can no longer be accessed.

Truly explosive machines will detonate in glorious ASCII-plosions that can engulf nearby machines or robots. As with all particle effects, there are many styles:


They didn’t need this Nuclear Reactor, did they? (Don’t get on my case about nuclear reactors not exploding. Because this one clearly just did ;D)



Lesson: Don’t blow up a Fusion Modulator while sitting in the same room.

(More shots from the sandbox, because I’m not hunting through the game to find these things.)


A vacuum chamber (yes I’m standing too close, but that’s okay because I gave myself 40,000 integrity points =p The sandbox is nice like that.).



Scratch one Antiparticle Reservoir. Might as well take out the Power Conduit, too. Aaand.. for good measure let’s just switch to the Rocket Launcher and take out some other machines. (Several times I’ve caught myself unable to stop strolling around the sandbox doing this, again and again and again :D)

There are more, but I’ll leave them for you to discover in game, hopefully when an enemy hits one you’re standing next to ;)

To prevent overuse of the boring (and overpowered) strategy of “lure enemies near a machine and blow it up,” the predictability of explosions for some machines will be reduced by introducing a system of “machine instability.” When a machine takes damage it may have a random machine-dependent chance to become unstable, which starts an invisible timer after which it will automatically explode on some later turn.

The only element of this I’m not sure about is whether the player should have cues to indicate that a particular machine has become unstable and may explode at any time. Since the time remaining before explosion is still uncertain, it makes sense to tell the player at least when there are signs of instability. In any case, the implementation will depend on playtesting, as well as the precise number and frequency of machines that explode (these parameters haven’t been added to the data yet).

With powerful enough weapons you can of course cause a machine to explode instantly, but machines prone to deadly explosions are generally more heavily protected against weapons as this is not exactly the safest of environments.


Melee weapons, however, are particularly good at hacking up machines, though for obvious reasons point blank attacks on explosive machines are rarely a good idea. On a related note, recall that knock-backs are possible with impact-type melee weapons, thus as a new extension of that mechanic, you can now smash robots into a machine.

Normal machines will simply shoot debris from the point of impact (and coincidentally make some pretty cool metal crunching sounds). Explosive machines on the other hand will probably roast whatever robot is so unlucky as to be smashed into ground zero, and probably engulf those nearby, too.


Whacking a flying swarmbot with a Gravity Flail, sending it careening into a Nuclear Reactor which explodes and takes out all his friends, too ;)

Be wary of enemy brawlers that may unwittingly do this to you!

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