Hot answers tagged hexagon
36
Octogons:
Hexagons:
The gaps in the octogons make for an unappealing game world.
Typically, if you wanted to allow for eight directions of movement, you would just use squares.
18
The solution is actually simpler than expected. The trick is to use Minkowski subtraction before your hexagon technique.
Here are your rectangles A and B, with their velocities vA and vB. Note that vA and vB aren't actually velocities, they are the distance traveled during one frame.
Now replace rectangle B with a point P, and rectangle A with rectangle ...
17
I have been able to come up with a few reasons myself, but I'd really like to hear more.
Horizontal layout matches the layout of the keyboard. You could use WEADZX for movement, similar to WASD on square grids. On the other hand, I have also found suggestions that QWEASD is a natural fit for vertical hexes.
Horizontal hexes seem to be better suited for ...
16
A hexagonal ring with the radius of N consists of 6 straight lines, each with length N - see my extremely crude example below :) For N=2:
The arrows cover 2 hexes each.
I assume you have some functions which give you the neighbouring tile in a specific direction, like north(), southeast() etc. So your algorithm, in pseudocode, should be something like ...
13
A few answers!
The coordinate system I've seen most often for hex-based traversal is one where the player can move in every normal NSEW direction, as well as NW and SE. Then you just render each row half-a-square offset. As an example, the location (2,7) is considered adjacent to (1,7), (3,7), (2,6), (2,8), and the weird ones: (1,6) and (3,8). Meanwhile, if ...
13
Sounds like you're leaning toward horizontal as having more advantage. For what it's worth, bees agree with you when they build their honeycombs:
The axes of honeycomb cells are always quasi-horizontal, and the
nonangled rows of honeycomb cells are always horizontally (not
vertically) aligned. Thus, each cell has two vertical walls, with
...
12
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 ...
10
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 ...
9
From a technical and programming perspective, there should be no fundamental difference in data structure between the two orientations - any reasonable scheme should be easily modifiable to work well with either setup.
Design-wise, in the end it will come down to preference — as you've noted, there are multiple games using either scheme, which is ...
7
First of all, in the case of axis-aligned rectangles, Kevin Reid's answer is the best and the algorithm is the fastest.
Second, for simple shapes, use relative velocities (as seen below) and the separating axis theorem for collision detection. It will tell you whether a collision happens in the case of linear motion (no rotation). And if there's rotation, ...
7
Your hex orientation will influence both your general aesthetics and your asset production.
If you choose vertical tiles, you can make your hexes twice as wide as they are tall and have pixel-perfect accuracy. Here are some 64x32 hexes.
Note that the diagonal edges are at 45 degree angles, making them easier to render in pixels.
The narrow height of ...
7
Before I answer the question you already asked, some notes:
You can use A* with the original grid system you are using. The key things you need are neighbors and distance (for the heuristic). For neighbors with your grid system, you need to do something different for even and odd columns (as you mention); here's how:
neighbors = [
[ [+1, +1], [+1, ...
7
Basically what you want is a monohedral tesselation (or tiling), that is a coverage of the entire plane (assuming 2d) with a single shape where the tiles do neither overlap nor leave gaps.
There are lots of shapes with which this can be done but when we introduce other constraints, usually orientation should stay the same or they should conform to a ...
7
Use a Canonical (Or oblique) coordinate system (with axes at 120 degrees) to identify the hexes that are in the triangle. Then convert the coordinates of those hexes (with a homogenous transformation) to Rectangular coordinates for display. The utility toolkit I linked to above could be of help in writing this code.
7
It seems to me that the easiest way to do this would be in two steps:
Determine the smallest possible convex polygon surrounding all red nodes.
Expand the convex polygon until it reaches the largest possible area without intersecting with white nodes.
Suppose we start with this situation:
Look at that glorious programmer art. I've chose red and green ...
7
I would go with vertical layout if you are using any sort of bird's eye perspective, as in the image above.
Why? Because all walls will be visible. If you use horizontal layout, and you have walls that run along the vertical lines, you will not be able to make out details on them very well (such as doors or gates). Furthermore, if you are using the ...
5
If you are building a strategy game, the game requirements and design itself should dictate which orientation you choose. Note that defensive lines are more easily held with the grain than against it, so your choice of grid orientation relative to map orientation will affect game play. To emphasize defence, such as in WWI, align the hex grid with the natural ...
5
The parallelogram coordinates you're using are easier to work with, but they do have the drawback of being weird for rectangular maps. One approach is to store it with the offset coordinates but actually use parallelogram coordinates in your game logic.
Observation: in each row of the map, the grid data is contiguous. All the wasted space is on the left ...
4
Personally, I would prefer simplicity over saving memory. Don't optimize until needed!
If you're still bent on saving a few bytes, here's how you can do it:
Slice the parallelogram in half to form two right triangles
Rearrange the two triangles to form a rectangle.
(Note I added the green buffer strip so the math works out nicely.)
Python code to map ...
3
Try this: if w,h are the width and height of your tile image, replace the first two lines of that code sample with just
tile._x = x * 0.75 * w;
The factor of 0.75 comes from the geometry of hexagons, where the spacing between adjacent columns is 3/4 of the diameter of a single hexagon. (It's the same origin as the 1.5 in the original code, where s was ...
2
The Cocos 2D library has support for rendering hex tile maps. I have not used it, but the library has been around for years and seems quite popular.
That might be more for rendering than for doing calculations on the hex map though. Fortunately what you ask for is quite simple to implement anyway, especially if you use a good x/y coordinate system for your ...
2
I have just postd a library of hex-grid utilites on CodePlex.com here:
https://hexgridutilities.codeplex.com/
The library includes path-finding (using A-* a la Eric Lippert) and includes utilites for automated conversion between jagged (termed User) cordinates and non-jagged (termed Canonical) coordinates. The path-findingn algorithm allows the step cost for ...
2
I don't think using the 'hexagon' is all that helpful. Here's a sketch of a way to get exact collisions for axis-aligned rectangles:
Two axis-aligned rectangles overlap if and only if their X coordinate ranges overlap and their Y coordinate ranges overlap. (This can be seen as a special case of the separating axis theorem.) That is, if you project the ...
1
I don't think there is an easy way to calculate the collision of polygons with more sides than a rectangle. I would break it down into primitive shapes like lines and squares:
function objectsWillCollide(object1,object2) {
var lineA, lineB, lineC, lineD;
//get projected paths of objects and store them in the 'line' variables
var AC = ...
1
Consider this:
public sealed partial class HexCoords {
static HexCoords() {
MatrixUserToCanon = new IntMatrix2D(2, 1, 0,2, 0,0, 2);
MatrixCanonToUser = new IntMatrix2D(2,-1, 0,2, 0,1, 2);
}
protected HexCoords(CoordsType coordsType, IntVector2D vector) {
switch(coordsType) {
default:
case CoordsType.Canon: _vectorCanon ...
1
It's not necessary to distort your map, as conversion between rectangular and "canonical" coordinates is quick and easy. Here is a link to an intro on how to do it:
Converting between Rectangular and Canonical hex coordinates
This technique combines lazy evalutation with caching of calculated conversions.
1
You could treat circles (balls) as hexagons, and calculate exact position of a circle mathematically, but I suggest you use a grid, as in these answers:
Making an efficient collision detection system
Fast, accurate 2d collision
Then get balls registered on a cell under mouse cursor and iterate through them to see which is in shortest distance to the ...
Only top voted, non community-wiki answers of a minimum length are eligible
