Handling large playing areas

Summary

-

We have a playing area, or 'board', effectively consisting of a matrix of squares.

The board is potentially very large. (100 x 100 grid, perhaps more?!)

What possible approaches/architectures would be suitable for handling such a potentially large playing area where by each square can 'react' differently to a player 'landing' on it.

Details

-

The board itself need not actually be made of individual 'squares', but the way in which 'player pieces' are to move and be positioned on the board is on a grid-like pattern.

Each square is 1 of a number of types, and each type has different 'effect' when a player piece 'lands' on it. (each square type must look different too).

Prototype

My original prototype used a different class for each square type, and a separate instance for each individual square. Each of these classes extend javax.swing.JPanel, and contain the specific behaviour for that square type.

However, JPanel is a large class and having 100x100 or more classes in memory (for the board alone - not to mention the game and player classes etc) is an EXTREME drain on resources. In fact it is simply not possible to do this (without perhaps fiddling with the JVM memory settings).

So clearly this 'an object per square' approach simply isn't workable, but I'm unsure how to build a board consisting of various types of squares without having to have a separate square object (or some kind) for every individual square.

Any pointers for such a problem?

thanks

John

(johnsenford@hotmail.com)

[1634 byte] By [johnsenford] at [2007-9-27 22:31:59]
# 1
Hi,Check on the Flyweight pattern in the GoF's book. The situation you've described sounds like an ideal situation to apply this pattern.Flyweight - Use sharing to support large numbers of fine-grained objects efficiently.Thanks,Balaji
GBalaji at 2007-7-7 13:10:49 > top of Java-index,Other Topics,Java Game Development...
# 2
Try using JLabels instead of JPanels as the ancestor for your squares. I've had 75x50 maps work with them with no problems...
bh94704 at 2007-7-7 13:10:49 > top of Java-index,Other Topics,Java Game Development...
# 3

It looks like a typical game trade off situation: Speed vs memory. You might have to choose one. Or, you can settle somewhere in between. But you cannot have both.

If the memory is the issue, you might want to load only needed squares or grid cells of the main board to the memory. I assume your board is a lot bigger than a screen size. You have to find a fitting swapping method for this. Depending on how many cells fit into a screen? Are you going to have a scrolling scene? Do the players move around fast. Is it a multi player?

No? You go for the speed as knowing jvm runs in 64megs of memory. I think that's huge!! Find a good way of representing your grid cell. I wouldn't use anything starting w/ J. Use something that is immediate child of a Component, like Canvas or Label. All the swing components derive from Container which you don't need. Do you need a swing comp.?Keep it simple. Use what you need. You probably need a component that you can draw on...

Either case, you better know well what each grid is made off. So that you create all of the combination of little pieces to make up a cell. Like tile-based games. Tiles make up your grid cell, grid cells make up your board. Once you get this, you can easily deal with speed vs memory trade offs.

ibosan at 2007-7-7 13:10:49 > top of Java-index,Other Topics,Java Game Development...