How to handle map features (and items)?

G

Guest

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

Hello.

I am slowly making something that might become a roguelike / rpg at some
point in time. I'm using an OO structure. I've got the map, movement and
FOV ...ok.

Handeling the Monsters (and player) in the dungeon is done by setting a
flag (IS_OCCUPIED) on the Tile at it's position, then storing the
Monsters hashed on position. Any interaction on the Tile checks the
flag, and if it is set, the game gets it from the table. Quick and easy.

Features, on the other hand... They are usually immoveable (door,
stairs, traps) and often blocking movement and/or LOS. It would be
easier for the Tile to check if it allows entering by a Monster if it
(the Tile) had a pointer to the feature. Will it be too expensive
(memory-wise) in this day and age to keep a pointer instead of a flag?

Probably yes, for larger maps.

Items. These would be nice not to keep a position on (I mean, if they
are carried or within a container - a position would be redundant), but
that would mean that each Tile needed an Item container. Which even I
would see was a waste of space. Dang. Position for Items, and flags on
the Tile, here I come. Probably flag for Features also.

Incredible how much I realize as I type it out. I'll post this anyway.

And also: If I make a *big* boulder, - that can be pushed by magic or a
great feat of strenght (or strenght of feet), but not picked up. Should
it then be a moveable Feature, or an unliftable Item. Think Indiana
Jones size boulder.

Thanks for the insight I've gained by reading rgrd and by writing this.

tormodh.
 
G

Guest

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

Tormod Haugen wrote:
> Handeling the Monsters (and player) in the dungeon is done by setting a
> flag (IS_OCCUPIED) on the Tile at it's position, then storing the
> Monsters hashed on position. Any interaction on the Tile checks the
> flag, and if it is set, the game gets it from the table. Quick and easy.
>
> Features, on the other hand... They are usually immoveable (door,
> stairs, traps) and often blocking movement and/or LOS. It would be
> easier for the Tile to check if it allows entering by a Monster if it
> (the Tile) had a pointer to the feature. Will it be too expensive
> (memory-wise) in this day and age to keep a pointer instead of a flag?

If you have a flag, per tile, it can mean "can I be entered" instead of
"do I have a monster". Features can go in a hash table like monsters.
Other things that are in most or all tiles like terrain type are better
represented as enumerations and bitfields.

> Items. These would be nice not to keep a position on (I mean, if they
> are carried or within a container - a position would be redundant), but

Be aware that queries of "where is this item" would perform much worse.
Probably you can avoid them by design.

> that would mean that each Tile needed an Item container. Which even I
> would see was a waste of space. Dang. Position for Items, and flags on
> the Tile, here I come. Probably flag for Features also.

Item lists per tile can live in a hash table too.

> And also: If I make a *big* boulder, - that can be pushed by magic or a
> great feat of strenght (or strenght of feet), but not picked up. Should
> it then be a moveable Feature, or an unliftable Item. Think Indiana
> Jones size boulder.

It seems Features and Items are almost the same and the big boulder is
exactly halfway: a textbook example of unification. A "Thing" could be
potentially pushed, be located on a tile and picked up; some flags can
disable the operations for a thing type. All former Features cannot be
picked up, a few former Features and the boulder can be pushed, former
Items allow all three operations.

Lorenzo Gatti
 
G

Guest

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

At Wed, 13 Jul 2005 01:57:02 +0200,
Tormod Haugen wrote:

> Hello.
>
> I am slowly making something that might become a roguelike / rpg at some
> point in time. I'm using an OO structure. I've got the map, movement and
> FOV ...ok.

Most of these quoestions you will have to answer by yourself.
You might want to check my article, which is an answer for a similar
question posted here recently:
<http://roguebasin.t-o-m-e.net/index.php/Data_structures_for_the_map>

Note, that you can't do the design "in air" -- you must be aware of what
you want to achieve and how you want the things to look and behave like.

Whether a boulder should be an item or object -- it depends what features
you want it to have and what features the items and objects in your game
have. You could probably even get away with just making it a terrain
feature.

--
Radomir `The Sheep' Dopieralski @**@_
($s) 3 Ching!
. . . ..v.vVvVVvVvv.v.. .
 

Thomas

Distinguished
Jun 27, 2003
449
0
18,780
Archived from groups: rec.games.roguelike.development (More info?)

Yeah...

I have been wondering about the boulder question myself.

I think personally i will have it be a piece of terrain that you can
interact with.

pushing a boulder might be like closing a door or removing a trap...
its just a terrain interaction... unless you want someone with like a
crown of str + ring of str + like 30 base str to be able to lift it...

lifting terrain would be a bad idea so in that case i would make it an
item which would be probably harder then terrain. (at least in my
engine)

but asuming that there is no way you can pick up the rock... just make
huge rocks terrain and small rocks and pebbles items...

thats my 2 cents worth... ;)

-Thomas
RL: CHAZM
 
G

Guest

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

The Sheep wrote:
> At Wed, 13 Jul 2005 01:57:02 +0200,
> Tormod Haugen wrote:
>
>
>>Hello.
>>
>>I am slowly making something that might become a roguelike / rpg at some
>>point in time. I'm using an OO structure. I've got the map, movement and
>>FOV ...ok.
>
>
> Most of these quoestions you will have to answer by yourself.
> You might want to check my article, which is an answer for a similar
> question posted here recently:
> <http://roguebasin.t-o-m-e.net/index.php/Data_structures_for_the_map>

Thanks. This is actually quite like what I've managed to come up with
it's just that...

> Note, that you can't do the design "in air" -- you must be aware of what
> you want to achieve and how you want the things to look and behave like.

Yes. I seem to sometimes have a problem writing things down for myself.
I mean; when I try to explain it to myself in a document, it doesn't
help me as much as when I try to explain it for others. This is just the
one post I actually made after arriving at a solution while writing it
out for someone else than me.

Of course, most of this I should have picked up from here a long time
ago... ;)

> Whether a boulder should be an item or object -- it depends what features
> you want it to have and what features the items and objects in your game
> have. You could probably even get away with just making it a terrain
> feature.

The boulder will be a Feature (probably what you call an object) - along
with doors, traps, stairs... it is walkable, but the effect of entering
it is that the player must be able to push it one step, or the action is
aborted (with a message).

My terrains are implemented as factory produced objects.. there are only
one dungeonfloor object, one square of lava etc. all linked to their
tile. Then these terrains will be able to affect (with code) whatever is
upon them...

Incidently, when I wrote this out now, I saw that it is possibly wery
much like my features, and then I might merge them into the terrain
instead. Back to the drawing board.

(Feel free to ignore this monologue - but it worked, I think.)

(Thanks Lorenzo - I've read and appreciated your answers too.)

tormodh.
 
G

Guest

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

Thomas <comments@foresightsagas.com> schrieb:
> I have been wondering about the boulder question myself.

Why are you implementing boulders? Is it just because Nethack (et al)
does it? It seems like an unnecessary feature.

Nethack has a lot of uses for boulders. Is your game going to have as
many uses?

Also, every use for boulders is hacked in somewhere, which is easy
because Nethack is coded in C. If your progamming style is more elegant,
you may find implementing such features more difficult (and
unnecessary.)

--
Jim Strathmeyer
 
G

Guest

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

Jim Strathmeyer wrote:
> Thomas <comments@foresightsagas.com> schrieb:
>
>>I have been wondering about the boulder question myself.
>
>
> Why are you implementing boulders? Is it just because Nethack (et al)
> does it? It seems like an unnecessary feature.

My reason is that I am *slowly* building up my game. Currently it is a
'maze' program that generates mazes and lets the players solve it.

Next step is a Sokoban clone in just a few changes. Just as a step on
the way.

I hav a hope of turning it into an RPG in 10 to 20 years time ;)

> Nethack has a lot of uses for boulders. Is your game going to have as
> many uses?

Who knows. It was just a step on the road. It will block visibility, but
allow movement (as long as it can be moved in the same direction as the
player. And it will (in my case) be a Feature (or Object if you want),
same as doors.

>
> Also, every use for boulders is hacked in somewhere, which is easy
> because Nethack is coded in C. If your progamming style is more elegant,
> you may find implementing such features more difficult (and
> unnecessary.)

I have a plan. At leats, I think I do... But with the time I have to
spend, it might be some time before I get anywhere. Therefore - small
steps, and derived projcets.


tormodh.
 
G

Guest

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

Tormod Haugen <tormodh@googles_popular_email.com> schrieb:
> I have a plan. At leats, I think I do... But with the time I have to
> spend, it might be some time before I get anywhere. Therefore - small
> steps, and derived projcets.

Do you mind sharing your plan?

--
Jim Strathmeyer
 
G

Guest

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

Jim Strathmeyer wrote:
> Tormod Haugen <tormodh@googles_popular_email.com> schrieb:
>
>>I have a plan. At leats, I think I do... But with the time I have to
>>spend, it might be some time before I get anywhere. Therefore - small
>>steps, and derived projcets.
>
>
> Do you mind sharing your plan?
>

Yes, that is my plan. Make a Maze program, then make a Sokoban clone,
then make an enhanced Maze program, then make a simple Roguelike, then
make a more advanced Rogulike, then make a simple RPG. Then retire from
my day job, and enjoy old age with my grandchildren. ;)

If things progress faster than this, I'll adapt.

tormodh.