Grid-based Game Design

BlitzMax Forums/BlitzMax Programming/Grid-based Game Design

Torrente(Posted 2008) [#1]
I've had an idea of a grid-based strategy game running around in my head, but I've run across a few problems concerning the structure.

The types that I currently have are
TGrid -- The type to hold the array that represents the grid
TGridEntity -- A base type for anything that'll go into the grid
TUnit extends TGridEntity -- The basic unit type

Should I have a global instance of TGrid, and then reference that in the TGridEntity functions? Should the array in TGrid hold all of the units, or should the Units know their respective positions in the grid, or both? Should I update the GridEntity's by adding them to a list and then looping through it, or by adding them to the TGrid array and looping through that?

I'm really terrible at design, I've discovered -- I always get stuck early on, and then get too discouraged to finish. I'll probably have some more questions later.

Any help would be appreciated, thanks!

ps. Also, since this will be a two-player game, should I add a player type that contains all of the player's units, or should the units contain a reference to the player?


slenkar(Posted 2008) [#2]
If you were using Blitz3D you would have to code work-arounds but blitzmax is awesome..

I usually make it so that units know where they are and iterate through a list of units

You should make a player type that contains a list of units


Torrente(Posted 2008) [#3]
So the units will have no idea which player controls them unless I code a Player.owns(unit) method or something similar?


gameproducer(Posted 2008) [#4]
I think Jeremy was thinking that unit won't know who is controlling them. They just get orders and move to where they are told. They don't care who ordered them.

The players know which units they are controlling.


Torrente(Posted 2008) [#5]
And what about when a unit goes to take action against another unit on the board? Won't I have to check that the other unit is a member of the opposite team, or should the Player type handle the movement/action, as in Player.move(unit, x, y), and Player.action(myUnit, otherUnit)?


Arowx(Posted 2008) [#6]
You may not want blue on blue incident's though, at least in general players destroying their own unit's would be considered a bad thing!

The default unit could have a simple team/player id or reference which would allow simple unit/enemy checks.

The key is to keep it simple, but stay flexible which is a lot harder to do than you would think!

Try of think of it from the players perspective what commands can the players issue and what objects recieve those commands...

Then work out what those objects need to do to complete those tasks.

E.g. A player commands a unit to engage an enemy

I believe this is called Use Case Design and the aim is to think about what the user will want the system to do and then what each object needs to do to complete the task.

Work out all the player commands/actions and then work through how the objects in the sytem complete those tasks.


gameproducer(Posted 2008) [#7]
If units need to know who are the enemies, then you can add "controlled by player ID/refence" variable in the unit (I think player equals "team" in your case).

Then you could have method "TUnit isMyEnemy(unit)" that would check "if self.controlledPlayer is same as unit.controlledPlayer then return false, otherwise return true" or something like that.


tonyg(Posted 2008) [#8]
I think it would be useful to know who owns which grid for strategical decisions especially when using Influence maps. Keeping a central area with this information rather than having to re:reference the player seems like a good idea.


Torrente(Posted 2008) [#9]
Thanks everyone, here's what I have so far.

TPlayer contains a list of TUnits, carries out the movements/attacks etc, and changes TGrid accordingly. For changing turns, TPlayer has beginTurn() and endTurn() methods, which carry out operations on the TUnits (such as telling them they're active, or changing their colors, etc).

TUnit contains an id which matches its player's id.

TGrid has an array that contains references to the TUnits for pathfinding, etc.

This brings up another question. Should I render the TUnit instances using a global list, or through the player's lists, or by looping through the TGrid's array?


Arowx(Posted 2008) [#10]
That depends...

If the grid of the game fit's on the screen and all unit's can see every other unit then just go through the unit list!

However if the grid is larger than the screen then work from the subset of the grid that is visible!

If unit's have a limited scan range then you need a player/team specific unit draw selection process!