Hello,
Recently I've been implementing a hex tile grid system in the Unity3D engine to get some practice in both the engine and the concept, but I'm having some issues with how the structure of the grid should be. The grid will be used in a turn based strategy game, so I think in the logic of the code, the tile will hold onto the character (have a reference to the character object in the tile). Also when I think about how I would normally move a variable in a normal 2 dimensional array, I would go to the section of code that houses the array itself and move or change the variable from the grid "manager". I'm assuming this would work the same way in a hex grid. Then there's the issue of how a character is going to attack another character. What I was thinking was that the grid manager will move the character, and when it comes time to do some action to another character, the grid manager will check to see if an enemy or something is in that tile, and if it is, move to the code inside the character class, and provide, for example in an attack method, the reference to the target so the characters will interact with each other directly. In my mind this is the best way to separate the responsibilities of the grid and the characters on that grid.
Is this idea sound or is there a better way of doing things?
Wrapping my head around a hex tile grid
There isn't much difference from a high level between a normal grid and hex grid. I think if you re-order your logic based around your characters vs the grid tiles you'll be better off. Logic flows more smoothly since the most important operations usually are character 2 characters.
So instead of a grid manager you would have a character manager which manages characters, which happen to live on a hex grid. The movement of course is dependent upon the character type and the grid itself. There will still be a grid manager but it will only be used to resolve character 2 grid interactions like finding paths or free locations around a character etc..
Good Luck!
So instead of a grid manager you would have a character manager which manages characters, which happen to live on a hex grid. The movement of course is dependent upon the character type and the grid itself. There will still be a grid manager but it will only be used to resolve character 2 grid interactions like finding paths or free locations around a character etc..
Good Luck!
Code wise, does this mean characters will need to have a module in them that has a reference to the grid? So they can check to see movements and distances.
My current game project, Goblinson Crusoe, is a hex-based game. The way I handle it, though, is that the underlying scene manager is just a basic rectangular grid, for simplicity. The hex system is just a layer that sits on top of it. In this layer, I can convert a World coordinate to a Hex coordinate, and vice versa (although, when converting from Hex to World, I just calculate the World coord of the hex center). Objects, then, don't need to track their current Hex coordinate, but can just call the hex layer to calculate it when needed. The hex layer also provides other operations such as listing all neighbors of a given hex, listing all hexes within a given radius of a hex coordinate, and so forth; pretty much any kind of hex operation.
Movement and animation are all done in world coordinates. Pathfinding is done on the hex grid. So when a character wants to move, the pathfinder will try to find a valid path on the hex grid between the character's hex tile and the destination tile. This path is generated and returned as a list of hex coordinates. Since the game is a turn-based RPG fixed to the hex grid, this set of hexes is simply converted to a set of world coords representing the centers of each tile, and the character is progressed along the vector path thus produced.
Since the underlying scene structure is a simple rectangular grid, there is nothing weird to worry about as far as trying to manage the scene as a hex grid. Objects don't belong to a given hex, but they are maintained in the spatial grid. Frustum culling using regular grid cells is quicker than trying to do it with hex-shaped cells. Hexes are an appropriate abstraction for the game board, but not necessarily appropriate for the scene structure, and you just compound your work by trying to force the issue.
Movement and animation are all done in world coordinates. Pathfinding is done on the hex grid. So when a character wants to move, the pathfinder will try to find a valid path on the hex grid between the character's hex tile and the destination tile. This path is generated and returned as a list of hex coordinates. Since the game is a turn-based RPG fixed to the hex grid, this set of hexes is simply converted to a set of world coords representing the centers of each tile, and the character is progressed along the vector path thus produced.
Since the underlying scene structure is a simple rectangular grid, there is nothing weird to worry about as far as trying to manage the scene as a hex grid. Objects don't belong to a given hex, but they are maintained in the spatial grid. Frustum culling using regular grid cells is quicker than trying to do it with hex-shaped cells. Hexes are an appropriate abstraction for the game board, but not necessarily appropriate for the scene structure, and you just compound your work by trying to force the issue.
@TheAsterite depends on how complex the grid and game is. Some grids are nothing more than flat sheet, x,y coordinates will suffice, other grids are complex multi-level hex voxel with area of effects and custom logic executing on them etc.. depends on your game. For now just a simple 2d coordinate should be sufficient.
So in a basic strategy rpg, the tiles need height, be impassable at times, and figure out range for the characters. Height will just be variables compared with the characters jump value. The 2 heights will be subtracted, and if it's withing +- the character's jump, the character can move there. For now that's what I'm going to start off with. JTippetts' approach seems to work best for what I need the grid to do. I'm not sure what you mean by a multi-level hex voxel with area of effects though. It seems that JTippetts' approach solves that issue too. The path-finding and range algorithms tied to the grid should be able to take care of attack ranges and area of effects.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement