Re: Cheap tricks for map data structure

At Fri, 20 Feb 2009 01:13:19 -0800 (PST), Mingos wrote:

On Feb 19, 7:32 pm, Radomir Dopieralski <n...@xxxxxxxxxxxx> wrote:

But an array of Cell objects is more manageable, more elegant...
simpler in the long term :).

I really can't agree with that, but I guess it's because I only use
fast, low-level programming languages that would let me get away with
such an inefficiency only when my resources are already constrained,
so I can't get away with it anyways. Well, I'm happy it works for you.
Let's see if this one works for me.

Is C++ a slow, high-level language?

It can be used as such. It can be much lower-level and several orders
of magnitude faster (as long as you are careful) than other high-level
languages.

If you write everything in
assembly language, then indeed, my language of choice is both slower
and higher level. But I reckon you use C++ as well as I do, so this
particular argument is a missed one.

I mostly use Python and JavaScript, and C when I need some computational
power. I was forced several times to read and write C++ programs, but I
don't want to remember that.

As for the inefficiency - I don't notice any inefficiencies here. I
don't really care whether the game eats up a few extra kB of memory.
The computational cost isn't an issue either - I think you're looking
the slightest defect in something that otherwise works perfectly.

Well, it's not just a few extra kB of memory, when you multiply it by
the number of squares of all the maps you keep in memory. It really
grows fast. Computational cost is a smaller issue, but it all adds up.

No, the cell object doesn't know its own coordinates.

That's good. So it's not exactly a "map square object" anti-pattern that
gives so many headaches. You are just improperly using objects instead
of structs.

No, the garbage
collector - if there was one in C++ - wouldn't have anything to do in
my case. I don't delete objects that will be reused and when an object
has to be replaced by a new one, there's always a method that handles
the issue so I don't even have to remember to delete the old one
before creating the new one.

Well, the garbage collector has to keep track of all the objects at all
times, no matter if you delete them or not. Depending on the strategy,
this might involve for example copying all "alive" objects each time
a garbage collecting sweep is made. Having millions of them doesn't help.

Your Map class with separate arrays, hash tables and whatnot are way
more difficult to manage. for instance, when you wish to print the
contents of one cell on the console, how many times do you enter the
same coordinates for various arrays in the Map class? Whereas I can
simply put a method in my Cell class that does printf("%d %d, %c,
%s...",a,b,c,d,...);, thus entering the coordinates once and letting
the cell do the thinking.

My games usually use curses and print the characters representing the
contents of the map square, in the traditional roguelike fashion of
ascii-art dungeon. Of course if you decided that it is more intuitive
to instead print all the data in separate lines and let the player
figure out what goes where, it's your choice, but I can see a hint of
a bad user interface here.

Btw, I can simply put a method in my map class: debug_print_square_info
that will display detailed information about the map square, nicely
formatted, maybe even visualized in different ways than just a row of
numbers. And I can then reuse it in many places without copy-pasting.

In other words - the fact that you disapprove of using cells as
separate objects doesn't make it an inefficient way of dealing with
things.

No, it's exactly the other way around.

Your arguments against it are weak and only show that you
never really thought about how such a way would work.

I tried it in practice.

The memory overhead is barely an issue.

Depends on your map size and the number of maps you hold in memory. But
it's a trap that you set early on, when the problems are not yet visible.
Using an abstract map class lets you change your decisions later on easily
without having to rewrite half of your code.

The computational cost for creating so
many objects is still near nil on any modern machine (maybe unless I
coded for a mobile phone, which I don't).

The fast language lets you get away with bad programming practices.

Storing unnecessary data in
the cell is not an argument against the method itself, but rather the
lack of imagination of a hypothetical programmer. In the same way, I
could criticize using floats in general (float operations have a
higher computational demand, after all, plus, they're 4 bytes each),
but I don't because I assume you (and any programmer) know when a
float is a must and when it can be replaced by an integer.

If your map square objects are not used outside the map handling routines,
then they are simply an implementation detail that is not really a part of
design and can be changed at any moment if the need arises. The whole time
I'm criticizing a common design pattern where the map square is part of
the design, has its own class (or a hierarchy of classes), its reference
is passed around the whole program, etc. That's what I mean by "object".
If your language lets you use objects as some sort of heavier structs, but
they are not really part of your design, then that's just a small
inefficiency that can be easily corrected later if needed. I'm not arguing
against any particular type in any programming language, as well as
I don't argue against other implementation details of any particular
component of the game here.

--
Radomir Dopieralski, http://sheep.art.pl
.

Relevant Pages

  • Re: Cheap tricks for map data structure
    ... one map in memory at each time? ... So it's not exactly a "map square object" anti-pattern that ... The fast language lets you get away with bad programming practices. ... design and can be changed at any moment if the need arises. ...
    (rec.games.roguelike.development)
  • Re: Cheap tricks for map data structure
    ... A huge map, 500x500 tiles, where each tile has, ie, 8 ... means it occupies about 8 MB in memory. ... "object oriented programming" that I saw, ... But if you have an object per map square, ...
    (rec.games.roguelike.development)
  • Re: what is the difference between the two kinds of brackets?
    ... programming this language for 5 years, and I still can't figure out the ... you had a map with x,y coordinates and you wanted to place items on that map ... The lists cannot be indexes to directories because they are mutable. ...
    (comp.lang.python)
  • Re: object system...
    ... for that you need machine language. ... isn't even as fast as other systems programming languages. ... Stroustrup's stated design goal was to enable ... all manner of elegance or abstraction can be sacrificed for speed, ...
    (comp.object)
  • Re: Macro Question: Paraphrasing
    ... why not use keywords for everything? ... which is the language used by the human reader to map symbols to ... It's the basic building block of the Lisp language. ...
    (comp.lang.lisp)
Loading