Map Design news - Cogmind

In designing Cogmind's maps, at the highest level, and throughout the process, I think about the ways in which a player with perfect knowledge of the game could viably approach each area, and make sure those options are part of the experience I want to enable.

I can take this approach because Cogmind's maps are encountered almost as semi-isolated challenges (most variables are reset as you advance to a new level, and you can't travel backwards to previous maps).

It would also be bad if there is always one best way to overcome an entire map of obstacles (incidentally this is more or less how I approach all questions of design in Cogmind--make sure there are multiple benefits and drawbacks to nearly everything).

Below is a general look at Cogmind's map design, touching on important points regarding the form and content of those maps, and summarizing the overall process used to design them.

Form

The map layouts in Cogmind are highly reflective of the game's mechanics. You'll find lots of open areas, spacious rooms, and long wide corridors to accommodate the distances required by a ranged-focused combat system and potentially high-speed movement.

A high number of inhabitants--the non-hostile ones outnumber hostile ones, and they even replenish their numbers--means that more space is also required to allow all these busy robots to go about their tasks and still leave room for you and others to pass. (Or shoot each other, as the case may be =p)

By extension, lots of open areas means maps will generally be very large. Maps can be up to 200x200, or larger in special cases. The Factory subsection shown above is only 17.5% of that particular map's area.

In a more general sense, I believe loops are incredibly important for keeping play interesting. As little backtracking as possible should be required to advance, and Cogmind achieves that with highly connected expansive maps that almost always give you a new and different path forward from where you are.

So-called "loops" refers to having multiple routes to reach many of the same points on the map, both within a local area and across the map as a whole. Certainly primary routes can be lined with short spokes from which the player will need to return to the main path, but those shouldn't become long excursions that will force the player into a backtracking slog. Excessive backtracking is an opportunity for frustration and boredom to set in. Dead ends at the end of a long tunnel are the worst, especially without some kind of reward or other purpose.

Exploration is a good thing to be encouraged, and it's better encouraged if moving forward into unexplored territory is likely to lead to increased options. This is especially true in a game like Cogmind where you don't need or want to confront everything to grind XP, and therefore farming every nook and cranny isn't too important.

In Cogmind rooms line corridors, but don't often connect directly between one another, thus the main path of the maps is largely along obvious corridors, turning rooms into optional side-areas for satisfying the player's circumstantial needs, e.g. finding items, machines to hack, refuse/hiding spots, allies...

You can see in the sample Factory map below that the widest corridors snake through most regions of the map, with smaller corridors allowing robots to jump between the larger ones, and plenty of extra rooms in the surrounding areas.

Cave maps are simpler and more open, but are also more difficult to balance in terms of loops because due to the nature of caves they tend to have loops that are either too large or too small--if you want to keep that "cave feel" to them, anyway.

As part of that cave feel, local walls are also often lined with protrusions or crevices making complete exploration too tedious if we have many small connecting tunnels with entrances that might be just barely hidden (forcing the player to methodically examine every corner). Lacking those little tunnels, however, we can end up with a lot of dead ends:

The solution I propose is to throw out the idea of a square map, instead squishing caves into long rectangles to force smaller loops and keep spokes from straying too far from the main path.

When designing maps, don't forget there are solutions that can work from outside the normal map generator, sort of like "meta mapgen," as in this example constraining a regular old map generator to a non-square area.

I still haven't added caves to the actual game--those are coming later this year--but I have used the generator to create mines:

In this case a square area works since the map is rather small, and mines allow for robot-made tunnels, improving connectivity while still remaining realistically cavey.

I've also written more about all this cave stuff in this post.

Content

For some maps, or parts of maps, I prefer to have much greater control over the layout than the map generator can provide on its own. Integrating prefabs (hand-made map pieces) are a way to ensure the conditions are right for a specific experience, down to the last wall, door, or item if necessary. They can of course be scripted to offer some degree of variable content, too, not necessarily identical every time. These are useful for crafting story elements and specific challenges. I've written about the basics of prefabs and how they're created before.

A concept closely tied to prefabs is "encounters." Encounters are a broader concept than prefabs, and may either decide to replace a map room with a specific prefab, or use an existing space, such as a room or cave. In fact, the cave/mine generation relies entirely on encounters to populate the map with content. (Corridor-and-room maps make use of a separate system that distributes content based on quotas, room counts, and metrics that come out of the layout generation process.)

Encounters fall into one of several categories which, specifically speaking, determine what to place in a given area, be it robots, items, special event triggers, dialogue opportunities, etc. So you have encounters as generic as "patrolling hostiles here" or something more special like "robots trying to steal a MacGuffin ask for your help." I've written about the encounter categories towards the bottom of this post, so I won't repeat them here, but this is a cool image showing how I can examine the distribution of encounters in a map:

Hovering the cursor over a region will display the encounter's reference name, for convenient analysis. In short, balancing encounters is a way to control the risk vs. reward scenarios encountered by the player. If I see that every map being produced is nothing but dangerous encounters, something needs tweaked ;).

Now that I think of it, earlier this year I put together a diagram showing what types of map generation content goes into the two main categories of maps:

As the core of the game focuses on robots and parts, I try to keep the surroundings fairly minimalist. That said, the environment is not completely barren--there are just enough features to provide a number of extra opportunities for interaction:

• Machines. Last year I wrote about the major types of furnishings and how they're placed on the map.
• Traps. These are usually unseen, which makes them a great addition since they don't clutter up the map.
• Hidden doors. Another "unseen" element that adds a lot to the gameplay. See below for an example (and after writing this post I created a new type of hidden door as well).

Each additional feature also helps support the theme of the game, which is pretty important because I want it to be as atmospheric as possible without too much clutter. (This will be even better once all the machines emit their own sounds; sound is a great way to improve atmosphere since it doesn't take up any map space =p. Right now there are only a few test sounds in place for those.)

Lots more I could say about this topic but oh my this thing is getting long.

Process

In addition to the mechanical analysis mentioned in the opening, the pre-planning stage for map design also includes a confirmation of the purpose the map will serve, such as:

• be a source of resources (items, allies, knowledge)
• give the player breathing/rest room
• provide access to a more distant area
• tell a part of the story
• influence the future course of the game in a more general sense
• (other stuff)

The best maps will of course serve multiple purposes simultaneously :)

After that, it's time to work on increasingly specific iterations over the map's layout and what it will contain:

1. I start with general sketches on scrap paper, along with random notes describing the general attributes of the map, such as its approximate size, important physical features, and what kinds of challenges and rewards it can contain. Just yesterday I happened to be working on a new type of map, and was sketching out how it would play from the most basic route A + B to a few little detail features here and there.

2. Then I'll do diagrams in REXPaint, usually vague and mysterious blocky things that aren't exactly "mockups," per se, but more a representation of how I feel the map should play out. These I use for tweaking map gen parameters, and keep permanently for reference. For special cases I may make a simple mockup to take a closer look at tactical possibilities. (An example of what I was working on after drawing those sketches I just showed :)) It's always better to figure these things out before putting time into actual code, which takes much longer to get results, and subsequently fix when something goes wrong.

3. The last stage is to play around with the mapgen visualizer to get the settings right. It's easy to tweak because I can just make changes to the parameters directly in a text file and continue generating maps based on the new data until it looks right. I'll watch hundreds of maps before a design is finalized.

Okay, that was long, but hopefully informative, and helpful if you're a developer :D