Development Strategy

[cgalroy]

From a development strategy, for easier maintenance and better performance, when you have a game where all levels share the same or similar scene layout and only some elements within the scene are different from one level to another (a Candy Crush type of thing), is it better to create one scene for every level, or stay in the same scene while handling the different levels via script?

[Ryiah]

It’s largely personal preference. Both approaches can be easy to maintain and have good performance but they can also be hard to maintain and have bad performance.

[TheOtherMonarch]

One scene for every level is kind of the way Unity is designed. You will find using different scenes will make it far easier for other developers to contribute.

[cgalroy]

I also thought that one scene per level is the intuitive way to do it, but doesn’t that add a lot of weight to the game, as it will have so many repetitions of the same objects?

[angrypenguin]

Unity only stores each asset once and references it via its ID. So no, it doesn’t add much “weight” at all that Unity or any modern computer is likely to care about.

For humans, however, It’s a pain in the backside. Imagine that you need to change something and it’s in all 150 of your levels. For this reason unity provides prefabs for anything that’s common. Prefabs can be nested and have variants, which helps a lot with this, too. For instance, you can have a CommonLevelObjects object, and then have variants which load different characters. Make a new scene, drag one of those in, and you’re ready to go. Also, if you need to change something, apply it to the correct prefab and it’s set in all of your scenes.

Another approach to consider: use one Scene for the stuff that is the same in every level, and use additive scene loading for the unique content of each level. This doesn’t involve duplicating anything or messing with prefab hierarchies, but does require planning out your scene usage in advance.

[DevDunk]

If you have different levels like candy crush you could also look into storing the data in ScriptableObjects maybe. Then you have just 1 puzzle scene with a loose object with all the level data and code

[Ryiah]

@DevDunk

If you have different levels like candy crush you could also look into storing the data in ScriptableObjects maybe. Then you have just 1 puzzle scene with a loose object with all the level data and code

Alternatively you could store the data in external JSON files. That does add the complexity that you need a way to get the level data into the files, but it adds the benefit that players can potentially create their own levels without having to go through complex steps involving the Unity editor and asset bundles.

With additional work you could even take it one step further and have a custom level editor. It wouldn’t have to be just for your players either. If it exposes all of the capabilities of the game you could use it to create the levels that come with your game.

[xjjon]

My simple answer is: if your game is like candy crush with that many levels, use 1 scene and create the levels programmatically - it is not scalable or purposeful to create them in scenes or prefabs.

I would suggest defining a data format for your levels (csv, json, image map, etc) and then use that to create the levels.
It could be done by the editor (data → prefab) or at runtime. As others have said, this would open up other possibilities like a level editor for players and other benefits such sending new levels to your game clients easily.

[Billy4184]

I prefer 1 scene for all gameplay, maybe another scene for the main menu.

I just find it easier to manage context while working when I can see it all connected together in one place.

[TheOtherMonarch]

@xjjon

My simple answer is: if your game is like candy crush with that many levels, use 1 scene and create the levels programmatically - it is not scalable or purposeful to create them in scenes or prefabs.

I would suggest defining a data format for your levels (csv, json, image map, etc) and then use that to create the levels.
It could be done by the editor (data → prefab) or at runtime. As others have said, this would open up other possibilities like a level editor for players and other benefits such sending new levels to your game clients easily.

Interesting point here. I think it depends on your game. If your levels are for a 3D FPS, you don’t want to create that programable.

Basically will you have level designers or only programmers developing and will you be placing complex 3D geometry that needs to be fine-tuned.

[DevDunk]

@TheOtherMonarch

Interesting point here. I think it depends on your game. If your levels are for a 3D FPS, you don’t want to create that programable.

It can. Just load the map into an asset and have stats per player
As someone stated before, do whatever you find best for your project with your skillset

[angrypenguin]

@Ryiah

Alternatively you could store the data in external JSON files. That does add the complexity that you need a way to get the level data into the files, but it adds the benefit that players can potentially create their own levels without having to go through complex steps involving the Unity editor and asset bundles.

With additional work you could even take it one step further and have a custom level editor. It wouldn’t have to be just for your players either. If it exposes all of the capabilities of the game you could use it to create the levels that come with your game.

It also gives another benefit: the more rigid workflow probably eliminates a bunch of opportunities for errors.

For example, if your levels are always build to a 2D pattern (eg: a hex grid or whatever) then it’s really easy to break that by accidentally dragging something in a stock Scene view. If you’re using your own tools and saving to a purpose specific format you can choose what operations are valid and what data to save.