• Job Offering

  • [Paid] Looking for programmer to create dynamic isometric depth-sorting-system for my commerc2D-game

Hey there, because I'm more an artist and can't finde some good tutorials/have not much programmer-experience, I'm looking for someone who would be able to create an dynamic isometric depth-sorting-system.

What do I mean with this? It's not a big problem to create an static isometric scene in godot 3, but there are allways situations where a character needs to get drawn correctly at corner-tiles where he can be in front or behind the wall/object. I could try to use some workarounds like changing the z-axis or trying to prevent situations like this with big collisionshapes but this would result in an very static gamefeeling. On top of this I plan to integrate an jump-function in my game which means the depth-sorting hasn't just to work for situations like described above. It would be needed to handle situations where the player jumps down a collumn or jumps up/climbs walls at specific areas.

As said in the title I'm willing to pay for such a little script-library but would need it well commented and someone with experience who calculates the costs before he starts. I would prefer GDScript as language but are open for suggestions as long as integrating other languages isn't a big deal (I'm still the programmer-newbie).

If you are interested, feel free to write an PM in this forum or on discord (ChimaereJade#0109)

Hmm, seems like you are looking for the Y-Sort node?

Hey @kryzmak , thanks for the reply! I'm allready using the Y-sorting in Godot 3.X, but this doesn't works for my (tilebased) isometric game because there are often situations, where the lower part from the center needs another depth then the higher part from the center.

This is something Y-sorting as prebuild node can't handle from default (as far as I see) because it's allways using the lowest part of the sprite. Another problem is that the depht-sorting needs to handle motion with +2x = +1y. That means the fixed center can't work because there is allways the possibilty to be stepwise "higher in perspective" with the pixelmovement (something I forgot to mention) in the game.

There is a gif to visualize what I'm talking about. :)

For this cases there is "origin point" in tilemap, you should use "CENTER" , but if you do that your textures and collision poligons can go away if the don´t match exactly cell size, you can not flip h and v without displacing textures and polligons... for me tilemap dessign is very strange. I did open this issue in the past: https://github.com/godotengine/godot/issues/22989. Nobody seems to be interested. I did modify "scene/2d/tile_map.cpp" to achieve my expected results, but it breaks other things, and i´m actually thinking in dropping godot use, so i will not go deeply in that problem. If using origin point -> CENTER doesn´t fix your problem you should go to github to explain your problem and ask for a solution.

Sounds sad what you have to say. I'm using mostly default-settings with centering, z-layer, etc. Right know I can fix the biggest problem by using different layers of tiles which are seperated for background, details and allways-in-front. Your tipp about the center could work in most cases but I'm afraid it doesn't works for my iseometric-view, because I need an grid which calculates the movement (and depth) for x AND y with each difference ini position.

Someone wrote to me on discord - I hope he can find a solution. I will try to improve my programmer-knowledge over time but at the moment I don't find the time for multiple construction areas.

I didn´t see the problem in calculate the movement, this is different that the visual part. Tilemap have a method called map_to_world and other called world_to_map that you can use. You would use too get_cell_size().x and get_cell_size().y to get any position inside the cell... I think that you can calculate any movement and position with tilemap now. If I remember, map_to_world returns the position of the top_left point of the passed tile, and with cell_size() you can do the calculations. I think i didn´t unrestanding well your problem, but i´m sure that you can do any calculation.

Hm... ok! My worries are about that simple y-sorting need the sprites to be on horizontal values to be comparable. But to be honest this is something I need to look deeper in because the aviable tutorials of GDqest are with done for godot 2.X and unlike in other 2.X-topics I can't find a way make it working throught using the dokumentation. But thanks - you make me some hope and I will see if I should get some things done. :)

3 months later

This thread can be closed. It seems I just misunderstood some prebuild things I will use for a workaround. :)

@ChimaereJade said: This thread can be closed. It seems I just misunderstood some prebuild things I will use for a workaround. :)

If you are sure, then I can close the topic.

I just want to make sure you are okay with the topic being closed before I close it, as once it is closed no one will be able to post on until it is open again (feel free to PM me, or one of the other staff, if you want to open the topic again once/if the topic is closed).

Also, unrelated to the topic of closing this topic, but your game looks cool! I like the visual style :smile:

Hrm, perhaps it should be moved to 2D category instead? :confused:

Yes I'm sure. :) Beside creating more pixelstuff I found a better understanding how most nodes in godot work and how to start learning programming with really small modular pieces.

@ChimaereJade said: Yes I'm sure. :)

Alright then, closing this topic. If you want/need it reopened, message one of us and we'll see what we can do.