Sign in with
Sign up | Sign in
Your question

Distinction between PC and Monster

Tags:
  • Development
  • Games
  • Monster
  • Video Games
Last response: in Video Games
Share
Anonymous
April 19, 2005 5:35:09 PM

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.

More about : distinction monster

Anonymous
April 19, 2005 5:35:10 PM

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.
April 19, 2005 9:05:05 PM

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.
Anonymous
April 20, 2005 12:34:40 AM

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
Anonymous
April 20, 2005 7:15:50 AM

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.
Anonymous
April 20, 2005 10:19:19 AM

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)
Anonymous
April 20, 2005 2:53:37 PM

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.
Anonymous
April 20, 2005 8:02:43 PM

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
April 21, 2005 4:46:30 AM

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...
Anonymous
April 21, 2005 5:16:31 AM

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)
Anonymous
April 21, 2005 10:41:50 AM

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
Anonymous
April 21, 2005 10:56:55 AM

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.
Anonymous
April 21, 2005 12:25:16 PM

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
Anonymous
April 21, 2005 3:42:17 PM

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
Anonymous
April 21, 2005 3:45:13 PM

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
Anonymous
April 21, 2005 3:51:54 PM

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
Anonymous
April 21, 2005 3:54:24 PM

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
Anonymous
April 21, 2005 8:57:21 PM

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 -
April 21, 2005 9:20:43 PM

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.
Anonymous
April 21, 2005 9:59:18 PM

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)
Anonymous
April 21, 2005 11:39:15 PM

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
Anonymous
April 21, 2005 11:47:38 PM

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.
Anonymous
April 21, 2005 11:57:15 PM

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
Anonymous
April 21, 2005 11:57:16 PM

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."
Anonymous
April 23, 2005 7:31:21 AM

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
Anonymous
April 25, 2005 2:27:08 AM

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?
Anonymous
April 25, 2005 10:31:29 AM

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
Anonymous
April 25, 2005 1:54:18 PM

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
Anonymous
April 25, 2005 8:13:05 PM

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
Anonymous
April 28, 2005 5:12:52 PM

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
Anonymous
May 1, 2005 8:16:55 AM

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:) 
Anonymous
May 1, 2005 4:48:54 PM

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.
Anonymous
May 2, 2005 6:43:58 AM

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.
Anonymous
May 2, 2005 10:31:48 AM

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..)
Anonymous
May 2, 2005 2:35:07 PM

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.
Anonymous
May 2, 2005 6:06:35 PM

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.
Anonymous
May 3, 2005 4:30:55 AM

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:p yt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
Anonymous
May 4, 2005 3:47:38 AM

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
Anonymous
May 5, 2005 8:05:02 AM

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.
Anonymous
May 6, 2005 2:51:20 AM

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
Anonymous
May 6, 2005 8:35:00 AM

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:p yt E+++ T-- R+ P+++ D+ G+ F:*band !RL RLA-
W:AF Q+++ AI++ GFX++ SFX-- RN++++ PO--- !Hp Re-- S+
!