Official development blog

2018 7DRL Postmortem, Part 3: Spending Too Long on Map Generation and Content

Picking up where we left off at the end of Part 2, about the early days working on the core interface and mechanics

Map Generation

I spent an entire day just working on map generation. At the end of that day my desk looked like this:

polybot7_desktop_mapgen_work_7DRL2018

My desk after reasoning through various POLYBOT-7 map layout needs.

All the maps use my tunneling algorithm from Cogmind, albeit with different parameters. Slot Modules (the way to get new parts slots) are actually among those parameters, existing as prefabs that are deliberately placed in certain locations relative to map entrances/exits.

polybot7_procedural_map_structure_annotated

Sample 100×100 map layout, annotated. The player enters from one of the red dots and has to exit from another. This particular layout has four distributed slot module rooms rather than the usual three, and POLYBOT-7 has a lot more hidden doors and corridors than Cogmind. There are also very few large rooms.

I was particularly worried about screwing this phase up because a good set of maps takes a long time to create and there’d be no time to redo this later. While designing the layouts I based a lot of my assumptions on what I knew from exploring Cogmind maps, combined with plans for how POLYBOT-7’s content was going to change everything (the next step in the process, which I’ll cover later). Honestly I didn’t have to spend so much time on map generation and everything would’ve been fine, but I wanted more variety to maximize replayability while also keeping it challenging. Map size and layout are understandably crucial to balance, and I’d decided it would be appropriate to increase map size at each depth, meaning multiple different layouts were needed for every floor. So this took a while.

polybot7_mapgen_tests_80

Testing layout generation for the 80×80 map (second floor).

polybot7_mapgen_tests_100

Testing layout generation for the 100×100 map (third floor).

polybot7_mapgen_tests_125_cubbies

Testing generation for one layout style (each floor has multiple styles) of the 125×125 map (fourth floor).

It was during mapgen work that I made a huge change to the game’s direction: permanent upgrades. Rather than Cogmind’s evolution-based system where you simply have to reach an exit to regain core integrity and get stat boosts, the player collects random upgrade modules that provide permanent benefits like damage resistance, extra energy/matter capacity, greater accuracy or sight range, etc. This is a mechanic I really wanted to explore in P7, but it had originally been relegated to the “probably no time for that” list in the design doc. Little did I know, come the middle of the week I’d be forced to draw on this idea to balance the design.

When it came down to it, under the new mechanics map entrances and exits were very difficult to place in the same way I did for Cogmind, since P7 maps needed to be smaller, but all stat upgrades being local to a floor would mean that I no longer have to spread out the exits! Players can locate exits quickly and that’s fine, because they’ll still want to explore for more upgrades as long as they reasonably can without losing too much in the process, which is where the real challenge lies.

What’s more, obtaining these upgrades would require attacking Dispatchers (the primary source of enemies scattered across the floor), helping focus on the combat-oriented nature of the game--risk fighting for upgrades, or leave early. Collecting permanent upgrades is also simply a fun thing to do in games, despite being almost totally absent from Cogmind, so it’d be nice to experiment with that in a Cogmind-like setting.

In Cogmind, stealth/speed-based strategies emerge naturally from the mechanics because you can simply attempt to avoid (or outrun) enemies while locating exits, but that’s not possible here and now the POLYBOT-7 mechanics do so much more to reinforce combat as the main approach. Focus! Unfortunately it also meant that there would now be even more work to do when it came to content: making all the upgrades :P

Content

While I had a pretty good schedule worked out for 7DRL, fortunately that schedule also had a couple extra days built in for “balance and fun stuff,” because as it turned out I needed to reallocate all that to more pressing matters with regard to content in the middle of the week xD. My original plan was to focus mostly on giving POLYBOT-7 lots of unique mechanics while retaining many of the same items as Cogmind. But for a number of reasons that felt inappropriate, both thematically and mechanically. A better approach would be to add a whole bunch of new content as well… so I ended up crazily working through that unplanned bit mid-week. Towards the last couple days it was looking bleak and I thought I might not even finish! Apparently I ended up finding enough shortcuts to take, while just working really really fast :P

New content or not, everything had to be reworked for the new map view size. Cogmind shows up to a 50×50 area of the current map at once, and all its mechanics and content are designed assuming those dimensions. Frequently spotting, or being able to shoot (or be shot by), enemies who are off the edge of the map view and require scrolling in order to see/shoot is poor design, so it should be avoided at all costs. At the same time, having items and systems that can take maximum advantage of the available viewing area is also desirable, so you can see how central that view area is to a design.

To try to retain as much balance as possible without excessive work and testing, the simplest way to approach existing data is to take any range-related numbers and drop them by 40%, to mirror the 50-to-30 change. This was the first adjustment, to literally copy weapon range data into a spreadsheet, multiply it all by 0.6, then copy the results back :P

But the 40% reduction would also have a significant indirect effect on firing time. Earlier for the propulsion system rewrite I set the desired base movement speed to be slightly faster than once per turn, and calculated that in practice (based on total loadout mass) players would generally require anywhere from 0.75 to 2.5 turns to move one space--this was intended to keep players from moving too fast relative to the smaller map sizes. And in relation to that, again to retain a familiar balance based on experience with Cogmind, the next goal here would be to choose a firing time cost that gave enemies approximately the same number of opportunities to shoot at a fast or slow moving player as seen in Cogmind. The numbers came out as 3 turns to fire one weapon, 4.5 turns to fire a volley of two. Later testing showed that these seemed to work fine, so they weren’t tweaked at all.

polybot7_7DRL_speed_time_notes

The few notes used to calculate movement speeds and relative volley times, sketched out during the mapgen process to ensure the map sizes would be reasonable for the target movement rates.

The item work of course involved a lot more than just ranges:

  • All (110) Cogmind propulsion items were removed and replaced with 46 new ones (although some of the names were reused, all the stats were reworked).
  • The range of power sources was simplified, removing 23 of them as well as adding a new set of 9 which most of the enemies use (instead of the regular power sources).
  • 14 upgrade modules were created (at least the behavior code for half of these was available from Cogmind, and the other half was pretty quick to add using a similar model).
  • Utilities were reworked to remove most of those with purely non-combat effects, and simplify the remaining ones to use a more basic naming scheme. In all, P7 has 182 fewer utilities than Cogmind.
  • Weapon names and progression were similarly simplified, in addition to adding 21 new weapons, most intended for use by enemies. Lots of Cogmind weapons (nearly 200) were removed, and as mentioned before, this process avoided keeping most weapons that used slower animations. One exception was the micro-nuke, the awesomeness of which many think is underemphasized in Cogmind, so I used POLYBOT-7 as a chance to give it the spotlight and make it the best launcher :D. A number of Cogmind weapons were also significantly altered to convert them into better versions of earlier weapons, and had their animations changed to match their new group, albeit recolored.
  • Overall, POLYBOT-7 has only 412 items compared to Cogmind’s 900.

Once items were done it was then time to put together robots, which are mostly defined by their items. All robots were built from scratch, but in most cases used Cogmind robots as reference templates to guide their design. The general idea is that enemy robots use inferior parts, so while the player can attach and use anything, it’s often best to avoid salvaged parts when possible (but the challenge comes when there’s a lot of salvage lying around and it fills any empty slots for you automatically! This somewhat discourages the “safe” tactic of fighting in doorways). Their power sources also come with no energy storage capacity, so the idea here is that if you rely solely on other bots for power you’ll have less reserves for supporting flexible builds.

I also gave some robots items they don’t really take advantage of but that the player might want, as a reliable way to acquire them. This is a design strategy used a lot more often in Cogmind than with P7, but there were a few cases it’s helpful. For example Aimbots carry Structural Scanners so that players have frequent access to a way to detect hidden doors--remember there are a lot more of these in POLYBOT-7! (Also thematically it does kinda make sense that Aimbots, which can attack targets through walls, might have these :P).

polybot7_7DRL_entitiy_data

Complete robot data!

Once robots were completed (see how all this progresses in a nicely orderly fashion? :D), it was finally time for Dispatchers, the focal point of much of the combat and therefore gameplay experience, including the difficulty! Dispatchers are basically Cogmind Garrisons but with different behavior (activating based on player proximity, timed dispatch of squads until destruction, and dropping modules once disabled), but being a focus of the challenge they ended up requiring a lot of balance work, especially in terms of how far away they might trigger, and how many bots they release. This is something I revisited a few times over the final couple days. Their bots do not, however always directly attack the player! That would be pretty boring, so some of them may stay to defend the Dispatcher, and others will head to the area where the Dispatcher was triggered from, but technically never seek out the player directly like some squads in Cogmind might.

With content more or less finished, I moved on to overall map balance. This is where I’d spend time repeatedly loading random maps and looking at them in a zoomed out view to examine distribution of items, patrols, sentries, Dispatchers, etc. and tweak a lot of spawning numbers/ratios as necessary to create something close to what looked like a balanced experience.

polybot7_WIP_7DRL_day6_balancing_map_content_2_paths

Examining content across a section of map, including patrol paths (the colored lines).

POLYBOT-7 was meant to be a pretty short experience, only five floors, but aside from unique map layouts I figured another relatively inexpensive way to increase replayability for those who are really into it (and play well) would be to offer a “New Game+” after winning. A number of difficulty-related variables could simply be tweaked by the number of times the player had won, and why stop at a single NG+? I decided to add up to five consecutive New Game modes, each harder than the last. Tweakable factors:

  • Number of patrols initially on a map
  • Patrol size
  • Range at which Dispatchers are triggered
  • Number of robots dispatched per group
  • Weighting for types of robots dispatched
  • Chance that a dispatch will be accompanied by a supporting Blastbot (uses missiles) or Forcebot (protects allies with force field)
  • Interval between dispatches (this was implemented but I didn’t see a need to tweak it so it remains static: 100 turns)
  • Salvage rate from destroyed robots

Other non-gameplay-related changes for NG+ runs:

  • Each has a unique name: “Alpha,” “Beta,” and so on
  • Each have their own wall color
  • The score multiplier increases with each mode, giving massive bonus points for all actions that earn points to begin with, even if a win isn’t achieved

To simplify the overall execution, I made it so that losing any NG+ run causes the player to perma-lose the streak and have to start over from the beginning with a “regular run.” Basically roguelike permadeath but for New Game win streaks. This isn’t the best design, but I was in a hurry! In hindsight it would be better to have a loss push the player back to the previous NG+ mode (assuming they’ve won more than one consecutive run already) so that not quite so much progress is lost.

Note: Sure enough one of Cogmind’s top players has already won P7’s final final final NG+++++ mode to achieve ultimate victory :D

Coming next is Part 4: Finishing Touches!

This entry was posted in Dev Series: 7DRL Postmortem and tagged , , , , , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

Post a Comment

Your email is never published nor shared. Only the anti-spam entry is required. See here for the privacy policy.

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