|Topic was automatically imported from the old Question2Answer platform.
|Published before Godot 3 was released.
Hello guys !
My friend and I are trying to create a top-down adventure game, like a Zelda.
It’s the first time we make this kind of game and we don’t know how we should organize our world. We would like to know what are the best practices.
An example of what we want to do : https://youtu.be/hhb3LqLtTBM?t=45s
One thing to know is that we have a root node containing several layers of Tilemaps, to handle the ground, the objects, the roofs, etc.
Consequently, we put the player scene as a child of a given Tilemap in order to use the Y-Sort feature.
Screenshot related :
We think about 2 solutions, but we don’t think they are “effective” :
- Should we store all the maps in one big tilemap, then move the camera when we reach the border of the screen ?
If so, how would we handle the dungeons, houses, etc.
I heard some games had those places in a specific area of the world map, but I don’t think this is really elegant (feel free to correct me if I’m wrong =D)
Also, I think this won’t be really “optimised”, or maybe we should use a VisibilityEnabler ?
- An other solution we consider is creating a lot of small scenes with tilemaps, then change the current scene when we reach the border of the screen.
In this case, It won’t be simple nor intuitive to notify the request of scene change to the main scene, then retrieve the player to put it afterwards as a child of the Tilemap.
I really hope this post is understandable.
Please ask questions if you want some clarification !
Thank you for you reading and/or your help !
EDIT : typo
A big TileMap might be under-performant depending on how big is your map. Also, it would likely make it problematic to enter houses and dungeons. You could maybe use visibility tricks to show what you want, but I don’t think that would be easy.
Your second idea sounds better to me. It’s the approach I used on my top-down RPG test (which I haven’t touched in almost a year, but will come back to it soon).
If you look at my project, you can see I used a “warper” scene, which consists in an Area2D to detect the player and a simple script with two exported variables: a target scene and a target warp, so you can instance the scene whenever you need it and edit this properties through the editor itself.
This warper script is just to detect the player. Then it sends the data to a singleton which manages to transition the scene and re-position the player at the correct target (which is a Position2D node). Note that the current scene is never changed, it just replaces the instanced level with another.
Depending on how big are your levels, you might want to do a smart loading to avoid hiccups when transitioning: preload all the scenes that can be reached through this one (and discard the rest) and repeat the process when warped. This is optimization though so it can wait until your project is bigger.
I created warpers and spawn points, and it works well. =)
For now we don’t need to optimize but I will remember your suggestion !
Thank you !
If the world is huge, I would make a big map per zone (zone = scene). This is convenient for designing the map, while keeping a tradeoff on performance. For example, the inside of a house, a dungeon or a city are zones.
Zones obey to a grid, where each cell is the size of one screen. I would draw this grid inside a tool script so it’s easier to see.
This also allows you to make the state of objects persist as long as you don’t leave the zone. If you don’t want that, you can have one scene per screen instead, and assemble them in a big scene so you can see the big picture.
Now, how to handle transitions between zones? A few options:
- No transition, just fade to black. Simple.
- Instantiate the next zone and move it at the right place, slide the camera as usual, then destroy the last zone.
- Screenshot the current zone, unload it and replace by a sprite, load the next one, slide the camera, and delete the sprite. This should only be useful if you can’t afford to have two scenes loaded at a time.
Thank you for your answer !
I will go for the fade-to-black transition for now.
For the second choice :
Instead of moving the camera, I would have moved the level itself. In order to keep the elements in the “center” of the world. Is this worth it ?
If the world is big, I wouldn’t move the world. It implies to update the transform of a lot of objects, and it makes more sense to move the camera.
It shouldn’t really matter if elements are centered anyways, because your avatar is child of the current map.
Zylann | 2016-06-26 19:48
Ok I understand, thank you very much ! =)