Uh... yet Game Programming... or Is there a way to build tilemap graphics in Rev?

[Dave Beck]

I wrote a game that uses a rev app as a level editor. I used the same
tilemap approach that is being discussed, with a grid of buttons which take
on different images depending on what is being 'painted' on the level. There
are close to 600 buttons in all and the speed is remarkable. Painting
objects takes place in real time. Entire levels load in a few seconds on my
400 Mhz G4. I don't know about scrolling though..

Both the game and the level editor are available at:

http://www.crystalpiersw.com

There are both Macintosh and Windows versions, but you need to register to
use the Macintosh world editor (soon to be changed). Windows users can
already use the world editor without registering.

I found that it is imperative for decent performance to NOT keep the
information about what is in what position in the buttons themselves. For
instance, to query what is in grid pos (2,4), you should NOT have to find
the button at (2,4), and then access some custom property of that button (or
the button's name or icon) to determine what occupies that grid spot. A much
faster approach is to keep a behind-the-scenes field of what is where, each
line representing a row of the grid and each item representing a column.
When you need to find out what is at pos (2,4), inspect item 2 of line 4 of
your field. Also, I found it helpful to keep a separate 'lookup' field of
button ids, again each line representing a row of the grid and each item
representing a column. When you need set the button's icon at (2,4), you can
lookup the button's ID from item 2 of line 4 of your lookup field. Probably
both these fields could be replaced by arrays (perhaps with a speed bonus?),
but I have had some trouble with two dimensional arrays in the past and
opted to steer clear.

Abstracting the logic that keeps track of what is where in the level as well
as giving the right icons to the right buttons into a 'brick wall' library
was also helpful.

>From what I've seen I think a scrolling game could be feasible using the
button-grid approach but speed would definately be a problem it it wasn't
structured correctly. All game logic should take place 'behind the scenes'
and should NOT depend on getting or storing information in the buttons
themselves. Just my 2-sense. Good luck!

Dave