Official development blog
[ Latest Cogmind Release Notes: Feb 2026, "Unchained More" ]

Dungeon Metrics

By Kyzrati | Published: July 4, 2014

Rarely will an algorithm produce a perfect procedurally generated map, and even if it does, some degree of post-processing will still be necessary to analyze the layout. When we look at a map produced by a generator, we can determine pretty quickly whether or not the layout is sufficient for our purposes; we can also see likely bottlenecks where enemies might gather to stop the player, or areas considered “out of the way” that might hold more treasure. In the program, however, a map is nothing but coordinates telling us what each space represents, giving us no hint as to its overall composition and layout. How do we teach a game to understand and use the map as we do? We need “dungeon metrics.”

Requirements

First and foremost we have to check if we even want a given map. Without any constraints on the results, the same algorithm can produce a wide variety of layouts, some of which are either not what we expect or downright unplayable. In those cases we’ll want to throw out the map and try again.

Composition

The most basic requirement is the final amount of playable, or “open,” space. A lower bound ensures the map isn’t too sparse, while an upper bound keeps it from being too open.

map_metric_openness

These two caves were generated using the exact same algorithm, differing by only one parameter: the amount of open space required (15~30% on top, 40~60% on bottom).

Another important requirement to consider controlling for is the number of individual rooms/caves of varying sizes.

map_metric_roomcount

These two maps were generated using the exact same algorithm, differing only by the number of rooms required (20 or more small rooms on top, at least 20 medium and 5 large on bottom).

Pathfinding

Some games use precalculated map data to optimize pathfinding, but that’s not what I’m referring to here (it’s also not too useful in Cogmind due to the completely destructible environment).

Pathfinding is an important part of map analysis since you have to ensure it’s possible to reach one or more exits from the entrance of a map. This won’t be an issue for cellular automata assuming the final tunneling phase is doing its job, but tunneling algorithms constructing maps with more than one tunneler must confirm that the tunnelers did eventually meet and join their respective creations.

Another possible requirement pathfinding can enforce is a minimum distance between entrances and exits. If too close together much of the map area remains unexplored, an especially relevant issue in Cogmind because there is no XP system--the best reward (“evolving”/leveling up) comes when you find the exit. Having an exit too near the entrance would be poor design in this case since there’s little incentive to stick around.

Etc.

An alternative to automating the selection process is to use procedural generation but hand-pick the set of maps that are actually used in game. This works, but ultimately limits the pool of possibilities to the number of maps selected by the developer. (Nonetheless some games out there do use this method.)

Whether selecting maps for final use or simply to trying to improve an algorithm, it can help to have multiple ways to look at the same map. For example a monochrome view is useful for checking available play space and overall layout without being distracted by a map’s individual parts.

map_metric_monochrome

The normal view on the left is nice for clearly identifying size and positioning of caves, but the monochrome view is the purest representation of playable vs. non-playable space, and is closer to what the player will see and experience.

See the previous two posts for images showing individual highlighting of tunnels, caves, rooms, junctions, “halls,” etc. Those are not processed images--the debugging features of the map generator itself include many such views to aid development.

Another tip for more efficiently addressing issues during development: Always have the generator output the random seed used to generate each map (I have mine added to an ongoing list). That way you can always feed the seed back into the generator to repeatedly generate the same map and find out what went wrong or how the algorithm could be improved.

Records

Once you’ve decided to keep a generated map, there’s still plenty to be done. It’s time to analyze the content and layout to record what useful info we can.

The simplest component we’ll want to remember is where all the rooms/caves are located. Rooms (and corridors) dug by tunnelers are easy since we built them in the first place--just record as you go. Caves are a different story since they were grown randomly. To find them we just scan the map with a standard floodfill.

map_metric_floodfill

Locating caves in a map via floodfill before connecting them.

Herein lies another advantage of allowing cellular automata to create many disconnected caves then reconnecting them during post-processing: The caves are naturally separated into discrete “rooms” for you by the algorithm! This means we’ll later be able to take advantage of any of the methods of analysis that work on normal room-and-corridor dungeons. More on that later.

Location and size are not the only important information that could come in handy when deciding how to use different parts of the map. We can record doors and which direction they face (used for optimizing some types of pathfinding, or setting up ambushes), which rooms and corridors are attached to each junction, which tunnels are linked to which cave(s), and which caves are directly accessible from another cave. My favorite piece of data that I’ll be discussing further below is relative seclusion/connectedness.

General statistics collected from the final map may also affect what you decide to do with it as a whole, data like the percent composition by cell type, maximum and average seclusion of areas, the largest individual hall/cave, etc. These could of course be used as additional requirements to filter out unwanted maps.

Analysis & Application

So what do we do with all this collected data besides decide whether to throw away a map? The obvious application is object placement.

Robots and parts in the 7DRL were spawned without regard for whether an area belonged to a room or corridor; you could find a stockpile of parts sitting anywhere out in the open. It would make more sense to store most of those in rooms, both for realism and from a gameplay point of view (“do I open that door to search for parts even though my scanners show robots on the other side that may or may not be hostile?”).

As mentioned before, corridor junctions are likely to contain terminals, and large halls will contain bigger machines. Guards are more likely to patrol intersections. Choosing the best locations would be difficult without first recording details about the map layout.

Connectedness

My favorite analytical tool for cave systems is the relative connectedness of each cave.

map_metric_connectedness

Visualization of cave connectedness, where brighter caves are better connected to the system.

Because the number of direct cave connections alone is less meaningful in many scenarios, I define “connectedness” as the number of immediately connected caves plus the number of caves those are connected to as well. Notice in the above visualization that outlying caves are shaded darker, representing a lower connectedness value.

Less connected caves in different parts of the map are likely positions for entrances/exits, and others are good candidates for placing loot, secrets, or perhaps nastier surprises for nosy explorers.

At the other end of the spectrum, well-connected caves are where most enemy activity will probably be concentrated.

Seclusion

For maps created by the tunneling algorithm, all rooms are rated by their “seclusion” value. Seclusion uses different calculation criteria than cave connectedness since map connectivity is much higher. Instead it’s based on the distance from the fastest path the player can take between an entrance and the exit(s).

map_metric_seclusion

Visualization of room seclusion, where darker red rooms are further from the quickest routes across the map.

The four entrances/exits (pink dots) are connected by the most direct paths between them (green lines), then the entrance to each room pathfinds to the closest point on any of those lines. Notice that the further a room is from a path the darker its shade of red. (For purposes of the visualization any room with below average relative seclusion, where “average” is based on the map values, is not shaded.) The more secluded a room, the more likely it will hold something of value or interest to the player. Of course this idea of “seclusion” assumes the player knows where they’re going when they may very well not! But that’s okay, because the player deserves a little something for having traveled so far out of their way, and having overcome whatever obstacles they had to in order to arrive there.

This is the fourth in a five-part series on procedural maps:

Posted in Design, Dev Series: Procedural Maps | Tagged , , , , , | 11 Responses

Mapgen: Cellular Automata

By Kyzrati | Published: June 27, 2014

Unlike the 7DRL, which only spanned a 10-level “main dungeon,” Cogmind will cover a much greater area. Naturally a larger world needs a greater diversity of regions to explore. Taking place underground, many of the outlying areas tend to be caves, and for that cellular automata are usually the best choice for generation.

I say that but I’m actually not going to use the standard application of cellular automata. (Read about the standard process here, here, or here; I won’t be explaining it in detail.) Instead I kinda fell in love with a related idea described by Andy “Evil Scientist” Stobirski over on his blog earlier this year.

Evil Science

His method still relies on cellular automata in that you apply adjacency rules to open and close cells organically, but instead of repeatedly applying the rules across the entire map at once you pick cells at random. (Hey, we make roguelikes and we like random, so random it is!)

Performance-wise I believe that once fully optimized Andy’s method is faster than the standard method for achieving comparable results, and it’s a lot more versatile in terms of what it can do. I don’t have a lot of experience fiddling with cellular automata, but the few times I tried it was somewhat difficult to tweak for good results. This method produces good results with ease. “Good” is of course relative, but what I was looking for wasn’t quite available with vanilla cellular automata. I need more variety, and the flexibility of this method makes producing a variety of nice maps a simple matter. I’m sure variety can be coaxed out of cellular automata (via switching rules partway through generation), but it won’t come as easily as these did:

evilscience_map1

evilscience_map2

evilscience_map3

I like how in many maps the random distribution of rule application creates variety even within the same map, in the form of a mix of sharp and round, large and small areas.

One of the variables you can tweak using this method that is not normally adjustable when using cellular automata is the number of cells randomly visited, which is where some of the additional variety comes in. Lowering the number of applications will result in some rougher maps, but a final smoothing phase can still operate on that and get some interesting results:

evilscience_map4

Connectivity

As with any cellular automata-based procedural map generation, connectivity is an important issue to consider. If there’s no way to travel between multiple disconnected areas on the map, then the extra ones may as well not be there. In that vein one solution is to remove unconnected areas entirely, but that doesn’t work with certain cave styles because there will naturally be many disconnects resulting from algorithms used to achieve thinner “sprawling” styles (as opposed to big blobs).

The better solution creates new connections to reattach those areas. One possibility is to “grow” some areas so that they reconnect with others. Another is to dig tunnels between them. I prefer tunnel connections because they 1) fit the style and theme I’m going for, and 2) allow a cave system to consist of many smaller caves that can be individually identified as “rooms” for purposes of object placement (this advantage will become apparent in the next post on dungeon metrics).

My solution here varies a bit from Mr. Evil Scientist (mostly since I’m delving into the specifics of applying it to a game while he was building a more generic generator). Mine removes most pointless U-bends, goes through multiple corridor-digging phases that may not apply to all caves, has an adjustable ratio of cave-spawned corridors vs. branching corridors. and sometimes chooses to dig wider tunnels based on both set parameters and the relative size of caves being connected.

cogmind_map_automata_tunnels

Tunnels connecting individual caves.

Guided Generation

Cave maps in Cogmind won’t be as large as the main dungeon maps introduced in the previous post, but even then smaller square cave maps tend to simply not be very fun to explore, at least in the disconnected style I’ve chosen to go with. Taking the above map as an example (that’s one of the styles I’m currently planning to use):

cogmind_map_automata_flow

Flow path of a square cave map.

Assuming we’re not putting a meaningful destination at the end of every dead end, the above map will require a lot of backtracking, and even if more tunnels are dug to turn it into a more intricate web of connections (enabling more loops), the map really won’t be too fun to explore due to a fundamental difference between caves and normal dungeon maps: The rough edges are filled with nooks and crannies that you have to fully explore to make sure you didn’t miss an important pathway.

In a normal dungeon with flat walls and rectangular rooms you can quickly scan the entire visible area and be relatively sure of where there is and is not a valid path. In caves you can’t be sure you haven’t overlooked something until checking everything out up close. That gets tedious, more so when you weren’t headed in a certain direction in the first place.

The solution is “guided” cellular automata. Let the generation play out as normal, but enforce a general shape that the cave must fit into, such as the narrower corridor seen below.

cogmind_map_automata_guided

Caves made fun with guided cellular automata.

This way we can continue to use the sharp spiky style with longer offshoots but keep everything moving in the same general direction.

Mines

Another variation on this algorithm will be used for mines. These are generally smaller maps where you have rectangular areas dug out for processing machinery and storage purposes, as well as the actual mined areas connected to them via corridors.

cogmind_map_automata_mine

Mines have a higher number of connections and loops.

Composite Maps

Who said a single algorithm has to control an entire map? Some special areas could very well combine cellular automata and the tunneling algorithm for special cases.

cogmind_map_composite

A hidden base?

This is the third in a five-part series on procedural maps:

Update 3/16/2016: I’ve since written Generating and Populating Caves, giving a more comprehensive overview of how caves are actually created and used in Cogmind.

Posted in Design, Dev Series: Procedural Maps | Tagged , , , | 6 Responses

Mapgen: Tunneling Algorithm

By Kyzrati | Published: June 20, 2014

Cogmind’s main dungeon maps are excavated by “tunnelers” that dig corridors and rooms, much in the way a dungeon architect would build a home for their master’s minions. An empty map is seeded by one or more tunnelers, and they travel around that map opening up all the areas that will become occupiable space, e.g. corridors, doors, rooms, halls.

I like tunneling algorithms because with the right parameters they can create fairly realistic environment.

cogmind_map_main

Behold an underground complex ruled by robots!

Inspiration

First I must give credit where it is due. Tunneling algorithms didn’t interest me before because when used in expansive dungeons they tend to produce boring repetitive layouts. Then a few years ago I came across this project, which introduced me to the key concept that tunnelers can change their own parameters as they move (there’s a good overview of the idea on that site). The result is a more varied dungeon environment, especially across larger maps like those Cogmind uses.

That particular algorithm has some oddities--what’s with all the useless and redundant corridors? Why doesn’t it ever produce even-width corridors?* I suppose many of its drawbacks never came to the forefront because the creator never applied it to an actual game:

mapgen_tunneler

Looks cool, but not very realistic.

*I suspect this has to do with symmetrical tunnelers being easier to work with in code. While I’ve written my own algorithm to handle arbitrary widths, because tunnels logically tend to shrink and grow two cells at a time, even-width corridors eventually become odd-width corridors anyway after shrinking to 1-cell wide then growing again!

cogmind_map_tunnelers_even

A dungeon excavated by a single even-width tunneler (begins top center) eventually creates more odd-width corridors (blue) after its initial run of even-width corridors (orange).

I may not bother using even-width corridors since they are more likely to produce off-center connections that don’t look quite as nice. I do like 2-width corridors from a gameplay point of view since they are narrow yet still leave enough room to maneuver around other units, but 3-width corridors are probably better as a standard for a game like Cogmind in which battles are most commonly fought from a distance--there needs to be enough room to set up a decent firing line.

In any case, over the years I’ve been working on my own algorithm based on the same principle: that tunnelers creating the dungeon can evolve over time to “mix things up.”

Parameters

There is a wide variety of parameters to control for tunneler behavior: Width, direction, speed, chance to turn, chance to create rooms, size and shape of rooms to create, how much space to leave between self and other dungeon objects, when to quit…

cogmind_map_tunnelers_padded

Example: Increased padding between both corridors and rooms might be desirable if you don’t want it to be too easy for the player to blow their way into another room/pathway. In my case I keep padding low because what good is destructible terrain if you can’t use it to your advantage to make situations more dynamic? (But look out, because a very determined enemy may come blasting through a wall, too!)

Anyone familiar with procedural map generation will know that the same algorithm can produce significantly different results by tweaking its parameters. Later I’ll be showing more features used in conjunction with this algorithm to make it even more dynamic, but this is essentially all we need for the core game.

Size

Many maps in Cogmind are going to be even larger than in the 7DRL, and include more open spaces. The main dungeon used to be 100×100 per map, which will be increasing to up to 200×200 for the largest maps. That’s four times as large:

cogmand_map_tunnelers_huge

The largest likely map. Layout/style is still very WIP, but the algorithm is 90% complete--still some cleanup to do to reduce overall jaggedness. (click for full size)

Why larger maps? Well, first of all Cogmind always needed the space since combat is mostly ranged--you are generally fighting enemies an average of 15 or more cells away. Maps are growing even larger mostly to accommodate changes in game content.

The world will be larger with more places to visit, so we need to spread out the main maps such that area transitions aren’t too frequent. Battles might be bigger depending on your play style; who knows, raising a small robot army is likely to start a little war? In short there’s more you can do now, and we need more space to do it in.

There’s also a greater emphasis on intelligence gathering. Aside from sensor-type parts seen in the 7DRL, you’ll be able to learn about the map via terminals. Larger maps will encourage players to take advantage of these sources of information when possible. This should make the stealth route more feasible since you have more means of learning about the layout and enemy movements, but the map isn’t small enough that this knowledge will make success too easy.

On a more fundamental level, many areas of the map that would have been empty in the 7DRL will now be occupied by machines, so less of the map space is actually as “occupiable” as it appears. The current stage of map generation is only interested in connectivity, flow, and open vs. closed space; we’ll get around to placing objects later.

Composition

As stated earlier (and you can see above), the new maps have a fair number of wide corridors and open areas.

The 7DRL contained a much higher ratio of corridors and places to hide, making it seem easier to hide than it actually was--the enemy could track you down without much difficulty, or even head you off at a shortcut because after all they know the dungeon better than you do!

Opening up the map forces you to think a bit more before attracting attention, since in doing so you may end up committed to a confrontation until it’s resolved.

Layout

During the generation process tunnelers are responsible for laying the paths that take the player from an entrance to an exit, of which there are usually several with a guaranteed amount of space between them. How tunnelers move and what they decide to do pretty much determines what most of the map will look like.

When possible most tunnelers try to dig out rooms along their edges. These serve as places to hide/wait or find parts. They may also contain machines, which are sometimes just for atmosphere, or not. Rooms with multiple doors are usually an intersection of sorts, giving access to areas other than their primary corridor.

Tunnelers also sometimes build junctions when turning or changing width. These aren’t purely aesthetic enhancements--junctions can contain terminals from which operator class bots supervise local activity.

cogmind_map_tunnelers_junctions

Those junctions located along main corridors will almost certainly have terminal access.

cogmind_mockup_machines_terminal

The idea of having some terminals located at corridor junctions was seen in the very first mockup, as above.

Tunnelers also spill into and contribute to larger areas called “halls.” If you’re trying to stay undetected you’ll want to think twice about traveling through halls, since a passing patrol or scout is more likely to spot you.

cogmand_map_tunnelers_halls

Halls will usually contain larger machines to further subdivide them and provide obstacles behind which to hide.

We’ll be taking another look at tunneler-generated maps in later posts on other map-related topics.

This is the second in a five-part series on procedural maps:

Update 190306: There’s also an additional article now which covers procedural layouts as they related to level design in Cogmind.

Posted in Design, Dev Series: Procedural Maps | Tagged , , , | 8 Responses

Procedural Map Generation

By Kyzrati | Published: June 13, 2014

Procedurally generated maps are a core feature of roguelikes. For a genre that is almost synonymous with “randomness” (within reason), randomized maps are the easiest way to broadly manifest that key element since maps affect many aspects of gameplay from exploration strategy and tactical positioning to item and enemy locations.

Notice how walkthroughs for strategy games need only mark key locations on an overview map and indicate what to do where--you can win every time by following that series of steps. While players can enjoy having multiple attempts to solve what is essentially a glorified puzzle, no matter how fun the game is it will come to an end once all the solutions are found.

So randomized maps give us infinite replayability by providing different challenges every time, not to mention the extra satisfaction from overcoming less spoilable challenges where player progress is measured by personal skill rather than trial-and-error. That the layout of every new map is 100% unknown also lends a good amount of suspense to exploration.

Of course the benefits of procedural maps are pointless without sufficient variety in mechanics and content to make multiple playthroughs worthwhile--the same old hack-and-slash affair won’t do. Hence any roguelikes that survive the test of time will have deep gameplay, too.

Lately I’ve turned my attention to Cogmind’s map generation, so here begins a series of posts on the topic.

Methods

There is a wide variety of methods for generating maps. Naturally no single method is suitable for all purposes, thus most developers will end up tweaking whatever method(s) they choose to fit the needs of their game more closely. Of course designing a method from scratch is also possible, though conceptually a few of the common ones are a good place to start exploring the topic.

There’s no need to go into implementation details here since that’s already been done all over the web; instead I’ll just link to the source of each image where you can find an explanation.

BSP Trees

BSP trees can be used to create some of the simplest and most immediately recognizable roguelike maps--rectangular rooms attached to one another by corridors.

mapgen_bsp1

BSP Tree, Example 1 (source)

mapgen_bsp2

BSP Tree, Example 2 (source)

Tunneling Algorithms

Tunneling algorithms dig corridors and rooms out of solid terrain, much as a real dungeon architect might. Except for the often useless or redundant pathways…

mapgen_tunneler

Tunneler Example (source)

Drunkard’s Walk, a highly-randomized tunneling algorithm, is useful for creating cave-like environments with a mix of open and narrow areas.

mapgen_drunkard1

Drunkard’s Walk, Example 1 (source)

mapgen_drunkard2

Drunkard’s Walk, Example 2 (source)

Cellular Automata

Cellular automata are great for digging natural-looking cave systems. Unlike other methods you have to find a way to ensure connectivity in a post-generation phase, since certain algorithms are likely to produce disconnected areas.

mapgen_automata1

Cellular Automata, Example 1 (source)

mapgen_automata2

Cellular Automata, Example 2 (source)

As you can see from the types listed above, what I’m really talking about here is procedural dungeon generation. Most roguelikes take place beneath the ground, which makes sense from a design standpoint. The highly random nature of roguelikes means it’s likely that at some point (many points…) the player will face an encounter for which they are woefully unprepared and must escape. Underground environments offer a greater amount of negative space that can be used to control what can and cannot be seen or reached from a certain vantage point, and all of it shown in an easy-to-digest manner, e.g. rectangular rooms, corridors, and cavern walls. Compartmentalizing encounters into rooms enables dungeons to provide a tighter experience, fitting more content within a smaller overall area. Sure one encounter may very well spill over into the next when you start running for your life, but that’s why every experienced rogueliker will tell you to never flee into the unknown!

Design

Beyond choosing a method of generation (or mixing multiple methods), any number of parameters must be established and tweaked to produce layouts that work for the gameplay. Many small rooms or fewer large rooms? Lots of long corridors, or no corridors at all, just rooms separated by doors? An expansive winding cave system that draws the player to explore and lose themselves in it, or a mostly linear cavern contoured as it is for the atmosphere?

Map layout isn’t just about theme, it reflects how the game (or sub-area) plays. Many roguelikes have fairly small rooms and narrow corridors due to a high percentage of close-range combat. Cogmind is mostly ranged combat, so wider corridors and large rooms are much more common to give combatants room to find a shot.

Exploration & Fun

Aside from designing maps that complement game mechanics, it’s also important to consider available travel routes from one encounter to the next. Unpopulated rooms and corridors actually do serve a purpose, as there doesn’t need to be a fight around every corner. Real players do need some rest, or more importantly some extra space to work with when things aren’t going according to plan. In Cogmind in particular that extra space is also useful for taking the stealth approach--with the right components and know-how many confrontations can be avoided entirely.

But the primary factor I pay attention to when tweaking map parameters is the number and density of loops. By loops I mean places where multiple pathways reach the same destination. A map with few or no loops in its layout will require lots of backtracking, and backtracking is not fun! Players may still choose to travel along previous paths be it to gather items or escape an enemy, but taking the same route multiple times shouldn’t be forced on them. Long paths that lead to dead ends had better at least contain treasure or access to a new area. Cogmind has some fairly large maps by roguelike standards, so I have to be especially cognizant of pointless pathways.

This is good opportunity to point out that while developing and tweaking a map generator is often done outside the game itself so you can see the entire thing and examine it from a higher level, the fact that a map “looks good” can be misleading and is rarely something that players notice once inside the thing, anyway. Inside it may not be fun at all!

mapgen_deadends

Here’s a map that doesn’t look too bad as a cave system but wouldn’t be very fun to play without the right mechanics--waaay too many long dead ends.

Testing a map for connectivity post generation is an important step in determining whether to use that map (more on that in a future post). Some more complex procedural methods can build that requirement into the generation process itself:

mapgen_complex

A graph-based map generation technique that ensures a general number of loops (source).

Content

How we decide what to put where in these maps is another big issue, obviously a very game-specific one. Randomly spawning objects everywhere could be fun (heck, that’s what I did for the 7DRL!), but the most enjoyable experience can only come by considering the terrain and choosing locations with a purpose. This step is often dependent on dungeon metrics, which I’ll be dedicating a post to later on.

In a general sense, I should mention here that Cogmind will make use of some manually designed dungeon sections. These “prefab” areas will have to be integrated into the existing dungeon generation algorithms. Before that there’s also the issue of having a way to create and edit them, a process I’ll likely handle via REXPaint in combination with text files.

Prefab map pieces have many advantages, essentially all those things that are good about hand-crafted levels: Increased control over a specific part of the experience, their uniqueness draws attention to them and makes them more memorable/meaningful, and they provide a reference point common across games that players can talk about. I won’t go overboard in the prefab department, the second point of procedural maps being that you save time on content creation, but I’ll probably want more control over the look and feel of significant plot-related locations.

Cogmind

Cogmind maps will be using a combination of tunnelers and cellular automata, which I’ll be introducing in subsequent posts.

This is the first in a five-part series on procedural maps:

Posted in Design, Dev Series: Procedural Maps | Tagged , , , , , | 4 Responses

Kickstarter?

By Kyzrati | Published: June 1, 2014

This is a question I’ve wrestled with for some time now: Should I take the popular crowdfunding route to support Cogmind development? I’ll use this post to lay out the situation and my thoughts both for and against that route.

Platforms

First, a caveat. As a non-US citizen (no, not UK either) it’s not easy for me to do a Kickstarter.

Certainly there are international alternatives, e.g. Indiegogo. While I wouldn’t completely rule out IGG, it is without a doubt an inferior option with its poorly-designed site/UX compared to KS. As a company it has very questionable practices in its failure to vet projects that are clearly scams, all in the name of driving up their own revenue. Its smaller scale and lower in-site traffic also result in reduced visibility, equating to less funding. Overall, assuming all other factors are identical, the same project on KS will bring in more than on IGG.

So in an ideal situation without barriers Kickstarter is preferred. In my case it’s not absolutely impossible to get Cogmind on KS, it would just be more difficult because I would have to run it through someone else.

There are a few other options, like smaller crowdfunding platforms (meh) or an in-house solution, though the latter is not possible in my country due to rather tight rules governing payments and money.

Analysis

I’ve been following a number of crowdfunding campaigns in recent years, and digesting the many Kickstarter “post-mortems” generously shared by other devs, so I’m very familiar with the market and what it takes to succeed. The question is whether or not the effort will be worth the benefits.

Exposure

Combined with a game’s actual release, the attention received during a fundraising campaign is akin to another release in terms of hype generation. Traditionally a game only gets “one shot” at major publicity, and that’s release day. Any number of factors can conspire to ruin that opportunity (calendar holidays, other game releases, short-term trends in gaming…), so naturally the more “big events” the better.

As long as a game is ready for it, the added exposure from a crowdfunding campaign is also a great opportunity to gauge public reception. If the response is underenthusiastic you’ll definitely want to think twice about the project’s direction. I’m pretty sure the core roguelike community is interested in Cogmind, but I have no idea what portion of other gamers closer to the mainstream the game might attract. Not that I’m developing a game targeted at the latter segment, but certain features are obviously geared towards appeasing the less hardcore players out there. Maybe we’ll convert a few people ;)

Risk

Spreading the word about a game early strengthens the community around the game and enhances player-developer interaction while reducing the risk of development by sharing it with that very community (financially). It’s great to know in advance exactly how much support there is for a game/project before investing the months or years necessary to see it to completion. Assuming the developer(s) is qualified and capable of completing the project, the chance of success is much higher once funding is secured. Living on savings to complete a game that may or may not cover its costs (most don’t) is doable, but less stable and the more unknowns introduced into the development process the more a game is likely to suffer. Not having money is a pretty big unknown. While I have plenty of savings to see Cogmind to completion without any support, it would be a better game if I could know in advance how big a potential audience there is in order to pace development and include features accordingly. This is where the idea of stretch goals comes in. I have a pretty clear idea what of what Cogmind should be, but there are some time-consuming features that would only be added if the extra support is definitely there.

Marketing

There’s the argument that preparing and running a campaign takes lots of time (it does), time that could otherwise be allocated to development. If money isn’t an issue, why bother? It all comes down to the unfortunate necessity of marketing. You can spend all the time you want developing a game, but if too few people are aware of it or how to support it, it’s unlikely to go anywhere. So crowdfunding does double duty as a marketing tool and a way to raise money. It’s extra time-consuming, but extra-beneficial, too.

Another benefit is that raising money for incomplete games is even easier than a complete one, because when presented the right way backers tend to fill in any information gaps with their own dreams, desires, and imagination; it’s dishonest to take advantage of this by selling a “dream game” with little to show for it, but this effect does nonetheless benefit just about every project out there.

Rewards

While they may be a staple of crowdfunding campaigns, I don’t much like the idea of backer rewards. The benefits are apparent, but as a developer dealing with rewards is another of those “why am I doing this instead of making a game?” things.

Physical rewards are nice, but end up diverting a chunk of the funds and eat up time with organizing, packaging, and sending. The benefits only start to outweigh the costs at higher tiers, assuming they can still attract backers at that level. The size of the campaign can matter a lot here, too, since economy of scale is quite meaningful compared to spending the same base time handling a physical reward for a handful of backers who donated at a given level. I have a few ideas for potential physical rewards, but would have to do more research into the logistics to see if they would be worthwhile. The obvious ideas for physical rewards:

  • Poster: ASCII guns w/logo
  • T-shirts: Cogmind logo and/or ASCII guns

Non-physical rewards have their own drawbacks even though distribution is less of an issue. Common rewards like alpha/beta access and forum access for developer discussions seem like they should ideally be available to everyone interested enough to participate, even those don’t have the money to donate during the campaign. Feeling that charging for these “privileges” is wrong is probably my non-business free-games-for-all indie side talking, but that kind of thinking generally leads to failure if the goal is to continue developing games in more than a hobby capacity.

One of the other most common and varied non-physical rewards allows players to add/determine game content like weapons, enemies, or even levels. As a game designer who likes tight design with a purpose for everything, it would be difficult for me to open up this area to control by others. Of course developers still hold ultimate control and veto power, but finding a middle ground by both reigning in a backer’s creativity and relinquishing some control over the game experience seems at odds with satisfying both parties. This type of reward is perhaps best suited to sandbox games, which Cogmind is not. I can revisit the concept once the pieces of the game start to come together and the flexibility of the system and world become more apparent. Basic content is certainly easy to add to the text files, but deciding what to add where can be a function of a wide range of variables unknown to anyone not familiar with the inner workings of the game. At the same time, it’s important to consider that content-related rewards can get the player base even more “invested” in a game.

For fun, part of my list from brainstorming non-physical rewards:

  • Various wallpapers: Logo / ASCII art / procedural ASCII / generated maps
  • Name listed among backers on website
  • Early/beta access
  • Extra copies of game
  • Copy of 7DRL design doc
  • Design a weapon (melee/ranged)
  • Design static map locations
  • Design a robot and its ability/theme
  • Design a dungeon branch

Media

A good video is generally the number one key to a successful campaign. One problem with ASCII or similarly fine pixel-perfect visuals is that compressed videos look terrible. Cogmind gifs looks great, but miss out on the powerful effect of sound; videos include sound, but almost want to make you stab your eyes out--not exactly prime bait for piquing the interest of anyone who may be on the fence about a text-heavy roguelike. Of course, KS or not this is an issue that will have to be addressed eventually in order to sell the game.

In case you’re unaware of the effect I’m talking about, take a look at this:

cogmind_video_vs_gif

On the left is a screenshot of a 720p (high definition!) YouTube video (the Cogmind prototype)--that blue thing towards the bottom is supposed to be the ‘@’… HD my… never mind. On the right is the ideal crispness which can be replicated perfectly in an animated but sadly silent gif.

Quality

Cogmind is definitely not ready for a campaign at this stage. At minimum I’d want the sprites (still simple but less esoteric than ASCII for some), proper map generation (currently still handled by the old mapgen system), music for a trailer (need to hire a composer once there’s something to show), and a demo (fairly easy, since the core gameplay is complete).

Alternatives

The alternative is to continue along the non-crowdfunding route, which probably enters closed alpha funding at some point in the next few months before a normal release further down the road. These two paths are not mutually exclusive--a campaign could lead right into alpha funding.

Conclusion

In the end, a fundraising campaign would definitely slow development, but could result in an even better game. Based on my observations, I’m fairly confident that Cogmind could raise at least $10,000 to round off development, and any extra could be used for the handful of stretch goals I’ve thought up.

I still haven’t decided for sure either way, so I thought I’d write out what I’d been thinking about and see what others have to say.

In the meantime I need to be working towards a more complete product! I’ve been unable to work for much of the past month, but in a few days I’ll be returning home to start up the old IDE and begin putting this thing together.

Posted in Marketing | Tagged , , | 8 Responses