Move your mouse over the green plane and see how the white cursor fits to it in a block pattern. Leftclick to add a vertical fence block, and rightclick to add a horizontal one. (Holding down both mouse buttons and moving to a different square adds them both at once, making what looks like a plus-shaped fence block.) Play around with it and see how it works!
The script is included in the .blend file. That (and the showMouse thing) are the only scripts at play here and both were written by myself.
This is indeed very nice. Since I’m not good at coding - I only understand the basics - I’d like to ask you what defines the increments by which its moved? Or the grid-size? Its really a mystery to me as I only understand that the mouse gets updated to the hit position and then moved by 0.5 units - why isnt the hit position always considered but only at the anchor points of the grid?
Thanks for providing this script, can be turned into something very powerful!
x = (math.floor(mouse.hitPosition.x) + 0.5)
y = (math.floor(mouse.hitPosition.y) + 0.5)
math.floor means to round down to the nearest whole, then +0.5 so that it isn’t on the cross between the x and y axis, but rather the tile/area between.
Changing the size of the grid is quite difficult using this method, since math.floor will round down to a whole, not a multiple of two/whatever size specified.
Instead of changing the tile size, you could always design your game around a bigger size than the tiles. For example, make your player 2x2x4 instead of 1x1x2 for smaller blocks, or 0.5x0.5x1 for bigger blocks.
As for changing the size of the tiles in-game, like Putu said, it’s really difficult to do with this method. This is just a simple template for beginners, though, so the more you learn about Blender, the more “AHA!” moments you’ll have about how to change my script into something useful for you.
I don’t know if you’re still interested in the snapping feature, but my solution, inspired heavily by CGAstym’s excelent tutorial on mouse tracking (https://www.youtube.com/watch?v=-IeNnw6zzvQ&list=PLwEd84vPBW77XJ8WQhcINPPh-2qNaJw7R) is to rely on objects centers instead of calculating with any math functions. Because once you start calculating stuff with constant offsets it becomes very fast very un-maintainable…
In my example blend file which you can find here: https://www.dropbox.com/s/8ntt5bj0ruji5m0/bge_test_01.blend?dl=0 the floor is made up of a bunch of individual planes, exactly as in CGAstym’s tutorial, but I thought about this, and if you want to have tiles of different sizes, it’s not really a big deal to use empties for example placed at the coordinates of the grid centers.
Hope this helps.
I actually just realized (immediately after I posted… tired night) that I was talking with you (Stym) about your tutorial… :)) oh well.
The problem with that system is that in order for you to have this grid snapping, you need to have multiple different objects as a base, therefore your system has to be predefined in order to work. That takes away “infinitism”, which is something I was going for. On top of that, it almost doubles the possible object counts, which takes up lots of resources.
My system uses two mechanical objects. A single large plane, and a cursor. I can make the plane be any size I want and it’ll still snap the cursor in a grid. The only downside is a locked block size, which may or may not even be a downside, depending on what your game will go for.
Also, like I said before, there’s nothing stopping you from designing your game’s size around the blocks, as opposed to vice versa.