I’m experimenting with a top down vertical scroller, with a perspective camera, NOT orthogonal.
(It’s unclear how ‘pixelated’/pixel art I will want the graphics but that’s another question)
The map would be longer/taller than it is wide, and consist of squares, the image of which is different for each square. I’d like to be able to have 3 levels of height in the map. Most of the map would be flat square surfaces at those heights, but with occasional slopes between them. Some or all of the flat surfaces would be animated, eg water, and there would be buildings etc. scattered around.
The map will eventually be procedural but for now I can hand-make it.
This sort of thing, but with more levels and possibly a different graphical style (that’s partly why ‘experimenting’):
I’m considering the best way to do this. Seems like three options:
- three tilemaps, one for each level. Create additional 3D objects, or a some optimized mesh objects, for the slopes. Note: if this is efficient then I would probably use other tilemaps for eg trees, buildings and other decor on the levels, so possibly double the number of tilemaps
- a 3D terrain. Separate objects for the buildings and trees.
- An optimized mesh for the terrain. Separate objects for the buildings and trees.
Note 1: I don’t mind having fairly large tiles for the ground, to reduce mesh complexity etc.
What do I mean by ‘best’? Clearly some of those are harder or more complicated than others, and the relative simplicity of eg (2) or (3) seems nice (and I suspect that it would have other benefits, graphical and otherwise). But speed would be a consideration, probably the main or only consideration in the end.
Note 2 : making this for mobile is not a high priority, but it would be nice to get it so it works for that too without a complete rebuild. I hear that might leave out option (2)
What’s my best choice? Or is there a better method I haven’t considered?
With whatever you suggest, is there anything else I should look in to (eg instancing instead of separate models, etc.)?
Honestly, the best choice is the one that allows you to develop with as little discomfort as possible. I think any of those options are viable so it really comes down to what you think will be easiest for you. If you’re really having a tough time choosing then spend some time in pre-production. Allocate a couple of days or maybe even a week for each idea and try them all out. You’ll be much better informed to make the choice of which technique you want to spend the rest of your time on the project using.
Don’t even worry about performance here. It doesn’t sound like there’s going to be much of anything that will be pushing the limits of any modern computer so optimize for development time. If you have an issue it can very likely be spot optimized if and when it comes up. And even if there is a performance reason for not using one of those ideas, my suggestion above will help you quickly identify that problem. One of the best aspects of making games with these top-down views is that you have the best kind of culling at your disposal. No need for complicated occlusion culling when simple view frustum culling will work.
Personally if I were doing it I’d probably build small modular ‘tiles’ using GameObject hierarchies and 3D models that can be placed in a grid to build the entire scene. It tried the quake-style level design using ‘brushes’ in the past and while it can be a lot of fun it is also very easy to lose focus and means you spent a LOT more time making huge ‘hero’ set pieces for all of your levels rather than focusing on some smaller quality assets that can be recombined into different clever ways. That’s totally my biased opinion though.
Here’s a video to a somewhat related project to show what I mean. Almost every part of the level was built using the ‘brush’ technique by blocking out huge areas with basic shapes and then a few small props were plopped down here and there in different ways. I think if I were to redo it I would definitely want more focus in the art direction and smaller details so a tiled approach would be my choice.
