Android Question Hexagonal Board

A lot will depend on the game and its rules - for example, are all the spaces always filled? Do the attributes of neighbouring hexagons have an impact on what happens in the one you're in at the moment?

Without knowing the rules of the game, it's hard to be certain, but it may be that one solution would be to create a hexagon class, and then you could store all those in your array, so it's something like


Your class module might expose various attributes for the hexagon, like terrain type, or perhaps record the neighbours for each position one, if that's important, eg hexagon.neighbour_1, hexagon.neighbour_2 and so on.

If the tiles themselves don't do anything, then you could just create Hexagons using the Type keyword, eg


But if it would be handy to include some of the game logic in them - for example, if one hexagon can invade another depending on the terrain - then you probably want to create a full blown class file, which would allow you to say things like



There are lots of different ways to solve a problem; you really need to think first about how the rules of the game work, and that might then give you a good starting point for creating code that helps implement them.

The game is a WWI trench warfare game. The team exits the trench and attempts to make it across no man's land. The hexagonal tiles on the map represent craters, barbed wire, and debris. When a unit occupies a tile, the only considerations are where they are and what kind of terrain they are in. When a unit is attacked, the only consideration is the terrain hex currently beneath the unit. Adjacent hex considerations shouldn't be necessary.

I love the idea of creating a Hexagon class, if only to identify the X, Y coordinates and the terrain type. I'm away from my program but would it look like this?

Code:
Type Hexagon (Terrain as String, Row as Int, Col as Int)

How would I create an array of these hexagons that could be decoded and then drawn upon the corresponding canvas?

Well, there are lots of ways you can do all these things. First, a Class is defined in a separate file - I'm pretty sure there are some guides around here to creating your own class.

As for drawing the map, I would guess that if all the hexagons form a static pattern for each game, you could do something like this:

1. Work out how large the playing area is, based on the screen.
2. Work out how large each hexagon can be - if the pattern has a maximum of X hexes across or down, then you can use that, based on the largest dimension of the screen
3. Now you know the size, you can calculate the coordinates for each one; treat them as overlapping squares to make things simple; you'll have to work out your own rules for how you number them, eg from top centre, bottom left, or whatever
4. If the terrain is random, then perhaps in your class constructor you can assign that random value
5. Create a set of bitmaps for the different sorts of terrain

You might generate a new random hex from your class to fill the board with something like


Somewhere, at the end of each turn, you'll probably be updating the display. That's where you iterate over the array, and based on its position in the array, you calculate the co-ordinates (create a sub that returns them, for example), check the type of terrain, and draw the appropriate bitmap at that screen position.

To work out your positions, start small. I'm assuming all hexagons abut each other directly; so imagine just seven of them - one in the middle, and one touching each of its edges. Draw that out on a piece of paper. Think about how you might number them, and then how to work out a coordinate system.

I think this is one of the sorts of problems where a good time spent with paper and pencil will mean you'll spend much less time struggling with code.

Not entirely. The game is finished, I'm just trying to port it out. I can deconstruct code and look up examples well enough, but when it comes to adapting it for my own use, my learning style demands that I see something almost exactly identical to what I'm trying to do.

What I need seems to be so basic that almost everyone dismisses it as common knowledge and it goes unmentioned. I already have the grid coordinates, size interaction and interspatial relations between hexes worked out. I need a code example for the following scenario:

Here is the map. It's blank (no hex tiles upon it, just clear terrain)
Here is a setup profile. This will hold all of the information for a particular scenario.
Here is the code that deconstructs the profile and brings it all together visually.

Informational particulars such as exact coordinates, variables, and images I can work out on my own, I'm just trying to get some code structure. Something like "you need to store your scenario profile using <THIS TOOL>. It should look like <THIS>."

A bit about how my mind works: once I canonize a way to do something, I never forget it or need assistance on it again. My VB6 CD-ROM has a copyright of 1999 on it. I've read the VB6 to B4A thread but given the inefficient self-taught way I learned to use that language, I was hoping to invest a little more study into B4A and get away from those early mistakes of "well, this code is working, but it's 500 lines long, but it's working."

So, is there an accepted norm of how someone puts together a grid of objects? Because what comes naturally to me is identifying all 113 variables individually and creating massive blocks of code to handle them all. How do I do this and keep my code simple and efficient? I appreciate your help but I don't see things the same way others do. If there was source code out there for a hex board game, I'd deconstruct that and adapt it to my needs. Do you know of any examples? Once I figure this out, I'll post a tutorial.