Flavour adjectives for random monsters
Darren Grey
roguelikes is being surrounded by multiple of the same enemy and
getting spammed with messages like "The orc hits you. The orc misses
you. The orc misses you. The orc misses you. The orc winces in
pain. The orc hits you. The orc critically hits you. The orc picks
up the shining long sword. The orc misses you. The orc hits you."
It can be hard to keep track of what's going on, except maybe to get
an idea if you're being gangraped or laughing off the opposition.
It's hard to tell which orcs are more of a threat, how many attacks
each have, and what's happening with the specific orc you're
targetting (he might panic and run away and you can't find him again).
So, simple thought - give each enemy a random descriptive adjective.
Each monster type or each class of monsters would have its own set of
adjectives that could apply to it, and upon birth the enemy would be
randomly assigned one of these adjectives (it could be related to the
monster's stats somehow, but random does the job). For instance orcs
might have the set of adjectives "yellow-skinned, tall, burly, red-
eyed, hairy, smelly, fat, squat" etc. The combat messages above would
thus become:
"The burly orc hits you. The burly orc misses you. The tall orc
misses you. The yellow-skinned orc misses you. The red-eyed orc
misses you. The red-eyed orc winces in pain. The smelly orc hits
you. The smelly orc critically hits you. The fat orc picks up the
shining long sword. The hairy orc misses you. The hairy orc hits
you."
From this you can now see that the red-eyed orc can be quickly taken
down, the smelly orc is giving some trouble, and if you want that
sword then make sure fatty doesn't get away. Actually distinguishing
them on the map would require using the look command (or in a tiled
game the tiles could be linked in with the flavour adjectives to have
slightly different appearances).
Of course there'd still be some monsters generated with the same
adjectives, but it's only natural that it can be hard to distinguish
between some. For certain enemy classes such as demons or wizards
there may be a much bigger pool of adjectives (fiery, horned,
monstrous, bull-headed, grinning, leering, winged, etc). For others
like insectoids there would be a smaller pool to make them harder to
tell apart. For rarer monsters there would simply be no need.
I figured surely someone has thought of this before, but I've never
seen any roguelike that uses it.
--
Darren Grey
dominik...@gmail.com
A good idea, and seems fairly easy to implement. My way of making it
work would be this:
1. create an array of descriptive adjectives
2. in the monster description struct (or whatever one uses), put a
minimum and maximum adjective index that can be picked,
3. in the actual monster class, simply add an integer representing the
adjective's index number in the adjectives array (randomly picked
number between the max and min index numbers defined in the monster
description struct).
Easy to implement, great to have :), I just might decide to steal your
idea at a certain point, if you don't mind :).
Mingos.
Darren Grey
> A good idea, and seems fairly easy to implement. My way of making it
> work would be this:
> 1. create an array of descriptive adjectives
> 2. in the monster description struct (or whatever one uses), put a
> minimum and maximum adjective index that can be picked,
> 3. in the actual monster class, simply add an integer representing the
> adjective's index number in the adjectives array (randomly picked
> number between the max and min index numbers defined in the monster
> description struct).
One big array for all adjectives? I'd personally see that as being
hard to maintain - any time you want to add/remove/change elements of
the list you'll have to make sure that *every* monster class is
updated with new index values (lest you end up with hulking hobbits
and ginger gorgons). To me it seems more sensible to keep a separate
array for each monster type within the monster description struct, and
have a random pointer to it when building the monster object. The
downside to this is that you would likely have every adjective array
the same length for easy referencing, which would mean duplicating
entries for those with less adjectives and even having an array of all
blanks for monsters that need no adjective. However it's still far
easier to keep track of. Besides it would be a great effort of
imagination to come up with several hundred descriptive words for all
your monsters at once when typing out the array.
> Easy to implement, great to have :), I just might decide to steal your
> idea at a certain point, if you don't mind :).
You're more than welcome to :) I personally wish this feature could
be shoved into several games I play right now...
--
Darren Grey
Garrison Benson
example, you might see "Marine Larry", "Janitor Bob", or "Medical
Robot ER337". Obviously knowing the name of every NPC isn't
particularly realistic, but it's intuitive to the player and fits the
silly-ish tone of my game pretty well.
dominik...@gmail.com
> One big array for all adjectives? I'd personally see that as being
> hard to maintain - any time you want to add/remove/change elements of
> the list you'll have to make sure that *every* monster class is
> updated with new index values (lest you end up with hulking hobbits
> and ginger gorgons). To me it seems more sensible to keep a separate
> array for each monster type within the monster description struct, and
> have a random pointer to it when building the monster object. The
> downside to this is that you would likely have every adjective array
> the same length for easy referencing, which would mean duplicating
> entries for those with less adjectives and even having an array of all
> blanks for monsters that need no adjective. However it's still far
> easier to keep track of. Besides it would be a great effort of
> imagination to come up with several hundred descriptive words for all
> your monsters at once when typing out the array.
Err... Unless you plan in advance and need no further changes :).
You're right, of course, it's just my game has exactly 4 monster types
at the moment :).
I see you DO realise that having a set of adjectives for every monster
can be as troublesome as my system :). I was thinking rather of using
a general set of adjectives, say, for all huanoids, for all, uh, say,
lizards, insects, that sort of thing. For instance, if you have an
array like {"fat","slim","muscled","red-eyed","hairy","drooling"}, you
can use it for all kinds of orcs, goblins, hobgoblins, bugbears,
giants and so on. If you tweak the set to be a little bit more
general, you can extend it to MANY kinds of creatures.
Mingos.
Darren Grey
> I was thinking rather of using
> a general set of adjectives, say, for all huanoids, for all, uh, say,
> lizards, insects, that sort of thing. For instance, if you have an
> array like {"fat","slim","muscled","red-eyed","hairy","drooling"}, you
> can use it for all kinds of orcs, goblins, hobgoblins, bugbears,
> giants and so on. If you tweak the set to be a little bit more
> general, you can extend it to MANY kinds of creatures.
Ah, I see - that would indeed work very well, and cause less sameness
within specific monster classes. Another way to approach things might
be to try and group the adjectives by descriptive type. For instance
all size adjectives together, all facial descriptions together, all
hair descriptions together, and so on. Size would apply to
everything, facial would include humanoids, and hair might be for
selective PC-type humanoids. All depends on the monster variety
really...
--
Darren Grey
dominik...@gmail.com
Exactly, now we're talking :). I'll try to get this running ASAP to
test how it works in practice (with all four monsters I have
implemented, heh heh).
Mingos.
Timofei Shatrov
confuse everyone with this message:
>
>A good idea, and seems fairly easy to implement. My way of making it
>work would be this:
>1. create an array of descriptive adjectives
>2. in the monster description struct (or whatever one uses), put a
>minimum and maximum adjective index that can be picked,
>3. in the actual monster class, simply add an integer representing the
>adjective's index number in the adjectives array (randomly picked
>number between the max and min index numbers defined in the monster
>description struct).
>
Are you guys still in the mindset of writing 1k roguelikes?
Structs? Arrays? No one uses those in XXI century.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
dominik...@gmail.com
> Are you guys still in the mindset of writing 1k roguelikes?
> Structs? Arrays? No one uses those in XXI century.
Eh? My game's 400kB so far... And what do you use instead of an array?
Maybe you could kindly explain me what's used instead of these so I
can make my code a little bit more modern.
Mingos.
Darren Grey
> Are you guys still in the mindset of writing 1k roguelikes?
> Structs? Arrays? No one uses those in XXI century.
This is a *roguelike* newsgroup, yes? I'm not sure what else you mean
to use than arrays for a simple list of terms, but regardless there's
plenty of old style code bandying about here. 21st century be
damned ;)
--
Darren Grey
Timofei Shatrov
confuse everyone with this message:
Well, the simplest solution is to have a method/function that generates a random
adjective for each monster type, and when a monster is spawned you just set its
name property by concatenating its random adjective and its default name.
I think array is a rigid and low-level structure. Unless the code is
performance-critical, I'd encapsulate it somehow, so that only it's high level
function is exposed. For example, arrays could be used for a random selection
from a finite number of options. I'd create a class with 1 method which returns
a random element, and is initialized by a list of options. Its internal
implementation could in fact use array, but it doesn't matter. Every time you
create an object of this class, its purpose is absolutely clear.
Arrays do however have a place for spatial stuff like maps. Because in this
case, the indices of array are actually meaningful, unlike the previous example.
When taking a random element of array, the element's index is not really needed.
It could be a linked list, or a hash table or whatever. For a map a usage of
array is far more convincing.
Martin Read
>Structs? Arrays? No one uses those in XXI century.
Assertion failed.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
dominik...@gmail.com
> Well, the simplest solution is to have a method/function that generates a random
> adjective for each monster type, and when a monster is spawned you just set its
> name property by concatenating its random adjective and its default name.
"The hairy green slime attacks you. The tall mustard jelly attacks
you. You hit the drooling unicorn." Yes, very clever.
> I think array is a rigid and low-level structure.
Indeed. And very useful as well.
> Unless the code is
> performance-critical, I'd encapsulate it somehow, so that only it's high level
> function is exposed. For example, arrays could be used for a random selection
> from a finite number of options.
Don't tell me you use arrays after all! It's so old fashioned! You
said that!
> I'd create a class with 1 method which returns
> a random element, and is initialized by a list of options. Its internal
> implementation could in fact use array, but it doesn't matter. Every time you
> create an object of this class, its purpose is absolutely clear.
We're not talking about its purpose, which indeed is clear. We're
talking about how it works. And it uses an old fashioned array.
> Arrays do however have a place for spatial stuff like maps.
Aha!
> Because in this
> case, the indices of array are actually meaningful, unlike the previous example.
Of course, of course. An array of adjectives is meaningless, that's
cool. I guess it only has some meaning if you don't use garbage
collection, which is not your case.
> When taking a random element of array, the element's index is not really needed.
> It could be a linked list, or a hash table or whatever. For a map a usage of
> array is far more convincing.
OK, so you suggest a linked list of adjectives? You like taking the
long way around a problem, don't you? Sheesh!
Mingos.
Slash
> On Sep 1, 8:32 pm, g...@mail.ru (Timofei Shatrov) wrote:
>
> > Well, the simplest solution is to have a method/function that generates a random
> > adjective for each monster type, and when a monster is spawned you just set its
> > name property by concatenating its random adjective and its default name.
>
> "The hairy green slime attacks you. The tall mustard jelly attacks
> you. You hit the drooling unicorn." Yes, very clever.
>
> > I think array is a rigid and low-level structure.
>
> Indeed. And very useful as well.
>
> > When taking a random element of array, the element's index is not really needed.
> > It could be a linked list, or a hash table or whatever. For a map a usage of
> > array is far more convincing.
>
> OK, so you suggest a linked list of adjectives? You like taking the
> long way around a problem, don't you? Sheesh!
I think he is just talking one abstraction layer higher than you, both
will get to the same point over implementation...
I would however use a (unordered, mapped) set of any kind instead of
an array, because of well, you know, it is just a bag of unordered
items (unlike a roguelike map). There are collection frameworks for
about any language I think, so you would just put and get your
elements.
But, you know, implementations of Sets commonly store their elements
in (guess what) arrays!
So stop fighting around it and get developing your games! :D
--
Slashie
dominik...@gmail.com
Yes Sir!
Mingos
Xecutor
> seen any roguelike that uses it.
Actually there are two ways to identify monster from action in log.
First - thru descriptive adjective.
Second - it is possible to select entry in the game messages log,
and source of action will be highlighted on the map.
Soyweiser
> Second - it is possible to select entry in the game messages log,
> and source of action will be highlighted on the map.
This looks like a very nifty thing to do. Would really improve the
usability of the logs. More logs need this. I'll add it to the list of
things I would like to do someday :).
--
Soyweiser
jot...@hotmail.com
Alright, so which direction is the burly orc so I can hit it? :)
This is a great idea, but while we're at it there should be something
to connect the descriptions of the creatures to their representation
on the map. Some ideas: adding "to your left" and such to the
description, a simple arrow surrounded by brackets in front of the
name, or printing the name in a distinguishable color which is also
used on the map (true color RLs would benefit the most from this, as
orcs could all be different shades of green/yellowish-green).
That would do it too, except it adds just a bit more of a hassle for
the player.
Jotaf
Darren Grey
> Alright, so which direction is the burly orc so I can hit it? :)
> This is a great idea, but while we're at it there should be something
> to connect the descriptions of the creatures to their representation
> on the map. Some ideas: adding "to your left" and such to the
> description, a simple arrow surrounded by brackets in front of the
> name, or printing the name in a distinguishable color which is also
> used on the map (true color RLs would benefit the most from this, as
> orcs could all be different shades of green/yellowish-green).
The problem with added direction text would be that in 80-90% of
battles it would be superfluous, since there'd only be one orc
attacking you. It's hard to write in such a way as to look like
natural combat description (since how is that your back when you just
moved in that direction?) It would work extremely well in the case of
a game which gives the character a facing based on their last command,
and this facing affects combat significantly. You would be getting
messages like "The burly orc strikes your left flank. The tall orc
hacks at your back and misses you." In such a case the directions are
far more vital.
--
Darren Grey
Xecutor
> battles it would be superfluous, since there'd only be one orc
battle.
Since my rl have graphical backend, I have
floating text with damage type and amount,
and some primitive attack direction visuals.
Message log feature was added for the case if missed turn animations.
jot...@hotmail.com
> I forgot about 3rd way to understand what's going on in a tight
> battle.
> Since my rl have graphical backend, I have
> floating text with damage type and amount,
> and some primitive attack direction visuals.
> Message log feature was added for the case if missed turn animations.
That kind of visuals makes it easy to take information at a glance,
but they can't replace a detailed message log. Anyways given the
availability of true colors, I'll probably chose a different color for
each creature, by blending 2 base colors with a random alpha value
(for the orcs, these would be 2 shades of green). The message log will
use the same color when displaying a creature's name.
> > The problem with added direction text would be that in 80-90% of
> > battles it would be superfluous, since there'd only be one orc
Easy enough: only show direction text when there's more than one enemy
around.
About direction text seeming a bit awkward, instead of "the orc in
front of you", you can use absolute directions: "the orc to the left",
"the orc to the right", "the orc below", "the orc above". Even the
other 4 combinations if you want, such as "above and to the left". If
you wanna be really extreme prefix these with "far" or "near".
Anyways, just 4 directions should be enough :)
Jotaf
gize...@gmail.com
> About direction text seeming a bit awkward, instead of "the orc in
> front of you", you can use absolute directions: "the orc to the left",
> "the orc to the right", "the orc below", "the orc above". Even the
> other 4 combinations if you want, such as "above and to the left". If
> you wanna be really extreme prefix these with "far" or "near".
> Anyways, just 4 directions should be enough :)
Surely using the compass directions would be scan more naturally?