For years I've been taking a pretty standardized approach to designing each new map in Cogmind, and although we have dozens of them now, it's one of the few topics I've never covered on the blog. This is essentially because a serious in-depth look at the entire process would require spoiling a lot of content, considering that all the most interesting maps have been located beyond the early game.
But with the recent release of Beta 8, which adds a very interesting map right to the early game, we now have a good opportunity to discuss map design without worrying too much about spoilers, since for the most part it's easily accessible content anyway.
This article will walk through every stage of the design and implementation process, from start to finish. I took a lot of notes about the process itself as I was building Beta 8, specifically so I could share them here and to ensure that what I write is an accurate representation of what actually went down.
Note that unlike the majority of maps in Cogmind, due to its nature this particular map has a mostly static layout and content rather than drawing heavily on procedural methods. As such the process is missing a few steps, but I'll cover those separately in an addendum. A mostly static map, on the other hand, provides some unique discussion opportunities of its own.
Before even starting, each map idea needs one or more concepts to build around, and in this case we have several goals:
- add more potential variety, especially to the early game
- provide more early plot hooks
- help new players
For a very long time my notes for potential Cogmind features contained the concept of "derelict labs," a way to access strange and fun technology, so when I started feeling we'd need a new area of the game to achieve all those goals, this concept seemed particularly fitting.
Once I'd decided this was likely to happen (several months before actually doing it), I began intermittently revisiting that section of my notes to expand it with new ideas and considerations. On each new visit to add more ideas, I'd intentionally avoid rereading previous notes on that topic, instead just appending any new thoughts at the bottom. This keeps me in the unique frame of mind I'm in at the time, allowing me to come up with potentially very different ideas, or even perhaps the exact same ideas again without realizing it :P (this because usually days or even weeks have passed and I've forgotten the details of my earlier ideas). Note that coincidentally repeating notes on the same ideas can actually be valuable, because it validates them, perhaps with different reasoning, or even fleshes them out in different directions I hadn't thought of in previous note-taking sessions!
This process resulted in a total of about 2,600 words of rough notes on the topic, which like all of my notes are organized as nested lists in a TXT file.
Normally I just delete rough notes once their contents have been implemented or converted to more permanent notes elsewhere, but this time I saved them to share with you. Download/read the original notes here (you'll need line wrapping off to view them properly!). Since the notes are a top-to-bottom process, you can see how they kept getting longer and longer with each extension as I apparently went back and forth on various points. There's even "final summary" followed by the typical "final final notes" followed by "no wait, final final reverses that" xD
In short, a new mini-faction of "Exiles" from another community has their own lab, offering the player both a new sensor ability (dubbed "FarCom") and access to prototype gear from among a pool of possible items. Story-wise, they become the player's earliest significant exposure to the world's lore. As such, it's good that I've circled back around to add this map after the rest of the world is already completed, so they can hook into it properly based on my knowledge of how everything can play out both in terms of story and gameplay. The alternative, trying to build this map from the start, would've likely meant repeatedly updating or changing its contents as the rest of the world was built. (Cogmind's world was almost entirely built from beginning to end, rather than skipping around.) I'm not a fan of ripping out or making significant changes to old content, preferring to get it right the first time.
So back in late October when it came time to add the Exiles, the first task was to reorganize those rough notes. This normally means reading back over them to remove the stupid ideas, refine rough ideas, and generally consolidate the notes while expanding on any unclear points, making sure it all fits together in support of my vision for the map.
I didn't spend very long in this phase, though, because there were simply too many notes this time around, and more importantly they were just going to be converted to a new form shortly afterward anyway. After just deleting some unnecessary chunks and making a few modifications, I quickly started on the proper map design doc.
Map Design Doc
The last planning stage before actually working on a map is to finalize all its relevant notes into a basic format I've been using since the beginning of Cogmind Alpha.
Each map generally has its own text file describing its design. I call these text files "supplements," since the idea originated when I started using these external files to supplement Cogmind's original design doc, a massive file which started to get a little unwieldy by the time the first public Alpha was released after two years (plus I didn't like the format/program that was used to create the original doc and wanted to start moving away from that, and by then the entire primary design doc had been implemented anyway).
Supplements for various maps added over the years. "EXI" is the code for Exiles--note its size relative to the others. It happens to be one of the more complex maps, with a lot of possible content and various scenarios.
Map design docs break down their contents into a number of common sections, including at the very least the following:
- goal: Main purpose(s) behind adding the map to begin with
- layout: An overview of environmental factors including the terrain and any props the player will see
- inhabitants: Descriptions of all the entities (in Cogmind's case, essentially robots) found on that map
- gameplay: Primary interactive elements of the map, including any cause and effect related to dynamic content
These are the main four, but some maps have one or two additional note categories applicable to that map in particular. For example the Exiles design doc adds a "location" section, because unlike most maps there are a number of important comments to make regarding how to access this map in the first place, and its general position in the world. There's also a large "part concepts" section for collecting ideas for their stash of prototypes.
You can read the entirety of the Exiles map design doc here (again, turn off line wrapping). If you checked out the rough notes earlier, you can see how they evolved into the proper design doc, which weighs in at three times the size (about 7,500 words). Some of the minor details in this doc may not be the same in the final implementation since I sometimes make last-minute changes that aren't necessarily reflected back in the notes, but it's mostly accurate.
It's extremely important to expand the initial map design process to include considerations beyond the map itself. How that map fits into the bigger picture with regard to overall player strategy should be determined in advance, since it can have a broad impact on a map's content, and if not careful a poorly planned map could end up needing more significant changes later on if players find that it's either not very interesting or useful to them in the long run.*
(*There is currently one optional map in Cogmind which unfortunately fits this description: Recycling. It's a relatively simple, small map with some unique mechanics of its own, but its advantages aren't really as enticing for players as I had first envisioned them when it was created early in Cogmind Alpha. Back then I was just getting started adding optional maps, and have learned a lot since then, including by way of the player community as it's matured. I have plans to improve it one day, but it's not a pre-1.0 priority since it's rather out of the way anyway.)
I wouldn't want to waste player time, or my own, so the Exiles map in particular has a number of long-term strategic implications, and properly building them into the experience as a whole involved addressing different kinds of player needs, goals, and... um, craftiness ;)
Like pretty much all of the many optional branch maps in Cogmind's world, the Exiles offer tradeoffs, making certain areas easier while increasing the challenge level in others.
Primary long-term strategic decisions related to the Exiles. Note that some "drawbacks" may even be seen as good (or at least neutral) by certain players, so there are alternative interpretations to this graph as far as coloring goes. (I've chosen the most common view.)
There are other random Exiles scenarios which can affect the available options, but I'm covering just the most common one here. Also, graphed above are only the major strategic considerations--individual prototypes can change a player's potential route or even suggest builds depending on what they are, because they're selected randomly from a pool of possibilities. Overall this one map has really opened up a lot of new options! I'll talk about these options in more detail later.
As designed, the standard Exiles benefits (one free prototype + FarCom) are especially noticeable in the short-term, at the expense of long-term drawbacks, making them a great choice for new or inexperienced players. That's not to say they can't be useful for experienced players as well--already one player won an extended run despite using FarCom, which essentially makes late-game Research branches off limits, even though that's where one normally accesses a lot of the most effective tools for tackling extended game challenges.
Having tradeoffs makes visiting the Exiles much more interesting, and they're essential, too, because without tradeoffs it would be easy for a player to become overpowered, and a no-brainer to route a run through this map. Naturally not every map needs such explicit drawbacks, since in a lot of cases the drawback is the inherent cost of reaching and/or fighting whatever is in the given map, but here I should emphasized that the inhabitants of this particular map are all friendly, and reaching it is quite easy, so stronger measures were required.
Okay, planning is over, time to start doing.
As we already have our high-level analysis and relatively complete plans to guide construction of the new map, the first stage is to put together its entities and items, basically any individual objects that can be created in isolation. This would be the "pieces before the puzzle" approach, breaking down a large project into its smallest parts and working on each of the latter first.
But I'm not even adding them to the new map at this point--it doesn't even exist yet.
Since there's a lot of work to do for such a giant chunk of content, trying to add each new element to the map as it's finished would often involve thinking at multiple levels (local area, map-wide, game-wide...), which is a lot less efficient than focusing on as few aspects as possible without constantly bouncing around. Working efficiently is not only faster, but also gives better results.
So the plan here is to get all the pieces in order, then put them together all at once.
Personally I like to start with the pieces that require the most time to implement, which for me includes most importantly anything that I think would be fun and interesting but is ultimately "optional" when it comes down to it, such as certain rare special events, items, etc.
Stuff like Beta 8's time travel-enabling "Chronowheel" item took forever, one of those things where I'd say "okay I'm going to tackle this one today," then at the end of the day it's "okay, I'll just have to finish this tomorrow...," and then a couple days later I'm like "uh, really gotta finish this thing up today!" (and maybe still don't xD)
But this is the type of content that really makes the project feel more like what it really is, a world built out of passion rather than just a "good enough game to sell and keep the lights on." If I leave this tough optional stuff until later in the release cycle, it's more and more likely to get dropped as I see the deadline approaching and there's still so many other necessary tasks left to do, not to mention the fatigue of what it took to get near the end of the release cycle in the first place.
In the end I'm always glad I've done these parts of the content, but I have to essentially force it through proper planning to make sure it actually happens :P
Items are the smallest building blocks of a map, so we start there.
The notes and design doc originally listed them in completely random order, but again in the interest of efficiency I somewhat reorganized the list to keep certain categories together. For example all projectile weapons should be worked on in succession, since they would all involve similar parts of the data and code. This makes working down the list flow more naturally, without having to jump between too many different areas throughout the source/data, mentally loading extra scopes.
Before starting on any code or data at all, however, I worked with a completely different scope: art. All the art for the new items (more than 30 of them) was done together over a several day period, since again it makes sense to tackle like tasks in bulk. It can be harder to bear when a process like this stretches on for weeks or more, but as a solo dev who can only do one thing at a time, despite game development being a huge long-term undertaking, the efficiency gains are pretty vital.
Art for some EX-tech prototypes found in Beta 8. Each of the new primary NPCs I'd planned for the new map have "signed" their prototypes with their name.
Immediately after the art came the lore. Each of the new items has some lore text associated with it, and seeing how that would in some cases help define or refine the item capabilities themselves, I wanted to make sure they were all accurate and consistent. So all of those entries were written at once, also important here since because they're generally meant for the player to discover/read them in a particular order.
And finally it was time to create the dozens of items themselves--adding the data, balancing their stats, etc., which altogether took a couple weeks. Some items can be added in as little as 30 minutes or so, while others like the Chronowheel mentioned earlier could take several days.
The "Latent Energy Streamer" weapon adds a whole new resource in the form of "latent energy" which could potentially be more widely used later, but for now the entire thing was added specifically for just that one weapon, despite taking several days to complete xD
Latent energy is found throughout the environment, more often concentrated around stationary props like machines and doors.
The LES draws on that energy and focuses it for devastating amounts of electromagnetic damage over an area, but also has side effects such as destabilizing nearby explosive machines, breaking automatic doors, and even corrupting the user. In fact, a number of the Exiles prototypes have negative side effects, which is what makes it possible to give the player such powerful parts early on in the game.
Firing the LES. The firing animation took a while to perfect, too, being different from normal weapons in that it more closely ties into the surrounding environment, tracing lines through the latent energy that it's actually using to fire.
The LES itself also has a unique tag which displays the amount of nearby accessible energy in number terms, as well as shows the actual range of damage it can convert that energy to, values which change as the local energy naturally ebbs and flows, or is used up and slowly rebuilds.
I'm really glad the LES is in game (and can't wait to get a chance to use it myself during a regular run :D), though if I'd waited until late in the dev cycle to add it I'm not sure it would be a thing.
After items comes another basic building block: NPCs. Some of these bots make use of the new items so they couldn't come first, but once the items are ready we've got everything we need to put bots together, and an entity (robot) is a pretty self-contained little unit of development that doesn't rely on the map itself (but will become a part of it), so they're a good candidate for getting out of the way early. They take a while to build and balance, but focusing on them individually now means it will be easy to drop them all in on short notice when and where we need them later.
The Exiles map includes four new core NPCs, each of which has a line of data defining their properties. It's a fairly long line!
As a demonstration, here's the data for one of the new NPCs, 8R-AWN. (I've wrapped the line a couple times here so as not to force quite that much horizontal scrolling :P)
When their data is complete, I run them through a separate program that can analyze robot designs and tell whether they'll be overweight, have resource problems, overheat in combat, or any number of other issues. Their stats can be adjusted as necessary before moving on to the actual map :P
Actually no... At this point I also decided that before the map itself I'd implement the FarCom sensor ability they can give you. This, too, could be worked on as an isolated system since I could test it explicitly rather than immediately developing the proper method of obtaining it in game. It could be hooked in as a piece of the puzzle later.
FarCom in action, showing a faint circle within which hostile 0b10 combat bots are detected. (The circle has a slow pulse to it, but the gif doesn't capture that well.)
From an overall design perspective, there are enough types of differences between FarCom and normal attachable Sensors that there is no clearly superior form of detection in all scenarios. Each has their own benefits and drawbacks.
That said, FarCom is definitely a clear boon for new players, who get a free way to locate threats from afar without relying on any items for that knowledge. New players don't have an easy time finding (and knowing to use!) Sensors, and parts can be destroyed, while FarCom cannot.
The unquestionably most significant benefit from FarCom, one that's quite attractive even to non-beginners, is that it doesn't occupy any part slots at all. This is especially true in the early game where two slots is a larger relative portion of Cogmind's available slots. Sensor users can try to get away with one slot (just the array without an interpreter), but getting the same level of detail that FarCom offers requires two slots devoted to sensor data.
Freeing up a slot or two means extra armor, more storage, better targeting, and/or any number of other utility options, and this is a benefit that extends throughout much of the run, wherever FarCom is active. Of course, using FarCom is still not something everyone will always want to do, as per the earlier chart showing the serious late-game drawbacks.
Overall I'm pretty happy with how it's turned out.
Layout and Integration
Time to build a map! Sort of :)
I always start on blank sheets of loose paper since I find it the most natural, fast, and free-form.
Most of that page is actually occupied by graphs considering how to connect this new map to the rest of the world. The route the player has to take to reach a map, and return to other areas, are important factors in setting the related rewards and challenge level.
The Exiles are accessible from either -10 (essentially the lowest/earliest depth!) or -9, by the way of the Mines at that depth. They will only appear at one depth, though, and as the entrance is somewhat tucked away inside the Mines, I added a special indicator that lets observant players know when they're at the same depth as the Exiles. I didn't want players potentially wasting their time scouring an entire Mines depth for an entrance that might not even be there, so I drew on so-called "level feelings," a mechanic found in a number of classic roguelikes such as NetHack, ADOM, and Angband whereby on entering a new map you get a log message reflecting a special aspect of that map.
Cogmind's first application of "level feeling," added to save players time when searching for the Exiles.
Players can also read lore in the Exiles Terminals which explains the scanning.
As for the return trip after visiting the Exiles, I had thought to maybe send the player back to the main path through the Lower Caves, but that was when I was initially trying to restrict the design to existing options. Instead I ended up deciding to add a new Mines depth at -8, one that can only be reached while returning from the Exiles. This is both better gameplay (Mines are the smallest and easiest maps, suitable for weaker players) and more logical (the Exiles shouldn't feel quite that close to the Complex, hence no immediate return to it from their map).
In-game world map showing a player route having visited the Exiles and come back to -8/Materials through -8/Mines. That Mines depth is not normally directly accessible in the reverse direction, from -8/Materials, to avoid adding unnecessary exits in that map.
The little nondescript blob at the top right of the note paper is actually quite important, determining the general locations of entrances/exits for the map itself, which in turn can affect the whole map design (terrain layout, content positioning, event timings...). These most vital points determine the flow of the experience. The player enters from the lower-right, and almost immediately there's a junction leading to an exit out (mainly necessary to provide an avenue for other robots to enter the map from this side--more on that later), then the main content area would be in the middle, and further to the left is a second "back exit" from the map.
Lastly, on the left* of the notes is a list of ideas for things I'd need to add to the actual map layout, which I'd sketch out next...
*I'm left-handed and tend to orient my paper horizontally and fill pages of notes from right to left :P
Confident in the connections, it was time to sketch the map layout in more detail!
As a static map with important NPC interactions, the layout really had to take into consideration the flow of a new player coming in and experiencing it for the first time--who will they see first and what will they say so that the order of everything makes sense?
So after doing the quick tentative sketch above (based on the earlier general list), I had to take a break from this and jump ahead a bit to work on content for a day, specifically dialogue. True, the NPCs haven't been placed yet, nor is there even a map to place them in, but by writing out the dialogue in advance I could make sure no single NPC was saying too much or otherwise needed to offload some lines onto another, which might affect the layout. (It did.)
After the dialogue detour, I did another pass on the map sketch, creating this second more specific iteration to match it:
The player enters from the bottom right, sees another corridor leading to an exit but no hostiles in view so it's safe to continue exploring. Also there are some "rigged" power sources in the tunnel forward, a mechanic only made available via Exiles tech and therefore will be new to the player--anyone curious will want to check them and out and continue exploring, first meeting 8R-AWN in the corridor there for a friendly welcome/intro chat. Then they'll move into the central area and spot the second main NPC, EX-HEX, who introduces a bit more of the lore and invites the player to seek out EX-BIN to help with a project. From there they can go anywhere, either learning more about the place from prototype tester NPCs in the south area, or head north to get the main benefits of the map, FarCom and the prototype(s). Either direction is fine for a first experience. Then they can leave by heading back to the east side, but are more likely to take the rear exit.
At this point I went ahead and put together all the extra terminal lore and minor NPC dialogue as well, since there might be something in there which could affect the map layout as well (there wasn't, but anyway having just finished the dialogue it was good to keep up the pace while still in "writing mode"--efficiency!).
Then comes time to break out my next tool: REXPaint. I turn the reference sketch into a general layout in REXPaint, measuring out cell distances to make sure everything will fit just right--not too squished and not too open, and that the average player FOV from a given position will reveal the right amount of content.
Exiles map taking shape in REXPaint. For now it's just a single layer containing the general layout, entrance, and exits, still no objects or other details yet. It's also lacking some layout details that might emerge/become necessary as objects are added.
And with that file saved it's ready to drop into the game!
(This map happens to have a fully static layout, so it skips some steps here that many other maps might require. I'll cover those in an addendum.)
It's now time to build the actual experience, starting... outside the map :P
As a beginner-friendly map which is still kind of out of the way, I wanted there to be some ways to help funnel new players in that direction. So before working on the map itself, I again wanted to develop along the flow of the experience by beginning with how players are most likely to find it the first time. 8R-AWN, the brawn to the Exiles' brains and the first NPC players meet on entering their lab/cave, is sometimes out running errands for them, and the player might meet him while on one of these errands.
In one of the first Materials floors, whichever matches the Exiles depth, 8R-AWN can be found making his way across the floor towards an exit the Mines. The chance he'll be around is higher for new players who've never met the Exiles before (unless they're using a seed, since seeded content should be consistent, irrelevant of player history). On spotting the player, 8R-AWN invites them to follow, and proceeds to trash hostiles all along the route to the exit. (Or if the player is on the far side of the map, they may simply find a trail of destruction left in his wake from earlier, and 8R-AWN is long gone.) He'll take the exit himself, and if he spoke with the player earlier will be waiting there when the player arrives before some more dialogue and continuing to lead on to the Exiles' hidden entrance.
Another possible encounter with 8R-AWN occurs during the Mines infestation. Assembled suddenly swarming into the area is a pretty deadly encounter for the unprepared, so it's nice that 8R-AWN might show up to save the day, using special tech to shut them all down remotely. In this case if he spots the player he'll also lead them back to the hidden entrance.
This hidden entrance actually took a few attempts to design, since there needs to be a wall that opens up automatically for a friendly player, but I didn't want the player to see a wall from a distance, conclude that it was a dead end, and never bother approaching, so the trigger was placed such that the walls would open immediately as they came into view.
Exiles entrance layout design in Mines. To the player it will appear as if the corridor continues forward until they round the corner, at which point the hidden doors open automatically to reveal the exit as long as the player is friendly.
This entrance is placed as a guaranteed prefab using the pre-mapgen method described here.
That same post describes the data/scripting methods used to define the contents of Exiles, which as a static map is simply one giant prefab :)
At this point we can start dropping in all the objects that were created earlier--items, NPCs, dialogue, lore, etc. So it's a relatively quick process since the objects are all ready, which is better than having to repeatedly stop what I'm doing to implement them. Instead I can focus on how everything is fitting together at the macro level, rather than worrying about low-level details.
Once again we're following the flow of the experience into the map from the right side, only this time using additional layers of the REXPaint to draw machines (gray lines) and mark entity and item positions (green letters and green numbers, respectively). Machines and other props, including invisible triggers, are identified using uppercase green letters.
The corresponding data goes into a text file, the features of which I've provided a breakdown before in "Map Prefabs, in Depth."
Complete Exiles prefab data in image form, since it's easier to read with syntax highlighting enabled. (Some of the lines are really long but not worth extending the image for, so they're just cut off.) The file is also available in text form.
As I'm going through adding the objects, I make a list of all the related explicit tests that will be necessary to confirm the content is working as intended. I'm also constantly thinking of all the things that could go wrong and need to be looked into once everything is in motion. This list will be quite important later, and is better put together while each element is on my mind rather than trying to remember these points later, or coming up with tests from scratch. Despite my best efforts at the initial implementation, usually a number of things don't work as intended, and it's certainly better to work through it all systematically rather than wait for a stream of bug reports from players :P
This is a fairly large map so I didn't wait until everything was placed before testing, instead stopping a few times to test in batches, generally clearing out the list in the process.
With most of the main content done, I moved on to more superficial elements of the kind that can be tacked on.
The FarCom mechanics were already implement much earlier, but it was still missing the animation played when you first receive the ability from the Exiles. There are a number of full-screen animations throughout Cogmind which occur when major abilities are conferred, so FarCom shouldn't be an exception.
One element I also always leave for the end of the content phase is audio. Working with sound effects involves concentrating on tasks other than code, including managing a bunch of audio files and messing with them in Audacity. It's more efficient to do all of them together, so whenever I come across something that needs audio I just leave a placeholder and add it to a list, one that gets taken care of after the rest of the content.
Ambient audio visualization of the area around the FarCom Aligner, where brightness indicates volume. For those who want to read more on this, I've written about ambient sound before.
There were other non-ambient sounds to handle as well.
I keep saying the Exiles map is "static," but that doesn't mean it can't have a little variety!
There's the usual variety created via the prefab data shared above: Common items in store rooms are randomized, as are the prototypes (where there is quite a large amount of variety since the items can change up gameplay significantly, but appear in different combinations each run).
There's also some variety created via the fact that you may or may not meet 8R-AWN before reaching the Exiles, in different situations, so that makes for unique dialogue options.
But the most significant variety comes from players not always finding the map in its default state at all. There are actually four different scenarios, the above text describing only the first. As part of the world generation, a random state for the map is chosen from among the following:
- 51%: The default scenario, as described. This state is also always forced under a number of other world conditions outside the map, so the effective percentage is somewhat higher.
- 12%: Deserted. The Exiles have already wiped their terminals and abandoned their lab.
- 12%: Destroyed. Complex 0b10 has already attacked the Exiles, leaving the place scarred from battle. There are no survivors to be found, but the area contains other useful remains.
- 25%: This is equivalent to the default scenario, except forces from 0b10 will attack while the player is there.
I built the base map first, then implemented the 0b10 attack (essentially an event tacked on), then moved on to the other two variants last since they were less complicated. More complicated map variants should come first in case they require changing parts of the map concept itself to work right, whereas doing complicated variants later could mean having to waste time changing a bunch of earlier work! It's hard to predict all the changes that might be necessary in advance, so prioritizing like this is important.
The deserted and destroyed variants were easy to manage since they were basically just modified data and REXPaint maps.
"Destroyed" Exiles prefab in REXPaint with all data layers visible. A comparison to the earlier default scenario reveals newly destroyed machinery, randomized (and randomly shifted) debris, exploded areas, and other different procedural content like possible salvageable robots.
The attack scenario was the most time-consuming variant, since I had to watch the same battle again and again to see all the possible outcomes and whether they met expectations. I spent a couple hours just watching attacks, repeatedly tweaking various parameters to get the desired results.
The Exiles are attacked by 0b10, with the map fully revealed for observation/debugging purposes. 8R-AWN covers the retreat, and EX-DEC drops a sentry turret before taking off.
Finally almost done! The "normal" way to play is complete at this point, but there's one more important stage: anti-cheese measures :)
Naturally some players will try to gain every possible advantage they can think of, even those requiring outright thievery or murdering allies, so it's necessary to balance those possibilities, too.
Aside: Not all roguelikes need to be balanced like this--some even revel in being totally unbalanced, but for the most part Cogmind is meant to be a tightly balanced experience. Even though some players do still manage to stretch the limits through extreme cunning, which is fine, I want to be careful about allowing specific actions to be so rewarding over others that players always see it as "the proper way" to do something, to the detriment of all other possibilities.
Sure the Exiles are a friendly bunch, but players who see them as a means to an end will likely... try to end them. Handling this was a bit more complex than usual because the Exiles experience isn't limited to a single map--player hostility could begin wherever they see 8R-AWN, thus behaviors could change during future meetings, including on the map itself.
Earlier I charted the strategic decisions a player can make with regard to the Exiles, and the whole reason these are decisions to begin with is that each comes with an associated cost. Players can choose to...
1) Use the default approach, by taking a single prototype from the Exiles vault and using that and FarCom scanning support to just tackle the main areas of the Complex.
This is the easiest option, good for new players. They'll lose the chance to get imprinted in Zion (normally another good crutch for newer players but one that doesn't appear until the mid-game), and they'd have to avoid the late-game Research branches which are very deadly for players with FarCom. Balance-wise, this is because those branches contain alien tech and many of the most powerful items in the game. FarCom makes many other maps easier, at the cost of not having access to these resources.
2) Take one prototype and FarCom, and enter the Research branches anyway.
This is extremely difficult. Entering a Research branch with FarCom triggers "Maximum Security," the strongest response from the Complex so far, which is essentially like an instantly triggered version of "High Security" with even more assaults (basically endless increasingly strong waves of hostiles entering the map). This mode was added to Cogmind specifically as a response to FarCom, but also made sense to trigger in a few other special scenarios, so I appliedit to those as well.
You can see in the rough design notes that the original anti-FarCom plan for Research branches was to dispatch Trackers, a new type of fast and deadly prototype bot. Later I decided that Maximum Security was a better solution there (mainly as an even stronger deterrent), but having already done all the preparations for adding Trackers, I decided to at least make them part of a revamped Intercept squad system.
Intercept squads are another form of tradeoff in Cogmind, originally intended to be very challenging, but players had gotten so good at strategizing that they weren't quite challenging enough anymore--now the good players have to think long and hard about whether they really want to risk Intercepts :P
Ideally like the FarCom sensor mechanic and other building blocks, something as fundamental to the overarching design as MaxSec and new Intercepts should've been determined much earlier in the map design process, but I hadn't yet come up with a good solution and needed to let it sit for a while, and couldn't wait any longer to start Exiles work for Beta 8, so it had to be postponed and wasn't even decided until close to this final stage. Some major changes are best left in waiting :)
3) Steal all three prototypes from the Exiles vault and add some challenge to the mid-game caves.
For those who really want more than one prototype, this is possible albeit with a bit of a drawback. For one, FarCom will no longer work since by stealing all the prototypes you didn't follow their instructions, although for some players this may be a positive since entering Research branches then becomes a possibility (as does imprinting, if they want to!).
The prototypes are quite powerful, so there needs to be a clear cost associated with stealing them. For this scenario I added a new drawback: Master Thieves. Although they're not too common, Cogmind already has thieves hiding in caves, so I made a special variant which is even more effective and specifically tracks a thieving player any time they're traveling through caves. If you steal from the derelicts, they steal right back--it's an "eye for an eye" sort of deal :) (Thieves race up and try to rip a part off their target, then run away and eventually disappear forever once out of sight.)
Beta 8 has been out for a little while and the current meta among the better players seems to be preferring this route more often than others. I'm not sure if it'll be necessary, but if this route is always superior there are other tweaks to consider, such as allowing Master Thieves to rip parts out of the player's inventory as well ;). That said, I don't want to make this tradeoff as expensive as the FarCom-Research thing--it should be something that players are willing to face under certain circumstances.
4) Steal all three prototypes but just tackle the main areas of the Complex, avoiding the caves.
While not the easiest option, this is still easier than a non-Exiles run. Stealing all the prototypes means losing FarCom, but using sensors instead and avoiding the caves means staying safe from thieves, and still being able to stealthily raid Research branches for the best parts. Avoiding the caves does means losing access to some potential mid-game benefits, but those are optional and there are helpful non-cave branches to consider anyway.
5) Kill the Exiles, specifically 8R-AWN to salvage his own excellent prototype loadout, and also steal all three prototypes.
This is basically the strongest result for the player (assuming no need/desire for FarCom), though also the most dangerous option since 8R-AWN is pretty powerful and Cogmind is weak at the beginning. Players are already doing this, though, because of course they are :P
I did add the possibility of a Hero of Zion attacking the player as a result of their hostilities, but didn't make it guaranteed since that, too, could be gamed by players for more cheese potential. I'd rather it just happen in some cases as more of a lore-related surprise.
As you can see there are quite a few special considerations when adding a new map! Gotta think of how players will react to each possibility, and whether they'll think certain tradeoffs are worth it. In making these judgments it helps that I play a fair bit of my own, and that I'm also always reading about player experiences.
(This article was originally published here, on the Grid Sage Games dev blog, where the next pair of articles are addendums to this one, covering steps specific to procedural level design, and a comparison of static vs. procedural maps as well as hybrid approaches..)