Im making a game and I wanted to know if I should try to optimize while I create the levels or if I should make sure everything works and then focus on optimization?
I always say “make it work first, optimise later”. First, it can take time away from actually making the thing you want to make. Second, you could be optimising code you replace later because your design evolved.
If you see a quick trick to make something run faster/more efficiently, you should change it then and there though.
Generally do it in stages, for prototyping and such you don’t need to optimize you simply need to make sure things work right and feel good. Pre-optimization at this early point is usually detrimental to progress.
Later, you might use segmented kits to build levels with separate objects. If the object count becomes an issue then finally you might end up just mesh combining them into chunks/groups when the level is done.
I think that if you’re making a mobile game you should always keep an eye on how the game performs on the devices, at least a superficial look, but, of course, only when you start to play around with 3d models, shaders, etc.
What I do is I don’t shoot myself in the foot by doing things that I know will be problematic on the platforms I’m targeting. I want to know that it can work well on those, even if I don’t optimize anything right now.
Like if I am targeting mobile and using terrains, there are some decisions on how I handle that and what my limits are that I have to account for right from the start. But I don’t particularly care about stuff like character models, I’ll use whatever I have laying around early on. Because it’s easy to switch those out later. But if I architect my terrain handling wrong, I could end up with all sorts of dependencies that I would have to redo later. That is what I would call shooting myself in the foot.
Since you’re asking about optimizing while creating levels, I’m going to buck the trend and suggest a qualified yes, optimize.
Ideally you won’t be creating gameplay levels until your technical architecture is in place (e.g., character controllers, interaction systems, save system, terrain handling as snacktime mentions, etc.). Changes in tech may fundamentally change how you make levels. You’ll probably create test levels to stress-test your tech, but not gameplay levels until your full tech is working and reasonably efficient.
Once at that point, a typical process for a level is to graybox it and playtest. When you’re satisfied with the general look and flow, rework it with efficiency in mind, which is a little different from optimization. In programming, an example of efficiency is choosing the right algorithm – such as an O(n log n) merge sort over an O(n^2) bubble sort – while optimization is fine-tuning the implementation of the merge sort to squeeze out a few extra milliseconds. Similarly, an example of efficiency in level creation is to design your levels to support occlusion culling, which lets Unity render a lot less each frame, or to reuse models to leverage GPU instancing, or to set up polling checks every 2 seconds instead of every frame. Optimization, on the other hand, might include reducing the poly count in the models that do get rendered.
TL;DR: Get your gameplay systems working before creating levels. Then graybox the level for “fun”, then redesign for efficiency, then optimize. So you’re going to “optimize” as soon as you’ve grayboxed your level.
1 Like
This might seem very strange, but I optimize first and build on top of that later. My thinking is that if I can get a good game working, it’s easier to add stuff to it rather than first spend lots of time on stuff I’m going to need to cut out. I’ve had more than 1 occasion when I’ve spent a ton of time on a project and then spend a long time re-writing scripts and optimizing animations/models/lighting, which means I’ve wasted time making something I’m removing because of performance, and I’ve wasted time because I didn’t optimize in the first place.
But that’s my 2 cents, if the opposite works best for you, then good for you!
I’m very much an optimise-as-I-go kind of person. But… that doesn’t means I optimise everything!
As @TonyLi talks about, you should have performance targets early on, based on testing you do on your actual target hardware. Once you’ve got that, “optimisation” is about making the thing you want to build meet your performance targets on that specific hardware. With clear targets in mind you know exactly what to measure, which means you can use the profiler to effectively achieve those goals. You’re not changing stuff to arbitrarily “increase performance”, you’re profiling and picking specifically what to change based on measured results.
Note that you need to be doing that testing in a (release) build, which will usually mean some purpose-built code or tools to help out. For instance, if you’re trying to build a level that’s in the middle of your game then you want to have a fast way to get to specifically that level in the build, and possibly even fast ways to get to areas in the level or trigger events. Iteration needs to be fast, so don’t make people spend minutes just getting to the thing they’re testing. (This could go for your build pipeline, too. Do you need to re-build the whole game, or could loading levels from AssetBundles speed things up?)
This question depends on the experience of the individual. If you are new to programming then I would say never optimise. I don’t think you’ll get the the point where performance can matter to you.
Once you’re a bit further along or intending to get it fit for public consumption then you should optimise if it will not run correctly on the target platform.
If this is your second rodeo then you will already know the usual culprits to be careful around during the engineering phase.