Technical Tile Data vs. Visible Tile Data
While i was working on my game, i got stuck at a point where the actual height information of a walkable tile needed to be different than the the visual representation of it.
If a Unit should be placed in a pond or just walk through a river, its legs and feed should be below the surface. But still the surface must keep its position.
So here is a mismatch in the height of the terrain (the Y Coordinate in 3D space).
As i was already calculating the height of a tile in the map based on the avg of all the Y values that are located in the area of the tile, i ran into an additional problem.
If i like to add more or special shaped geometry to the 3D mesh of the map, it would automatically have a impact on the height of this tile and a unit may be placed to hight or to low and all the logic like walking and attacking would also no longer work. Connected to all this information i would also need to know IF this tile is walkable at all and even if it is next to an other tile, it may be not reachable if the 2 tiles were separated by a fence for example. So i had a lot of information i needed to store somehow and connected it to the 3D model of the current map.
As i am a lazy guy, just like any programmer, i liked to find a way to have all these Information in the 3D mesh, so i could just 'model it in' while working on the level in blender.
So i came up with the simple idea to bring in all the walkable tiles into the 3D model but in a location that would not be visible to the player but easily to implement for me in 3D.
Just moving all the tiles that are holding logical information down by -10 units did the trick for me here. So all geometric points above 0 would remain visible and can freely be styled and modefied,
but all points below 0 (to be save i made it -1) will only be processed by code and never be visible on screen.
At the upper right side you can see the avg. Y coordinate of the selected and yellow marked tiles on the lower left in the 3D view.
What i have not used in this map is the technique to bring in the information that 2 tiles cant reach one an other.
Just a quick explanation: if i have the tile at 2d position ( 3 , 3 ) and the tile at ( 3 , 4 ) i just change the Z values of one of the tiles like ( 3 , 3 ) to ( 3 , 2.85 ).
So there is a small logical (not visible) gap between the two tiles and in my code i can easily check if the difference between the tile is bigger than 0.1f, and if so i add a boolean flag in the tile info that
the tile can not be crossed over that side (edge).
Anyway, with this simple tricks i was able to export the 3D data in the most easy to read and use format wich is *.obj. I do not even need to use material files and can only relay on the plain geometric data of all the triangles in that scene.
In my code i simply read all the geometric data and do the simple comparison to check if this is a walkable tile or not.
If a tile is below the -1.0f i just add +10 to get it back to its original height and use this information in the logic of the game to run calculations on it.
Additionally to the "sub zero" logic of not visible tiles i also made sure that i don't use tiles that have angel higher that approx 50 degree.
This is mostly because a 3d quad that is stretching in a 45 degree plain causes me trouble if i try to place a 2d sprite character on it.
So in this case it may cause the feet of the character to be hidden by the geometry. I may find a solution for this in the future as well but from a realistic point of view
it would not make scene to walk or stand on such ground.
So here is the very simple code to react on it:
Having now all this clean tile data only based on quads and on the correct height i generate some 'TileInfo' instances to keep track of all the tiles in the map.
For debug reason i can viaualize these tiles as blocks in the szene, so i can visualy validate if my logic is working and all information are processes correctly.
You can see at the diagonal parts of roofs, that the TileInfo boxes are crossing half of the visual roof geometry.
That´s because i am always calculating a avg. height for each of the TileInfo instances to have a reliable value for each of the 2d positions on the map grid.
Also below the water you can see how far away from the surface of the water, the top surface of the corresponding TileInfo box is.
This concept gave me the flexibility i needed and also allows me to place tiles above each other.
So if i am building a bridge or a castle gate i can place and use tiles in the same 2d space but on different height levels in the Y space.
What do you think about this approach?
If you like to get more information about this game or you even like to support me, please see the links below.
Instagram: https://www.instagram.com/silence_is_a_lie/
Twitter: https://twitter.com/lie_silence
YouTube: https://www.youtube.com/user/uwi2k2/
Patreon: https://www.patreon.com/silence_is_a_lie
Stay healthy and take care!
cu
kai
If a Unit should be placed in a pond or just walk through a river, its legs and feed should be below the surface. But still the surface must keep its position.
So here is a mismatch in the height of the terrain (the Y Coordinate in 3D space).
Here you see what i wanted to realize somehow:
As i was already calculating the height of a tile in the map based on the avg of all the Y values that are located in the area of the tile, i ran into an additional problem.
If i like to add more or special shaped geometry to the 3D mesh of the map, it would automatically have a impact on the height of this tile and a unit may be placed to hight or to low and all the logic like walking and attacking would also no longer work. Connected to all this information i would also need to know IF this tile is walkable at all and even if it is next to an other tile, it may be not reachable if the 2 tiles were separated by a fence for example. So i had a lot of information i needed to store somehow and connected it to the 3D model of the current map.
As i am a lazy guy, just like any programmer, i liked to find a way to have all these Information in the 3D mesh, so i could just 'model it in' while working on the level in blender.
So i came up with the simple idea to bring in all the walkable tiles into the 3D model but in a location that would not be visible to the player but easily to implement for me in 3D.
Just moving all the tiles that are holding logical information down by -10 units did the trick for me here. So all geometric points above 0 would remain visible and can freely be styled and modefied,
but all points below 0 (to be save i made it -1) will only be processed by code and never be visible on screen.
In this blender screenshot you see how i added the "data tiles" -10 below the "visible tiles":
At the upper right side you can see the avg. Y coordinate of the selected and yellow marked tiles on the lower left in the 3D view.
What i have not used in this map is the technique to bring in the information that 2 tiles cant reach one an other.
Just a quick explanation: if i have the tile at 2d position ( 3 , 3 ) and the tile at ( 3 , 4 ) i just change the Z values of one of the tiles like ( 3 , 3 ) to ( 3 , 2.85 ).
So there is a small logical (not visible) gap between the two tiles and in my code i can easily check if the difference between the tile is bigger than 0.1f, and if so i add a boolean flag in the tile info that
the tile can not be crossed over that side (edge).
Anyway, with this simple tricks i was able to export the 3D data in the most easy to read and use format wich is *.obj. I do not even need to use material files and can only relay on the plain geometric data of all the triangles in that scene.
Here is how i export the data for my game:
In my code i simply read all the geometric data and do the simple comparison to check if this is a walkable tile or not.
If a tile is below the -1.0f i just add +10 to get it back to its original height and use this information in the logic of the game to run calculations on it.
Additionally to the "sub zero" logic of not visible tiles i also made sure that i don't use tiles that have angel higher that approx 50 degree.
This is mostly because a 3d quad that is stretching in a 45 degree plain causes me trouble if i try to place a 2d sprite character on it.
So in this case it may cause the feet of the character to be hidden by the geometry. I may find a solution for this in the future as well but from a realistic point of view
it would not make scene to walk or stand on such ground.
So here is the very simple code to react on it:
Having now all this clean tile data only based on quads and on the correct height i generate some 'TileInfo' instances to keep track of all the tiles in the map.
For debug reason i can viaualize these tiles as blocks in the szene, so i can visualy validate if my logic is working and all information are processes correctly.
You can see at the diagonal parts of roofs, that the TileInfo boxes are crossing half of the visual roof geometry.
That´s because i am always calculating a avg. height for each of the TileInfo instances to have a reliable value for each of the 2d positions on the map grid.
Also below the water you can see how far away from the surface of the water, the top surface of the corresponding TileInfo box is.
(the blue highlighted areas are the once where the current character may walk to)
So all path finding calculations (A* start - extended to 3d) and all visual positioning of the characters on the map is now based on the 'invisible' tiles with the correct height.
This concept gave me the flexibility i needed and also allows me to place tiles above each other.
So if i am building a bridge or a castle gate i can place and use tiles in the same 2d space but on different height levels in the Y space.
What do you think about this approach?
If you like to get more information about this game or you even like to support me, please see the links below.
Instagram: https://www.instagram.com/silence_is_a_lie/
Twitter: https://twitter.com/lie_silence
YouTube: https://www.youtube.com/user/uwi2k2/
Patreon: https://www.patreon.com/silence_is_a_lie
Stay healthy and take care!
cu
kai
Kommentare
Kommentar veröffentlichen