Every tile an object?!

G

Guest

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

I've been looking at the source code to IVAN for the past 30 minutes. IVAN
is a RL written in C++ and which is more object-oriented than some other RL
code that I have read.

IVAN uses an array of "lsquare" objects to represent the map. These lsquares
have about 20-30 different fields and at least 150 different functions
handling everything from lighting to the handling of spells.

I'm thinking about switching to the "every tile is an object" methodolgy
myself. Currently my tile map just stores an array of tile structs; and a
tile struct is the index of the ground tile at this square, and a pointer to
an ArrayList holding anything that might be occupying the tile. I'm thinking
that the every-tile-an-object idea would make it easier to keep my code
object-oriented and it would also make it easier to keep track of the
properties of different tiles.

But it seems like the IVAN design takes things a little too far... I mean,
spell-handling logic in the map tile object?

What do you guys think?

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
 
G

Guest

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

First post via a new news server...your patience is appreciated.

"Shedletsky" <mylastname@stanford.edu> wrote in message
news:del4vc$1l1$2@news.Stanford.EDU...
> IVAN uses an array of "lsquare" objects to represent the map. These
> lsquares
> have about 20-30 different fields and at least 150 different functions
> handling everything from lighting to the handling of spells.
>

In my project, I've encapsulated each square as its own object, and it has
led to some nice simplifications in the map class. My profiler has shown the
cost of using objects here to be negligible.

Nathan
 
G

Guest

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

At Thu, 25 Aug 2005 15:08:24 -0400,
Shedletsky wrote:

> I've been looking at the source code to IVAN for the past 30 minutes. IVAN
> is a RL written in C++ and which is more object-oriented than some other RL
> code that I have read.
>
> IVAN uses an array of "lsquare" objects to represent the map. These lsquares
> have about 20-30 different fields and at least 150 different functions
> handling everything from lighting to the handling of spells.
>
> I'm thinking about switching to the "every tile is an object" methodolgy
> myself. Currently my tile map just stores an array of tile structs; and a
> tile struct is the index of the ground tile at this square, and a pointer to
> an ArrayList holding anything that might be occupying the tile. I'm thinking
> that the every-tile-an-object idea would make it easier to keep my code
> object-oriented and it would also make it easier to keep track of the
> properties of different tiles.
>
> But it seems like the IVAN design takes things a little too far... I mean,
> spell-handling logic in the map tile object?
>
> What do you guys think?

I think treating the map as an object is enough. The squares themselves
are just an internal feature of the map object, and their exact
implementation shoudn't be revelant for the rest of code.


--
Radomir `The Sheep' Dopieralski @**@_
(Uu) 3 Sigh!
. . . ..v.vVvVVvVvv.v.. .
 
G

Guest

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

Shedletsky wrote:
> But it seems like the IVAN design takes things a little too far... I mean,
> spell-handling logic in the map tile object?

I don't see anything inherently wrong with making every tile an object, but it's up to you, really. If it makes more sense to you to abstract things to that level, go for it.

Spell-handling logic in the tile object sounds broken (in the "pure OO" sense) to me, but that's a separate issue. Unless, of course, the magic in question is operating on the tile itself, whatever that means. ;)

-Aaron
 
G

Guest

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

Shedletsky wrote:
> But it seems like the IVAN design takes things a little too far... I mean,
> spell-handling logic in the map tile object?
>
> What do you guys think?

Depends if you highest goal is clean design, or finite ressource
usage ...
 
G

Guest

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

Andreas Koch wrote:
> Shedletsky wrote:
> > But it seems like the IVAN design takes things a little too far... I mean,
> > spell-handling logic in the map tile object?
> >
> > What do you guys think?
>
> Depends if you highest goal is clean design, or finite ressource
> usage ...

In either case, the answer is the same: don't make map tiles objects.
You get clean design and avoid unnecessary code and data bloat.

I find it depressing that this is even considered an option to people.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

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

> Depends if you highest goal is clean design, or finite ressource
> usage ...

Well there is that... But most RL maps are smaller than 100x100. So even
with a bloated tile object we are talking about map memory footprints on the
order of kilobytes here. In comparison the .Net framework code that gets
loaded into memory when my program is running is on the order of 20 MB. And
that's still not even worth thinking about these days -- the 3-year old
laptop I'm developing on has a gig of RAM. For anything you'd want to do in
the RL space, memory is basically limitless.

So maybe I should go with clean design. Seems to work for the IVAN people.

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
 
G

Guest

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

John wrote:
> On 2005-08-26, Andreas Koch <nospam@kochandreas.com> wrote:
> > Depends on what you are targeting. If you only want to run on modern
> > Wintel PCs, RAM is no limit. But you should consider that a gig
> > is more than many CURRENT super market PCs have (at least here
> > in germany), and many people still run boxes with Win98 and
> > 64 Meg (and no .NET ... )...
>
> And what roguelike, no matter how bloated, doesn't run on 64MB?
>
> > If you want to port on something like PDAs with 2 Meg of Memory for
> > disk and working RAM, it DOES matter if that 100x100 map needs
> > 100x100 bytes or 100x100 pointers+byte+etc ...
>
> What color screen PDA made in the last 5 years has only 2MB of memory?
> Please provide a model number and link.

The Gameboy Advance is made to this day.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

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

Shedletsky wrote:
>
> > Lack of experience combined with "object-oriented" being their only tool
> > leads them to believe that every problem has an object-oriented
> > decomposition and that every last thing in a program must be an
> > object. Java doesn't help in this regard.
>
> Beyond the fact that C# basically forces OOP, I want my code to be as
> extensible as possible and OOP seems like a good paradigm for this.

OOP has nothing to do with making tiles objects. OOP means you make
the map an object. Tiles are not things that should be exported
outside of the map. Thus, you *could* implement them as objects
*inside* the map's universe. But the rest of the world should
interface with a map, not with a MxN array of Tiles.

When you build this distinction you then realize your reprsentation of
tiles can be arbitrary. There is no need to store monsters "inside"
your "tile" structure. And for the vast majority of roguelikes a
simple index sufficies to completely describe each tile. At this
point, it is simpler code wise, more effecient memory wise, to just use
an MxN array of indices.

This also lets you do any other tricks you feel like. For example,
breaking your 1000x1000 map into 50x50 chunks can be done seamlessly
from the viewpoint of the outside world. Compressing these in ram,
swapping to disk, whatever, can be done without dealing with outside
TILE references dangling. Building a KD tree to store creature and
item positions for fast nearest searches can be cached and maintained
at the level that makes sense. You don't have to worry about the tree
becoming invalid because someone with a pointer to a tile changed the
monster value there (or, alternatively, making sure the proper dirty
notifications get bumped back up to the tile's parent (which requires
storing with the tile its parent information - ugh!) whenever the tile
set() methods are invoked).

This is why I'm tired with this tacit assumption that "Everything Is An
Object" implies some magical cleaner design. It doesn't. A clean
design seeks to minimize the number of objects you need.

> like a lot of RL coders are old school procedural C hacks, which has made it
> difficult to read other source code for ideas of how to do things.

Have you read the source for You Only Live Once?

http://www.zincland.com/7drl/liveonce
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

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

John wrote:
> On 2005-08-26, Jeff Lait <torespondisfutile@hotmail.com> wrote:
> > > What color screen PDA made in the last 5 years has only 2MB of memory?
> >
> > The Gameboy Advance is made to this day.
>
> Too bad its not a PDA.

I forgot. The GBA is analog, so it is really a PAA.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
 
G

Guest

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

"Shedletsky" <mylastname@stanford.edu> writes:
> > Depends if you highest goal is clean design, or finite ressource
> > usage ...
>
> Well there is that... But most RL maps are smaller than 100x100. So even
> with a bloated tile object we are talking about map memory footprints on the
> order of kilobytes here. In comparison the .Net framework code that gets
> loaded into memory when my program is running is on the order of 20 MB. And
> that's still not even worth thinking about these days -- the 3-year old
> laptop I'm developing on has a gig of RAM. For anything you'd want to do in
> the RL space, memory is basically limitless.

Well, maybe. The major roguelikes (and quite a lot of the minor ones)
still run fine on my 100Mhz/96Mb machine, and out of a feeling that
roguelikes shouldn't eat memory or require the 'latest' hardware I'd
like mine too as well. So far mine's an order of magnitude too slow.

I don't know... it already runs at a reasonable speed on a 450MHz
machine - is it worth optimising so that it runs on a 100MHz machine
or should I just give up and expect people to have a machine from this
decade or so?

Another reason to avoid power-hungry roguelikes, at least on the
Unix/Linux platform, is that lots of machines are multi-user and so
while the machine might have 2Gb you'll be in real trouble with the
admin/other users if you use it all yourself. Similarly with processor
usage.

On the windows platform where the majority of machines are single-user
it's obviously not so important.

--
Chris
 
G

Guest

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

Shedletsky wrote:

> Well there is that... But most RL maps are smaller than 100x100. So even
> with a bloated tile object we are talking about map memory footprints on the
> order of kilobytes here. In comparison the .Net framework code that gets
> loaded into memory when my program is running is on the order of 20 MB. And
> that's still not even worth thinking about these days -- the 3-year old
> laptop I'm developing on has a gig of RAM. For anything you'd want to do in
> the RL space, memory is basically limitless.

Depends on what you are targeting. If you only want to run on modern
Wintel PCs, RAM is no limit. But you should consider that a gig
is more than many CURRENT super market PCs have (at least here
in germany), and many people still run boxes with Win98 and
64 Meg (and no .NET ... )...

If you want to port on something like PDAs with 2 Meg of Memory for
disk and working RAM, it DOES matter if that 100x100 map needs
100x100 bytes or 100x100 pointers+byte+etc ...

I read a nice document about designing games for java enabled phones.
They strongly suggested to use as less objects as possible
(in java ... <g>) because of the overhead.
 

john

Splendid
Aug 25, 2003
3,819
0
22,780
Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-26, Jeff Lait <torespondisfutile@hotmail.com> wrote:
> In either case, the answer is the same: don't make map tiles objects.
> You get clean design and avoid unnecessary code and data bloat.
>
> I find it depressing that this is even considered an option to people.

My theory is that most schools teach new programmers an "object-oriented"
language like Java or C++ and most roguelike "developers" are still in
school.

Lack of experience combined with "object-oriented" being their only tool
leads them to believe that every problem has an object-oriented
decomposition and that every last thing in a program must be an
object. Java doesn't help in this regard.

Unfortunately, being new, inexperienced, and intelligent, these
"developers" are too sure of themselves to see their own faults.

I think a look at the source code for most new roguelikes will lend
credibility to my theory.

This is also why most of the posts in this newsgroup are about trivial
non-issues rather than real development challenges.

Just my $.02
 
G

Guest

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

> My theory is that most schools teach new programmers an "object-oriented"
> language like Java or C++ and most roguelike "developers" are still in
> school.

Yes. That's probably true.

> Lack of experience combined with "object-oriented" being their only tool
> leads them to believe that every problem has an object-oriented
> decomposition and that every last thing in a program must be an
> object. Java doesn't help in this regard.

Beyond the fact that C# basically forces OOP, I want my code to be as
extensible as possible and OOP seems like a good paradigm for this. It seems
like a lot of RL coders are old school procedural C hacks, which has made it
difficult to read other source code for ideas of how to do things.

> Unfortunately, being new, inexperienced, and intelligent, these
> "developers" are too sure of themselves to see their own faults.

Damn straight.

> This is also why most of the posts in this newsgroup are about trivial
> non-issues rather than real development challenges.

All development challenges are trivial if you already know the answer.

--
Blog:
Shedletsky's Bits: A Random Walk Through Manifold Space
http://www.stanford.edu/~jjshed/blog
 

john

Splendid
Aug 25, 2003
3,819
0
22,780
Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-26, Andreas Koch <nospam@kochandreas.com> wrote:
> > And what roguelike, no matter how bloated, doesn't run on 64MB?
> OP was talking about using .NET, with a 20 meg runtime.

That leaves 44 MB. Your roguelike doesn't fit in that?

> > What color screen PDA made in the last 5 years has only 2MB of memory?
> Who did say color screen?

Everyone in this newsgroup who uses a non-color screen PDA with 2MB of
memory on a daily basis raise your hand.

> > I think you are arguing just to hear yourself speak at this point.
> Oh, a Troll. Couldn't you have said that right in the beginning?
> Would have saved me typing ...

Calling a person a troll because you can't deal with there differing
opinion is pretty sad.
 
G

Guest

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

John <piQqySNI@mailinator.com> schrieb:
> Calling a person a troll because you can't deal with there differing
> opinion is pretty sad.

More or less sad than trolling someone with a different opinion because
you have nothing useful to say?

--
Jim Strathmeyer
 

john

Splendid
Aug 25, 2003
3,819
0
22,780
Archived from groups: rec.games.roguelike.development (More info?)

On 2005-08-26, Jeff Lait <torespondisfutile@hotmail.com> wrote:
> > What color screen PDA made in the last 5 years has only 2MB of memory?
>
> The Gameboy Advance is made to this day.

Too bad its not a PDA.
 
G

Guest

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

Jeff Lait wrote:
> This is why I'm tired with this tacit assumption that "Everything Is An
> Object" implies some magical cleaner design. It doesn't. A clean
> design seeks to minimize the number of objects you need.

I don't want to get *too* nitpicky, but a clean design seeks to minimise the amount of trouble involved in making changes to your source code. For roguelikes it might mean minimising the number of objects, but it might not.

Ultimately it depends on the programmer.

-Aaron
 
G

Guest

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

John wrote:

> Everyone in this newsgroup who uses a non-color screen PDA with 2MB of
> memory on a daily basis raise your hand.

Well, "on a daily basis" seems to me to make this into a strawman.

I use a Palm ... er, 3, I think it is? on an irregular basis to play
some simple games on. I have one of those super-simplistic elite-clones,
and a couple of "make shaded blocks come next to each other" games. A
roguelike for it would be very cool.
 
G

Guest

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

Shedletsky wrote:
> I've been looking at the source code to IVAN for the past 30 minutes. IVAN
> is a RL written in C++ and which is more object-oriented than some other RL
> code that I have read.
>
> IVAN uses an array of "lsquare" objects to represent the map. These lsquares
> have about 20-30 different fields and at least 150 different functions
> handling everything from lighting to the handling of spells.

Sounds a little dangerous to me - most of this stuff either belongs in
the map object or in separate spell handling code.

Having said that, there is a case for making tiles into object *if*
they are immutable. By this I mean that you can't change any of the
fields. If you do this, you effectively have no per-tile resource
overhead because you use a single object instance for every "wall" tile
in the entire game, and the reference to these objects only take up 4
bytes per tile. Any event that changes a tile would just need to change
the reference for that tile to a different tile object instance.
 
G

Guest

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

> Thus, you *could* implement them as objects
> *inside* the map's universe. But the rest of the world should
> interface with a map, not with a MxN array of Tiles.

Right. This is model that IVAN uses and the one I had in mind when I posted
the original topic.

> When you build this distinction you then realize your reprsentation of
> tiles can be arbitrary. There is no need to store monsters "inside"
> your "tile" structure. And for the vast majority of roguelikes a
> simple index sufficies to completely describe each tile. At this
> point, it is simpler code wise, more effecient memory wise, to just use
> an MxN array of indices.

Definitely it is more efficient memory-wise - that was never contested.
However, it seems like there is a design advantage to allowing the tiles to
be objects. For example: If my tile object has an EntityEntersTile(Entity
*ent) method and I have a Lava tile that burns any entity that steps on it,
this would be a good place to do ent->TakeDamage(10). Without the object
model, whenever a creature moves in my map, I will have to do the test (If
map[new_x,new_y] == LAVA_TILE then...) That's ugly. I want an extensible
system, which mean I want to minimize special case code like that. The tiles
probably will store pointers to all the entities standing on them, to make
getting a list of entities at (x,y) very fast. This doesn't prevent a
separate list of entity pointers in the map object for interating over all
entities (to update their states or what have you).

> This also lets you do any other tricks you feel like. For example,
> breaking your 1000x1000 map into 50x50 chunks can be done seamlessly
> from the viewpoint of the outside world. Compressing these in ram,
> swapping to disk, whatever, can be done without dealing with outside
> TILE references dangling.

I can still do that with a map of tile references. C# is garbage collected,
so dangling refs are no problem.

> Building a KD tree to store creature and
> item positions for fast nearest searches can be cached and maintained
> at the level that makes sense.
> You don't have to worry about the tree
> becoming invalid because someone with a pointer to a tile changed the
> monster value there (or, alternatively, making sure the proper dirty
> notifications get bumped back up to the tile's parent (which requires
> storing with the tile its parent information - ugh!) whenever the tile
> set() methods are invoked).

KD tree? Is this like a BSP or QuadTree? I don't know anything about that so
you may be right. If my tiles store references to all the entities on them,
finding all the monster entities in a set of tiles is going to be pretty
fast.

> This is why I'm tired with this tacit assumption that "Everything Is An
> Object" implies some magical cleaner design. It doesn't. A clean
> design seeks to minimize the number of objects you need.

Clean design seeks to minimize special case logic.

>> like a lot of RL coders are old school procedural C hacks, which has made
>> it
>> difficult to read other source code for ideas of how to do things.
>
> Have you read the source for You Only Live Once?

No, but I will look at it right now. Thanks for pointing it out to me.

Thanks for the thought-provoking response,
John
 
G

Guest

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

Shedletsky <mylastname@stanford.edu> schrieb:
> Definitely it is more efficient memory-wise - that was never
> contested. However, it seems like there is a design advantage to
> allowing the tiles to be objects. For example: If my tile object has
> an EntityEntersTile(Entity *ent) method and I have a Lava tile that
> burns any entity that steps on it, this would be a good place to do
> ent->TakeDamage(10). Without the object model, whenever a creature
> moves in my map, I will have to do the test (If map[new_x,new_y] ==
> LAVA_TILE then...) That's ugly. I want an extensible system, which
> mean I want to minimize special case code like that. The tiles
> probably will store pointers to all the entities standing on them, to
> make getting a list of entities at (x,y) very fast. This doesn't
> prevent a separate list of entity pointers in the map object for
> interating over all entities (to update their states or what have
> you).

This is a good point. A tile can also have EntityLeavesTile(),
Drop/PickUp(Item*), and other tile specific actions.

I don't see what the big deal is. Asking questions like this and only
seeing pro/con OO reactions is sort of useless. How you implement maps
and tiles depends upon how much you want tiles to be able to do, and if
it's very little (such as a tile just being what the tile looks like,
whether it's passable, and what items and characters are on it) then it
may be easier to not make a map a list of tile objects. But every time
you encapsulate something as an object, you make it easier to extend and
refine it.

--
Jim Strathmeyer
 
G

Guest

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

> Sounds a little dangerous to me - most of this stuff either belongs in
> the map object or in separate spell handling code.
>
> Having said that, there is a case for making tiles into object *if*
> they are immutable. By this I mean that you can't change any of the
> fields. If you do this, you effectively have no per-tile resource
> overhead because you use a single object instance for every "wall" tile
> in the entire game, and the reference to these objects only take up 4
> bytes per tile. Any event that changes a tile would just need to change
> the reference for that tile to a different tile object instance.

Hmm. I hadn't thought of doing it that way. That might be a good solution.
 
G

Guest

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

U¿ytkownik "Shedletsky" <mylastname@stanford.edu> napisa³ w wiadomo¶ci
news:del4vc$1l1$2@news.Stanford.EDU...
> But it seems like the IVAN design takes things a little too far... I
> mean,
> spell-handling logic in the map tile object?

Sounds like a bad design.
We have one of the three cases here:
1. a tile object knows (or is able to find out) its position on the
map
2. a tile object does not know (and is unable to find out) its
position
3. tile objects know their neighbours, (eg. have pointers to them) and
make up a map by themselves. There is no additional map object.

In the first case we have a circular dependency: map asks tiles about
some things, and tiles ask map about some other things. This will make
debugging and writing code harder than it should be, especially the
serialization routines.

In the second case - the tile objects will have a very limited use.
All effects concerning area will have to be handled by the map anyway.
This makes tile objects almost useless, they won't encapsulate
anything meaningful.

The third case _might_ work, but seems really complicated and
indirect. Maybe it could be used for hexagonal grids?

Good design is choosing the right algorithms and data structures.
Encapsulating a bad algorithm or a poor structure will not make it any
better.

regards,
Filip
 
G

Guest

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

John <4gjehIqp@mailinator.com> wrote:

> On 2005-08-26, Andreas Koch <nospam@kochandreas.com> wrote:
>> Depends on what you are targeting. If you only want to run on
>> modern Wintel PCs, RAM is no limit. But you should consider that
>> a gig is more than many CURRENT super market PCs have (at least
>> here in germany), and many people still run boxes with Win98 and
>> 64 Meg (and no .NET ... )...
>
> And what roguelike, no matter how bloated, doesn't run on 64MB?
>
>> If you want to port on something like PDAs with 2 Meg of Memory
>> for disk and working RAM, it DOES matter if that 100x100 map
>> needs 100x100 bytes or 100x100 pointers+byte+etc ...
>
> What color screen PDA made in the last 5 years has only 2MB of
> memory? Please provide a model number and link.

Almost all of them, actually. You see, the "memory" advertised is the
combined heap+storage, but almost all of it is allocated for storage.
So on, for example, my Palm Tungsten E (32MB), the heap is only 2MB. On
16 meg Palms, you've got 1MB of heap. On phones, you could have even
less.

--
CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux:
calcrogue.jimrandomh.org/
Remove the "NOSPAM-" from my e-mail address to contact me.