Re: Every tile an object?!

In article <1125404451.955539.257550@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Jeff Lait" <torespondisfutile@xxxxxxxxxxx> wrote:
> Damien Neil wrote:

> > Better approach: Make all tiles singleton classes.
> >
> > i.e., there is exactly one instance of each type of tile, so there is no
> > such thing as an "outdated reference". There's only one object to have
> > a reference to.
> Then, instead of storing pointers to the singleton class, we can store
> indices into an instantiated array of such classes. We can also
> initialize the data fields of the singleton classes from an external
> data file, thus letting us add new tile types just by editting one data
> file location.

....which adds an unnecessary extra level of indirection. If you're
using singleton classes, there's no reason not to store the pointer.
That's what singletons are for.

> > You could assign an integer to each terrain type, and build an array to
> > indicate visibility:
> >
> > vis += Visibility[tile[x][y]];
> >
> > Or you could make each tile an object and call a method to look up the
> > visibility:
> >
> > vis += tile[x][y].visibility();
> I would rather do:
> vis += map->getVisibility(x, y);

The two options I presented are different ways of implementing the
getVisibility() method on the map object.

> I don't see how either system would give you that. You haven't passed
> down the player's class type, so unless you are hacking your way back
> up with a global variable (which would mean all creatures see farther
> in a forest if the player happens to be a druid) there are problems...

Obviously, if the viewer can affect the visibility of different tiles,
you will need to include that information in the call to whichever
function or method contains the special-case check implementing that

- Damien