Jump to content
  • Advertisement
Sign in to follow this  
TheAsterite

Unity Wrapping my head around a hex tile grid

This topic is 2130 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
@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.

Share this post


Link to post
Share on other sites
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. Edited by TheAsterite

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!