# Distinguishing between multiple objects with the same name in a text based adventure game/interactive fiction

I'm in the middle of writing my own parser in Python. I've managed to make some simple commands, with simple prints to make sure they work. Since I intend there to be combat, I needed to write a command for attacking something. I just completed that.

My issue is: What should I do to allow the player to choose which of a given enemy they attack? It is fairly simple when they are different types of enemies (e.g. a goblin and a troglodyte), but how should I distinguish between two of the same type (e.g two troglodytes)?

Suggestions I have had so far: Give each of them a significant feature (color, height, relative direction) but that only so far; name each of them (so you attack "bob" or "steve"); or the one I have been favoring the most, give them each a number (so there would be troglodyte1, troglodyte2 etc.)-this might break some immersion, though.

You have what I feel are two distinct problems. One is a design problem: how to deal with multiple distinct objects that have no distinct visualizable characteristics. The second problem is a technical problem, which is how to make it easy to identify individual objects out of a group via commands.

Technical Solution

Back in my MUD programming days, I just added syntax for specifying ordinals. Most MUDs do the same, albeit most only support a terse syntax.

For example, you can parse out the following words from an enemy or item argument to a command: first, second, other, third, fourth, fifth, etc.

You can usually stop around "third" to "fifth" depending on how common those sizes of groups are in your game. I used "other" as a synonym for "second".

You'll also want a way to just enter in the ordinal with digits, so you don't need a huge dictionary (or all the crazy logic to deal with English ordinals, at least). Parsing "1st", "2nd", "3rd", etc. is pretty easy. There's only a few special rules for those ("11th", "12th" and "13th") and the rest all follow a simple pattern. Going this route, make the suffixes optional.

The result is that you can type in phrases like:

attack third goblin
pet other wolf
get 4th sword


You can even parse out and throw away a leading "the" if you want to please the 0.02% of your players who feel a need to type out full English sentences. (It's a neat feature to demo, but really, nobody who plays these games is interested in typing that much, and these days you'll be lucky if half your players can spell "fourth" correctly much less use proper grammar.)

Typical MUDs and text adventures use a terser method of specifying ordinals, usually with some special punctuation. For example, you might have to put a period or a colon or some such followed or preceded by a number, e.g. ".5", giving you syntax like one of the following:

kill .5 goblin
kill :5 goblin
kill 5:goblin


Note that this solution works even when you have distinct names. Maybe you have a "large ornery goblin" and a "small timid goblin." The player doesn't want to type all that out. The player will be happiest if you support partial matches. The player still wants to easily identify both goblins when typing, though. Ordinals are one way the player can do that, assuming there is a clear ordering to the goblins.

Design Solution

Don't have non-distinct items and creatures or, if you do, have them implicitly act as a whole. You listed that as an option to solving the problem. It really is a good one, but only if you can do it completely.

Consider the case where you have five goblins in your typical MUD-like environments (interconnected "rooms"). The player enters the room and sees:

[Cavern Entrance]
There are five goblins (hostile) here.
Exits to the north and south.


The player wants to attack first, so he types:

attack goblin


The player attacks the first goblin (first by implication of not specifying another, which is just whichever goblin is arbitrarily first in the list of enemy game objects you have. The player does some damage to the goblin. Then the player sees:

A goblin flees north.


The player looks around again, and sees:

[Cavern Entrance]
There are four goblins (hostile) here.
Exits to the north and south.


A goblin fled. The problem is, which goblin was it? The one that the player injured? One of the other goblins? The player doesn't know. Let's say it was the injured goblin for this example.

The player continues fighting:

attack goblin


The player attacks the goblin that is now the first goblin (but was previously the second goblin). A few moments later, the player sees:

A goblin enters from the north.


The goblin that fled got its courage back and returned. Likely, it is added to the end of a list of some kind in the game code, so it is now the fifth goblin. If the player looks again, he sees:

[Cavern Entrance]
There are five goblins (hostile) here.
Exits to the north and south.


Again, the player attacks. Only, the player has no idea which goblin he's attacking. Is it the injured one? A different one? How does he tell that one of the goblins is injured? How can he target that goblin? We know that the injured one is the fifth goblin, but without some way of visualizing that, the player can't know it for sure. And you probably want to avoid overly verbose output like:

[Cavern Entrance]
There are five goblins (hostile) here.
The second goblin is injured.
The third goblin is injured.
The fourth goblin has a nasty rash.
The fifth goblin looks longingly at the second
goblin, but the second goblin is out of his league.
Exits to the north and south.


That's where the design decision comes in.

One option is to treat all game objects of the same type grouped together as a single entity. Hence, you do not have five individual goblins with individual health values. You have a group of five goblins with a single shared health value. Whenever that health value is reduced below zero, the number of goblins is decremented by one and the health is incremented by the per-goblin health value.

Example: Say goblins have 12 health, and there are 5 goblins. You have a single goblin object that has a count of 5 and a health of 12. The player does 20 damage to the group. Health is now -8. One goblin is subtracted from the count (there are now 4 goblins), and the health is incremented by 12 (health is now 4). If the player does 4 more damage, another goblin will be killed.

Combining and splitting groups is a little wonky in this case, but it can be fudged. When a second group of goblins shows up, take the sum of their counts and the minimum of their health. When some number of goblins should flee, their count is subjected by the number that don't flee, and a new group object with that count is created with full health (the original group should also leave the room as part of this operation so that they don't automatically merge back together).

This of course changes the dynamics of the game a bit. The player can no longer decide to weaken all the goblins and then finish them all in one area attack. He is implicitly always attacking the weakest goblin. This small trade-off in flexibility gives you a much more obvious, clean, understandable, and approachable UI for a text game, however. It's up to your design constraints to decide if the trade-off is appropriate.

There are other variations of this approach you could use as well. Anything that statistically approximates a group of individuals with some broad group numbers works fine. Strategy games like Heroes of Might & Magic or Warlords do something like this. Rather than dealing with individual units, the player has "stacks" of units, which are treated as a single entity.

• I'm surprised not to see # in the ordinal notation, e.g. attack goblin #5. Seems like that would be the most natural puctuation in English. – Nathan Reed Dec 25 '12 at 8:26
• @NathanReed That seems like it would be just as easy to parse as the others. I'm not sure I like the "grouping units" idea, simply because I want the player to feel like he is attacking a particular creature as opposed to just fighting a force that happens to consist of that many creatures. This also because I really don't like the generic items of a creature. Why are all goblins holding spears? Why not clubs? I was hoping there would be a way to say that you want to "attack first goblin with club", and not have it interpreted as "make a melee attack with club at first goblin". – PixelArtDragon Dec 25 '12 at 15:44
• @Garan: of course there's a way. Just parse that. Once you have a specific syntax in mind, writing a parser for it is generally quite easy. Ask nicely enough and I might be convinced to write up how I did my generic phrase parser. Short version is that it was just a simple back-tracking grammar parser, like a very simplistic regular expression type language that looked at words instead of characters, with partial-match support. You could probably implement a much better version as a DFA. – Sean Middleditch Dec 25 '12 at 20:15
• "And you probably want to avoid overly verbose output like:" ... The fifth goblin looks longingly at the second goblin, but the second goblin is out of his league. -- actually, that sounds funny and AWESOME. Want. – wjl Jan 19 '14 at 22:25

Instead of distinguishing them by different names or colors you could give the player a variety of commands with the power to distinguish.

For example, if "five goblins attack you", you could invent either numbered or named commands like - "attack first goblin" or - "attach goblin 1"

This approach is almost like you already suggested, but instead of naming or presenting a long boring to read list of enemies, you just tell the player the amount and the player decides how he likes to interact/type.

Also, you could have a database of random names to choose from, if you really want to distinguish uniquely between enemies.

• Hmm... I had considered this, but I still wasn't quite sure it would be better. I felt it was too similar to the third option. But this tells me that it wouldn't be too clunky and that it might still be intuitive. Thank you! – PixelArtDragon Dec 25 '12 at 5:32
• Of course, you're going to run into some fun edge cases where you've killed the first goblin, and now you need to decide what to do with the second through fifth goblins. Do they keep their numbers? Or do they re-shuffle down to take the earlier numbers? If so, how does the player know which is which, so he knows which he's already hurt? And if not, what happens when another goblin enters the room when goblins 2-5 are alive? Does he become the new #1, or is he now #6? Numbers really are problematic, here. – Trevor Powell Dec 25 '12 at 7:45

The way classic text adventure games of the Infocom style solved this problem was, indeed, by making sure that every distinct object did indeed have a name that allowed it to be uniquely identified.

A detail to note is that, in Infocom-style parsers, one could refer to an object by any combination of words in its name. So, if the player came across a red chrysanthemum, a red circular amulet and a green triangular amulet, typing either:

> get red amulet


or just:

> get circular


would allow the player to take the red circular amulet, while typing:

> get red


would (if both objects were indeed present) produce a clarification request like:

Which do you mean: the red chrysanthemum or the red circular amulet?


Also, objects might well have synonyms that were not part of their display name, so, for example, typing:

> get red flower


would very likely also work for picking up the red chrysanthemum. Indeed, players would (and, indeed, still do) very much expect any well written game to understand such natural synonyms. Similarly, an amulet might also match the word pendant, especially if it was described as being or resembling one anywhere in the game, and the circular amulet might also be described as round.

Indeed, this parsing style is still very much in use in modern interactive fiction. For example, you might want to take a look at how the parser recognizes objects in Inform 7, a special-purpose language designed for writing this kind of games.

Ps. Roguelike games, which typically have a lot more objects, generally solve the same problem in a different way: they let you pick the object you want from a menu. Some of them, to deal with the potential issue of apparently identical objects that nonetheless are different somehow, also allow the player to name individual objects, or even entire classes of objects, so that one might see e.g.

What do you want to light [p-r]?
p - a lamp
q - a lamp called "magic"
r - a lamp called "magic" named "this one's probably cursed"

• So this would be more like saying "attack" and then be prompted with "Which enemy do you want to attack?" followed by a menu of enemies present? – PixelArtDragon Dec 25 '12 at 21:16
• Yes, or at least typing "attack goblin" and being asked "Which do you mean: the hairy goblin, the fat goblin, the wrinkled goblin or the goblin chief?" (Note that the parser would typically accept just, say, "hairy" as a response to indicate that you meant to attack the hairy goblin.) Also, in such a game, if you really were facing, say, 3,872 indistinguishable orcs, they'd likely be represented by a single actual monster (just like in the link I gave). – Ilmari Karonen Dec 25 '12 at 21:46

It looks like most of the territory has been covered for major methodologies, but I thought it might be a good thought exercise to step through how you might want to conceptualize this decision anyways, and stretch myself to cover some methods I haven't seen.

# Perspective and Quantification methods

Several of the solutions involve working around this question by using names or features to identify the monsters. In order to address the purest version of this question, we'll assume you are confronted by N identical goblins.

They are inevitably arrayed in some spatial arrangement and you will end up with a few ways to describe their arrangement in relation to you:

### Top Down Perspective

1. They may be described with yourself as dead-center on a compass. This allows for the richest spatial arrangement but let's imagine all 5 goblins are in a line due north from you--"north" alone is not sufficient for distinguishing their arrangement.

### First-person Perspective

1. They may be described in an informal version of the above (left, front, right, back). This has similar limitations, but this is relative to your orientation at any given moment. This may also be restricted to what you can "see" (you'd need to have some form of magical vision to target something behind you.)

### Quantification

Both of these cases allow for indicating spatial arrangement but do nothing for clarifying between multiples in the same relative space. We can add some concept of closeness which could be either applied on its own or in order to augment one of the above conceptions.

1. They may be described based on their closeness to you in verbal form. Near to far. This has obvious quantification limitations, but given a spatial arrangement we realize that the relevance of goblins beyond the "nearest" are only relevant if you have some sort of ranged method of hitting them (or some method of running past any number of intervening goblins to attack the last.) This method of distinction is most compatible with the "stack" methodology suggested by others.
2. They may be quantified based on their closeness to you. The first goblin is the closest, and the Nth goblin is the furthest. This alone is probably the most common method of distinction in use.

### Other

1. You might be able to use some sort of newfangled client or technology to require the player to click on the name to attack.

# Naming and Description methods

There are a number of approaches here, and they all involve sidestepping the need for resolving the text medium's weakness at these forms of reference:

1. assure the monsters are unique in the design phase and need no distinguishing
2. generate random, locally unique properties for distinguishing them
3. generate semi-random names (probably with algorithms tailored to race/class)
4. generate unique random indicators as meta-data for targeting (one or two alpha characters).

All of the various solutions thus far are predicated on the assumption the task of targeting other objects with actions is that of the player. If we are suspicious of this assumption some new possibilities open up to us:

1. It might instead be the case that your game is set in a realm where creatures dictate action; mobiles will decide whether they attack or interact with the player and the player takes on a purely reactionary role within the world.
2. Mobiles in your world might engage with you based on actions you take. To give an example, a guard may refuse to engage in hostilities with you until you try to sneak or push past him at which point he engages you in combat. Rather than trying something like "ask spy about village", you might instead "ask about village" and allow all present mobiles a chance to respond.
3. We might design a slow, deliberative game in which the player is presented with ALL options in some sort of alpha-numeric selection mode. (i.e., select option 1 to go west; you go west; what would you like to do: 1 - go west, 2 - go east, 3 - attack the ugly goblin, 4 - talk to the ugly goblin...)
4. We might design an even more deliberative version of the same concept in which the player is making branched decisions in a choose-your-own-adventure sort of style. The player might be confronted with a choice between one of two skills, and rather than having points and agency to train the other later on, the skill they didn't choose might never be presented again.

# Deciding: mechanics, tedium and immersion

A useful discussion to have with yourself is probably: what sort of pace and scale do we want our game to have? You could ask questions about verbosity and linguistic purity, but I feel like these are values which must ultimately be in harmony with your primary decision about how your game will play. If your game will involve occasional combat with a sparse collection of NPCs I suspect it's very viable for you to have a descriptive selection system. If your game is a hack-and-slash where players kill hundreds of mobiles an hour, making them have to read and re-type properties frequently is going to either be tedious, or get shifted off onto triggers.

Part of the discussion surrounding this decision seems to be predicated on the idea that "get amulet 2" or "get 2nd amulet" is somehow breaking immersion with the intrusion metadata; I'd argue contrarily that being asked by the game's parser whether I meant the red amulet or the green amulet is a far more egregious attack on my suspension of disbelief than the former--it subverts my agency, reminds me of the ever-present role of the parser, and speaks with a disembodied voice. We live in a world where spatial decisions make sense. You don't stand before a police line-up and select the guy with beat-up Levi's, black hair and a porn-stache; you identify the suspect within space based on these very properties--but then you select an appropriate number along a logical scale from left to right to communicate quickly and clearly.

# Conclusion

Only two of the answers proposed actually resolve the root question: How does the game disambiguate between references to like objects if/when they occur? One of these is to demand clarification from the player after the request, and the other is to assume a logical spatial arrangement of some sort and assume the player doesn't need to clarify the ambiguity. There's a time and place for both of these, but there's a big difference between the two--and I think it probably behooves most text games to answer this question in the parser rather than by attempting to contrive a game in which two identical items will never be present and need referring to.

I'm obviously a fan of a numeric reference, but I think you can also combine a variety of the various ideas that have cropped up to sculpt the feel of your game. You can also leave these decisions up to the player, and provide them with the ability to choose between a parser that responds to ambiguous requests with a question, and a parser that executes ambiguous requests with an assumption. You can, for that matter, give players the option of generating a meta-data indicator for each item which they may use to refer to it.