hexagonal grid issue

So I have this idea (actually I “borrowed” it from another game… but anyway) for a “simple” game I want to make to improve my BGE skills just a tiny bit (and put all those nice comments and guides I’ve read to use).

But… I’m facing with a rather… annoying issue just from the start of it.

I’d like to have physics turned on with rigid bodies and the lot. I also plan on working with a hexagonal grid system, but if I turn on physics and I choose anything else than “box” for the collision bounds on the ground plane, the rigid body “units” start moving about, which is not what I want. If I do choose “box” then the mouse collides with the plane in areas outside of it’s “display” bounds, which is not desirable.

If anyone could have a solution to this I would be really grateful.

It will be a easier to understand once you look at the file. I also know that I could probably get away with it if instead of one big plane I would use a bunch of hexagonal “grid boxes” but I wanted to get in coding a bit and… well, devised the grid system on that big plane. Is it possible to have it collide with the mouse just inside it’s graphical area and also have reasonable physics? If you play with the physics of the plane you can see what’s wrong…

Thanks.

bge_adventure.blend (589 KB)

P.S.

I’d just like to note that I’ve search around and yeah… it seems that we can’t get the dimensions of the object from BGE which is kind of counter productive, and since I didn’t want to have to get the list of vertices and calculate the bounding box manually… I came up with the workaround of setting the scale to the actual dimensions instead:

Just select the object you’re interested to know (in Python) the dimensions of and take note of it’s current dimensions when it has scale at 1 in all directions. Then set it’s dimensions to 1 all over and CTRL + A to apply the scale then change the scale back to what the dimensions where. This way we can then access it’s “dimensions” in BGE with object.worldScale. I don’t know if this changes the physics though… probably not :).

Edit:
OK, so I manage to work around this issue by imposing some limits on the hexagonal grid, but I’d still be interested to know if any of you have other solutions.

Attachments

bge_adventure.blend (583 KB)

Do you really need the player to be a rigid body? I set it to dynamic and character type physics and it worked fine with the triangle or convex hull type collision floor.

Rigid body is best used for bullets or balls, or dropped bottles or chunks of debris in an explosion, generally things you need to really accurately simulate their physical movement. (like you open a box of mechanics tools and all the tools fall to the ground in a crash, or you break a window and all the pieces of glass crash to the floor). Dynamic is best for players or monsters, it handles dynamic movement and collisions but doesn’t worry about falling over, or center of gravity or anything like that.

If you still get problems with sliding movement later you can use the servo type movement actuator. This works hard to keep the object in the desired position while moving.

If you’re going to be using a lot of physical simulation I’d advise against arbitrary scales for objects. I’d advise against it anyway, it’s much better if everything stays at a scale of 1.0. It’ll make things much easier later on.

On the other hand, it seems like you know what you’re doing on the coding front (unless you just cut and pasted that :slight_smile: ) so why not handle movement and other things with a non-physical approach? It seems like you’re going with a more stylized game, using a hexagonal grid, maybe you don’t need to use physics as much as you seem to want. Once you get in to pathfinding on a hex grid and combat and lines of sight and things you’ll probably find that detailed physics simulation is just a hindrance to such a game and more of a complicating factor rather than an asset.

OK, I’ve just noticed that the “Edit Object” actuator has a “Dynamics” option. Does this mean that if I do “Enable Rigid Body” it will actually have “Rigid Body” behavior even though my character is set to “Character” in the physics panel? I’m asking because I just tried it and when set to “Enable Rigid Body” it doesn’t move weirdly as it does when using the physics panel to set it.

edit:
So… I’ve actually realized that it wasn’t moving around all weird because the “Track to” wasn’t enabled… so that answers that.

Well, thanks :). I should know my way around coding a bit… I’m in the atmospheric modeling business and although I don’t have a degree in CS I read a lot about algorithms. It’s more of a hobby really, I didn’t just cut and paste (and like to have all organized, as you can see by my docs…), I really want to understand the things before I do anything though I obviously search for information before, for example I had an idea on how to do the grid in my mind… but since other people are doing it for decades now I won’t just go and code what’s in my head… I tend to follow some guides :).

Anyway, I would like as I’ve said, those things to kind of fly around (that’s the whole point of the physics simulations :D). I need to experiment with that scale and physics though, I might end up having to calculate the bounding box manually :(. Not that it’s hard, but it’s one of those things you’d expect the tool has for you.

I think I tend to be better with low level stuff, that’s why I have a difficult time discovering “the way of the BGE”.

So if (for some reason…) anyone else is interested (maybe?!) in setting up the hex grid and may want their mouse cursor to checked for bounds this will do the trick:


# set some small margin for error (it's always a good idea to do so when working
# with floating point numbers - say if we have `f` = floating point number variable, then
# instead of checking for equality like so: `f == 0.5` we should write `f - 0.5 <= ERR`
# where ERR is some (properly) arbitrary chosen uncertainty value)
ERR = 1e-5

# NOTE that in my example I have the hexagonal grid aligned with the "small radius" on X and
# with the "larger radius" on Y

# here we calculate how many times the 'grid box' is contained in the ground plane along the X and Y axis
# this step may differ. For example, because my beginning location is in the left on the X and middle on the Y
# then I have to take in account these facts.
# NOTE also that I'm using worldScale to get the dimensions. For an explanation take a look at the P.S.
# from my first post
xTimes = ground.worldScale.x / gridBox.worldScale.x - 1
yTimes = (ground.worldScale.y - gridBox.worldScale.y * .25) / (.75 * gridBox.worldScale.y) // 2

# now we set the Y limits. Because of how I chose the hexagonal coordinates orientation relative to Cartesian
# coordinates I need to only recalculate the X (this waill make sense if looking at the blend file
mouseLimits = {'y': (-(yTimes + ERR), yTimes + ERR)}

# this function will be used to update the X limits (again, in hexagonal coordinates) based on the mouse
# (hexagonal) coordinates
def getMouseLimitsX(mouseHexHitPosition):
    return (0 - ERR if mouseHexHitPosition.y &gt;= 0 - ERR else -mouseHexHitPosition.y,
            xTimes + ERR if mouseHexHitPosition.y &lt;= 0 + ERR else xTimes - mouseHexHitPosition.y)

# then later in the code
mouseLimits['x'] = getMouseLimitsX(mouseHexHitPosition)
if (mouseLimits['x'][0] &lt; mouseHexHitPosition.x &lt; mouseLimits['x'][1] and
    mouseLimits['y'][0] &lt; mouseHexHitPosition.y &lt; mouseLimits['y'][1]):
    # do something when the mouse is within set limits


It all makes more sense if opening the blend file and looking inside :D. (I updated the file from the first post with this code). So now you can see, even if you have collision bounds set to “Box” for the ground plane, the limits do their job and the ‘grid box’ will not move outside of the ‘graphical’ representation of the ground object.

I hope it all makes sense… :slight_smile: