Official development blog

Traps

2 Flares Filament.io Made with Flare More Info'> 2 Flares ×

Traps. Right, that’ll be easy. Design a handful of spaces that when stepped on by the player cause any of a number of effects. Just a couple days of work.

Or not.

That might be the case with traps in most roguelikes, but not Cogmind traps. Two weeks later, they’ve been heavily integrated into many aspects of the game--map generation, hacking, particle effects, sound effects, object labels, off-screen event resolution, FOV code, pathfinding, prefabs… in total traps added 1,202 lines of code to the source, a 1.83% increase. Then of course there was the huge number of tests to run to make sure all these things were operating normally, especially in the context of other macro systems.

Traps were not a part of Cogmind’s original design, and as recently as one month ago were still an afterthought on the “maybe one day” list. In a change of direction I decided to completely remove another feature slated for early alpha implementation in favor of traps, because I believe they can serve to somewhat satisfy players seeking a greater variety of interaction with the environment, in addition to their other benefits.

Background

Cogmind’s game design is very much focused around robots and parts, a principle most important on the map where the intent is to avoid cluttering it with too many disparate categories of objects and therefore symbols. A side-effect of this focus is a relative lack of chances for unique environment interaction. You have destructible terrain and exploding machines, but dozens of other features are packed away into interactive machine interfaces, out of sight. No chests, no altars, no pools of liquid, and no fountains. Not that most dungeon crawling roguelikes thrive on environment interaction--mobs and items are generally much more important than furnishings and terrain features--but Cogmind’s expansive and open map layouts can make it feel even more barren than its counterparts. Personally I think interactive machines already offer quite a lot in terms of dynamic environment manipulation (with still more functions planned), but can understand the desire to physically see more elements out there on the map itself, and have a greater variety of distinctive objects to interact with.

I don’t want to stray too far from the guiding philosophy here by adding a ton of unique objects to the environment, but within the context described above traps do offer a nice package in which to provide more of those “interesting terrain features”--they’re static, compact, varied, and visually unobtrusive. In fact, they’re so unobtrusive they’re invisible! :P

On a gameplay level, traps provide alternatives for stealth builds (anyone inclined, really, but those who don’t have as much space to spare for combat gear benefit the most) to deal with hostiles. They also create additional challenges in the form of preventable but not always predictable events. More on trap effects later.

Appearance

We’ll start by taking a look at traps’ appearance in game.

For ASCII I went with my first choice and instinct, the ‘^’ common among traditional roguelikes. There really wasn’t any question about that until I decided that all traps would be floor-based and I thought that ‘_’ might be an appropriate alternative. However, an underscore is both less obvious and lacks the same precedent; it also simply doesn’t look at interesting, or menacing. Sorry, underscores, but carets are menacing in their pointiness :D

traps_in_classic_roguelikes

Spot the traps in these classic roguelikes.

Regarding underscores, one might imagine that a “less obvious” glyph would be a good choice to represent traps due to their nature, but in a turn-based non-twitch game about making decisions based on the full extent of available knowledge, punishing players for not being able to notice something on the map is a poor design choice. Not that players are likely to miss visible traps at first, anyway. They’ve been integrated into the auto-label system so you get a nice pop-up on discovering one:

cogmind_trap_detection

Auto-labeling a trap on detection, right behind a door.

Rather than create a new label category, for which there’d be no room in the interface, I simply merged them with what were “enemy/ally” labels, renaming the categories to “hostile/friendly.” After all, traps are simply immobile friends or enemies :)

cogmind_cscan_update

Scan window and auto-label categories update.

In line with earlier talk of avoiding map clutter, all traps are represented by the same symbol, a caret. The only difference between them is color.

cogmind_all_traps

All current types of traps, seen here in the testing sandbox.

cogmind_trap_tile_concepts

The tiles version of traps has only just reached the concept stage, and isn’t in game yet. Above are multiple WIP samples (remember Cogmind’s tileset is handled in grayscale), but the single-symbol-for-all-traps approach holds true in that mode.

This doesn’t mean that you only have color to rely on (especially important for color-impaired players, but there are so many traps and a limited set of colors that even I can’t always distinguish certain traps). Manual labels can be called up to get a quick overview of the terrain:

cogmind_manual_trap_labels

Calling up manual labels for “Hostiles,” which includes some traps I’ve spotted.

One of the interesting obstacles to trap design was incorporating them into the map alongside items. As a rule, to simplify the map viewing and interaction only one object can occupy a space at a time (excluding robots, which can stand on anything except machines). Normally traps are unseen/unknown to the player and we can’t have dropped items avoid those locations, so what happens when the player discovers a trap while an item is sitting on it? The only options here are to either destroy the item or move it. Naturally the latter makes a lot more sense, and while it’s still not entirely logical, Cogmind doesn’t aim for hyper-realism, anyway, much less where that would interfere with player convenience. It’s a good enough solution, handled by pushing all items away from the trap rather than even more unrealistically teleporting the blocking item to the nearest available spot.

cogmind_trap_discovery_item_shifting

Item shifting due to trap detection.

Distribution

Traps are organized into groups called arrays, which can be manipulated as a whole through nearby terminals, but are triggered individually. An entire array will consist of the same type of trap. Traps are found in a variety of layouts:

cogmind_trap_layouts

Sample trap array layouts, by category.

Layouts are not entirely predictable, but in most cases an array is composed of more than one trap, so strategically speaking even if you get on the bad side of one trap (e.g. it chops your leg off), you can assume there are more nearby and theoretically seek out the rest then use them to your advantage… unless you have absolutely no way to detect the others (maybe later!), or were unfortunate enough to trigger a bomb that blew them all up =p

Trap counts are particularly difficult to balance across Cogmind maps. Too many and the player would be absolutely forced to carry a reliable way to detect them; too few and they become an occasional annoyance that the player will rarely even bother to consider. This is a major reason for organizing them into multi-trap arrays--groups of traps are a lot more meaningful in the big picture where the idea is that players can use traps against the enemy. Even though traps might not be hugely abundant in most areas after I err towards the latter “distribute fewer rather than more” approach, players who ignore that possibility for a while then suddenly take a hit from one trap still have the option to find a way to reprogram the rest, at which point the one hit could have been worth it.

Triggering

A trap is normally triggered when a robot moves over it, though triggering isn’t a certainty. The chance is based on the form of propulsion used. Flying over a trap will only be detected 20% of the time, while rolling over it in treads is 100%, with varying degrees in between. (There are also some other interesting circumstances that trigger traps, not to be revealed here.)

Stasis traps, designed to catch unauthorized fast movers, use the opposite chance (ex: 100 -- 20 = 80%). And as you can see, rolling around in your tank will trigger every single landmine you’re unlucky enough to encounter (if you’re not actively practicing detection and avoidance). To compensate, treads (and to a lesser extent, legs) are getting an integrity boost, which I think they needed a little bit of anyway to further offset the fact that their slow speed essentially forces a fight with any hostile that spots you. At the same time, slower movement also has the advantage of greater opportunities to locate traps while moving through an area.

Faster forms of movement get a separate chance to evade already triggered traps when using maneuvering thrusters, though it’s funny how this doesn’t really help if you triggered a massive explosion :P

On the UX side, traps do not trigger in the exact moment you step on them--there is a 360ms delay during which an alarm sound plays. The same sound effect is used for all traps, and the reason for the delay is two-fold:

  • 360ms is a very short period, but it creates a moment of suspense during which you aren’t sure exactly what’s about to happen. (Slightly longer would be better for suspense, but too annoying in its potential to slow actions.)
  • More importantly, this provides feedback as to the cause of what’s happening. It makes extra clear that an explosion, for example, isn’t the result of a robot blasting you from around a corner. Sure this information can be gleaned from the log, but good UI design provides redundant feedback through multiple channels.
cogmind_trap_trigger_log_example

Well, that escalated quickly.

Triggered traps leave open ground that is then repaired by engineers to normal concrete floor.

Detection

Unlike most roguelikes where you may have just one or two ways to detect traps, in Cogmind there are many methods:

  • Built-in sensors give a small chance to detect each trap in view each turn
  • Carry one or more active structural scanners to increase the chance
  • Hack terminals, in the same way that looking for hidden doors works
  • Nearby allied Operators will detect those in your field of view
  • Pick up a non-expired Operator data core
  • Blast a wide area of ground with explosives--any surviving trapped areas will stand out among the rubble because they are better reinforced

There are also several “non-detection” alternatives that let you know traps are nearby before having revealed them, including triggering another trap in the same array, or simply seeing trap-related hacking options appear in a terminal interface (only listed if there are actually traps near the terminal).

Handling

Once you’ve detected traps, there are also multiple ways to deal with them:

  • Rewire them individually using a Datajack (improved results when done in combination with hacking utilities)
  • Blow up the floor, or set them off with an EMP (these work even if you haven’t found the trap--just annihilate everything)
  • Take another route, or make one--most areas are accessible via multiple paths (sometimes through hidden doors), and if not you could excavate a tunnel of your own
  • Hack terminals to disarm or reprogram entire trap arrays at once
cogmind_trap_hacking_terminal

Hacking nearby trap arrays via terminal commands.

Traps converted for your own use, triggering when a hostile passes over them, will oscillate on the map:

cogmind_trap_ownage_glow

Aw yeah, these traps are MINE. Now I just need to find some enemies to lure over here… (or keep it as a convenient area to retreat to)

To make controlled traps more predictable and therefore more useful, it is assumed that in reprogramming them you also raised their sensitivity to dangerous levels, such that they will always trigger regardless of the robot’s propulsion type. You’re welcome :)

Effects

Like items (parts) in Cogmind, the goal with trap effects is to be more than simply direct damage and increasingly large numbers. There is a very small amount of “number increasing” going on, while the majority of traps rely on unique effects to differentiate themselves (or in the case of damaging traps, at least unique aspects to their damage, like a special side-effect or different damage:AOE:falloff ratios for explosions that impact their tactical implications). Now that I think of it, there aren’t even any traps that simply do direct damage to the robot stepping on them without some other effect.

So sure we have basic landmines, because explosions are satisfying (admittedly more so when an enemy is doing the triggering), though we mostly have other effects like slicing off parts or setting off alarms. In fact, I say “traps are done” but the effect of one in particular is not--its special effect alone will take an entire week to complete. Yes, it’s a bit of feature creep, but I feel it adds some very interesting possibilities to the game, as it’s far more than just a regular trap. I will neither confirm nor deny what this trap does--just wait for the next release and find out for yourself :D

Another important consideration in trap effect design was ensuring that most are also useful to the player in some way, while not being altogether deadly when triggered accidentally. There are even multiple types of traps you may want to step on and trigger under certain circumstances! How’s that for interesting ;). This plays into the idea that traps should fully serve their new role as a multi-use terrain feature.

In the end, it makes more sense to think of “traps” as an optional new resource to use against the enemy. Yes they can damage and maim you, but for the experienced player their presence is a net positive. For those that you do trigger, however, none are trivial. Unlike other roguelikes where traps are either pointless (e.g. you can 100% recover from their effects immediately after triggering one) or deadly (they can kill an unprepared character in a single hit), in Cogmind there is no recovery until you reach the next depth--an important rule underpinning much of the game’s mechanics--and traps are nowhere near powerful enough to kill you unless you were almost done for, anyway. (The ALMOST_DONE_FOR status is best avoided, by the way!)

To conclude, here’s a nice new way of rewarding pursuers for their tenacity:

cogmind_trap_owned_trigger

Luring the enemy into their own traps pisses them off, by the way :D

Okay, one more. Much to the enemy’s chagrin, here I step on a heavy explosive while they’re in mid-assault:

cogmind_explosive_trap_step

Just another perk of being a bigger badder robot than they are.

2 Flares Twitter 0 Facebook 0 Google+ 2 Reddit 0 StumbleUpon 0 Filament.io Made with Flare More Info'> 2 Flares ×
This entry was posted in Design and tagged , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

10 Comments

  1. kriptosporidium
    Posted August 18, 2015 at 9:40 am | Permalink

    I do love me some traps. Dungeons ain’t the same without the occasional pressure plate. Although usually more of an arrow thing than landmines. God, landmines, I can’t remember what RL it was, but there were some elite lategame enemies that had a death rattle of randomly scattering 1-3 mines wthin an area. That shit was ridiculous, but manageable due to the fact they were the kind of landmine that didn’t distinguish friend from foe.

    Just wondering, if there’s programmers running around an alert along with sensor friends, is there a chance they could reprogram the traps back into anti-player mode? Or are traps, once hacked, safe to forget about unless you’re gonna make someone step on them?

    • Kyzrati
      Posted August 18, 2015 at 10:25 am | Permalink

      Traps are definitely a dungeon staple, though I think that in roguelikes they are more easily interpreted as being “unfair” due to their unpredictable and sudden nature, forcing players to almost waste effort taking any precaution they can against something that may or may not happen, but if it does it will be immediate and possibly unpreventable. The occasional very deadly traps you find in roguelike classics are pretty poor design for long games with permadeath.

      So I’ve tried to design trap mechanics that are both as fair as possible and, honestly, in the end something that can just as easily work for the player.

      I did consider allowing certain robots to reprogram traps back to their original mode (I was thinking operators), in the same way that programmers can already reprogram former allied AIs, though decided against it for now since undoing the effort of detection and reprogramming already undertaken by the player is a bit too mean.

      “Or are traps, once hacked, safe to forget about unless you’re gonna make someone step on them?”

      Even traps you’ve reprogrammed may be unsafe under particular circumstances, but I’ll save that surprise for the game ;)

      • kriptosporidium
        Posted August 18, 2015 at 10:38 am | Permalink

        Yeah, fair enough on the reprogramming. I’d make the argument that you still remember the location of a trap even when you lose control of it, and then it gives you an idea of where there are operators. But I can definitely get behind the idea of not giving the AI TOO much comeback potential.

  2. Monsieurmarc
    Posted August 18, 2015 at 6:06 pm | Permalink

    Is the complicated trap a teleport by any chance?

    • Kyzrati
      Posted August 18, 2015 at 6:12 pm | Permalink

      “I will neither confirm nor deny what this trap does.”

      But there’s no harm in placing your bets here in advance where we’ll have proof whether you were right or wrong :)

  3. Reiver
    Posted August 19, 2015 at 8:00 am | Permalink

    Would an explosive trap mostly hit the treads, I wonder? Explosions usually damage everything, but in this case you really do know which parts were physically obstructing an attack.

    Which is not to say it won’t still cause problems for the robots nearby, of course…

    • Kyzrati
      Posted August 19, 2015 at 9:27 am | Permalink

      I thought about it, for about 5 seconds :)

      That’s true, but Cogmind doesn’t bother with directional damage. From a mechanics standpoint it could be somewhat unbalancing to allow damage that doesn’t obey the regular coverage system. Treads might be fine, especially after the planned integrity boost, but concentrating the damage against weaker bottom-mounted propulsion would be too deadly to too many builds.

      As part of the tread/leg integrity boost, however, I was considering also upping their coverage a bit, which would have the same effect.

      • Reiver
        Posted August 20, 2015 at 7:46 am | Permalink

        Aye, that’ll do it.

        Do you have any plans for traps/hazardous areas that can be crossed with certain movements and not others? I envisage a wind tunnel that hover and flying go skittering off but the ground-based shrug through, and roadspikes that the opposite happens…

        Granted, these wouldn’t really be ‘traps’. Just interesting terrain. ;)

        • Kyzrati
          Posted August 20, 2015 at 10:10 am | Permalink

          This is something many players have suggested, and even expect to see, since it’s a common feature of roguelikes. But it doesn’t work as well in Cogmind. The world structure and inhabitants tend towards sci-fi realism, while most special terrain makes very little sense in that context and the story setting.

          On top of that we have the gameplay implications, which would be either very far reaching, if we embraced terrain types, or insignificant (and distracting), if we avoided going all out in order to avoid the drawbacks. Cogmind not being a kitchen sink roguelike, anything that doesn’t play well with every other element (as I see the final vision) is left out. Special terrain types/areas is one of those features.

          The closest we’ll get is the fact that some traps are triggered more or less by different forms of propulsion, as describe. And note that sometimes traps can block an entire corridor/route.

          On further thought, I do imagine it would be possible to have “special areas” that are mostly based around terrain type(s) (outside the main complex floors), but that would be beyond the scope of the primary roadmap and something I wouldn’t add except maybe as an expansion after 1.0 to spice things up, if there’s interest.

Post a Comment

Your email is never published nor shared.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>