Official development blog

Multi-tile Robots

One thing you don’t see in a lot of traditional grid-based roguelikes is multi-tile units. Most such games are designed on the “one space, one entity” principle (though X@COM has had multi-tile units for a couple years).

This makes things simpler from both a tactical and implementation perspective, but somewhat reduces realism when your fighter ‘@’ is up against a dragon ‘D’ that should be many times your size, but isn’t and can squeeze through any corridor you can. Or in the case of Cogmind, you’re fighting (or more likely running from) a Behemoth class robot which, aside from being a capital letter ‘B’, is still not all that huge compared to a little Swarmer class ‘s’.

For the 7DRL prototype, multi-tile units were removed from the engine to avoid complications from a feature that wouldn’t see much use given limited development time.

Now I’ve added them back because they’ll be fun and further improve variety.

This of course re-introduces level design issues that uniform unit sizes manage to avoid, but large units will be fairly rare so it isn’t a problem, and the rarity serves to further enhance their “wow-factor.”

In ASCII mode large units simply repeat their symbol across their area:

Cogmind Multi-tile Robot

Right now you’re not thinking “wow”, but you will when you know what that thing is armed with as you consider the nearest path down which it can’t follow you!

Cogmind Multi-tile Robot (3x3)

Larger than 2×2 is possible, but robots that big would need their own special area to make sure they didn’t have to smash through walls to get where they’re going.

Large units are also compatible with sprite mode:

Cogmind Multi-tile Robot (sprite)

Wanted: Pixel artist.

So the days of tiny Behemoths is over. Another candidate for largification is the optional end boss. (I say “optional” because Cogmind should technically be winnable by stealthily avoiding as many enemies as possible, including the end boss.)

Next: Time to spruce up the environment with some “furnishings” appropriate for a world of robots.

Update 200407: Since this post I’ve written a lengthy article describing technical and design issues associated with having creatures that occupy multiple cells in the grid-based world of a roguelike, with solutions.

This entry was posted in Mechanics and tagged , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.


  1. Bim
    Posted November 24, 2013 at 11:41 pm | Permalink

    First time poster -- keep up the fantastic work, it looks incredible and your design choices are superb.
    However, I think the repeated sprites for ASCII multi-tile monsters (robots) might be a bit confusing, as you don’t know if it’s lots of monsters together or one big one when looking at it. How about ASCII lines with a B (or other char) at the front? That’d give you an idea about the direction it’s facing, which would presumably be quite useful.

    • Kyzrati
      Posted November 25, 2013 at 5:42 am | Permalink

      Thanks Bim! Agreed on the possible confusion. You make a good point, and it’s something I should’ve addressed in the post. For now take the following into account, and we’ll see how it plays out once you’re actually in the game for possible changes.

      I think in most cases it will be obvious because normal robots will 1) not move in formation like that and 2) ASCII are unique for each robot, so at worst you’ll only be unsure the very first time you see a given type of robot whether it’s actually that large or not--once you open it’s info screen, which I’m sure you’d want to do the first time you see a new type of robot! For example, upper case ‘B’ would only be used for a Behemoth, which would only ever appear in a 3×3 block. You’ll never see a ‘B’ by itself or in some other formation. Even without seeing the info screen, you can safely assume that if you see a capital letter in a perfect block, it’s a large robot; smaller swarming type robots, the only kind you may happen to see in sufficient numbers to very rarely happen to form a perfect block,
      are always lower case letters.

      The next post I have ready is going to show the info screen, on which you’ll see how a multi-tile robot is shown.

      As for direction, there is no facing in Cogmind so we don’t have to worry about that. Facing in ASCII roguelikes can be tough to convey properly, so very few games actually use it. Vision is always 360 degrees. My other game X@COM is an exception by necessity, but one I didn’t want to bring to Cogmind since the two games play very differently. Facing makes more sense when you have a squad-based game, and if there’s a single player character that feature makes the most sense in a stealth and/or horror roguelike, but not much else.

  2. Luke Jones
    Posted November 6, 2017 at 6:40 am | Permalink

    Cool to see someone actually doing multi-tile monsters. I always thought it was silly when a dragon or giant or something was only one tile, same as the puny human player.

    • Kyzrati
      Posted November 6, 2017 at 8:21 am | Permalink

      Yeah not only is it generally more logical, there’s the scare effect and also interesting tactical situations, like robots that don’t fit into narrow corridors. (Ahhh, and looking at this post it uses my old programmer art placeholder tiles! The real ones we have now look much cooler, but I’ve never shared screenshots in order to retain the shock effect when players actually meet them :D)

      But implementation does take a lot of special considerations and it wouldn’t be a good fit for how many games are put together, so we don’t see them very often. Newer roguelikes are tending to include these more, but part of the reason I started doing so from an early stage is because I was recreating X-Com for X@COM, and of course needed 2×2 units :)

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>