8
\$\begingroup\$

I've been working on a boardgame that has a hex grid as this board:

enter image description here

Since the board will never change and the spaces on the board will always be linked to the same other spaces around it, should I just hard code every space with the values that I need? Or should I use various algorithms to calculate links and traversals?

To be more specific, my board game is a 4 player game where each player has a 5x5x5x5x5x5 hex grid (again, the image above). The object is to get from the bottom of the grid to the top, with various obstacles in the way, and each players being able to attack each other from the edge of their grid onto other players based on a range multiplier.

Since the players grid will never change and the distance of any arbitrary space from the edge of the grid will always be the same, should I just hard code this number into each of the spaces, or should I still use a breadth first search algorithm when players are attacking?

The only con I can think of for hard coding everything is that I'm going to code 9+ 2(5+6+7+8) = 61 individual cells. Is there anything else that I'm missing that I should consider using more complex algorithms?

Improve this question
\$\endgroup\$
3
  • \$\begingroup\$ I can tell you the area for a radius attack is 1 plus the sum of the terms of the sequence given by f(n) = 6(n-1) from n=1 to n=x where x is the number of rows. E.G. 3 rows (10 foot radius) = 1 + 6 + 12 = 19 \$\endgroup\$
    – eazimmerman
    Jun 22, 2012 at 18:39
  • \$\begingroup\$ Here is pseudocode of what I described int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; } \$\endgroup\$
    – eazimmerman
    Jun 22, 2012 at 18:46
  • \$\begingroup\$ It doesn't seem very hard? From {X,Y} you can obviously go to {X-1, Y} and {X+1, Y} on the same row. On the rows below and above you can go to {X, Y-1} and {X, Y+1}. Finally, depending on the even-ness of Y, you can go to {X-1, Y-1} and {X-1, Y+1} or {X+1, Y-1}` and {X+1, Y+1} \$\endgroup\$
    – MSalters
    Jun 25, 2012 at 12:51

3 Answers 3

Reset to default
12
\$\begingroup\$

I guess I'll take the counterpoint here and argue against using static values. In this case, all of the hex regions you're talking about are (a) easy to compute - you don't need to use BFS or anything so complicated; you should be able to iterate over all of the hexes in any of them with straightforward doubly-nested loops; and (b) not something you'll need to compute 'on-the-fly' very often. At worst you should only need to compute them once per turn, and if multiple systems do want the cells touched by an effect then you can easily cache the values off into a 'reachableCells' array or something similar; regardless, the computation is so easy that it should be effectively free to do in terms of per-frame costs.

So what do you get for that? Flexibility. It's easy to say right now that these values will never change, but games have a knack for surprising you; even if it's more likely than not that these regions won't change, you give up essentially nothing by building that flexibility in, and there's a good chance that future-you will thank you down the road. What's more, even if those are the final regions you use, well-written loops for iterating over the regions will be substantially easier to understand and debug than any sort of fixed-tiles array will. I just really don't see any meaningful gain for going with hard-coded data compared to the benefits of going the other way.

Improve this answer
\$\endgroup\$
11
\$\begingroup\$

If the values will never change, they may as well be static. Why waste CPU time recalculating something that will be the same as last time?

However, they don't necessarily need to be 'hard-coded':

  • You can put the values in a data file, and load that in at the start.
  • You can perform the search during play and cache the values once you find them.

The first way makes sense if you think you might change the map shape or size in future. The second way makes sense if calculating the static values is a bit tricky.

I have no idea what a six-dimensional hex map looks like, or why there are 9+2(5+6+7+8) cells involved, but the best result for your situation - and indeed most situations in game programming - is to code in whatever gets you the correct result most quickly. You can generalise it to an algorithm later if you need to. "Code for today", as some say.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ All of this. First make it work then appease the ego ;) \$\endgroup\$
    – Mike Cluck
    Jun 21, 2012 at 23:02
  • 2
    \$\begingroup\$ Just to clarify your confusion, I think the OP when referring to a 5x5x5x5x5x5 hex grid was not referring to 6 physical (or virtual) dimensions, but instead a hexagon of hexagons, where each side of the hexagon contains 5 smaller hexagons along its length, similar to this (ignore the black dots). In that case the board would contain 9+2(5+6+7+8) cells. \$\endgroup\$
    – user17344
    Jun 22, 2012 at 4:10
  • \$\begingroup\$ Yeah, I saw that from the diagram posted up in an edit. \$\endgroup\$
    – Kylotan
    Jun 22, 2012 at 11:43
0
\$\begingroup\$

Q: is this the only hex game you'll ever write? No?

A: Then obviously you should try to be flexible wherever it doesn't cost you a lot of extra effort. Regardless how you define the board, represent it at runtime with explicit links. It's very convenient to code movement and relationship logic in terms of traversing links, which is independent of the size or topology of the board.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .