ToME: the Tales of Maj'Eyal

So does anyone one have on how to make a multi tile enemy in the t-engine? how would this work for graphics and such.

I don't know! I would really like to, though.

Also, how do you have multi tile floors/backgrounds? I have been separating the tiles up and squishing them together, but it's not a perfect fit.

You might be able to make a 3x3 blob by having the center one spawn the N/NE/E/SE/S/SW/W/NW parts of itself on creation, and teleport them to around itself every turn. I don't know how you could do more complex creatures though, or 2x2 ones. Graphics should be easy enough with that method as well.

EDIT: for multiple tile backgrounds, look at the farportal tile, it is 3x3.

Hey, thanks Lukep! I was able to easily implement that multi tile background.

I used the code:
On an npc, and it seemed to work okay. I put it right under the image = parameter. That's for 64x64 tiles and a big image of 128x128.

The only thing I can see wrong with using this is they act like one tile creatures as far as walls are concerned. As in, if they are in the topmost tile in a room, it will look like they are partly in the wall. It's not all that bad if the feet are in the bottom tile, and I bet you could tell the ai to avoid walls.

This is hard to do because it interferes with normal pathfinding. I think that boss monsters in tome, cheat, by having the topmost part not be really a 'occupied', it's just cosmetic to make them seem larger, and treated especially so that they are at a higher Z dimension so they are always on top of other tiles). This works because of the perspective.

I suppose you can do something similar for a scripted boss, that is actually immoble with 'moving part' (for instance a huge hydra heads where the neck overlaps other tiles because it is 'over' them) or only moves on a large room where you control his movements, not the pathfinding routine.

Solutions in 'normal' games abandon tiles normally (ToEE for ex), or create multiple pathfinding maps, one for each creature dimension 'category' (most older RTSs).

Apart from disconnected or immobile creatures, the only multi-tile monsters I've seen in a roguelike were in POWDER. The mid-game boss was a 2x2 minotaur, and while he couldn't fit into tight passages, he did have an ability that let him knock down walls.

It's an interesting idea but I feel like multitile monsters subvert a lot of the abstraction that comes with roguelikes. I think you can simulate size in many other ways that also contribute to gameplay (increased health, reduced innate dodge, ability to muscle aside smaller monsters). Also, you'll need to deal with some odd cases for multitile monsters. Do arrows of piercing hit twice? Are traps triggered when first walked over, or also when shifting position over the trap? You might have answers to these questions, but writing the logic into the engine is another issue.

Incursion's the only one I've seen use multi-tile critters regularly, and perhaps to the most sophisticated degree. Occasionally buggy, but generally they operated quite well. Pathing was often, if not always, solved by having the critter capable of shapeshifting into something smaller (and potentially down-sizing, though the AI couldn't use that intelligently. The player could, though, and could turn multi-tile itself given some effort.). Other cases, things were just stuck in the room they generated, in barring special abilities (teleportation, wall-walking, etc.).

IVAN had a few, too. There's a few others. Common low-effort method is to have them tunnel freely, knocking over walls kool-aid man style. Or just be incorporeal.

What would be really awesome would be multi-tile, amorphous oozes. It'd be neat to have to cut your way through a room sized jelly, with it trying to grow back around/over you...

Hey, i just thought of a evil enemy!

A 'wall mimic'

More than one of the *band variants had/have those There's at least two variants in heng/entro band, ferex. Stunwall, iirc, and something else.

I wouldn't be terribly surprised if crawl implemented them at some point. If they haven't already... they've got door ones, after all.

Admittedly, it would be hilarious to fatfinger yourself into a wall unintentionally and see damage numbers pop up.

And then you go a few more squares and do it again. And repeat, and repeat, and repeat. Then the stairs start coming for you and walls start attacking and the floor tries to eat you... you just awoke the dungeon mimic! Despair! You've already been eaten!

Totes sounds like something pen and paper dungeon crawlers would do.

I would work my way up-- start with a 2-tile creature. Think a snake.

Here's how I'd do it: two different creatures, head and tail. The tail doesn't do anything, maybe just passes damage it receives on to the head. When the head moves, the tail moves into the space previously occupied by the head. When the head and tail get drawn, rotate their appropriate textures so that the head and tail meet. (EDIT: or I suppose the easier way to do it is to use a single texture, rotated appropriately, but then you might have difficulty when you want to show how many arms your dragon has had chopped off )

A three tile snake gets a little more complicated, because you need to specify what the 3rd segment does when the first segment moves onto the 2nd segment (if you want your creature to be able to do that!) Hardly an insurmountable problem, you just need to figure out how you want to handle it.

If you want your creature to be a 3x3 blob, but be able to make it through doors, then spawn its peripheral body on a turn-by-turn basis, only if the hex is free. This same technique can be used to create limbs, if that's what you'd prefer. Note that you'll have to despawn the peripheral body (or do something with it!) if you want to blob center to realize it can move, so you're basically looking at replacing creature AI with despawn periphery, AI, spawn periphery.

If you don't want your creature to be able to make it through doors, it gets more complicated, because you have to rewrite pathfinding code, but I would stay away from this anyways, because it makes your creatures very easy to game.

Obviously, the parts of a multi-tile critter need to communicate well. There are multiple ways to handle this. You could have separate effects, hp totals, etc for each component, with the head passing a "die now" message to the rest of the body when it dies (or not!); you could just keep track of hp and effects for the head, and apply them to all components; you could do any number of things, with the best answer depending on what exactly you were trying to make. (Think about the difference between making a zombie dragon like from Dark Souls and making the Midgard Serpent. They'd communicate with their components in very different ways.)

EDIT: Even if you want a large creature that can't make it through narrow openings, this is relatively easy from a programming standpoint. Simply have them pathfind through a modified map.

For instance, if you have a 3x3 creature, you take your input map, and extend each wall by one tile in every direction. Now you have a map that your 3x3 can path through. (You also have to make sure it doesn't try to path to things inside of walls, because it can't reach them-- when chasing the player, for instance, it should try to path to tiles that are within 2 tiles of the player, rather than just one tile.)

If you have something like a 2x2, nominate (say) the NW corner as the pathfinder. Now go through your map, first from the east and then from the south, and every time you run into a wall, put another wall behind that wall (to the east or to the south of it).

This can extend to creatures of any square dimension. Creatures with orientation (take up more space in one axis than another) wouldn't work for it. It's remarkably similar to how collision is handled in my first love, Quake-- the players and monsters are point entities, and the walls are invisibly extended by half the size of the appropriate creature's bounding box.

Actually, I think movement is the most trivial issue when it comes to multi-tile creatures. It's the graphical depiction, AI, and special effects (knockback or AoE, for example) that are most difficult to reason about. There certainly are solutions to these problems, but in general I'm not sure it's a good idea to simultaneously embrace and eschew the paradigm of a grid-based game.