[DevLog] #03 Object Sorting in Top-Down View [2/2]

[Translated from Korean]

Hello, this is Team OOPArts, currently developing Frostory.

During the game development process, we often encounter unexpected problems. The object sorting method mentioned in a previous post was one such issue.

In this post, we will discuss how we resolved this problem.

1. Issues with the Previous Method

The previous method had issues handling sloped terrains. While splitting terrain tiles and sorting them based on the y-axis and z-axis was effective on flat surfaces, it showed limitations in more complex terrains.

In a terrain like the one above, where the player (A), monster (B), sloped terrain, and ground need to be drawn, we must decide the criteria and order for drawing these four objects.

In the old system, the order was determined based on the y-axis and z-axis. Simply put, the closer the object was to the bottom of the y-axis or the top of the z-axis, the closer it was drawn to the camera.

For objects, we used the point where they touched the ground as the center point.

However, due to the nature of sloped terrain, it was impossible to determine a single center point to represent it.

1. Attempts and Limitations with the Previous Method

Initially, we tried to solve the problem by splitting the slope into multiple segments.

By dividing the slope as shown above and assigning different y-axes, we could handle movement below the slope without much problem.

However, when moving on top of the slope, situations like the one above occurred.

This was an inevitable issue in the current system, which processes tiles and objects in the same way:

• Player (A) < Monster (B) - Slope < Player (A) - Monster (B) < Slope

This contradictory situation made it impossible to sort them correctly.

1. Seeking Solutions: Learning from Other Games

We decided to explore how other games solved this problem. One famous game that features slopes in a top-down view is CrossCode.

CrossCode used a 3D rendering technique involving z-testing. This method places the terrain on the z-axis and records height values in the z-buffer, rendering it like a 3D game.

It’s a game I thoroughly enjoyed playing through to the end, without realizing this was a 3D rendering technique.

They seemed to have standardized image sizes and collision sizes well enough that the 3D rendering was inconspicuous.

1. Solution: Adopting 3D Rendering

Switching to a 3D rendering method required a major overhaul of the levels and systems we had previously created.

However, this decision not only solved the problem but also provided an opportunity to enhance the visual quality and technical possibilities of the game.

Looking at the game world through a 3D camera, you can see how it’s structured. This approach fundamentally resolved the sorting issues with tiles and objects.

1. Additional Benefits of 3D Rendering

The transition to 3D rendering opened up various possibilities beyond merely solving the sorting issue.

a) Displaying Characters Behind Walls

With shaders, we can now display characters even when they are behind walls. This feature can be utilized to improve gameplay visibility when necessary.

b) Improved Decal Representation

Decals can now naturally adhere to walls and terrain, enhancing the fine details of the game world.

c) Improved Shadow Representation

Previously, shadows appeared to float when not aligned with the ground, but they now adapt naturally to the terrain.

Conclusion

The process of introducing 3D rendering to solve the sorting issue was long and challenging, but it allowed us to improve the game’s quality and expand its expressive possibilities.

Thank you for reading!

If you’re interested in the game after reading this, please follow us. We will continue to write more posts about the development process.