Developing Multitile Creatures in Roguelikes

Creatures/entities that occupy more than one space in the grid-based world of a roguelike still aren’t all that common, although in the development community this is an increasingly popular topic. Many of these discussions revolve around how to solve various technical and design issues associated with this type of entity, and while I’ve provided input in a number of these conversations over the years, it’s really about time to collect some of these experiences, observations and advice into a single article for better reference :)

I gave “multi-tile robots” cursory coverage back when I was first spinning up Cogmind as a commercial project in 2013, but all I really did there was give a basic description rather than look into the nuts and bolts underpinning this feature.

I’ve been working with multitile creatures since 2011 when I first added them to X@COM. As I wrote about there, it was quite a headache because I didn’t include them from the very beginning, but it was both necessary to do considering the primary source material (X-Com) and also definitely adds a lot of character to these creatures, so very much worthwhile.

The famous example of a big ‘D’ dragon occupying only one space, the same tactical unit as a tiny adventurer, is great in its own way (elegant!), but there’s something to be said for the psychological impact and mechanical implications of an actually physically larger creature.

I guess there’s also the realism argument--although complete realism isn’t usually a good goal in games, it’s always nice when you can both embrace it and get some benefits in return.

“Holy… look at that thing! We probably can’t take it on at this point, but if we escape down this narrow corridor it probably won’t be able to follow us… We’ll find another way around.”

Types and Examples

Technically the concept of “multitile” creatures can be subdivided into a number of different categories, not all of which I’ll be covering in detail here.

For example a number of roguelikes have stationary multitile creatures, like Ivy Creepers in Ragnarok.

Although stationary, sometimes creatures in this category can also grow outward, like the various Ivies in HyperRogue.

Overall these are fairly easy for developers to work with, it’s just a case of whether you want/need something like this in game.

There are also snake-styled multitile creatures which can move, but where the body essentially follows whatever path the head has taken, so also not all that hard to manage.

 

The genre also includes amorphous area-based creatures like DCSS Krakens, which consist of a single body tile and send out tentacles which essentially behave as individual creatures (although their range from the body is restricted, and damaging them also damages the Kraken).

For the purposes of this article, to keep the scope in check (and more importantly to cover the especially challenging areas where questions usually arise) I’m really only interested in the most generic type of multitile creatures, those where the entire creature is a “connected solid blob” that is present on the map and moves as a unit like other single-tile creatures.

Probably the most extreme example of this category would be Dumuzid, a 7DRL explicitly designed around the concept of size, so it’s not surprising that you can end up with a massive sprawling body that moves as one.

Some more typical examples, all coincidentally reflecting the theme that multitile creatures are often used for especially challenging or awe-inspiring enemies like bosses:

 

 

For X@COM I went all in on the multitile units, branching out from the original requirements for X-Com. It’s fun to drive a tank through walls and watch the building collapse :). It’s also fun--but scarier--to watch huge enemies rampage through buildings, knocking down walls and crushing furniture! X-Com itself only had units up to 2×2, but when putting in place mechanics like this, may as well make the size arbitrary! Back then while recording a video demonstrating sound testing there was a 5×5 Colossus at the end, which you can see below starting from 3:50:

Having inherited its architecture and even some mechanics from X@COM, Cogmind also includes a number of multitile entities for their shock and awe factor. Although there are slightly more obstacles to overcome when moving from a more open surface environment vs. the subterranean environments more typical among roguelikes, for me it’s worth the trouble.

IVAN reportedly also has 2×2 monsters that can usually destroy walls in order to move around (or are simply stationary), but I couldn’t find any good resources or images on those.

I’ll be sharing more examples from Cogmind and other roguelikes below where applicable to the topics we’ll be covering.

Note that as discussed here multitile creatures refer to those of an actual larger size when it comes to mechanics and the number of grid spaces they occupy, not just cosmetic size, which a number of games do as a simple way around implementation issues, but as a result also don’t fully realize their potential.

Appearance

There are a number of different ways to depict multitile creatures on the map, some of which might need to get creative if limited to ASCII and/or traditional grids with an otherwise uniform cell size.

For Cogmind’s ASCII mode I chose to repeat the single character across the area currently occupied by the entity. The usual opposition to this concept claims that it becomes impossible to distinguish whether it is a group of entities or a single large entity, but in practice that’s not really much of an issue since based on the game content it’s otherwise extremely rare to have individuals matching that letter both adjacent to each other in a uniform shape and also moving in perfect formation. Not to mention when examining such an entity all the spaces are highlighted together, and labeling (or for example in other roguelikes listing what is currently visible) only does so once for the entire thing, rather than for every constituent cell. So this isn’t really something to worry about unless there is something else specific to the given game’s content or mechanics that might lead to confusion.

 

Incursion offers another potential approach for ASCII-based roguelikes, linking the creature’s character to its surrounding occupied cells with a separate representative character, in this case using ‘+’:

Under a very strict grid-based system like that often used in ASCII games, it’s technically still possible to draw multitile creatures using a sprite that extends over more than one cell. Cogmind’s engine in particular doesn’t even support drawing anything that doesn’t match the grid size, so the only way to draw a multitile object is to do it piecemeal, one cell at a time. For example, the 2×2 Behemoth consists of four separate cells, appearing as such in the sprite sheet:

Many roguelikes using modern engines don’t necessarily care about this sort of thing, and are instead able to simply draw any sprite, large or small, at any position. Zorbus offers a good example of multiple different methods for drawing large creatures when there aren’t any architectural restrictions.

Partial Visibility

A number of roguelikes (including Zorbus above) might display multitile creatures simply using large characters, highlighting another consideration when working with multitile creatures: partial visibility. Field of view in roguelikes is almost always handled on a cellwise basis, so what does the player see if only one or more pieces of a multitile creature are visible?

In terms of ASCII and Cogmind’s default approach of repeating the same character throughout every occupied cell, seeing only part of a creature doesn’t make much of a difference since every cell contains the same representation. Perhaps the main concern here would be that a player might not be able to immediately distinguish whether a single ‘B’, for example, is a corner piece of a large Behemoth or a single-tile Brawler-class robot. This is where it helps to have those automated labels demonstrated earlier--the question is answered immediately on spotting them!

To demonstrate another scenario, we can use a graphical Cogmind mod recently released by Ape, which converts the default multicharacter style to instead use large characters like so:

So what happens when this only the corner of this particular Behemoth is visible?

Again the autolabeling will help here anyway, but the top-left corner of a large ‘B’ character actually looks like an off-center ‘c’! And of course each other corner, or side, will have its own unique appearance. Partial visibility doesn’t work so well with this approach as far as quick visual parsing goes (usually one of the advantages of using ASCII in the first place).

Based on this info, with multitile creatures we might want to break the mold of displaying only the cells that a player can currently see, and instead allow the player to know and see the full extent of any multitile creature they can at least see part of. This could apply to both ASCII and tilesets. Either show the entire creature normally if any of its parts are visible, or show it all but consider fading those cells not currently in FOV, since it can still be important to know when certain subsections are technically out of view.

For cogmind in particular I decided against showing parts outside FOV (which is an option even if separate characters are used for each part!) because it would complicate a lot of the UI features in my case. I imagine it would work fine for a lot of other roguelikes, though.

Architecture

Handling relative position data for entities is fairly straightforward when each one can only occupy one cell at a time, but what do you do for those with a larger footprint? Some people get hung up on this question. The answer for a given roguelike could depend on other needs and architectural concerns, but here I’ll share what’s worked well for me.

This is rooted in the format for general map data, so here’s a diagram of how Cogmind map objects are structured:

This diagram includes some superfluous info because I pulled it from a broader discussion, but the concept to pay attention to here is that 1) an entire map/floor is represented by a two-dimensional matrix of Cell objects, and 2) within each of those cells is an Entity object. “Entity” refers to an actor/creature/character/mob/whateveryoucallit, where the Cell stores its occupant’s handle (sorta like a pointer) or simply null if no Entity is currently present at that location.

Although I do also have a list of all the Entities in existence (technically managed as a separate list for each faction), and that format clearly comes in handy for some types of operations that need to iterate over all Entities, I find it very useful to have an actual 2D space across which to perform spacial searches and apply effects etc. For performance reasons this is especially important in Cogmind where there are hundreds of Entities at once.

So what does this mean for multitile Entities? Well… just put their unique handle in every Cell they occupy :)

It’s not like the Entity object itself is actually copied anywhere--it’s just a little handle, so there’s no serious waste of space, but definitely a serious bonus to convenience. Processes checking who’s occupying any one (or more) of those Cells will be pointed to the same Entity. Whenever the Entity changes position, it just moves its handles from all of the original space(s) it occupied to the new ones.

Each Entity itself also stores a list of all the map coordinates it currently occupies. While it’s true that for most/single-celled Entities this list only contains one coordinate, implementing the system like this makes it easily scalable. At the same time, although for most roguelikes you could generally extrapolate these additional coordinates if you know their reference position and size, that’s pretty slow to be doing all the time!

In my case I chose the Entity’s top-left corner as their “reference position,” the first to appear in its list, where any additional coordinates are added in row-first order (notice how the indices here will conveniently mirror offsets in the sprite sheet shown earlier ;)). The idea of a reference position will come in handy later.

(Although most devs there don’t make mention of multitile entities, regarding map object architecture you might find other inspiration in the previous relevant FAQs over on r/RoguelikeDev.)

Shape

Before we go any further it’s important to talk about shape as it relates to multitile creatures.

By far the most common multitile creature in a roguelike, if there are any at all, is the so-called “2×2”, occupying a total of four cells. As a square this is fairly easy to deal with because it doesn’t have any convex or concave elements to complicate movement or interactions.

Non-square shapes (even just rectangles!) are problematic since then you likely have to deal with the logic and consequences of rotation, among other issues. With multitile creatures already introducing enough of their own complications, most roguelikes don’t venture into other shapes. (Something like Dumuzid is of course an exception here, since its a small game where the central theme happens to be size manipulation. Interestingly, it does not allow rotation, either.) Rotation suggests an explicit facing, anyway, and most roguelikes don’t have facing mechanics, so multitile creatures that imply multiple orientations are often avoided.

Pathfinding

Whenever the topic of multitile creatures pops up in the roguelikedev community, there’s a good chance it’s someone asking about pathfinding. In a game where every actor occupies exactly one space, moving them across a grid seems a lot more straightforward than managing those which need extra space to move around.

For the purposes of pathfinding for multitile creatures we’re going to be ignoring these less common scenarios and, again, creatures outside this article’s scope:

• non-square shapes (and by extension any rotation involved with those--CDDA has rotating multitile vehicles of various shapes if you want to look into that, for example here)
• snakes (longer are especially challenging, since they can block themselves!)
• amorphous creatures

Still, if you’re working with any of the above, it’s mainly a case of picking a primary reference part (of the creature in question) on which the pathfinding is based, and extrapolate positions for other connected parts as it’s moving, which is actually akin to what we’ll be doing here in a moment for regular square multitile creatures.

Method 1: Static Approach

One method I haven’t used before but have seen others use is to explicitly map out the spaces available to large creatures, and use that map for pathfinding. Taking the most common 2×2 creature as an example, you can make a copy of your map and block any otherwise open spaces that have a wall or other impassable obstacle to their south, east, or southeast.

So as per the above screenshots, pathfinding algorithms would rely on two separate maps, one used for standard-sized actors, and another for 2×2 creatures:

 

However, this approach works better for static maps, since changes to the map due to terrain destruction or other factors would require recalculating the pathfinding map(s) (or at least parts of it). I love rampant terrain destruction in my roguelikes, so this approach won’t really work so well in my case. As you’ll see below, an alternative dynamic approach can also take into account more factors, anyway, creature size being just one of them.

Method 2: Dynamic Approach

The dynamic approach starts getting more deeply into how you build your pathfinding system architecture. Amit’s got great resources on A* pathfinding over at Red Blob if you want to read up on that common algorithm for more background. I’m not going over basic A* here, instead looking at how to best apply it so that it can specifically account for creatures of arbitrary size.

For all but the simplest roguelike worlds you’ll often want to have creatures actually examine each potential cell along a path and weigh it in terms of various relevant factors, for example terrain movement costs (which can differ by creature type and terrain?), or the creature’s own capabilities (able to swim? fly? open doors? some other form of environmental interaction?). One nice way to compartmentalize this feature: Callbacks.

In simple terms, when a creature wants to find a path from point A to point B and calls the game’s pathfinding function, it also provides a callback function that essentially contains instructions for how to value cells along prospective paths. A* pathfinding operates by assigning “cost” values to cells until it finds the sequence of moves that can arrive at the intended target for the lowest total cost. So the callback’s job is to just return the cost for a given cell in order to facilitate those calculations.

As shown above, Cogmind’s primary movement pathfinding callback that’s sent to the algorithm is actually an object holding multiple methods, originally virtually defined by the base class associated with the pathfinder itself (Cartographer2D). I found it more efficient to split out into multiple methods some of the checks that a callback might need to handle, e.g. isValid() is used to tell whether the goal is a valid movement position, which is probably important to know before bothering to start :P. (Cartographer2d also supports pathfinding via cell-enabled teleportation, but Cogmind itself doesn’t feature that kind of teleportation so the callback object doesn’t define the necessary method.)

Where does this accommodate multitile creatures? First of all, remember that the reference part of the creature is what’s being used to calculate their path--the beginning of the path matches their top-left corner, and the end of the path will be the final location of their top-left corner.

The isValid() function* just needs to be sure to check not only whether the reference position at each cell along the path is valid, but that all other relative parts of the same creature are also valid (*and by extension getMoveCost(), which is what checks isValid() before calculating and returning the cost for a cell).

This dynamic approach doesn’t require precalculating or maintaining any other pathfinding maps, can take into account any number of other factors (regardless of whether they’re changing all the time!), and is clearly just what we need for allowing multitile creatures to move around while also considering whatever else they need to consider.

In summary you get a lot of flexibility by using callbacks for pathfinding. We can add whatever absolute checks we want to isValidCell() and they’ll be applied to any cell the creature might think about occupying, or add checks to getMoveCost() for moves that are allowed but might have a different cost than moving into/through a normal cell. Cogmind doesn’t make especially heavy use of these features, though as you can see there are conditions determining whether or not an entity can use different types of hidden doors, and the cost of pathing through a known trap or area prone to cave-ins is higher (making it less likely).

Aside: The popular roguelike library libtcod (which I recommend in my How to Make a Roguelike talk/article) includes support for pathfinding callbacks! In fact, using libtcod in my early roguelikedev days is actually where I learned about them in the first place :)

Design

Having gotten the primary technical concerns out of the way, there’s also the design side of the equation when it comes to multitile creatures. Surely you can’t just drop them into a world made for your typical 1×1 cell-sized creatures and expect everything to be okay :P

Environment-based Factors

Naturally more open maps are better suited for these large creatures, since terrain is the biggest obstacle to their movement. Although roguelike maps tend to have a lot of tight spaces, even subterranean maps can also be made more hospitable for large creatures if there are at least some open areas for them to comfortably occupy.

For example Cogmind’s most common 2×2 unit, Behemoths, aren’t located in random rooms, but instead specifically placed in areas where multiple rooms and corridors have converged to create a larger space.

This ensures they’ll have some room to maneuver and engage threats without being overly restricted, and while it’s true they’ll not always be able to stray too far out of the area they’re defending, they still present interesting challenges when compounded with other factors to complicate situations, like a player fighting a running battle through such an area, or encountering other enemies at the same time and finding it difficult to disengage.

Other challenges arise when there’s no easy way to circumvent a large creature and a confrontation is almost guaranteed sooner or later. This also starts to suggests the idea of “multitile creature as boss or miniboss,” where their extra visual weight signals that they’re not to be trifled with (hopefully with stats and abilities to back up this assumption!).

Since multitile creatures can be problematic for map layouts, it makes sense to limit their overall number in the first place, plus having fewer of them enhances their wow factor anyway. Again: boss material.

On that note, another way around some of these issues is to design special areas explicitly for multitile creatures, like their home/den/native habitat. “Waste” is an example of one such place found in Cogmind, where chutes from Factory zones send scrap for disposal, and mobile Compactors mill about crushing everything.

Compactors are each 2×2 multitile entities, and all corridors in randomized Waste layouts are exactly four cells wide, just barely allowing two Compactors to pass each other. This of course presents a problem for players who have attracted the attention of more than one Compactor, since they can form an oncoming wall of death, so maneuvering to prevent or undo such a situation and slip by can be a useful skill if without the firepower or other means to actually take these chunky bots down.

Since we were talking about multitile creature representations earlier, here’s an alternative look at the same scene:

Garrisons are another example of a Cogmind map type in which multitile entities have influenced the design, where there is often a 2×2 Behemoth guarding the central room and double-width corridors extending outward to all four access points.

There are still small access tunnels mostly hidden behind walls that might be useful in avoiding a confrontation with the Behemoth in a Garrison, but overall it’s quite a game of cat and mouse if you’re not ready to engage them head on, since due to the layout and Garrison mechanics it’s likely you’ll have to pass through the central room more than once from different angles before being able to actually leave.

Creature-based Factors

Aside from external factors like map design, we can also examine this issue from the other side: What about giving multitile creatures more control over how they can maneuver through, or manipulate, the spaces around them? This is where various mechanics and creature-specific abilities come into play.

Seemingly the most common approach here, and the one that makes the most sense (because, I mean, they’re big creatures, yeah?) is to simply let them crush obstacles and smash their way through terrain! Whether or not this will work for you can of course depend on the environment and other circumstances, but it serves as yet another source of wow factor when some creature practically ignores walls that block normal-sized foes and just comes right through them.

The multitile creature demo in the X@COM video I shared earlier happens to show it smashing through walls, although much of it is out of view while doing so. In that game the system is generalized such that different materials require a different amount of force to knock down/through, so while a soldier can relatively easily jump through a glass window, or a bigger alien can possibly stomp through a fence, it takes a tank or huge alien to smash through walls of brick or stone.

While pathfinding, A* callbacks can help determine 1) whether a given unit is even able to take a “shortcut” through a given material and 2) whether the potential cost(s) of doing so are not greater than going around it (if possible).

[SPOILER ALERT: If you’re a spoiler-averse Cogmind player, you might want to just skip this paragraph.] Although not nearly as detailed, Cogmind has a similar mechanic specific to a certain entity. It’s a fairly rare encounter, but players might at some point discover an experimental “Superbehemoth” capable of disintegrating terrain around it, effectively tunneling through it if necessary to get somewhere.

As mentioned earlier, I’ve heard that IVAN also has 2×2 multitile creatures that can destroy terrain in order to move, thereby sidestepping one of the tougher challenges with this type of creature.

Very much in the theme of ASCII and turn-based grids and all the things that speak to a “limitations breed creativity” mindset, in trying to integrate multitile creatures into a roguelike you can always experiment with other forms of movement and enabling mechanics, too.

Maybe a multitile creature can temporarily reshape itself to squeeze through narrow areas and unexpectedly pop out on the other side? Maybe they can teleport or use some kind of network of gateways? I still haven’t actually done it, but one of the ideas I think would be fun to implement is a giant robot that can dispatch a bunch of tiny engineering drones to excavate pathways on the fly when it needs to, and they rebuild walls and terrain behind it after it’s passed.

Another approach here is to allow multitile creatures more flexibility in how they can attack, essentially projecting their sphere of influence beyond their movement range. Early in Cogmind development this was actually one of the first ways I made Behemoths more formidable than they started out, since they are otherwise huge lumbering bots that could be evaded by keeping obstacles between yourself and them. Well they already have powerful enough weapons, so I just made their AI much more aggressive, willing to fire their cannons through machines and terrain to get at targets.

So if the mechanics/environment/theme are suitable, consider giving multitile creatures the ability to attack and destroy terrain, or even just attacks that can penetrate terrain and other objects.

Or maybe they send out other attackers to engage targets? This could force the player to come to them in order to the deal with the source of the ranged threat, not unlike the stationary dispatchers of POYLBOT-7.

Miscellaneous Issues

You’ll no doubt discover more complications stemming from the introduction of multitile creatures, some of them specific to your mechanics and needs.

Origin vs. Target

One of the more common ones you don’t normally need to think about in a roguelike is the specific origin or target of an attack, in cell terms, considering that creatures might occupy more than one grid position. Perhaps if you have an odd-dimensioned multitile creature (e.g. 3×3) you might want to use its center point for this purpose. Or if you have special mechanics and a facing component there is/are actually a designated point on the creature where its attack(s) originate.

In my case, for the origin I always select the point on the attacker that is closest to the defender, and have it target the nearest point on the defender. That’s for AI-controlled units, anyway--the player has more freedom to select any cell occupied by the target, making it somewhat easier to acquire a clear line of fire on partially obscured targets. It would be better to allow the AI to target any visible cell as well, but I felt it wasn’t really needed, or worth adding that complexity, for my purposes.

AOE

If you’ve got area-based effects like explosions, as many roguelikes do, that’ll be something else to consider. Should multitile creatures take extra damage/effects separately for every one of their tiles within the radius?

Having larger entities take more AOE damage like this is an option if you think it balances well given your mechanics, and players may even sometimes assume it in tactical games with a heavy emphasis on grid-based play (in my experience it’s not an entirely uncommon question among players).

Personally I think it makes balance much more difficult to achieve when it comes to Cogmind mechanics, so I prevented that from being a thing--regardless of size, a single unit can only be affected once by a given AOE attack.

I simply keep a record of all the entities already impacted by each active AOE effect, in order to prevent further segments from applying the same effect. As per the map object architecture I shared earlier, each Cell occupied by a multitile Entity stores a handle pointing to the same Entity, so marking the first one affected by an expanding radius naturally makes all the others “immune” to the same event.

I ended up needing to take the same precautions for Cogmind’s penetrating weapons as well (capable of piercing a target and going on to affect additional targets behind it)--I didn’t realize until 2017 that these weapons were disproportionately effective against larger targets, since they could pierce one section and then hit one or more additional sections, affecting each separately. Now this does make logical sense, sure, but balance-wise it’s not so compatible.

Terrain

You might also need to consider how multitile creatures interact with various types of terrain. Like what happens if they simultaneously occupy locations with different or even incompatible effects? How are variable terrain-based movement costs applied?

For this and other reasons, it’s a good idea to add this kind of creature early in development so that you can take them into consideration throughout the process. Introducing them later could be quite problematic since you have to uncover and resolve all these issues retroactively rather than building each consideration into the system bit by bit as you encounter it.

Cogmind doesn’t include many terrain-based factors, although one example I can provide here is traps.  Chute traps, which suck units down into the ground into another area (the aforementioned Waste!), only occupy a single space, so they essentially ignore larger entities that “wouldn’t fit” :). Most other traps however, like those of an explosive nature, are triggered normally for every cell the entity steps on, meaning it’s possible to set off more than one in the same turn.

3D

Few roguelikes take advantage of 3D grid space, but while we’re on the topic we might as well cover some points regarding adding a third dimension to our multitile creatures.

Earlier I talked about square shapes being by far the easiest to work with when it comes to multitile creatures, though the z-height of such a creature doesn’t necessary need to match the other two dimensions. A 3×3 creature with a height of 2 isn’t going to operate significantly differently from one of height 3. We are, however, assuming that height is uniform across its area. You can easily have 3x3x3 cube-shaped creatures, flatter 3x3x2 creatures, or even tall and narrow 1x1x2 creatures.

In most cases you’ll be able to simply extrapolate everything we’ve already done for multitile creatures into the third dimension--like our pathfinding callback needs to check not just two dimensions, but three. I did this for X@COM, where I added 3D creatures and used the top-left corner of their lowest/base level as their reference point.

And although a full discussion of how to represent a 3D space in a top-down 2D map is beyond the scope of this article, it’s worth pointing out that with creatures like this it can be beneficial to allow a way to see them from the side as well. I first talked about side views back in 2011 when I implemented this feature for X@COM, and later shared how this can be applied to viewing 3D multitile units from the side as well.

This makes is easier to visualize targeting their different z-levels in case there are obstacles blocking line of fire at a given height.

More?

I’ve covered a lot of the main multitile creature topics here, but it’s a big one (haha) so feel free to ask about related issues or anything here you’d like clarification on!