Distinction between PC and Monster

Archived from groups: rec.games.roguelike.development (More info?)

Recently, a discussion about the random/non-random combat made me think
about how differently game mechanics affects gameplay when applied to PC
and to monsters.

There seem to be a tendency to make the PC "just another monster", the
only difference being his AI replaced with UI. It generally makes many
things simplier and looks pretty nice.

But it might be actually making some gameplay-related stuff harder. You
expect different things from PC-related mechanics than from
monster-related.

Insta-death may be used as an example -- while insta-dying player
characters are pretty annoying and generally viewed as bad, there's
nothing bad about insta-dying monsters -- often it even gives a feeling
of satisfaction.

It's similar with many other aspects of game mechanics -- these objects
have similar interactions with their environment, but are really
different. They've got different lifetime, need different attention,
different detail leven and granularity, etc.

It's obviously possible to realize the requirements of both kinds of
object in one implementation, but it seems to whole lot of work.

Just my thoughts.

--
Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
`The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
40 answers Last reply
More about distinction monster
  1. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Recently, a discussion about the random/non-random combat made me think
    > about how differently game mechanics affects gameplay when applied to PC
    > and to monsters.
    >
    > There seem to be a tendency to make the PC "just another monster", the
    > only difference being his AI replaced with UI. It generally makes many
    > things simplier and looks pretty nice.
    >
    > But it might be actually making some gameplay-related stuff harder. You
    > expect different things from PC-related mechanics than from
    > monster-related.
    >
    > Insta-death may be used as an example -- while insta-dying player
    > characters are pretty annoying and generally viewed as bad, there's
    > nothing bad about insta-dying monsters -- often it even gives a feeling
    > of satisfaction.
    >
    > It's similar with many other aspects of game mechanics -- these objects
    > have similar interactions with their environment, but are really
    > different. They've got different lifetime, need different attention,
    > different detail leven and granularity, etc.
    >
    > It's obviously possible to realize the requirements of both kinds of
    > object in one implementation, but it seems to whole lot of work.
    >
    > Just my thoughts.

    I agree with you on this one. I was originally going to derive both
    monsters and PCs from the same generic Creature class. Finally I
    scrapped that, and coded two completely different and individual
    classes. It's made my project run much more smoothly, and allows me
    to allow monsters to have different abilities from players, without
    any kludgey fixes, or roundabout generalized OO Design.


    --
    "There are of course many problems connected with life, of
    which some of the most popular are `Why are people born?'
    `Why do they die?' `Why do they spend so much of the
    intervening time wearing digital watches?'"

    -- The Book.
  2. Archived from groups: rec.games.roguelike.development (More info?)

    Risto Saarelma wrote:
    > On 2005-04-19, Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    > > I agree with you on this one. I was originally going to derive
    both
    > > monsters and PCs from the same generic Creature class. Finally I
    > > scrapped that, and coded two completely different and individual
    > > classes. It's made my project run much more smoothly, and allows
    me
    > > to allow monsters to have different abilities from players, without

    > > any kludgey fixes, or roundabout generalized OO Design.
    >
    > The problem with having the PC completely off the Creature class is
    that
    > you're then committing to having the player's view attached to that
    > single character. Guild and You Only Live Once are two interesting
    > recent roguelikes where the player's identity isn't that clearly
    fixed.
    > Instead, there are creatures that are at times npcs and at other
    times
    > under player control.
    >
    > In YOLO, the npc versions of the playable characters are very
    passive,
    > so that sort of a game can get away with a kludgy system. But in
    Guild,
    > the characters can quickly switch from being computer controlled npcs
    to
    > being the PC.
    >
    > Having different rules for player characters and monsters is
    sensible.
    > But I'm not sure whether it's a good idea to make the game assume
    that
    > the view is always centered on and player input is always sent to the
    > same character. I like Guild's idea of having a group of characters
    and
    > being able to switch between them, with the characters behaving like
    > npcs when they aren't under player control. Kludges with the special
    > player data structure being copied with the values of the npc the
    player
    > switches to wouldn't be useful, since you'd want all of the player
    > controllable characters to follow the player rules, and not become
    > instakillable wretches when the player stops controlling them.
    >
    > So maybe you should have a shared Creature base class for both PCs
    and
    > monsters, and you'd control the creature through this base. But PC
    and
    > Monster subclasses would have different rules attached to them.

    Coding Guild, I considered the idea of having a single base class for
    both characters and monsters, but rightly or wrongly, rejected it. Most
    of their behaviours are coded entirely separately. Things like fighting
    and movement are implemented in separate functions for characters and
    monsters.

    On the other hand, both characters and monsters have 'AI' objects that
    function fairly similarly. One key difference between the PC and the
    NPC is that this AI is 'switched off' and replaced with keyboard input.


    It might be worth mentioning that I don't even HAVE a data structure
    for a single character. Rather, I have a data structure for the entire
    party. It contains a vector of names, a vector of HPs, etc, etc. This
    was convenient for various reasons. (In fact I have another data
    structure again for the list of characters 'back at base' - when a
    group of characters go to the dungeon, they get loaded from the latter
    into the former.)

    A.

    P.S. I'm doing a big release soon; the game is already ready to roll,
    but I wanted to wait until after I go on vacation in May - so early
    June hopefully.
  3. Archived from groups: rec.games.roguelike.development (More info?)

    On 2005-04-19, Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    > I agree with you on this one. I was originally going to derive both
    > monsters and PCs from the same generic Creature class. Finally I
    > scrapped that, and coded two completely different and individual
    > classes. It's made my project run much more smoothly, and allows me
    > to allow monsters to have different abilities from players, without
    > any kludgey fixes, or roundabout generalized OO Design.

    The problem with having the PC completely off the Creature class is that
    you're then committing to having the player's view attached to that
    single character. Guild and You Only Live Once are two interesting
    recent roguelikes where the player's identity isn't that clearly fixed.
    Instead, there are creatures that are at times npcs and at other times
    under player control.

    In YOLO, the npc versions of the playable characters are very passive,
    so that sort of a game can get away with a kludgy system. But in Guild,
    the characters can quickly switch from being computer controlled npcs to
    being the PC.

    Having different rules for player characters and monsters is sensible.
    But I'm not sure whether it's a good idea to make the game assume that
    the view is always centered on and player input is always sent to the
    same character. I like Guild's idea of having a group of characters and
    being able to switch between them, with the characters behaving like
    npcs when they aren't under player control. Kludges with the special
    player data structure being copied with the values of the npc the player
    switches to wouldn't be useful, since you'd want all of the player
    controllable characters to follow the player rules, and not become
    instakillable wretches when the player stops controlling them.

    So maybe you should have a shared Creature base class for both PCs and
    monsters, and you'd control the creature through this base. But PC and
    Monster subclasses would have different rules attached to them.

    --
    Risto Saarelma
  4. Archived from groups: rec.games.roguelike.development (More info?)

    Timothy Pruett wrote:
    > scrapped that, and coded two completely different and individual
    > classes. It's made my project run much more smoothly, and allows me
    > to allow monsters to have different abilities from players, without
    > any kludgey fixes, or roundabout generalized OO Design.

    In early stage of my project I had separate code for the player,
    but I soon found out that it was clumsy and required two sets of
    routines for almost everything. Now I have shared class and routines,
    PC is just another creature object. Of course some things are
    different and some routines are only for the player, because NPC's
    will never use them. I think it's better to have characters
    use the same code as much as possible. I find it clumsy if there
    are two sets of code for the same task. It will double the effort
    and also double the possible bugs.
  5. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Recently, a discussion about the random/non-random combat made me
    think
    > about how differently game mechanics affects gameplay when applied to
    PC
    > and to monsters.
    >
    > There seem to be a tendency to make the PC "just another monster",
    the
    > only difference being his AI replaced with UI. It generally makes
    many
    > things simplier and looks pretty nice.

    I should point out the majority of well known roguelikes do *not* just
    make the pc another monster. The ones that do are in the minority.

    Further, I would note that many of those usually talk about having an
    Player object derive from the Creature object, which, IMHO, is making
    the PC too special.

    > But it might be actually making some gameplay-related stuff harder.
    You
    > expect different things from PC-related mechanics than from
    > monster-related.
    >
    > Insta-death may be used as an example -- while insta-dying player
    > characters are pretty annoying and generally viewed as bad, there's
    > nothing bad about insta-dying monsters -- often it even gives a
    feeling
    > of satisfaction.

    I would list those things as exceptions. If you are trying to build a
    consistent world (like I do), you want to minimize exceptions.

    I would rather have this:

    doFooAttack(MOB *mob)
    {
    if (mob->isAvatar())
    // take damage
    else
    // Insta death for critters
    }

    than this:

    doFooAttackOnAvatar(MOB *mob)
    {
    take damage
    }

    doFooAttackOnCreature(MOB *mob)
    {
    Insta death.
    }

    Having the insta-death and non-insta-death code paths as close together
    as possible means that we will be reminded that the two choices exist.

    > It's similar with many other aspects of game mechanics -- these
    objects
    > have similar interactions with their environment, but are really
    > different. They've got different lifetime, need different attention,
    > different detail leven and granularity, etc.

    Most of those issues are only important if you have space or
    computational constraints. Unless you are working in Flash or
    targetting the Gameboy Advance, we don't really have these.

    For example, I decided that piety would only be calculated for the
    avatar (the pc). This is primarily a space savings - a dozen bytes per
    mob adds up. Note, however, that it would have been even less code to
    track piety for mobs as well as the avatar than it is to only track it
    for the avatar.

    The other way in which one may want to break symmetry is with skills.
    I decided that only the avatar needs to have weapon & armour skills.
    All creatures are assumed to have one rank in all weapons & armours.
    This is not for any coding reason (again, it is more difficult to break
    symmetry than keep it) but is to simplify data entry. I didn't want to
    have to add token weapon skills to all the creatures that can wield
    weapons.

    > It's obviously possible to realize the requirements of both kinds of
    > object in one implementation, but it seems to whole lot of work.

    Well, I'm allergic to multiple code paths. So, when I see "uhitmons"
    and "monshitu" I start getting all twitchy (sorry Martin!) In some
    ways, I have definitely bought myself a lot of extra work. For one, I
    have to properly conjugate all those verbs.

    I really believe it is beneficial to have an "action" layer for your
    creatures. This is the interfaces that causes a monster to do
    something.

    For example,
    MOB::actionAttack(int dx, int dy)
    would cause the monster to attack in the direction (dx, dy).
    MOB::actionWalk(int dx, int dy)
    would cause the monster to attempt to walk in the direction (dx, dy).
    MOB::actionBump(int dx, int dy)
    would cause the monster to move in (dx, dy) with DWIM turned on. It
    would then open doors, attack hostiles, swap with peacefuls, etc.

    By only allowing the player to act through this layer, and only letting
    the AI act through this layer, we can ensure the monsters can do
    everything the player can and vice versa.

    If you want to see an example of how I think this should work, you can
    check the source code for You Only Live Once:
    http://www.zincland.com/7drl/liveonce.

    Most cases I can think of differing gameplay has more to do with
    differing attributs. Mind you, I don't allow insta-stoning of monsters
    - they get the same delay as the player. (I think this is something
    Nethack could use for balancing...)
    --
    Jeff Lait
    (POWDER: http://www.zincland.com/powder)
  6. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia 20 Apr 2005 03:15:50 -0700,
    Krice napisal(a):

    > Timothy Pruett wrote:
    >> scrapped that, and coded two completely different and individual
    >> classes. It's made my project run much more smoothly, and allows me
    >> to allow monsters to have different abilities from players, without
    >> any kludgey fixes, or roundabout generalized OO Design.

    > In early stage of my project I had separate code for the player,
    > but I soon found out that it was clumsy and required two sets of
    > routines for almost everything. Now I have shared class and routines,
    > PC is just another creature object. Of course some things are
    > different and some routines are only for the player, because NPC's
    > will never use them. I think it's better to have characters
    > use the same code as much as possible. I find it clumsy if there
    > are two sets of code for the same task. It will double the effort
    > and also double the possible bugs.

    I originally meaned the game mechanics, not the internal class structure.

    Most obviously, you'll want the monster and creature classes share the same
    interface, as they are subject to the same events. Most of the time.
    You can expand the interfaces (for example using inheritance) to include
    cases when mosnter and player character have special events.

    But sharing the interface doesn't mean you have to share the functions.
    Offcourse, if the code is the same -- you should share it.

    The point is the code doesn;t have to be the same, and it's sometimes good
    when it isn't.

    Z-Day is written rather clumsily and there code is repeated in many cases.
    But the player character has totally different health and wound system
    than zombies -- the rules to determine whether you're wounded when hit,
    the wound effects, etc. are totally different -- and I think it doesgood
    in this case.

    Offcourse, you can achieve the same effect by adding a lot of flags,
    attributes, etc. and writing a generic code to handle them. But it's a lot
    more work for the same effect.

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  7. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > . Of course some things are
    > different and some routines are only for the player, because NPC's
    > will never use them.

    I'd love to see the player's face when they read:

    "The wizard of Yendor exits the game without saving!"

    and get bumped back to the prompt.

    Bear
  8. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > The Sheep wrote:
    >
    > > Recently, a discussion about the random/non-random combat
    > > made me think about how differently game mechanics affects
    > > gameplay when applied to PC and to monsters.
    > >
    > > There seem to be a tendency to make the PC "just another
    > > monster", the only difference being his AI replaced with
    > > UI. It generally makes many things simplier and looks
    > > pretty nice.
    > >
    > > But it might be actually making some gameplay-related stuff
    > > harder. You expect different things from PC-related
    > > mechanics than from monster-related.
    > >
    > > Insta-death may be used as an example -- while insta-dying
    > > player characters are pretty annoying and generally viewed
    > > as bad, there's nothing bad about insta-dying monsters --
    > > often it even gives a feeling of satisfaction.
    > >
    > > It's similar with many other aspects of game mechanics --
    > > these objects have similar interactions with their
    > > environment, but are really different. They've got different
    > > lifetime, need different attention, different detail level
    > > and granularity, etc.
    > >
    > > It's obviously possible to realize the requirements of both
    > > kinds of object in one implementation, but it seems to whole
    > > lot of work.
    > >
    > > Just my thoughts.
    >
    > In the RL that I'm developing, I'm currently writing a lot of the
    creature
    > AI. The current puzzle that I'm investigating has to do with
    creature map
    > knowledge.
    >
    > There is one 'main' map object which maintains all map data for the
    game.
    > However, due to effects such as fog of war, the PC doesn't have
    immediate
    > knowledge of the entire map. Nor does the PC have immediate and
    current
    > knowledge of any part of the map outside of the FOV. So the PC would
    > require a seperate copy of the map which maintains information
    regarding
    > where the player has explored and what the player remembers.

    They don't need an entire copy of the map: just a small data structure
    saying what parts of the map they know. For example, a list of explored
    points.

    > One possible design that would simplify that situation is that all
    monsters
    > and NPCs use the main map object as their map knowledge, and when AI
    is used
    > to determine travel behaviors, map knowledge is simply not used as a
    > determining factor.

    Yes, I use this shortcut. I figure that monsters live in the dungeon so
    they should already know the layout of the entire level and be able to
    navigate accordingly.

    > Of course, monsters and NPCs might have knowledge of other things,
    like
    > remembering where the player was last, if the player isn't in the
    > monster's/NPC's FOV, if the player has even been encountered.

    Yes. Store this sort of thing in the monster's AI, it will come in
    useful. For example if a monster sees the player and then loses sight
    of them, they might want to move towards the space where they were last
    seen (or launch an area-effect attack into that space!). And so on.

    > Otherwise, if
    > creatures inherently know the location of the player, as that info
    might be
    > contained in the main map object, then that creates the possibility
    of a
    > hoard of attacking creatures making a journey from all corners of the
    map to
    > the player's location!

    Which you may or may not want. It would give a good arcade-game feel,
    keep the pressure up. However, more likely you want the monsters to
    only know where the PC is if they have some means of sensing them -
    sight, hearing, smell, ESP, etc.

    A.

    P.S. You seem to be approaching the design from the point of view of
    'what are my data structures and how should they fit together?' and
    then figuring out how that will impact the gameplay. You may be better
    off doing it the other way around. Figure out how you want the gameplay
    to work, and then you should be able to decide on the appropriate data
    structures and implement them...
  9. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > The Sheep wrote:
    >
    > > Recently, a discussion about the random/non-random combat
    > > made me think about how differently game mechanics affects
    > > gameplay when applied to PC and to monsters.
    > >
    > > There seem to be a tendency to make the PC "just another
    > > monster", the only difference being his AI replaced with
    > > UI. It generally makes many things simplier and looks
    > > pretty nice.
    > >
    > > But it might be actually making some gameplay-related stuff
    > > harder. You expect different things from PC-related
    > > mechanics than from monster-related.
    > >
    > > Insta-death may be used as an example -- while insta-dying
    > > player characters are pretty annoying and generally viewed
    > > as bad, there's nothing bad about insta-dying monsters --
    > > often it even gives a feeling of satisfaction.
    > >
    > > It's similar with many other aspects of game mechanics --
    > > these objects have similar interactions with their
    > > environment, but are really different. They've got different
    > > lifetime, need different attention, different detail level
    > > and granularity, etc.
    > >
    > > It's obviously possible to realize the requirements of both
    > > kinds of object in one implementation, but it seems to whole
    > > lot of work.
    > >
    > > Just my thoughts.
    >
    > In the RL that I'm developing, I'm currently writing a lot of the
    creature
    > AI. The current puzzle that I'm investigating has to do with
    creature map
    > knowledge.
    >
    > There is one 'main' map object which maintains all map data for the
    game.
    > However, due to effects such as fog of war, the PC doesn't have
    immediate
    > knowledge of the entire map. Nor does the PC have immediate and
    current
    > knowledge of any part of the map outside of the FOV. So the PC would
    > require a seperate copy of the map which maintains information
    regarding
    > where the player has explored and what the player remembers.

    I don't know what you mean about "separate copy of the map". The PC
    merely needs to track what tiles he has seen. This can be done in two
    ways: The PC can maintain a list of viewed tiles, or the Map can
    maintain a list of tiles viewed by the PC.

    If you have a standard WxH grid of tiles, both cases can be represented
    by a WxH array of flags.

    > If monsters, NPCs, and players are all 'creatures', with the only
    difference
    > being that AI controls monsters and NPCs, and UI controls the player,
    then
    > that would mean that every monster and NPC maintains some sort of
    knowledge
    > of the map, similarly to the player. That design could be very
    problematic
    > and require a lot of space, and might not be recommended.
    >
    > One possible design that would simplify that situation is that all
    monsters
    > and NPCs use the main map object as their map knowledge, and when AI
    is used
    > to determine travel behaviors, map knowledge is simply not used as a
    > determining factor.

    While forcing the creatures to explore the map does have a certain
    allure for its symmetry, I also think it rather odd that the creatures
    who live there don't know their own homes.

    If we assume only the PC needs to explore, it becomes clear we don't
    store the explore information with the PC. Instead, we can store as a
    property of each tile in the map whether it has been seen by the PC.

    > Of course, monsters and NPCs might have knowledge of other things,
    like
    > remembering where the player was last, if the player isn't in the
    > monster's/NPC's FOV, if the player has even been encountered.
    Otherwise, if
    > creatures inherently know the location of the player, as that info
    might be
    > contained in the main map object, then that creates the possibility
    of a
    > hoard of attacking creatures making a journey from all corners of the
    map to
    > the player's location!

    The last seen location of the player can be stored with each monster.
    The map itself can store whether each tile is inside the players view
    or not. We can then determine if a monster can see the player by
    checking the FOV flag rather than doing an explicit LOS test.

    The big advantage of doing it this way is you avoid the risk of
    asymmetrical AI. Apparently, some Bands suffer from the problem that
    players can set up situations where they can see and target the
    monster, but the monster cannot see or target them.

    For example, in the Charge AI for You Only Live Once
    (http://www.zincland.com/7drl/liveonce):

    // If we can see avatar, charge at them! Otherwise, move
    // to our target if set. Otherwise random walk.
    if (getMap()->isFOV(getX(), getY()))
    {
    MOB *a;
    a = MOB::getAvatar();
    if (a)
    {
    myTX = a->getX();
    myTY = a->getY();
    }
    }
    if (myTX >= 0)
    {
    // Charge to last known location. If there, abandon
    // the search.
    if (myTX == getX() && myTY == getY())
    myTX = -1;
    else
    {
    if (aiMoveTo(myTX, myTY))
    return true;
    }
    }
    // Default to wandering
    return aiRandomWalk();

    myTX & myTY here refer to the last-known location of the player. myTX
    starts negative for not knowing where the player is. getMap() returns
    the map for the level which the creature is on. isFOV(x, y) returns
    true if (x,y) is has the Field of View flag set.

    I could have instead done:
    if (getMap()->hasLOS(getX(), getY(), getAvatar()->getX(),
    getAvatar()->getY()))
    to see if there is a line of sight. Indeed, in POWDER I actually check
    if either argument to hasLOS is the avatars position and then use the
    FOV map if it is.
    --
    Jeff Lait
    (POWDER: http://www.zincland.com/powder)
  10. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:

    > Recently, a discussion about the random/non-random combat
    > made me think about how differently game mechanics affects
    > gameplay when applied to PC and to monsters.
    >
    > There seem to be a tendency to make the PC "just another
    > monster", the only difference being his AI replaced with
    > UI. It generally makes many things simplier and looks
    > pretty nice.
    >
    > But it might be actually making some gameplay-related stuff
    > harder. You expect different things from PC-related
    > mechanics than from monster-related.
    >
    > Insta-death may be used as an example -- while insta-dying
    > player characters are pretty annoying and generally viewed
    > as bad, there's nothing bad about insta-dying monsters --
    > often it even gives a feeling of satisfaction.
    >
    > It's similar with many other aspects of game mechanics --
    > these objects have similar interactions with their
    > environment, but are really different. They've got different
    > lifetime, need different attention, different detail level
    > and granularity, etc.
    >
    > It's obviously possible to realize the requirements of both
    > kinds of object in one implementation, but it seems to whole
    > lot of work.
    >
    > Just my thoughts.

    In the RL that I'm developing, I'm currently writing a lot of the creature
    AI. The current puzzle that I'm investigating has to do with creature map
    knowledge.

    There is one 'main' map object which maintains all map data for the game.
    However, due to effects such as fog of war, the PC doesn't have immediate
    knowledge of the entire map. Nor does the PC have immediate and current
    knowledge of any part of the map outside of the FOV. So the PC would
    require a seperate copy of the map which maintains information regarding
    where the player has explored and what the player remembers.

    If monsters, NPCs, and players are all 'creatures', with the only difference
    being that AI controls monsters and NPCs, and UI controls the player, then
    that would mean that every monster and NPC maintains some sort of knowledge
    of the map, similarly to the player. That design could be very problematic
    and require a lot of space, and might not be recommended.

    One possible design that would simplify that situation is that all monsters
    and NPCs use the main map object as their map knowledge, and when AI is used
    to determine travel behaviors, map knowledge is simply not used as a
    determining factor.

    Of course, monsters and NPCs might have knowledge of other things, like
    remembering where the player was last, if the player isn't in the
    monster's/NPC's FOV, if the player has even been encountered. Otherwise, if
    creatures inherently know the location of the player, as that info might be
    contained in the main map object, then that creates the possibility of a
    hoard of attacking creatures making a journey from all corners of the map to
    the player's location!

    There are other possible problems and/or nifty designs that might arise
    depending on how I choose to model players, monsters, NPCs, etc.

    Any suggestions on how I might approach the previously described situation?


    crichmon
  11. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Thu, 21 Apr 2005 06:41:50 GMT,
    crichmon napisal(a):

    > The Sheep wrote:
    > Any suggestions on how I might approach the previously described situation?

    I'd move tho FOV entirely to AI/UI.
    It's up to AI to decide which parts of the map are visible.
    Similarily, it's up to UI code to display only a fragment of map to the
    player.

    This way it's fast, there are no unneeded fov calculations, etc.

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  12. Archived from groups: rec.games.roguelike.development (More info?)

    Ray Dillinger wrote:

    > I'd love to see the player's face when they read:
    >
    > "The wizard of Yendor exits the game without saving!"
    >
    > and get bumped back to the prompt.

    Instead of exiting, open up a sub-shell. After the player is finished
    cursing, and logs out of the sub-shell, they see a message of "You shake
    your head and dispel the Wizard's illusion, and realize that it was his
    last - he is dead. You have won!"

    sherm--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
    Hire me! My resume: http://www.dot-app.org
  13. Archived from groups: rec.games.roguelike.development (More info?)

    On Thu, 21 Apr 2005 01:16:31 -0700, Jeff Lait wrote:
    > crichmon wrote:
    >> In the RL that I'm developing, I'm currently writing a lot of the creature
    >> AI. The current puzzle that I'm investigating has to do with creature map
    >> knowledge.
    >>
    >> There is one 'main' map object which maintains all map data for the game.
    >> However, due to effects such as fog of war, the PC doesn't have immediate
    >> knowledge of the entire map. Nor does the PC have immediate and current
    >> knowledge of any part of the map outside of the FOV. So the PC would
    >> require a seperate copy of the map which maintains information regarding
    >> where the player has explored and what the player remembers.
    >
    > I don't know what you mean about "separate copy of the map". The PC

    I think he means to store the visible map with items in it. And if some
    item changes location when it's not in PC's (or NPC's) FOV, the map
    information is not updated instantly, instead the map information (== the
    separate copy of map) is updated when the (N)PC sees that mapgrid again.
    Nethack does this at least for the player. I guess some of the reasons to
    do it this way is to show player items the character has seen and
    "remembers" (instead of player self having to remember them) and to
    help making AI more, may I say=), realistic (like: some orc is wounded bad
    and starts to flee, since the orc remembers seeing a healing potion few
    rooms to the west, it heads that way, but the evil player had made a trap
    there to which the orc falls).

    Saving this information is only about one byte per mapgrid.. for
    example a map size of 100x100, that makes 10000 bytes per (N)PC, and
    with 500 (N)PC's per map level, that makes 5000000 bytes per map level,
    which is less than 5 megabytes. Depending on your target platform, that
    may, or may not be a lot. IMHO when making a game for todays computers, it
    is not something to worry about, and if it becomes a problem, optimize it
    then (compress, use less bits per mapgrid, store only differences etc.).


    Regards,

    --
    joni
  14. Archived from groups: rec.games.roguelike.development (More info?)

    In article <RbudnaDBv-8Ss_jfRVn-tg@adelphia.com>,
    drakalor.tourist@gmail.com says...
    > The Sheep wrote:

    > > It's obviously possible to realize the requirements of both kinds of
    > > object in one implementation, but it seems to whole lot of work.

    > I agree with you on this one. I was originally going to derive both
    > monsters and PCs from the same generic Creature class. Finally I
    > scrapped that, and coded two completely different and individual
    > classes. It's made my project run much more smoothly, and allows me
    > to allow monsters to have different abilities from players, without
    > any kludgey fixes, or roundabout generalized OO Design.

    I think it might be good to have a base class that supports a certain
    amount of aggregation, like the StoningBehaviour I was talking about on
    another thread. It would be good if a StoningBehaviour object could be
    attached to a monster or a player. But the Monster and Player classes
    don't have to have very much in common to support an interface for this
    kind of thing.

    - Gerry Quinn
  15. Archived from groups: rec.games.roguelike.development (More info?)

    In article <D2v9e.15358$m31.144528@typhoon.sonic.net>, bear@sonic.net
    says...
    > Krice wrote:
    > > . Of course some things are
    > > different and some routines are only for the player, because NPC's
    > > will never use them.
    >
    > I'd love to see the player's face when they read:
    >
    > "The wizard of Yendor exits the game without saving!"
    >
    > and get bumped back to the prompt.

    Or:

    => The wizard dies.
    => The wizard reloads a saved game [map changes to just before you
    => spotted the wizard]
    => A bolt of lightning strikes you [more]
    => A bolt of lightning strikes you [more]
    => You are dead
    => The wizard has won again!
    => Play another game(y/n)

    - Gerry Quinn
  16. Archived from groups: rec.games.roguelike.development (More info?)

    In article <OWH9e.10883$go4.3035@newsread2.news.atl.earthlink.net>,
    crichmon@gmail.com says...

    > There is one 'main' map object which maintains all map data for the game.
    > However, due to effects such as fog of war, the PC doesn't have immediate
    > knowledge of the entire map. Nor does the PC have immediate and current
    > knowledge of any part of the map outside of the FOV. So the PC would
    > require a seperate copy of the map which maintains information regarding
    > where the player has explored and what the player remembers.
    >
    > If monsters, NPCs, and players are all 'creatures', with the only difference
    > being that AI controls monsters and NPCs, and UI controls the player, then
    > that would mean that every monster and NPC maintains some sort of knowledge
    > of the map, similarly to the player. That design could be very problematic
    > and require a lot of space, and might not be recommended.
    >
    > Any suggestions on how I might approach the previously described situation?

    Unless you are doing an AI research project, fake it. All the monster
    AIs can have const access to the real map.

    - Gerry Quinn
  17. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    *SNIP*
    > In the RL that I'm developing, I'm currently writing a lot of the creature
    > AI. The current puzzle that I'm investigating has to do with creature map
    > knowledge.
    *SNIP*

    What about the way CounterStrike bots are
    taught maps?

    --
    ABCGi ---- (abcgi@yahoo.com) ---- http://codemonkey.sunsite.dk
    Neo?TwistedOne?PaulDerbyshire?Neodymium?Kydaimon?Twisted medals
    - haha: 2 ignored: 1D wrong: B troll: 2E SAD: 5 ontopic: 2 -
    - SNR = 3h + 1o / .5i + 1w + 5t + 1S = 8 / 4C = 0.10 was 0.02 -
  18. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > "Antoine" <mail@guildgame.com> wrote:
    > > crichmon wrote:
    > >> The Sheep wrote:
    > >>
    > >>> Recently, a discussion about the random/non-random
    > >>> combat made me think about how differently game
    > >>> mechanics affects gameplay when applied to PC and
    > >>> to monsters.
    > >>>
    > >>> There seem to be a tendency to make the PC "just
    > >>> another monster", the only difference being his AI
    > >>> replaced with UI. It generally makes many things
    > >>> simplier and looks pretty nice.
    > >>>
    > >>> But it might be actually making some gameplay-
    > >>> related stuff harder. You expect different things
    > >>> from PC-related mechanics than from monster-related.
    > >>
    > >> In the RL that I'm developing, I'm currently writing
    > >> a lot of the creature AI. The current puzzle that I'm
    > >> investigating has to do with creature map knowledge.
    > >>
    > >> There is one 'main' map object which maintains all map
    > >> data for the game. However, due to effects such as fog
    > >> of war, the PC doesn't have immediate knowledge of the
    > >> entire map. Nor does the PC have immediate and current
    > >> knowledge of any part of the map outside of the FOV.
    > >> So the PC would require a seperate copy of the map which
    > >> maintains information regarding where the player has
    > >> explored and what the player remembers.
    > >
    > > They don't need an entire copy of the map: just a small
    > > data structure saying what parts of the map they know.
    > > For example, a list of explored points.
    >
    > Booleans for every point in the map grid?

    You could do that... I just store a vector<point> (working in C++).

    A.
  19. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    > "Antoine" <mail@guildgame.com> wrote:
    > > crichmon wrote:
    > >> The Sheep wrote:
    > >>
    > >>> Recently, a discussion about the random/non-random
    > >>> combat made me think about how differently game
    > >>> mechanics affects gameplay when applied to PC and
    > >>> to monsters.
    > >>>
    > >>> There seem to be a tendency to make the PC "just
    > >>> another monster", the only difference being his AI
    > >>> replaced with UI. It generally makes many things
    > >>> simplier and looks pretty nice.
    > >>>
    > >>> But it might be actually making some gameplay-
    > >>> related stuff harder. You expect different things
    > >>> from PC-related mechanics than from monster-related.
    > >>
    > >> In the RL that I'm developing, I'm currently writing
    > >> a lot of the creature AI. The current puzzle that I'm
    > >> investigating has to do with creature map knowledge.
    > >>
    > >> There is one 'main' map object which maintains all map
    > >> data for the game. However, due to effects such as fog
    > >> of war, the PC doesn't have immediate knowledge of the
    > >> entire map. Nor does the PC have immediate and current
    > >> knowledge of any part of the map outside of the FOV.
    > >> So the PC would require a seperate copy of the map which
    > >> maintains information regarding where the player has
    > >> explored and what the player remembers.
    > >
    > > They don't need an entire copy of the map: just a small
    > > data structure saying what parts of the map they know.
    > > For example, a list of explored points.
    >
    > Booleans for every point in the map grid?

    That would be my suggestion.

    You want fast access to determine if a given point is explored. Having
    a boolean per point is a perfect hash, is rather hard to beat. The
    memory trade off is quite minimal.

    Indeed, since one expects users to fully explore maps, one might end up
    ahead of the game with a straight boolean-per-square. The real space
    savings wouldn't be from having a sparse list of explored squares (as
    explored squares aren't sparse, but often dense and connected!), but to
    RLE the boolean-per-square.

    > > P.S. You seem to be approaching the design from the point of
    > > view of 'what are my data structures and how should they fit
    > > together?' and then figuring out how that will impact the
    > > gameplay. You may be better off doing it the other way around.
    > > Figure out how you want the gameplay to work, and then you
    > > should be able to decide on the appropriate data structures
    > > and implement them...
    >
    > More like 'what are the gameplay features, what data structures
    > are required for those features, and how will the data structures
    > fit together?', otherwise yeah, that's the situation. It's
    > probably better to start 'less-grandiose' as far as data
    > structures and features go.

    Less grandiose is definitely better. KISS: Keep It Simple Stupid.
    --
    Jeff Lait
    (POWDER: http://www.zincland.com/powder)
  20. Archived from groups: rec.games.roguelike.development (More info?)

    "Steve Yrjana" <my_dump@looks.great.but.is.invalid> wrote:
    > On Thu, 21 Apr 2005 01:16:31 -0700, Jeff Lait wrote:
    >> crichmon wrote:
    >>
    >>> In the RL that I'm developing, I'm currently writing a lot
    >>> of the creature AI. The current puzzle that I'm
    >>> investigating has to do with creature map knowledge.
    >>>
    >>> There is one 'main' map object which maintains all map data
    >>> for the game. However, due to effects such as fog of war,
    >>> the PC doesn't have immediate knowledge of the entire map.
    >>> Nor does the PC have immediate and current knowledge of any
    >>> part of the map outside of the FOV. So the PC would require
    >>> a seperate copy of the map which maintains information
    >>> regarding where the player has explored and what the player
    >>> remembers.
    >>
    >> I don't know what you mean about "separate copy of the map".
    >
    > I think he means to store the visible map with items in it.
    > And if some item changes location when it's not in PC's
    > (or NPC's) FOV, the map information is not updated instantly,
    > instead the map information (== the separate copy of map) is
    > updated when the (N)PC sees that mapgrid again. Nethack does
    > this at least for the player. I guess some of the reasons to
    > do it this way is to show player items the character has seen
    > and "remembers" (instead of player self having to remember
    > them) and to help making AI more, may I say=), realistic

    Yes, that is one feature being considered.


    > (like: some orc is wounded bad and starts to flee, since the
    > orc remembers seeing a healing potion few rooms to the west,
    > it heads that way, but the evil player had made a trap there
    > to which the orc falls).
    >
    > Saving this information is only about one byte per mapgrid...
    > for example a map size of 100x100, that makes 10000 bytes per
    > (N)PC, and with 500 (N)PC's per map level, that makes 5000000
    > bytes per map level, which is less than 5 megabytes.
    > Depending on your target platform, that may, or may not be a
    > lot. IMHO when making a game for todays computers, it is not
    > something to worry about, and if it becomes a problem,
    > optimize it then (compress, use less bits per mapgrid, store
    > only differences etc.).

    I'd like to avoid maintaining a copy of the map for every (N)PC,
    iff that would still allow to maintain the game's included/
    attempted gameplay. I'm not worried about the limits of today's
    computers, rather, the needless testing of the limits of today's
    computers.


    crichmon
  21. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia Thu, 21 Apr 2005 19:39:15 GMT,
    crichmon napisal(a):

    > "Steve Yrjana" <my_dump@looks.great.but.is.invalid> wrote:
    >> On Thu, 21 Apr 2005 01:16:31 -0700, Jeff Lait wrote:
    >>> crichmon wrote:
    > I'd like to avoid maintaining a copy of the map for every (N)PC,
    > iff that would still allow to maintain the game's included/
    > attempted gameplay. I'm not worried about the limits of today's
    > computers, rather, the needless testing of the limits of today's
    > computers.


    How about this:

    You've got one map, you've got the KNOWN flags at the player's side, and
    all tiles are 'KNOWN' at the monster side. That's the basic map, the one
    that was generated when the player character entered the level.

    Bu then you store all the modyfications (picking up an item, digging,
    opening door) separately, together with their IDs.

    The monsters then could have the list of modyfications they know --
    offcourse only those with memory.

    Yes, it's a little tricky to program, but I'm sure there's an elegent way?

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  22. Archived from groups: rec.games.roguelike.development (More info?)

    "Antoine" <mail@guildgame.com> wrote:
    > crichmon wrote:
    >> The Sheep wrote:
    >>
    >>> Recently, a discussion about the random/non-random
    >>> combat made me think about how differently game
    >>> mechanics affects gameplay when applied to PC and
    >>> to monsters.
    >>>
    >>> There seem to be a tendency to make the PC "just
    >>> another monster", the only difference being his AI
    >>> replaced with UI. It generally makes many things
    >>> simplier and looks pretty nice.
    >>>
    >>> But it might be actually making some gameplay-
    >>> related stuff harder. You expect different things
    >>> from PC-related mechanics than from monster-related.
    >>
    >> In the RL that I'm developing, I'm currently writing
    >> a lot of the creature AI. The current puzzle that I'm
    >> investigating has to do with creature map knowledge.
    >>
    >> There is one 'main' map object which maintains all map
    >> data for the game. However, due to effects such as fog
    >> of war, the PC doesn't have immediate knowledge of the
    >> entire map. Nor does the PC have immediate and current
    >> knowledge of any part of the map outside of the FOV.
    >> So the PC would require a seperate copy of the map which
    >> maintains information regarding where the player has
    >> explored and what the player remembers.
    >
    > They don't need an entire copy of the map: just a small
    > data structure saying what parts of the map they know.
    > For example, a list of explored points.

    Booleans for every point in the map grid?

    >> One possible design that would simplify that situation is
    >> that all monsters and NPCs use the main map object as
    >> their map knowledge, and when AI is used to determine
    >> travel behaviors, map knowledge is simply not used as a
    >> determining factor.
    >
    > Yes, I use this shortcut. I figure that monsters live in
    > the dungeon so they should already know the layout of the
    > entire level and be able to navigate accordingly.
    >
    >> Of course, monsters and NPCs might have knowledge of other
    >> things, like remembering where the player was last, if the
    >> player isn't in the monster's/NPC's FOV, if the player has
    >> even been encountered.
    >
    > Yes. Store this sort of thing in the monster's AI, it will
    > come in useful. For example if a monster sees the player and
    > then loses sight of them, they might want to move towards
    > the space where they were last seen (or launch an area-effect
    > attack into that space!). And so on.
    >
    >> Otherwise, if creatures inherently know the location of the
    >> player, as that info might be contained in the main map
    >> object, then that creates the possibility of a hoard of
    >> attacking creatures making a journey from all corners of the
    >> map to the player's location!
    >
    > Which you may or may not want. It would give a good arcade-
    > game feel, keep the pressure up. However, more likely you
    > want the monsters to only know where the PC is if they have
    > some means of sensing them - sight, hearing, smell, ESP, etc.
    >
    > A.
    >
    > P.S. You seem to be approaching the design from the point of
    > view of 'what are my data structures and how should they fit
    > together?' and then figuring out how that will impact the
    > gameplay. You may be better off doing it the other way around.
    > Figure out how you want the gameplay to work, and then you
    > should be able to decide on the appropriate data structures
    > and implement them...

    More like 'what are the gameplay features, what data structures
    are required for those features, and how will the data structures
    fit together?', otherwise yeah, that's the situation. It's
    probably better to start 'less-grandiose' as far as data
    structures and features go.

    Thanks for the advice.


    crichmon
  23. Archived from groups: rec.games.roguelike.development (More info?)

    crichmon wrote:
    >>For example, a list of explored points.
    >
    > Booleans for every point in the map grid?

    More likely, a sparse representation using an actual list.

    --
    http://www.gnu.org/philosophy/right-to-read.html
    Palladium? Trusted Computing? DRM? Microsoft? Sauron.
    "One ring to rule them all, one ring to find them
    One ring to bring them all, and in the darkness bind them."
  24. Archived from groups: rec.games.roguelike.development (More info?)

    "ABCGi" <abcgi@yahoo.com> wrote:
    > crichmon wrote:
    > *SNIP*
    >> In the RL that I'm developing, I'm currently writing a
    >> lot of the creature AI. The current puzzle that I'm
    >> investigating has to do with creature map knowledge.
    > *SNIP*
    >
    > What about the way CounterStrike bots are
    > taught maps?

    I haven't played CounterStrike, and I'm don't know much
    about FPS bot AI, so I'm not familiar with that. Right
    now maps are represented as 2d arrays of location info.
    (Maps will eventually be upgraded to use vectors of 3d
    locations.) If I do have creatures retain map memory
    (which all depends on speed and memory issues, as well
    as what works best with AI routines and desired creature
    behavior), then creatures will be 'taught' maps when
    they move around. Also, creatures will start with some
    knowledge of the map already, such a room, a collection
    of rooms, a level, or a collection of levels.


    crichmon
  25. Archived from groups: rec.games.roguelike.development (More info?)

    On 21 Apr 2005 01:16:31 -0700, "Jeff Lait"
    <torespondisfutile@hotmail.com> wrote:

    >The big advantage of doing it this way is you avoid the risk of
    >asymmetrical AI. Apparently, some Bands suffer from the problem that
    >players can set up situations where they can see and target the
    >monster, but the monster cannot see or target them.

    That's a feature, not a bug. Monsters can do this to the player as
    well, but don't try to. This is one of the ways in which a
    one-against-many game can allow the one a chance of success. More
    advanced means of allowing superior positioning would be nice in newer
    games, but IME, *bands are better off with this feature than without
    it.

    R. Dan Henry
    danhenry@inreach.com
    Idiot boy, when are you going to post something useful?
    Or better yet, get a job and stop being a welfare bum?
  26. Archived from groups: rec.games.roguelike.development (More info?)

    R. Dan Henry wrote:
    > On 21 Apr 2005 01:16:31 -0700, "Jeff Lait"
    > <torespondisfutile@hotmail.com> wrote:
    >
    >
    >>The big advantage of doing it this way is you avoid the risk of
    >>asymmetrical AI. Apparently, some Bands suffer from the problem that
    >>players can set up situations where they can see and target the
    >>monster, but the monster cannot see or target them.
    >
    >
    > That's a feature, not a bug. Monsters can do this to the player as
    > well, but don't try to. This is one of the ways in which a
    > one-against-many game can allow the one a chance of success. More
    > advanced means of allowing superior positioning would be nice in newer
    > games, but IME, *bands are better off with this feature than without
    > it.
    >

    If you improved *band's AI significantly, you'd
    have to weaken the monsters. A lot.

    I'm actually running into a slight problem that after
    a certain point, there's not a whole lot of distinction
    between the strength levels of earlier monsters and
    later monsters. Since the players rather quickly reach
    a point of diminishing returns in their hitpoints/etc,
    the monsters toughness has a natural limit. As a result
    there's not much difference between what you can handle on
    the 20th level of the dungeon and what you can handle
    anywhere deeper.

    So I wind up deciding arbitrarily at what depth certain
    monsters will be; it's not because of their strength
    level, really. After some point it's more about creating
    a feeling of alienness and otherworldliness. The player
    is supposed to feel that these antediluvian creatures are
    fundamentally of a different nature and order than what
    he or she has known on the surface, or even heard of in
    legend. The Kuu live way deep because they're way strange,
    not because they're actually that much tougher than, say,
    vampires.

    It becomes a viable strategy for players to get up to
    (say) tenth level, and then powerdive the rest of the
    game as fast as they possibly can. I'm trying to decide
    whether I'm okay with that.

    Bear
  27. Archived from groups: rec.games.roguelike.development (More info?)

    Jeff Lait wrote::

    > The PC
    > merely needs to track what tiles he has seen. This can be done in two
    > ways: The PC can maintain a list of viewed tiles, or the Map can
    > maintain a list of tiles viewed by the PC.

    [...]

    > If we assume only the PC needs to explore, it becomes clear we don't
    > store the explore information with the PC. Instead, we can store as a
    > property of each tile in the map whether it has been seen by the PC.

    I suggest to store it with the PC, even in that case. It allows to have
    multiple PCs. If you store it in the map, you block that path.

    Both variants are about equal in effort, so I chose to store the
    information in the PC data structure, not the map data structure.

    --
    c.u. Hajo
  28. Archived from groups: rec.games.roguelike.development (More info?)

    Hansjoerg Malthaner wrote:

    >> If we assume only the PC needs to explore, it becomes clear we don't
    >> store the explore information with the PC. Instead, we can store as a
    >> property of each tile in the map whether it has been seen by the PC.
    >
    >
    > I suggest to store it with the PC, even in that case. It allows to have
    > multiple PCs. If you store it in the map, you block that path.
    >
    > Both variants are about equal in effort, so I chose to store the
    > information in the PC data structure, not the map data structure.

    I store it in the map structure, because I'm using it
    in a way that breaks the pc/monster equivalence.

    The map remembers what range the square was from the PC,
    and what round it was, the last time the PC saw it (using
    normal sight only). Monster AI uses this information to
    chase-and-follow, finding a path to the PC in the dungeon.

    Bear
  29. Archived from groups: rec.games.roguelike.development (More info?)

    In article <RbudnaDBv-8Ss_jfRVn-tg@adelphia.com>,
    Timothy Pruett <drakalor.tourist@gmail.com> wrote:
    >The Sheep wrote:

    >> There seem to be a tendency to make the PC "just another monster", the
    >> only difference being his AI replaced with UI. It generally makes many
    >> things simplier and looks pretty nice.
    >>
    >> But it might be actually making some gameplay-related stuff harder. You
    >> expect different things from PC-related mechanics than from
    >> monster-related.

    >I agree with you on this one. I was originally going to derive both
    >monsters and PCs from the same generic Creature class. Finally I
    >scrapped that, and coded two completely different and individual
    >classes. It's made my project run much more smoothly, and allows me
    >to allow monsters to have different abilities from players, without
    >any kludgey fixes, or roundabout generalized OO Design.

    I did completely the opposite in Quest For Pants. All creatures are
    derived from a single abstract class "GmCreature" and all creatures
    contain a "brain" object which houses the AI (or AS, as it happens)
    code. The only difference between the player and any other creature
    is that the player's brain object is an instance of GmPlayerBrain
    instead of GmCreatureBrain and GmPlayerBrain shuttles information
    between the UI and the player object instead of determining what to do
    by itself.

    All I can say is that this has worked for me so far.


    --Chris


    --
    Chris Reuter http://www.blit.ca
    "I pay way too much for cable, so I have to watch what's on the premium
    channels, even if it's not very good, or else I'm just throwing money away."
    --Gregory King in alt.religion.kibology
  30. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > But the player character has totally different health and wound
    system
    > than zombies -- the rules to determine whether you're wounded when
    hit,
    > the wound effects, etc. are totally different -- and I think it
    doesgood
    > in this case.

    What if you have human npc's, what rules will they use?

    > Offcourse, you can achieve the same effect by adding a lot of flags,
    > attributes, etc. and writing a generic code to handle them. But it's
    a lot
    > more work for the same effect.

    >From my experience I wouldn't recommend that way. Instead use shared
    code as much as possible, because then you'll only need one piece of
    code for one particular task. Also, npc's are capable of doing all
    the things as the player right from the start.
    If the attribute (for example) exists then you have to check it at
    least once. So, it doesn't add anything. Instead making one routine
    removes the need to do trivial code set ups you would need in that
    other routine for the player.

    I went through a lot of trouble when I changed from separate
    player code to unified n/pc code. I guess the separate way works
    much better if you have planned your code well. But as we all know
    roguelike programmers are notorious for their lack of planning skills:)
  31. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia 1 May 2005 04:16:55 -0700,
    Krice napisal(a):

    > The Sheep wrote:
    >> But the player character has totally different health and wound
    >> system
    >> than zombies -- the rules to determine whether you're wounded when
    >> hit,
    >> the wound effects, etc. are totally different -- and I think it
    >> does good
    >> in this case.

    > What if you have human npc's, what rules will they use?

    If I were ever to add other survivors to Z-Day, they'd have yet another
    set of rules -- insta-death on any zombie attack. But this particular game
    is not a very generic case.

    >> Offcourse, you can achieve the same effect by adding a lot of flags,
    >> attributes, etc. and writing a generic code to handle them. But it's
    >> a lot
    >> more work for the same effect.

    > From my experience I wouldn't recommend that way. Instead use shared
    > code as much as possible, because then you'll only need one piece of
    > code for one particular task. Also, npc's are capable of doing all
    > the things as the player right from the start.

    Yes, but then also nobody can do anything until you finish the shared,
    generic code, which is harder to write that code for particular creatures.
    Offcourse, you shouldn't write any code twice if it's really common. But
    if it isn't -- don't try to make it common by force, generalizing it
    needlesly.

    > If the attribute (for example) exists then you have to check it at
    > least once. So, it doesn't add anything. Instead making one routine
    > removes the need to do trivial code set ups you would need in that
    > other routine for the player.

    I'm not sure I can understand what you mean :( Could you rephrase it, my
    english is far from good.

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  32. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Yes, but then also nobody can do anything until you finish the
    shared,
    > generic code, which is harder to write that code for particular
    creatures.

    I don't think it's harder.

    > But if it isn't -- don't try to make it common by force, generalizing
    > it needlesly.

    Well I have sort of generalized the game engine too. For example I
    have general types for monsters which then set (or derive) many rules
    for them, instead of defining specific rules for each monster.
    The difference of monsters between the same "family" comes from simple
    things such as size.
    It's really the special cases that take the most of programming time
    in roguelikes. Something which needs yet another check or piece of
    code.
    So, generalizing the engine and code is a good idea, because you can
    then start to add objects and don't need to write specialized code
    (at least not that much) for all them. What happens if you don't do
    it this way? Check out the source code of Dungeon Crawl. It's FULL
    of special case code. Hard to read, hard to maintain and develop.

    I have to add for clarity, that with OOP design you can use
    inheritance to write "separate" code for each monster type. So it
    makes sense that way, but it's also generalized code which shares
    the basic functions common to all monster types. What I'm doing
    right now is kind of pseudo-OOP inheritance inside the functions.
    It's not the best way, but it's better than having two totally
    different set of codes for the player and the monsters. It's obvious
    that when something changes you need to do it twice, which is
    insane when you think how much work a roguelike requires in the
    first place.

    > > If the attribute (for example) exists then you have to check it at
    > > least once. So, it doesn't add anything. Instead making one routine
    > > removes the need to do trivial code set ups you would need in that
    > > other routine for the player.
    > I'm not sure I can understand what you mean :( Could you rephrase it,
    my
    > english is far from good.

    My english is bad, too:)
    I just don't see how separate functions are better than one multi-use
    function that can handle the player too. You may have to add some
    special checks for the player, but it's really not harder than
    using two functions for the same task.
  33. Archived from groups: rec.games.roguelike.development (More info?)

    The Sheep wrote:
    > Special cases are the content of your game. Yes, they need attention
    --
    > you've got to think what you want to have in your game and how it
    should
    > work. The rest is just background.

    I was talking about special cases in the source code. It's really
    different thing than how complex your game is. Again, look at the
    source code of Crawl and its horrible special case coding:)

    > How you do it isn't that important.

    It is.

    > I'm talking about the design, I'm sorry I didn't state it clearly.

    I don't get it. Of course the desing of the monsters must be different
    and it can be achieved by many ways. The player doesn't see the source
    code when he/she is playing, but the programmer can save a lot of
    effort
    and time by choosing the right way to do it. I'm not the one to say
    which one is the best, I can only speak from my experience. And that
    tells me to avoid using separate class & code for the player. In fact
    I'm using the same class for ALL object types (basic types, such as
    npc, movable, item, sewer..)
  34. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia 2 May 2005 02:43:58 -0700,
    Krice napisal(a):

    > The Sheep wrote:
    >> But if it isn't -- don't try to make it common by force, generalizing
    >> it needlesly.

    > Well I have sort of generalized the game engine too. For example I
    > have general types for monsters which then set (or derive) many rules
    > for them, instead of defining specific rules for each monster.
    > The difference of monsters between the same "family" comes from simple
    > things such as size.

    Not sure whether it'll come out interesting.

    > It's really the special cases that take the most of programming time
    > in roguelikes. Something which needs yet another check or piece of
    > code.
    > So, generalizing the engine and code is a good idea, because you can
    > then start to add objects and don't need to write specialized code
    > (at least not that much) for all them. What happens if you don't do
    > it this way? Check out the source code of Dungeon Crawl. It's FULL
    > of special case code. Hard to read, hard to maintain and develop.

    Special cases is what drags human attention. It's the content of your
    game. If everything is smoothly scaled, without hard edges, then it
    becomes blurry and uninteresting. At least I'
    ve got such experiences.

    Special cases are the content of your game. Yes, they need attention --
    you've got to think what you want to have in your game and how it should
    work. The rest is just background.

    > I have to add for clarity, that with OOP design you can use
    > inheritance to write "separate" code for each monster type. So it
    > makes sense that way, but it's also generalized code which shares
    > the basic functions common to all monster types.

    Yes, it's pretty good mechanism, but it's different level than what I'm
    talking about.
    I'm advocating making the monster and player creatures different by
    design, not just differently implemented.
    Writing separate code for the same mechanics would be silly, indeed.

    > What I'm doing
    > right now is kind of pseudo-OOP inheritance inside the functions.
    > It's not the best way, but it's better than having two totally
    > different set of codes for the player and the monsters. It's obvious
    > that when something changes you need to do it twice, which is
    > insane when you think how much work a roguelike requires in the
    > first place.

    You've got to do it twice anyways if it's supposed to behave differently.
    And what I'm saying is that it often should be supposed to behave
    differently.

    >> > If the attribute (for example) exists then you have to check it at
    >> > least once. So, it doesn't add anything. Instead making one routine
    >> > removes the need to do trivial code set ups you would need in that
    >> > other routine for the player.
    >> I'm not sure I can understand what you mean :( Could you rephrase it,
    >> my
    >> english is far from good.

    > My english is bad, too:)
    > I just don't see how separate functions are better than one multi-use
    > function that can handle the player too. You may have to add some
    > special checks for the player, but it's really not harder than
    > using two functions for the same task.

    How you do it isn't that important. Yes, there are differences in
    readability and maintain-ability of code, but it's highly language and
    programmer-specific.

    I'm talking about the design, I'm sorry I didn't state it clearly.

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  35. Archived from groups: rec.games.roguelike.development (More info?)

    Dnia 2 May 2005 06:31:48 -0700,
    Krice napisal(a):

    > The Sheep wrote:
    >> How you do it isn't that important.
    > It is.

    But it's language and implementation specific.

    >> I'm talking about the design, I'm sorry I didn't state it clearly.
    >
    > I don't get it. Of course the desing of the monsters must be different
    > and it can be achieved by many ways. The player doesn't see the source
    > code when he/she is playing, but the programmer can save a lot of
    > effort
    > and time by choosing the right way to do it. I'm not the one to say
    > which one is the best, I can only speak from my experience. And that
    > tells me to avoid using separate class & code for the player. In fact
    > I'm using the same class for ALL object types (basic types, such as
    > npc, movable, item, sewer..)

    The design of monsters and player characters should definitely go before
    the design of their data structures and code. Before it's done, you can't
    tell what implementation would be good for them.

    But there's a tendency to think about data structures and internal
    architecture first, and to design the game mechanics around this.
    It often leads to making the player character and the monsters (and npcs)
    use the same mechanics, which I think is not always desired, as the
    requirements for the game mechanics for those entities are diametrally
    different and it's considerably harder to come up with one design meeting
    all the requirements, than three different designs, each one meeting only
    a subset of the requirements.

    One example I've given is the requirement for the player character game
    mechanics to avoid insta-death. This requirement obviously doesn't apply
    to monster game mechanics or npc game mechanics (and if your npcs are
    important for the progress, you might want to make the immortal, which
    will remove another bunch of requirements).

    --
    Radomir @**@_ Bee! .**._ .**._ .**._ .**._ zZ
    `The Sheep' ('') 3 (..) 3 (..) 3 (..) 3 (--) 3
    Dopieralski .vvVvVVVVVvVVVvVVVvVvVVvVvvVvVVVVVVvvVVvvVvvvvVVvVVvv.v.
  36. Archived from groups: rec.games.roguelike.development (More info?)

    "Krice" <paulkp@mbnet.fi> wrote in message
    news:1115040708.554045.34850@f14g2000cwb.googlegroups.com...
    > The Sheep wrote:
    >> Special cases are the content of your game. Yes, they need attention
    > --
    >> you've got to think what you want to have in your game and how it
    > should
    >> work. The rest is just background.
    >
    > I was talking about special cases in the source code. It's really
    > different thing than how complex your game is. Again, look at the
    > source code of Crawl and its horrible special case coding:)
    >

    Most great RLs have a ridiculous number of special cases. This is not
    (usually) because of poor coding; it a symptom of what Sheep is trying to
    say here. Special cases make things fun. Nethack is a little bit of an
    extreme example, but Crawl is nicely in the middle (IMO of course). If
    everything is generic then playing the game is just solving a system of
    equations, be they linear or not. It's not fun.

    The fun from RLs is usually generated from the special cases giving rise
    to interesting decisions...a generic engine with a generic game in a generic
    universe with a generic goal is going to have a generic optimal solution
    (i.e. playing style) which is not very interesting at all.

    Don't forget to play your own game!

    --
    Glen
    L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
    W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
  37. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > The player doesn't see the source
    > code when he/she is playing, but the programmer can save a lot of
    > effort
    > and time by choosing the right way to do it. I'm not the one to say
    > which one is the best, I can only speak from my experience. And that
    > tells me to avoid using separate class & code for the player. In fact
    > I'm using the same class for ALL object types (basic types, such as
    > npc, movable, item, sewer..)

    I use this technique as well. There is one class from which everything
    ( monsters, player, weapons, even buildings) is constructed. Since
    everything is stored in linked lists, it makes the entire game world
    easily interchangeable and easy to manipulate. The difference between
    any two actors in the game is only in the stats, but because any given
    object can be extended with as many additional variables as needed,
    everything can be defined to precisely the level of detail necessary.
    This makes it possible to create a system where the rules act almost
    like the laws of physics. That is, they can be applied indiscriminantly
    to any thing or person, as needed. Of course, special cases are
    provided for as well, and most procedures only accept a certain subset
    of actors.
    Its almost like OO, except that instead of having a seperate derived
    class for each of your 74 monster types, each with its own code and
    variables, you just have to worry about interpreting a standard
    structure of stats.

    On the other hand, if I had spent more time adding content and less
    time designing excessivley flexible game architecture, my rl would
    probably be a lot more fun to actualy play...

    Peace
    Mosa
  38. Archived from groups: rec.games.roguelike.development (More info?)

    Glen Wheeler wrote:
    > Most great RLs have a ridiculous number of special cases. This is
    not
    > (usually) because of poor coding; it a symptom of what Sheep is
    trying to
    > say here. Special cases make things fun.

    Yes, but there isn't just one way to create special cases.

    > a generic engine with a generic game in a generic
    > universe with a generic goal is going to have a generic optimal
    solution
    > (i.e. playing style) which is not very interesting at all.

    For me Nethack is this kind of game.
  39. Archived from groups: rec.games.roguelike.development (More info?)

    Krice wrote:
    > Glen Wheeler wrote:

    >> a generic engine with a generic game in a generic
    >> universe with a generic goal is going to have a
    >> generic optimal solution (i.e. playing style)
    >> which is not very interesting at all.

    > For me Nethack is this kind of game.

    Although the amount of "inside knowledge" required to
    get good at nethack is annoying to me, I have rarely
    seen a roguelike that rewards a more diverse set of
    playing styles. The diverse and radically different
    classes, plus conducts which would seem flatly impossible
    in most games, make nethack, in particular, the last
    roguelike I'd have guessed "generic playstyle" about.

    For me this end of the spectrum is occupied by *bands,
    where the winning tactics are approximately the same
    and winning characters look approximately the same,
    regardless of all other conditions.

    Can you elaborate about what you'd consider to be
    a game that *doesn't* reward an "uninteresting"
    style of play?

    Bear
  40. Archived from groups: rec.games.roguelike.development (More info?)

    "Krice" <paulkp@mbnet.fi> wrote in message
    news:1115291102.435421.139430@o13g2000cwo.googlegroups.com...
    > Glen Wheeler wrote:
    >> Most great RLs have a ridiculous number of special cases. This is
    > not
    >> (usually) because of poor coding; it a symptom of what Sheep is
    > trying to
    >> say here. Special cases make things fun.
    >
    > Yes, but there isn't just one way to create special cases.
    >

    Granted, you can use bifurcation points in your modelling functions as a
    special case. I think the point is still valid :).

    >> a generic engine with a generic game in a generic
    >> universe with a generic goal is going to have a generic optimal
    > solution
    >> (i.e. playing style) which is not very interesting at all.
    >
    > For me Nethack is this kind of game.
    >

    I am also not a fan, but it does have a very large number of people who
    are not us and who enjoy Nethack a vast amount.

    --
    Glen
    L:Pyt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
    W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Ask a new question

Read More

Development Games Monster Video Games