Official development blog

Map Comments and Log Notes

Back in August I was watching the first Tone-MTF combo stream, and listening to them repeatedly strategize aloud so they could collaborate brought more than the usual planning talk to the forefront of the conversation, through which I noticed the occasional potential for manual map comments to be helpful.

Very few roguelikes support freely adding annotations to specific locations on the map, perhaps because most roguelikes don’t have very large maps anyway, or rely on other features like map memory to serve enough of that purpose (some roguelikes will even store old enemy position data in addition to items and other objects/environment features), or don’t allocate quite as many dev resources to non-essential UI features.

tggw_map_memory_creatures

The Ground Gives Way remembering that a particular creature was left outside your FOV when you moved away, a simple way to let you know you avoided or fled from something in that area earlier. See the two ‘c’s to the south of the player (@), where ‘c’ represents a canine type creature. (Wild dogs are fast but can’t open doors so I used a rod of slowing on them then retreated to close the door.)

For a while on Patreon I had suggested map notes were a possibility for Cogmind, and although there was a fair bit of support for them among the player base, it wasn’t high compared to the desire for various other features. Some potential roguelike criteria to consider as far as the usefulness of map comments:

  • If backtracking to earlier maps is possible, players may need to remember some important local detail(s) long after they may have forgotten them due to having since interacted with many other subsequent maps and encounters.
  • If maps are large or complex enough, players may have a harder time remembering details about an area they might revisit later, or after saving and loading their game for another session.

There’s no backtracking to previous maps in Cogmind, so my personal preference is to avoid ending a session partway through a map if possible, to reduce the chance I’ll forget some important piece of information without having to make notes on everything. On that note, however, back in Beta 10 I did add “log notes” which can help with just such a situation. Compared to an interface feature like map comments, simply adding notes to the log is much easier to build :P

cogmind_player_log_note_demo

Adding a custom note to the log. Implementing this feature is as simple as calling up a dialogue box to accept a line of text and copying it to the log once confirmed.

In terms of temporarily preserving info as a reminder for later, log notes are similar to map notes but without the positional data, though as is these will of course also scroll away as the log progresses since they don’t have a separate dedicated display.

Log notes could also be used to add more explanation to the message log for those players who will export it in full at the end of their run, for example to describe in greater detail what was going on at the time (in fact this was the original reason one player requested it a long while back).

cogmind_streamer_break_log_note

Interestingly, since the log notes functionality allows players to type a line of arbitrary text in the middle of the screen, some streamers have taken to using it as an in-theme way to write a message letting viewers know they’re away for a short break.

Back to the idea of map notes, although I one day finally decided to just add them on a whim for fun (I do rather enjoy taking dev detours to implement little interface QoL bits), I quickly discovered this was a complicated endeavor filled with potential for bugs and coming with plenty of UI challenges! You’ve got your typical data storage considerations, the need to write but also edit or delete existing comments associated with a particular location, a new modal interface to handle all this separately from the rest of the main UI, and visualization work involving showing the comments normally, or just reminders of the comment locations when not shown in full, or relative directions to comments to help pinpoint them across a larger map… All told, this feature ended up taking a week to complete.

Fortunately for the visual parts I eventually managed to get the comments piggybacking on the exit label system (including support for displaying relative direction of off-screen comments) rather than having to write a separate system, which would’ve taken even longer.

I will say that at first I didn’t really feel this system would be worth the amount of time invested in building it, but in the time since I’ve been discovering more uses (including automated ones) that have made it seem more worthwhile.

Map comments are added by entering “Comment Mode,” currently activated via Shift-Alt-c (but later also coming to the “special commands menu” in Beta 11 for easier access).

cogmind_map_comment_adding

Adding a comment to the map.

Even when not in the mode, the map view reminds players about comments made earlier by intermittently highlighting those cells (the interval is adjustable in the advanced options, or can even can be turned off entirely if it’s distracting). Hovering the mouse or keyboard cursor over a single comment position also shows that one comment in its entirety, but on entering the mode they all appear at once and remain visible as long as the mode is active. Right-clicking on an existing comment (or the ‘r’ key) removes it.

cogmind_map_comment_highlighting_showall_deleting

Highlighting individual comments, as well as showing them all and demonstrating individual removal.

As with other on-map labels, of course we need support for showing indicators of those not currently within the map view area. This was where it came in extremely handy to already have lots of architecture in place for displaying directional labels.

cogmind_map_comment_offscreen

Demonstrating off-screen map comment markers.

Comment Mode also supports cycling through existing comments via Tab/Shift-Tab for added convenience.

cogmind_map_comment_cycling_editing

Tabbing through map comments, and also editing one of them.

Overall there’s a fair amount of overlap between map comments and other existing features (including the aforementioned log notes but also other new Beta 11 features like item searching) so their usefulness will likely vary greatly from player to player depending on preferences, but it’s always nice to enable extra optional possibilities.

Map comments are indeed the only way to add custom spacial info where it matters, though in my understanding player-side uses are probably pretty niche and I’ll be keeping an eye out for what people end up actually doing with this feature.

Either way, I am starting to like the potential for automated uses, making map comments a potential new tool I can apply to have the game serve up reminders of certain location-based knowledge that doesn’t already have or justify adding its own unique method of display. I already have some ideas of my own, but this is also one area where it could help to see what players are doing, since repeated manual behaviors in certain situations are always good candidates for automation.

One potential issue I’ll be on the lookout for here is whether map comments actually add tedium to the game, mainly in terms of optimal play. Like marking known Sentry/Heavy defense points? Behemoths? It’s true people can theoretically use screenshots as a recording tool for this sort of optimal play, but that requires enough work that it’s not something players do in practice--we just rely on our brain instead :P. Once you give players a tool that reduces the cost of some form of optimal play, one that was previously safely beyond the threshold of reasonability, there’s always the danger that this new tool will invite tedium.

Again though, if some form of map comment is useful enough, it may become automated if possible. That said, doing this in a way that’s both useful and accurate could end up being a lot more complex than it seems at first!

Map comments have been in prerelease test builds for a little while so far and I have yet to hear about them getting a lot of usage, so I guess we’ll need more time to tell!

// TODO: Add list of automated map comment features here ;)

…and here we go, since publishing this I’ve started posting some other examples of automated comments, so the list begins:

Posted in GUI | Tagged , | Leave a comment

Spicing Up Primary Maps 2: Area Denial

Our first dose of spice last time leaned heavily on risk-reward potential in the form of dangerous cargo convoys, whereas our second dose here is more about introducing additional challenging situations and increasing overall difficulty--less reward, more risk (although as you’ll see this new feature might also involve rewards for some builds).

Introducing the Heavy class, the first new common combat class ever added to Cogmind! New uniques and otherwise special bots from other factions have joined us over the years, but the ranks of standard 0b10 combat bots had remain unchanged in the time since the first release in 2015.

cogmind_heavy_class_tiles_20_large

Heavy class tiles. The ASCII version is an uppercase ‘H’.

The “Heavy” name was first used in Cogmind offshoot POLYBOT-7 back in 2018, where it represented a defender built around a single cannon and stronger than a typical Sentry, so kinda like a “1-tile Behemoth.” At the time I imagined we might see something like that in Cogmind one day, and here we are, although as you’ll see in this article there is a lot more to these guys than just cosplaying a smaller Behemoth!

The majority of threats in Cogmind’s primary maps come in three forms: active patrols, security bots guarding over a small area, and garrisons which can dispatch reinforcements. Heavies combine all three of these by usually defending a single location, but sometimes moving to guard another location, and also capable of calling in additional squads like a garrison can. In other words Heavies are a sort of “mobile garrison” that tends to be stationary more often than not.

As such, these are obstacles you’re more likely to want to avoid rather than confront, in many ways even more dangerous than garrisons since these can fight (!) and the latter can be destroyed or even hacked. Heavies can technically be hacked as well, although only by RIF builds--there is indeed a Relay Coupler [Heavy].

Of course, avoidance isn’t always an option, or in some cases doing so could put you in even more tactical danger for whatever reason, so let’s take a look at what confronting a Heavy really entails and how they live up to their “area denial” role.

Heavy Capabilities

There are multiple reasons to fear a Heavy, otherwise they wouldn’t make very good area denial bots, now would they? :P

Loadout

Even ignoring their other abilities, simply based on their build alone Heavies are not to be underestimated in a head-on fight. They’re heavily armored with a fairly well-covered chunky core and lots of supporting offensive utilities behind a huge cannon.

Compared to facing an entire squad of bots with more combined integrity and weaponry they’re technically not that bad when encountered alone, and in that regard can be considered somewhat glass cannon-y, but few enemies carry such a devastating weapon as their heavy cannon. Specifically for Heavies I added a set of new dual-slot kinetic cannons capable of inflicting a concentrated blast of damage along with a non-insignificant chance to also apply the Blast critical effect, which is quite powerful in combination with such high base damage. Of course as with most parts players can also acquire these cannons and put them to good use, along with other potentially useful Heavy salvage including their treads, unique sensors, Transmission Jammer (the only way to reliably get one of these via salvage), Weapon Cycler, Kinecellerator (no other reliable salvage sources for this, either)…

cogmind_ascii_art_beta11_heavy_cannons

Extra-heavy, extra-large heavy variants of existing cannons created for Heavies.

Mechanically speaking, the star of their loadout would be the other part added specifically for Heavies, namely the Active Sensor Suite which I detailed in an earlier article. This plays an important role in service of their area denial capabilities, since they can use it to accomplish two powerful AOE effects:

  1. Call reinforcements: Unidentified signals detected within their sensor range are considered suspicious and they’ll eventually take action against them by summoning a squad to check out the area. Up to two separate such squads can be active at once, so spending too much time near a Heavy without actually engaging it could be problematic in the long term.
  2. Mask allies: All of the Heavy’s combat allies within its sensor range are masked from detection by normal sensors, making it somewhat more dangerous to approach them, not knowing whether a regular patrol is passing through, or where summoned reinforcements may be lurking. Cogmind can see through the masking if using their own Active Sensor Suite, FarCom, or a relevant RIF ability, but those are special options many builds won’t necessarily have access to or want to take advantage of and therefore have to consider the threat of masked enemies if relying on sensors (builds not using sensors anyway simply won’t care about this aspect :P).
cogmind_heavy_class_destruction_sensor_reveal

Destroying a Heavy here shows what their sensors were masking.

Here it’s important to bring up several of the QoL mechanics that round out the Heavy experience.

First of all, as soon as Cogmind enters the Heavy’s active sensor range, its exact position is revealed on the map. This is important for balance, since projecting their location lets players plan for how to approach or traverse the area, if they want to at all. Heavies are fun challenges, but would be a lot less so if they didn’t reveal their location! This kind of mechanic also logically falls in line with the idea of “active scanning.”

Heavies don’t just pop into view, either, instead animating their full sensor range around them on the map as a prominent warning.

cogmind_heavy_class_active_sensor_array_warning

Heavy Active Sensor Suite AOE warning animation.

 

cogmind_heavy_sensor_range_recall

Holding the cursor over a known Heavy will also recall that range for reference.

Another important piece of info clearly telegraphed to aid planning is the timing of relevant squad dispatches, which we’ll get to further below.

Summoning

Tangling with a Heavy, or even passing nearby, is cause for concern because it’s hard to be certain just how far such an encounter could escalate (unless you’re really confident in your tactics). After all, they’re going to call for help, which means more enemies, more danger, more alert (also more loot, for players into that type of salvage!).

There are actually two kinds of reinforcements available, the first being those sent out to search for the source of the sensor blips, and another which the Heavy calls to its side as soon as it comes under attack. Heavy behavior is rather unlike other combat bots: since it can rely on allies to go after potential targets while it holds its ground, it therefore doesn’t need to chase them down on its own, but may also want additional protection capable of reacting to visible threats against its position. This mechanic makes it more dangerous to attack a Heavy without fully committing right away, since there will definitely be another squad arriving to fortify the area at some point. This “close defense squad” is composed of more typical front-line combat bots, different from the types sent after enemies (like Cogmind) detected on sensors. (Like most other calls for reinforcements, the Heavy can also be jammed with a Transmission Jammer, which again they happen to also use themselves so become a source for a second type of salvage that’s useful against them.)

Note that none of the reinforcements summoned by a Heavy actually go after a specific target until they spot one, they’re just sent in to reinforce the area, emphasizing the area denial aspect by increasing hostile bot density in the local area.

Regardless of the type of dispatch, all of them are announced, and in the case of reinforcements targeting sensor blips, they’ll even specify the type of squad sent out because Heavies don’t react in the same way to every signal!

cogmind_heavy_sensor_reinforcements_announcement_cutter

This Heavy is calling in… Cutters?!

Over time Cogmind has been trending towards more dynamic responses to different play styles, especially the significant difference between fast and slow player builds. Thus a Heavy that detects an unknown high-speed bot on their sensors is more likely to send out faster bots to intercept it, or if the target is slow it’s better to call in slower bots carrying heavier firepower.

The bot of choice to go after slow targets? Specialists.

Specialists

Specialists are an unusual case in Cogmind, relatively underused despite falling under the “common” (non-prototype) combat bot umbrella. They could sometimes be found in Garrisons or attached to assaults, but otherwise weren’t a part of regular patrols/reinforcements/investigations, at least not until now :)

There were also only three variants and that wouldn’t do for reinforcements meant to support Heavies across a large number of depths and situations--simply not enough variety and too predictable in terms of their capabilities. We’re going to need more variants, so I more than doubled it to seven.

Specialists also got unique depth-spawning rules, made possible as a result of being the only bot with a different variant for every level on which they might appear, and desirable especially due to the unique nature of their loadouts. Unlike other bots that have consistent loadouts across all their variants (e.g. all kinetic weaponry and relevant supporting parts), each Specialist has a mostly unique loadout aside from the common theme of “legged combat bot,” building around a different damage type or combat style. And unlike other bots which use the same predictable variant at each depth (the highest one rated at or below that level), Specialists are now selected randomly from among any variants at, directly above, or directly below, the current level. So there are up to three possibilities for a given squad. (A single squad of Specialists will all be the same type, however, to avoid mixing them and making them hard to visually distinguish during an engagement--Cogmind the game is mostly intended to have predictable enemy loadouts known purely by looking at a robot’s ASCII on the map without a need to further examine details once you’re familiar with them from previous runs.)

cogmind_robot_variant_distribution_sample_specialists

Sample chart showing how some class variants are normally distributed by depth, and how that compares to Specialists. Notice the overlap, more easily seen using the visualization. (“Level” 1 refers to -10/Materials, and goes up from there to -1/Access which is equivalent to level 10.)

As you can see above, Specialists may spawn slightly OOD (out-of-depth, giving access to better loot if you take them down!), or even slightly weaker, and this approach is perfect for the job here with regard to Heavy reinforcements since you can’t be sure what the variant will be, and therefore not exactly sure whether or not it’s a variant you’re better equipped to deal with. This again makes hanging around near Heavies a bit riskier, or at least more interesting :)

These unique selection rules apply to all Specialists wherever they may appear, meaning they’re also good for convoy defense variability, since those may be accompanied by Specialists, too, as well as Garrison interiors.

But Specialists certainly aren’t going to cut it when it comes to chasing down fast movers--for that we now have Cutters!

Cutters

Wow, all those years without any new common 0b10 combat classes and now we have two at once! I’ve added a second class of bots specifically to play a supporting role for Heavies, aiming to give faster player builds more of a challenge with this one. For a little flying bot it sure took a while to put these guys together, involving a range of new parts and multiple new AI features.

cogmind_cutter_class_tile

Cutter class tile. The ASCII version is a lowercase ‘c’. (Image originally put together for one of my YouTube videos on this topic :P)

Of course if you want to catch fast targets you probably want to be fast yourself, so the Cutter class is blazing fast, or at least can be. To accomplish this it’s the first AI capable of selectively toggling overloadable flight units. Cutters normally move at their propulsion’s base speed, but as soon as they have a known enemy they’ll overload and chase at a speed that only the fastest builds would be able to outrun.

In designing robots there’s always the important consideration of what players will do with the salvage, so in this case because I didn’t want Cutters to be a reliable source of widely desirable overloadable flight propulsion, I had to add a new set of parts with their own drawbacks. Enter “Surge Thrusters,” a rather different kind of flight propulsion which while overloadable and quite fast, also has higher integrity and coverage, lower mass support, and burns out faster than the usual overloadable airborne prop. Surge Thrusters can theoretically be useful in a pinch or as part of some specific strategies, but the average flight build will pass.

Another reason Cutters need speed is that they are primarily melee fighters that need to actually close the gap with targets before being blasted to bits. They’re built around a saw, which sounds as scary as it is with its very high slashing critical effect. Maybe one is not too bad, but having several of these bots racing towards you can be pretty scary and cause for emergency measures.

cogmind_ascii_art_beta11_saws

A range of saw variants created for Cutters.

Cutters also have a single-fire ranged option they’ll use on first sighting a target, one that also involved adding a new mechanic: AOE knockback.

Explosions in Cogmind don’t normally move bots, since as neat as that would be it would also make using them (or having them used against you) even more chaotic, further interfering with the planning that goes into the tactical positioning behind success during Cogmind encounters. But this is a special case where we can make an exception since that’s part of the intent…

The first application of this mechanic is the Cutter’s short-range “Concussive RPG,” which is hard to aim and doesn’t inflict much damage, but knocks targets away from its origin to disorient them, and due to the poor targeting the projectile may likely even miss and could knock a target back closer to the Cutter’s position!

cogmind_concussive_RPG_AOE_knockback_demo

Firing a basic Concussive RPG. More powerful variants have more significant knockback effects.

The RPG projectile itself (not the resulting blast) is also the first in Cogmind to do ranged impact damage, which is also quite scary for flight players since it’s more likely to smash fragile systems, although actually scoring a direct hit on an evasive target with such an inaccurate weapon is not very likely.

Again with the salvage concern, we can’t really have players repeatedly firing a reliably accessible AOE knockback weapon like this, hence part of the reason behind its design as a single-use disposable launcher, though this approach also happens to be more appropriate for Cutters themselves anyway since their priority is obviously to cut things :D

This part of their loadout required yet more new AI behavior tweaks to enable them to effectively use a disposable launcher and switch weapons when appropriate, in addition to taking special care to avoid firing while too close to a target, or with other Cutters nearby, lest it become easy to deal with an entire squad of these by letting them get in your face and tanking the first shot so they just kill themselves :P

The Cutter design was inspired by the Striker prototype, which also has a two-weapon design based around firing several shots of its Compact Linear Accelerator at long range before rapidly advancing to engage a target with its Plasma Lance, though internally the Striker was much easier to handle since there’s no AOE effect to consider, and getting them to switch weapons was as easy as making sure they’d run out of matter to fire their accelerator after X shots. (Strikers are similarly an anti-fast-bot design, though much beefier and not quite that fast.)

Heavy Placement

Where and how frequently these new Heavies appear is a vital part of how effective they’ll be at making exploration more interesting. Too few and they don’t add any of that meaningful and challenging area denial effect, too many and that would be a problem since the idea is that there are usually supposed to be ways to circumvent them if desired/necessary (though again this sometimes comes at the risk of being forced to do something else dangerous--hard to say!).

Heavy presence is not really a thing until the mid-game. Early-game maps are relatively small by comparison, so only a couple maps down there contain a single Heavy. There and even on into the mid-game you might even go a few floors without ever seeing one depending on how much you explore. More importantly, within a single map multiple Heavies will not be stationed near one another, since as one can imagine even just having their sensor ranges overlap could theoretically be an incredibly dangerous place where multiple reinforcement squads could converge more quickly than usual.

In terms of bot quotas, Heavies were not included as raw additions to the original inhabitants of each map. Instead they are replacing some of the Sentries originally stationed on a map, and similarly guard junctions or exits (but not individual rooms like Sentries might).

Heavies are usually placed in high-value junctions, potentially giving them a good vantage point for keeping watch over long corridors to make best use of their visual range and heavy cannon, or at least a position connected to multiple paths from where it makes sense to intercept hostile signals.

cogmind_factory_junction_rating_sample

Local map junctions labeled with their relative value (see “Desire Paths” for a Robot World for more about junctions). Notice how the highest-rated junction in this are contains a Heavy (‘H’), while two others are guarded by Sentries (‘Y’).

Heavies may also sit right on an exit--good luck circumventing that one if your goal is that particular exit! (just kidding, there are lots of strategies available, but naturally this complicates things)

cogmind_heavy_class_distribution_sample_with_sensors_factory6

Sample default Heavy distribution on an earlier Factory map (-6), with circles representing their active sensor range coverage. Not too bad here, as there are clearly many other optional paths, and these two may never even be seen at all depending on Cogmind’s route. Both of these are guarding junctions rather than exits.

 

cogmind_heavy_class_distribution_sample_with_sensors_factory5

Another Heavy distribution map including sensor coverage, this one a -5/Factory layout with somewhat higher Heavy density. These also happen to be only guarding junctions.

 

cogmind_heavy_class_distribution_sample_with_sensors_research3

This Heavy distribution scenario on -3/Research could be a bit more problematic, not unlikely on Research maps since they tend to be more maze-like and have more bottlenecks. Being forced to pass near or directly engage a Heavy is more common in the late game. The Heavy stationed at the top there is guarding an exit to the next depth.

Notice how none of the Heavies are too close to one another, and there are ways around them but they stand as obstacles on some paths.

An exception to rule ensuring each Heavy has its own mutual exclusion zone is a new 0b10 event meant to further spice up the main complex: Security rotation!

cogmind_security_rotation_announcement

ALERT: Heavies on the move!

Every so often Complex 0b10 will call for a security rotation, in which all Heavies will cycle to one of the other Heavy locations (and coincidentally any Heavies found to have been destroyed since the last rotation may be replaced by a new one dispatched before long).

While this can create extra danger in the form of a powerful bot on the move, and even more so when more than one Heavy might be moving through the same area (!), it might also open up a window of opportunity to slip through an area previously overseen by a Heavy.

Of course it also helps that you can always see them while they’re taking part in a rotation, due to their active sensors, thereby making planning a route past them, or evading their approach, that much more possible even without your own sensor data. From a design standpoint this is another part of their appeal, giving players a critical piece of information needed to help face a challenge, without solving the entire problem.

Aside from the above predetermined defense points, Heavies also star in Complex 0b10’s new cargo convoy interception response mentioned in the previous post, where “Access Lockdown redirects Heavy bots posted at junctions to exits across the map, and if necessary calls in additional Heavies to defend any other unprotected exits.”

Player Reception

In general players are loving the addition of a Heavy class, as its serving to spice up the main maps by making them even more dynamic and challenging on an intermediate level we didn’t really see before. We’ve always had “low-level” stationary enemies and roaming patrols that require LOS on a target (or a corresponding alert) to go after it, and “meta-level” extermination and assault dispatches with accurate long-distance tracking, but nothing quite like Heavies, occupying a space in the middle of that spectrum in the form of an enemy that can use sensors to more effectively control an entire area.

I’m really happy with how they’ve turned out!

Posted in Cogmind Beta Overhaul | Tagged , , | Leave a comment

Spicing Up Primary Maps 1: Cargo Convoys

One of the core principles of Cogmind’s original level design was to split the world into two types of areas: the main complex vs. branches. I wrote about this concept here on the blog shortly before Cogmind’s first alpha release, but one function of this approach is to provide a tamer more predictable central route to the end game, one containing plenty of challenges but overall few to no extreme surprises other than what trouble the player stirs up through their own actions (and also little to no intrusion by the story). Branches, on the other hand, are generally more dangerous while also offering significantly better rewards and even whole new play styles.

cogmind_pixelwise_world_map_no_redacted_spoilers

For fun I put together a world map of Cogmind in which each pixel represents one cell. Many direct branch links can appear at more than one depth (and in a few cases there are even shortcuts)--this just shows one set of possibilities, and in the version above I have removed highly redacted spoilers, meaning a number of maps are missing at various depths, but it shows the split between the main path (central column of larger maps) vs the branches linked out to the sides. You can download the full-size image to examine it more closely, or if you don’t mind FULL SPOILERS you can download this version which includes even secret redacted-level areas.

As a result of this division, the main complex will seem a bit same-y compared to the variety offered by branches, but it accounts for a minority of the total area of the world, and one’s route is optional after all, so there’s always plenty of opportunities for adventures into branches. Again, by design the main complex maps are intended as a sort of “hub-like” area where you can relax your mind a bit because there aren’t unique threats all over the place--it offers relatively consistent types of challenges regardless of depth, conducive to planning and preparation for those riskier branch excursions.

They are, however, the largest maps in Cogmind’s world, and with so much room to play with and the main game long complete now (who cares about version numbers :P), as we start to expand into really optional dev territory I think it’s time to consider new options for “sprucing up the main complex.”

Primary Map Events

Technically from early on we’ve had several small-scale surprise/random events that can occur in the main complex, but these are mostly rare encounters that only people who play a lot will ever see, sticking to the original goal of keeping that sort of content from becoming the norm in the main complex. This category includes Derelict or Assembled incursions of various types, among other faction activities.

Also of course there are some major player-triggered plot-related events initiated via branches, but those don’t really count in this context.

Cogmind Beta 11 is adding an event that belongs in a whole new category of its own, which can be summed up as essentially “optional high risk-reward content moving through the main complex.” Compared to the other types of events mentioned above, this new one is the first reliable risk-reward event that everyone can encounter, and the fact that it’s mobile rather than requires being at a specific point on the map gives it a further unique slant.

Introducing “cargo convoys”…

Cargo Convoys

Convoys are centered around the A-27 Freighter, a new Hauler variant which is itself based around the new Cargo Storage Unit introduced with the Beta 11 storage overhaul.

cogmind_freighter_info

A-27 Freighter stats.

Haulers (affectionately dubbed “loot piñatas” by players) are normally green non-combat bots ferrying parts around the complex, sometimes escorted by Grunts. Ambushing one in a direct attack without immediately destroying it generally results in reinforcements being sent to the area, but most of the time it’s not all that dangerous to intercept a Hauler and hope it’s carrying something useful (or targeting it precisely because you already know it is ;)).

Freighters are a different story, only dispatched as part of a special convoy containing a huge inventory packed full of Definitely Very Good OOD parts.

cogmind_inspect_freighter_inventory_via_mTNC

Examining a distant convoy’s inventory via a Modified TNC borrowed from the Exiles.

 

If convenient one can also hack a terminal to pull the convoy’s manifest to decide whether it might be worth intercepting.

Although Freighters still flee when attacked, unlike other Haulers they are armed with a close-range weapon for defensive purposes, thus instead of using the normal green color they appear yellow, earning them the nickname “yauler” (yellow hauler) from players.

The yauler itself isn’t all that scary, since even with high core integrity it moves relatively slowly and can’t fight back at normal ranged combat distances, but anyone interested in intercepting a cargo convoy is usually going to have to deal with the escorts, which are decidedly more problematic.

Shadowing the Freighter are two ARCs (Carriers) and a Protector class bot to shield them all. The ARCs are quite a significant concentration of power since they’re even deadlier than high-security assault forces, each carrying four dangerous bots including a range of possibilities (even Specialists) and making for high variability in terms of capabilities. On that latter point, one of the risks of engaging any ARC is that until it opens you can’t be sure what type of combat bot(s) are inside, and therefore may not be able to as effectively plan for that part of the fight in advance.

Anyway, it’s a lot of firepower (and defenses!), so high risk, high reward.

Some Freighters may even be hauling a seriously good piece of unique tech that can only be found on convoys, something I’d probably like to do more with in the future but for now haven’t added more unique parts for that purpose, just one so far to entice and reward would-be hauler robbers.

Telegraphing

So you have this concentrated deathball of robots making its way across the map, one can imagine how nasty it would be to turn a blind corner and be staring down one of these convoys… Okay earlier playtesters indeed reported this sort of tragedy which led to various refinements ;)

While running into a convoy when you least expect it or want to is always going to be entirely possible (SURPRISE! *cue volley of gunfire and lasers*), there are a number of things we can do here to make them a better experience overall while still preserving their unique challenges.

First of all there will only ever be one convoy on the map at once, and its impending arrival is announced in advance in the form of an ALERT message.

cogmind_cargo_convoy_alert

Cargo convoy alert warning of impending Freighter dispatch.

For fairness, the convoy’s entry point also won’t be near the player, and before the convoy itself is dispatched, a group of Swarmers is sent out to clear the “transfer corridor” as mentioned in the above alert. As implied, this means they’ll follow the intended convoy path to ensure there are no threats ahead (which may include Cogmind :P), and observant players seeing these guys on sensors will know something is up since they move at full speed, which is normally something Swarmers only do when chasing down targets. So that’s one way to get a glimpse of where the convoy will be headed. (Or even just running into a squad of Swarmers after the announcement is sufficient to be suspicious.)

Convoys may also be detected through a variety of other means that require proactivity from the player, such as of course regular robot/visual sensors and bot tracking methods, or installing a particular Hauler-tracking Trojan, or using various other forms of intel.

One of the more widely available options on shorter notice is to salvage a Transport Network Coupler from any Hauler and use that to pinpoint the Freighter, and as an added bonus the TNC will even show the entire planned cargo route, making it easier to set up an ambush or (avoid the path entirely).

cogmind_cargo_convoy_on_sensors_with_route

Using a combination of sensors and TNC to watch a squad of Swarmers then the convoy pass by, while also able to see the route they’ll take.

Cargo convoys do leave the map once they reach their destination, either a Garrison Access or 0b10 map entrance somewhere else on the map (usually far from where they entered so they’ll cover more ground).

cogmind_cargo_convoy_factory_route_sample

Highlighting a sample cargo convoy route across a Factory map

Of course even without any of these methods one could just generally be careful when there’s an active convoy out there--this knowledge affects how one might decide to path through rooms and corridors on the off chance you could run into such a large force. The likelihood of an undesired encounter also changes depending on general map layout, where routing through apparent bottlenecks increases the chance of meeting trouble (although this is always true regardless of convoys!).

Player Reception

Aside from early testing hiccups like being jumped by an unexpected convoy arrival (which were also more frequent at the time to allow for more encounter opportunities), players generally like the concept. Convoys add interesting new possibilities to the main complex, tapping into a bit of that risk-reward element more abundant in branches. It’s the type of addition multiple players have expressed a desire for over the years, but as mentioned earlier I’m only more comfortable working some of it into the game now.

It’s nice how many interesting tactical options there are for confronting a convoy, each with their own benefits and drawbacks, be it of the stealthy, hackish, or destructive approach. Part of the challenge comes not purely from having to deal with the escorts, either, but the Freighter’s high core integrity making it harder to quickly destroy and thereby increasing the difficulty of doing so without taking too much damage from the escorts, or instead prioritizing the escorts while the Freighter itself gets away during the battle.

That it’s a mobile event also makes the encounter even more dynamic and therefore more challenging to pull off a successful ambush, but doing so is usually quite rewarding, and not even just for the cargo since salvaging the powerful escorts can also net some nice parts.

Below is my test run of the Beta 11 prerelease in which yaulers were introduced, the first encounter I think is the one at 1:56:23. We met several on that run, and they were interesting but I didn’t do all that well with them :P

[Spoilers]

The following section/remainder of the article contains spoilers but is relevant from a design standpoint so I’m including them here with a notice in case some readers want to just experience this stuff in game.

Cogmind isn’t the only one who might want to stop a cargo convoy in its tracks. Players will be familiar with a particular warlord capable of sending in forces to intercept the whole bunch. This potential event doesn’t have anything to do with Cogmind directly, though Cogmind can technically benefit from it by looting the battlefield since the odds overwhelmingly favor the ambushers.

I added this as a way to occasionally give players some free rewards if they know where the convoy went down (or get lucky enough to happen across it before everything is cleaned up!).

Also it’s intriguing when a global ALERT pops up reporting that the convoy is under attack but the player maybe isn’t anywhere nearby :P. Just another way of reinforcing that the world goes on without Cogmind and keep players wondering until they discover why.

Of course, even if Cogmind wasn’t involved in the ambush (but hopefully got something out of it regardless xD) they still may have to deal with some of the fallout, which involves a new type of response by Complex 0b10, one that I may also use for future situations but this is the first and only one so far. “Access Lockdown” redirects Heavy bots posted at junctions to exits across the map, and if necessary calls in additional Heavies to defend any other unprotected exits.

What are Heavies? Well that’s a topic for later ;)

(Update 210928: Read all about Heavies and their design in Spicing Up Primary Maps 2: Area Denial.)

Posted in Cogmind Beta Overhaul | Tagged , , | Leave a comment

Extreme Infowar: Active Sensor Suite

While earlier in Beta 11 development I already revisited and expanded Cogmind’s selection of parts geared towards information warfare, there was a need for yet another new one to complement the upcoming Heavy class. This time it’s a big one with even more (big!) benefits but also more (big!) drawbacks! Introducing the Active Sensor Suite…

(Yes it comes with an unfortunate acronym that will no doubt see plenty of use in the community, but I decided that thematically and logically this full name would most suitably conform to the part naming conventions given its functions so I went with it anyway :P)

cogmind_active_sensor_suite_art

Look at all that sensing power!

As you can see it’s a three-slot utility--we didn’t even yet have any double-slot infowar, although technically multiple types do work in pairs and require two slots to achieve their full effect. This large slot size is a bit of a negative, although recall that the storage rework did technically free up more potential slots for use elsewhere, so we do want to create even a greater number of options to utilize those.

On top of that the Active Sensor actually can’t be removed without destroying it, Processor style, so it’s not the kind of device that can be stashed away to keep it safe during hostile encounters (drawback detected).

Although a relatively high-rating prototype, it can still be acquired earlier in the game from the Heavies that use it (so there’s at least a reliable source, though this could technically be seen as a drawback since salvaging a Heavy also requires attacking it in the first place :P).

See the Unseen

The Active Sensor Suite’s main new function is to allow you to see the “desire paths” I wrote about in the previous article. Thematically speaking, as per the in-game description of this effect it “detects long-term residual evidence of prior robot activity within field of view.”

In that article the WIP samples were shared in red, but in practice the final color chosen to represent these paths is purple.

cogmind_active_sensor_suite_desire_path_sample1

Map excerpt of desire path visualization via Active Sensor Suite (tiles mode)

 

cogmind_active_sensor_suite_desire_path_sample2

Map excerpt of desire path visualization via Active Sensor Suite (ASCII mode)

While active, newly discovered path segments are highlighted for a moment (the duration is adjustable) to give an idea of how “heavily trafficked” an area is over the long term, which as described before could be useful knowledge for more quickly locating interactive machines and exits.

cogmind_active_sensor_suite_exploring

Just follow the purple brick road…

Super Sensor Array

This three-slot sensor lives up to its slot count by also simultaneously functioning as both the most powerful Sensor Array and Signal Interpreter available, each of which would normally require a slot of their own and not be as easily available until later. So slot-wise the path visualization functionality only costs one additional slot beyond a standard sensor set, though of course there’s also the fact that you can’t swap out this utility without destroying it.

These additional abilities are why the activation animation for the Active Sensor Suite highlights a circle (the detection range) and for the first portion uses an animation similar to the signal interpreter animation itself.

cogmind_active_sensor_suite_toggle_animation_with_desire_paths

Multipart activation animation for active sensors.

Toggling the suite is also how you view all your known/previously discovered paths, since those do not change during your short stay on the map and you may want to reference the full layout again later after having explored more. The length of time they remain visible is adjustable in advanced options, and unlike other toggle animations this one doesn’t disappear when you shift the map.

cogmind_active_sensor_suite_desire_path_visualization_panning

Checking out a wider area of known desire paths extending beyond the map view. (The visualization duration is automatically extended while panning the map.)

The sensor effect is actually even better than the best arrays, because active sensors are also immune to almost all forms of blocking and avoidance, including even Watcher jamming, Phase Generator scrambling, and Heavy AOE cloaking.

The Biggest Drawback

So far we have a few common technical drawbacks, but the real mechanical drawback I’ve yet to introduce…

Well it turns out 0b10 bots don’t really like you so actively scanning the Complex: Each new bot you scan with active sensors eventually contributes to notching up your alert level, in addition to causing a heightened response from 0b10 in the form of investigations. Security and surveillance-type bots care the most, but any combat bots will report being scanned and the effect adds up over time.

(The original test implementation of this mechanic contributed fractional amounts to alert on a per-turn basis depending on the number and type of enemies being scanned, but that meant it could be more advantageous to occasionally toggle the sensor off when there are certain, or too many, enemies nearby, introducing the kind of tedium we don’t really want more of here.)

In either case, an alert-based approach is clearly somewhat at odds with one of their main uses, but they’re quite powerful overall and big benefits must come with big tradeoffs. We’ll have to see how people actually put these to use.

At least this particular drawback only comes into play within 0b10-controlled areas--outside such areas you have free reign to use it without similar consequences.

For more about how this sensor suite is used, check out its owner in Spicing Up Primary Maps 2: Area Denial.

Posted in Mechanics | Tagged , | Leave a comment

“Desire Paths” for a Robot World

desire path (n.) -- a planning term referring to a path made by walkers or cyclists, as opposed to one that is officially planned

For years I’ve always been interested in making some kind of utility that allows you to see paths that were traveled by robots, partially because it just seems like a neat thing to do, something which would also probably look cool :)

Of course if the player is just entering a map and the entire population has literally just been “spawned in” as well, then they haven’t actually done anything yet and this utility wouldn’t even have any real information to display at the time, making the environment seem pretty artificial. What we want is a way to basically fake the data to reflect actions that might’ve happened before.

At the same time, with a theoretical utility function such as this there’s also the concern that where actual robots have been moving in the past hundreds or even thousand turns probably isn’t really very useful information for the player. To be useful, it’s less about where these actual robots have moved, but the areas we imagine they might’ve been more likely to visit over a longer duration, thereby highlighting potential “points of interest” on the map, points that the player probably finds interesting as well…

Time to fake some traffic data!

Basically we need to:

  1. Identify points of interest
  2. Assign them relative levels of importance
  3. Plot paths between them to generate a reference map for visualization purposes

I also needed something to call this feature internally, so I looked up the term to describe natural paths gradually created over time by people taking routes that don’t perfectly align with available pathways. They’re apparently called “desire paths” (among other names).

Now obviously 0b10 is mostly straight corridors with fewer open areas that work differently than people walking through an area like a park and cutting corners through the grass rather than following walkways. Robots are still essentially confined to these corridors and we don’t see them blasting through walls just to make a shortcut (unless you’re a Behemoth? :P), but they’re also not always moving in cardinal directions and taking perfect right angle turns (even if in the world of Cogmind doing so would technically not affect travel time!). Instead we see them frequently cut across areas in what looks like more natural movement, or taking a shortcut through a room where it’s convenient, or slipping between several machines in an array rather than going around the edge of the array, and so on.

cogmind_desire_paths_and_junction_ratings_test1

A very early implementation of the desire path system.

Those big squares filled with numbers are junctions, one of the “points of interest,” where the number represents their respective rating. Junctions are rated based on their size and number of corridors and rooms they link to.

Aside: In working on this feature I discovered that in all prior versions junction ratings have been incorrect due to forgetting to initialize their value before a different part of the code actually did the calculations, meaning that junction Sentries have been misplaced this whole time. I always kinda wondered why they seemed to be in random junctions rather than the important ones, but it was never all that important so I didn’t look into it. Now we know xD (Junctions are now properly rated, though this may not have a huge impact on Sentries going forward anyway since the most important junctions are going to be repurposed for another defensive purpose coming soon…)

Clearly the first thing we need to do here is identify exactly what types of locations count as points of interest for our purposes:

  • Exits: Duh
  • Machines: The interactive ones, yup
  • Junctions: Mainly to help connect everything and also make the path map seem more realistic
  • Chutes: Technically count as exits of a sort, and also for realism since as we know there is some 0b10 activity centered around these

And that’s pretty much it? Really that covers most of the relevant core environmental features, and although I had some other ideas, if there are too many points and a dense web of paths connecting them all, then the entire map is filled and the information becomes mostly useless anyway, or at least really difficult to parse.

Each type of point has its own level of importance, and the links between more important points will appear more prominently in the desire path visualization. Point types are also broken down further where appropriate, since not all exits are created equal, plus we can assign different values to different types of machines, and junctions can use their calculated rating as their importance (which is how I discovered that bug since I needed the actual number here and something was seriously off at first :P).

The general idea for the process is to plot a path between every point and every other point, assigning the average of each endpoint’s importance (“desire path value”) along the entire pathway.

Now it’s not realistic or useful to literally connect every point on the map--we don’t want some tiny Terminal in one corner of Factory pathing its way over to a caves exit on the opposite side, so we’re going to need more variables in order to limit these connections in a realistic manner. Each point type and subtype also define a maximum connection range and maximum path distance. The former requires that endpoints be within a certain direct range from one another (also nice because this value can limit our number of pathfinding calculations by not even calculating those which are clearly too far away), and the latter path distance limit will be some larger value to allow a path to snake over to its destination if necessary, but still stop it if the direct range check found it was simply on the other side of a wall but actually reaching it requires an excessively circuitous route.

cogmind_desire_path_point_of_interest_data_values

Source code values describing how each point point of interest integrates with the web of paths.

With these three variables in action, our desire path map should start to look better.

cogmind_desire_paths_and_junction_ratings_test3

A further refined implementation of the desire path system.

Additional notes about the above map:

  • Unlike the earliest sample image I shared before, the paths have now been fuzzed to look a bit more reasonable and pleasant. This is accomplished by adding half of each path’s value to any adjacent positions not on the path itself, and can also represent bots moving around each other, or patrols checking out rooms via doorways, etc.
  • Overlapping paths of course increase the value of a route even more, which is what the brighter lines represent. Having access to this information brings interesting implications for navigation… Is that bold line leading to an exit? Or a bunch of useful machines? Or… a Garrison!
  • More path and value tweaking might still happen depending on the results of the current prerelease version patrons are testing, but it’s in a decent state for now so I put that on pause to see how that plays out.

Challenges

For the most part this system seems to work nicely in Complex 0b10 maps, which as you can see it’s been initially designed for, but what about caves? What about custom prefabs? Oh my…

Defining a list of points of interest is easy when our maps are procedurally generated and everything can be managed automagically with a simple set of data and algorithms, but when you mix in all that handmade content, that calls for… you guessed it… handmade points of interest xD

So yeah, looks like we’ll need to expand this yet further if we’re going to add it at all. For this purpose I added an additional range of point types that can be manually placed inside prefabs to link up with other points as usual. These are actually listed at the end of the POINT_OF_INTEREST_DATA I shared above.

cogmind_desire_path_points_of_interest_prefabs_exiles_rexpaint

As an example, here’s the Exiles lab in REXPaint, with my test points placed using pink numbered identifiers in one of the layers.

 

cogmind_desire_path_points_of_interest_prefabs_exiles

And here’s that same map with the resulting desire path visualization as generated in the game

Now I’ll be the first to admit this information won’t be particularly helpful when you visit the Exiles, but it’s a part of maintaining consistency and polishing a game, so what are you gonna do? :P (okay technically for now it’s even going to be impossible to get the ability to see these paths before reaching this very early map, so it’s totally unnecessary here, but I needed a big prefab test case, and one that wouldn’t require sharing spoiler locations!)

That’s the extent of what I’ve done so far in terms of prefabs, just to test it out, but this is going to be a fairly large amount of work, parsing through Cogmind’s many hundreds of handcrafted rooms and areas to assign these! (Some special types of procedural maps will also likely need their own rules for additional points.)

I’m waiting to see more playtest results before assigning all the manual values, since the amount of effort required means it had better get done right the first time!

Processing power is another concern when working with this many calculations at once. Altogether the desire pathfinding (and associated fuzzing process) does indeed slow down map generation, though it’s currently within acceptable limits. To make sure I wouldn’t need to optimize the algorithms yet I did a bit of profiling to see just how much time these desire paths adds to the map initialization process in various locations (“initialization” includes both generation and all post-generation steps, everything needed to get the map ready to start playing in):

cogmind_desire_path_calculations_map_init_time_increase

The percentage increase to map creation time caused purely by path-related calculations on that map. Comparisons were in each case of course performed on the same map via seeding, where the only difference between the two was the addition of the desire path step.

Overall the cost shouldn’t be noticeable, especially given that some maps themselves may occasionally take up to 2~4 seconds to load due to throwing out a large number of invalid layouts.

A feature like this would be pretty easy to optimize since you aren’t going to need the data within the first split second of entering a map anyway, and nothing else is dependent on them, so we could easily defer these calculations until after the map has been loaded and distribute it over the first handful of frames. My first profiling results were actually noticeably slow, but that was during the implementation phase when I was using the slower debug version, so I eventually went on to compile the above data using the release version to make sure.

Other notes:

  • Do we want to let desire paths be somewhat influenced by actual robots and their activities? Probably not, because again it’s not especially useful, and although it could be more realistic or interesting in other ways, I’ll be theming this data such that this factor won’t be too relevant or necessary.
  • How does the player access this intel? That’s for next time ;)

Update 210802: Meet the Active Sensor Suite, the gateway to getting all this info and more!

Posted in Mechanics | Tagged , , | 4 Responses