Hi!
It's a LOT easier to redefine your game "board" so the "squares"
are a different size if you use a single Canvas subclass.
Define a pair of public properties, "BlockWidth As Integer" and
"BlockHeight As Integer" so they're visible in the properties window
when you select this canvas subclass in the window in which you've
placed it. Now, define a pair of protected or private properties,
"fViewWidth As Integer" and "fViewHeight As Integer" for it as well.
In the Open event of the canvas subclass, put:
Sub Open()
...
fViewWidth = Me.Width \ BlockWidth
fViewHeight = Me.Height \ BlockHeight
...
End Sub
Now these two will give you the number of blocks/cells/squares
that your game board supports.
Alternately, if you wish to make the "board" parametric w/respect
to the number of squares across/down (instead of by the size of the
squares), reverse the logic above. Define "ViewWidth As Integer" and
"ViewHeight As Integer" as two public properties of the canvas
subclass, and define "fBlockWidth As Integer" and "fBlockHeight As
Integer" as two protected/private properties of the canvas, and -
again - in the open event, put:
Sub Open
...
fBlockWidth = Me.Width \ ViewWidth
fBlockHeight = Me.Height \ ViewHeight
...
End Sub
In both cases, the "view width/height" tells your code how many
squares/cells across/down your game board is, and "block width/
height" tells your code how big the cells are (in pixels). You would
use this information when you go to actually draw your game "pieces"
within the cells/squares.
In the first case, you would set the size of a cell/square to a
fixed measurement in pixels (32x32, for example), then the board size
will automatically change if you make the window bigger/smaller (and
you lock the canvas' sides to the window edges with the "Lock Left",
"Lock Top", "Lock Right" and "Lock Bottom" checkboxes.) If you need
it resizable in realtime, you can trap the window's resize event, and
perform the calculation in a separate sub (refactor the above code),
and call it from both the Open() and Resize() events. Make sure you
refresh the canvas to force a redraw with the new "size" in effect!
The catch is that with this approach (the single canvas), your
canvas has to be "smarter" since it now has to manage the entire
view, but this makes it easier to connect up a controller class
between it and your model class(es). The advantage is that everything
is now handled "under one roof", and you don't have to worry about
what happens if you resize the canvas, nor about changing the board
or tile/cell/square size.
On Jul 30, 2009, at 12:11 AM, <timm@lisauskas.net>
<timm@lisauskas.net> wrote:
Hi all,
I have a question about the advantages/disadvantages of using an array
of Canvases (Canvii?) as opposed to a single Canvas that's
programmatically subdivided. Consider this:
A grid- based game board that can be of a player- determined size.
Each
cell will have a background color, possibly a graphic image, and be
clickable so as to change state (active, not active, etc.). When the
player saves their game the state of each cell will have to be
stored to
file, and saved games will have to be read from a file as well.
I thought an array of Canvases might work better, but what kind of
issues might I run into? For example, while I imagine a 20 x 20 grid
(400 Canvas objects) would be no problem for any modern computer to
handle, what about something on the order of 100 x 100? 1000 x 1000?
An array of Canvases would also more easily allow for oddly- shaped
grid
maps, I believe. Instead of a simple square 20 x 20 I could have
designs such as a plus sign, square with a hole in the middle, and so
on. Game rules (like what does a given cell do when the neighbor cell
is affected) could be added to the Canvas subclass easily.
I think a single Canvas would avoid the possible memory- related
issues
an array of 1,000,000 Canvases would have, but would that outweigh
whatever disadvantages the single- Canvas approach has? A single
Canvas
seems slightly less OOPish to me, too.
Thanks for any advice!
Timm
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|