Creating a custom (not orthogonal) maze

Hi! Total newbie here.

I am trying to make a maze game, but not with the usual horizontal-vertical walls, but something adapted to a drawing, like this example (it is not the full maze):

(I leave the grid red lines for your orientation, but technically I don’t need them at this stage. The maze is neither the final one - I could give more space for the paths)

What would be the best approach to make it?

For collisions, I have tried the following:
A. Collision masks in the object: Too slow with Gdevelop
B. Collision based on simple invisible objects (triangles, squares…): It can be done, but too slow.
C. Collision shapes with the program Tiled (I just need one big tile for all the drawing and then I create, inside that tile, the obstacle shapes) and then, in Gdevelop, creating a new object “External Tilemap (Tiled/LDtk) collision mask” and import the tilemap and tileset: it is the best solution I have found, but with disadvantages:
C.1 The “pathfinder obstacle” behavior of Gdevelop does not work. Solution: it works with the experimental behavior “Obstacle for navigation mesh pathfinding (experimental)”.
C.2 It looks like some collisions between the player and inclined shapes make the player start to shake like crazy, until it separates a bit from the wall, on his own.

Ok, another issue: As the game has a 3d look, I would like that the player could be in front of the hedges (overlapping them a bit, closer to them) or behind the hedges:

Behind the hedges:

My solution was creating the upper light green part of the hedges as an independent PNG, and set it on a Z layer greater than the player. Maybe there is a more clever solution.

In front of the hedges:

For the front issue, I I tried:
A. Ysort behavior. I does not work as it only takes on account the central point of the object, and in my case would be the full background drawing. Solution: to cut all the maze in smaller parts, and that is something I would like to avoid (but maybe it is necessary).
B. Changing the collision mask of the player so his head and part of his body is not a collision part: ok, it works.
C. I thought about the “bounding box bottom” as a limit to how much the player can go up over an hedge: I don’t know how to use it of it it would be useful here.

And now, the around corners problem: when trying to go around the hedge, the player overlaps the side of the hedge:

The only solution that comes to my mind (I have not tried yet) is to extract a little png of that part of the hedge, like this:

And then using:
A. The Ysort behavior: The red line would be the PNG and the yellow dots, the central points of both player and PNG (because Ysort takes on account the central points of the object). So, when the player goes up beyond this yellow point, the PNG will be on a Z greater than him: maybe could work, but all these kind of corners of the maze would be need to be designed having in account the size of the character and his central point.
B. Some kind of Ysort behavior but with events, selecting a better point than the central one.

Any ideas that could help? Isometric would be better? Could Contruct 3 resolve the problems? But I like Gdevelop more. Or would it be “easier” to make all the maze in 3d, in Blender, and use it in Godot? But I want to publish the game on browser, and Godot, by now, it does not look like to export it to a small size.

Thank you very much!

1 Like

“Total newbie here?”
Excuse me, but I don’t think a newbie could do this.

I believe the Y sort takes the origin, not the centre point. If you move the origin to the middle bottom for all objects, then the Y sort will work.

:smile: I have been “playing” with Gdevelop for only 3 weeks, so I think I am total newbie. Maybe it looks like I know more than I know just because I focused on resolving this specific game.

Yes, you are right! It takes the origin point. I will try later and will post the results. Anyway, for my “front issue” is not going to work. I will test it for the around corners issue.

For the front issue, another solution should be just to make the obstacles smaller in their lower part (not covering the drawn zone) so the player can go up and overlap the hedges a bit more.

Sorry for my late reply, I have been busy.

Ok, so to summarize:

For creating the collision map:

Without a doubt, for not horizontal-vertical mazes is better to use the program Tiled. It is quicker and easier than doing it in Gdevelop. Then, in Gdevelop the experimental behavior “Obstacle for navigation mesh pathfinding (experimental)” is needed.
Be sure that your polygons (the obstacles) overlap each other because, if not, the player can enter between them. And light also can pass and it is ugly.

For the “in front of the hedges” problem:
The best solution seems to change the collision shape of the player (and enemies, if that is the case) to a smaller size, around their feet, for example.

For the “behind the hedges” problem:
My solution was creating the upper light green part of the hedges as an independent PNG, and set it on layer over the ones of the player and the lighting layer (this way, the light won`t affect it, as it does not make sense - you can compare the two images):

This one is ok:


This one looks wrong:

For the “around corners” problem:
This is the most tricky:

  1. I exported all those little parts from the painting software to PNGs. Be sure to export each corner as a different PNG (you will need them separated). I don’t need the upper light green layer part.

  1. In Gdevelop, I have placed each one of them in the Scene were they should be. The Base Layer is fine for me (I have almost everything there).
  2. Of course, their Z order should be greater than the background drawing… For me, their Z order is 9, meanwhile the Player and Enemies is 4, but this does not matter.
  3. I group all these corners into an Object group (I named it “corner_group”)
  4. I created and Extension to be able to assign a behavior to the Player and Enemies. What this extension does is to check if the object (the Player or Enemy) is close to a second object (I named it “objeto-fijo”, which would be the corners) and to check their bounding box bottom position (Y). For me the bounding box is fine cause it is like the feet of the characters and not any other point. The Y value of the bounding box bottom of both objects marks the moment when the characters will be in front or behind the corner. Also, checking the proximity is necessary as, if not, all the corners would take the Y position of the bounding box of the character at the same time. So the conditions are:
    1. If the bounding box bottom Y position of first object is greater or equal to the bounding box bottom Y position of the second object, the Z order of the first object has to be greater than the Z order of the second object (with +1 is enough)
    2. And if the Y position is smaller, set the Z order in -1

  1. In the Events, I set the “Repeat for each” event, and use my Extension with the Object group “corner_group”:

The text says “Change the Z order of [Player] depending upon the proximity with [corner_group] and the Y values of both of them.”

All this allows me to save code and events, but of course you can do it all in the Events sheet without Extensions.

Any other solution is welcome!

Thanks!