Pre-optimizing an Arkanoid clone too much instead of post-optimization

I’m still learning Unity, even being exposed to it for several months on a spare-time basis. But I’m finding out from my conversations with my friends on Facebook that I’m pre-optimizing my game too much, which doesn’t help. It doesn’t let me explore features that are definitely available, or do things that become easy to manage. They say that post-optimization is the way to go, because then I’m able to see how well the game or scene works before I cut some of the stuff down, or simplify them, in order to solve some problems such as complicated AI or too many polygons rendered on camera.

For my current game I’m working on, which is an Arkanoid clone, I’m to build it for WebGL and upload it to Newgrounds for others to play. It seems that I’m thinking way too far ahead and worrying about frame rates, level of detail, and load times. In my case, it’s about having the different states of a paddle, which rely on different meshes and loading them during the game instead of having all the different animated elements in one mesh alone and simply use imported Blender animation clips to make the transitions between the different states.

Is it really natural for an apprentice Unity developer like me to pre-optimize a game too much? What are the different reasons for this other than simply trying to make a game be too “perfect?”

Optimize when you need, especially when you are learning. “Pre-optimization” comes in two forms really. First, the bad kind : being overly careful and concerned about any minor issues before (if ever) they become a problem and sacrificing actually completing a project or progressing in your skill building stage. Look at this way, If you a spend a lot of time optimizing something that has little or no impact, then what you have actually done is create a suboptimal development process.

The other is the good kind, the practical kind. This comes primarily from experience. As you learn, you take your lessons forward with each new project. It is less about the “optimizing” and more just building optimally in the first place, because experience has taught you a better way. Part of this is also, recognizing where a bottleneck might be, and doing a tech prototype or small tests to find what works and use that determine how you build. As you grow in skill, you will do less optimizing and more building optimally in the first place.

6 Likes

From what I’ve noticed there are two basic types of beginner developers. There are those that pre-optimize their game and there are those that put together a game with no regard to actual performance. The former is mostly a time sink so you don’t see them too often on the forums asking about optimizing but the latter almost always results in a game with terrible frame rates and threads asking why their game is running poorly.

That sounds applicable. I actually test my game in the Game View many times as I develop. What I should start doing from now on, though, is testing the game on an actual platform to see how well the game works and whether or not there are a few things I need to cut down. (Hmm, which browser has the best performance and which one has the worst?)

Too bad I can’t get 60 frames per second on a WebGL build on my stock laptop, and I don’t know about the other players including those that have gaming laptops or maybe plugins that optimize the Web browsers for performance. That’s because before this project, I worked on my own version of Pong, where from using a frame counter I programmed once, I got between 30 to 40 frames per second on the build platform.

Bad preoptimisation is attempting to optimise without any data. That’s the common thread we get a lot. People say ‘I hear Find is expensive, so I’m never going to use it’. Find isn’t a cheap function, that’s true. But it only makes an appreciable difference if you call it thousands of times. Some new devs spend so much time worrying about things like this that they never finish a project.

So don’t bother optimising until you have some data. Build a solution. Make it work. Then profile it and figure out the expensive bits. Then optimise away.

Note that this doesn’t mean optimise at the end of a project. If you are adding in a new feature or system, you can optimise once it’s done. Really as soon as you have some real data to optimise with.

Experienced devs can optimise as they go. A solid knowledge of the framework and programming structure can give you an edge. However this is all based on data from previous projects.

3 Likes

My current project is running at around 10 FPS. And it’s only half done. :stuck_out_tongue:

Of course, once the math works and the system is stable, I intend to simply throw it all onto another thread that only updates twice a minute. So as long as I stay above 2 FPS I’m in the clear.

Edit: This is actually a good example to talk about doing preoptimisation. I’m doing a huge amount of Vector math on some massive arrays. I know Vector math can be sped up dramatically by inlining the operations. In fact that’s probably exactly what I will do in the end.

However the math hasn’t settled yet. Inlining the vector operations now would make development significantly slower. So it makes no sense to do so now.

public class ExampleClass : MonoBehaviour {
    void Awake() {
        Application.targetFrameRate = 3;
    }
}
2 Likes

:stuck_out_tongue:

Boredmormon’s laptop, powered by gerbil technology TM…

3 Likes

It might be a limitation of WebGL, and nothing to do with your project. From memory the WebPlayer used to have a default maximum frame rate. It may be the same thing in WebGL. Basically the browser slows down your game to prevent it chewing up unneeded system resources.

What’s the default frame rate on WebGL when Application.targetFrameRate is set to -1?

Seriously listen to what everyone is saying… I’m still re-teaching my self not to worry so much about every single detail that could slow things down.

This isn’t 20 years ago when you actually had to worry about optimizations as much, which is when I first started, and back then it was very meticulous for every single speed factor we could push into the engine to run better. But now days we are lucky to have tools like Unity that leverage already pre-optimized tasks.

Gone are the days where vert counts mattered, (for the most part), mobile still requires some smart modeling techniques, but aside from that, code wise you are pretty much free to do what you want, as long as you are smart about it.

Things like GameObject.Find(“Something”); yes can be slow, not not really so much if you go to Find One single thing.
Now if you have a bunch of Find objects, you’re better to do it while in a loading screen, or somewhere where it appears it’s still loading and just find everything while it appears to be loading.

There’s always some new tricks to the trade as I call them, so long as you are willing to learn.

But once you get stuck like I was into optimize this, optimize that, can’t hurt to optimize everything and avoid issues later.
But again, gone are the days where optimization was key to a smooth product in every way shape and form.

Once you get stuck into optimizing everything, you’ll slowly start to realize, nothing is ever getting done, and you will go to another project - just to do the same thing, over and over again. So it’s best to catch up with the new times and realize it’s really only important to do it when you really start to see dramatic frame drops and rendering speeds.

I’m still trying to teach my self to not optimize so much, it’s hard once you get stuck into it. Trust me, it’s not a bad thing to learn at all, and will certainly teach you a lot, but it’s remembering to only that knowledge when it really needs to be used.

1 Like

I’d say your single biggest mistake is ever using the term ‘frames per second.’ You need to start thinking in seconds per frame instead.

If you want to end up at 60FPS, that means you have 16.6ms/frame to spend. Divide it up into a budget for the different tasks you need to perform on a frame-to-frame basis, and then watch how you stack up against them. Stop when you’re hitting the budgets and get on with something else

5 Likes

This is very much true. If you are on your own, it’s actually pretty difficult to get enough content in a game to require tight microootimisation.

Sure you can’t go crazy. I can easily dial up the precision on some of my simulations to drive the frame time up to a couple of seconds.

1 Like

It is a common newbie programmer mistake, actually. This kind of thinking: “I heard that ++i is faster than i++, therefore I’ll use ++i in that line which is called once per year, to make things work faster”. Don’t do this kind of thing.

General rule is:

  1. FIRST make the prototype.
  2. Only AFTER THAT, and only IF you have performance issues… only then optimize.
  3. And before optimizing actually profile the game and locate performance bottlenecks.

Basically, if you start optimizing rightaway, you’ll never finish the prototype.
If you don’t profile before optimizing, you’ll waste time without improving anything.

2 Likes

“I’d say your single biggest mistake is ever using the term ‘frames per second.’”

Personally I don’t think it really matters, its all relevant anyway… whether you aim for above 60fps or below 16.6ms on your dev pc… what gets you 60fps, on another computer will be different either way you look at it. It’s just about being aware of where your dev pc stands, ie below or above average consumer hardware for cpu/gpu specs etc.

I do feel bad when the profiler starts averaging over 5ms a frame for me though

My biggest problem is wrangling Unity physics and total rigidbodies as its the single biggest cause of spikes and other weird problems with collision contacts. And for a game largely based around using rigidbodies and physics it really makes me wish I’d use Unreal for its ability to allow me have individual object sleeping thresholds instead of it being global. As not all objects need that accuracy and smoothness but others do… and in Unity its only global.

But you know what would help Unity… actually making an official benchmark and providing results for different devices/cpu/gpu setups/quality levels per release… cpuz comparison like… that way what my avg profile speeds at 5ms gives me a better idea of what base minimum spec would be for pc, and what kind of quality settings I’d have to change for devices to target on mobile… Would be nice to know what number of rigidbodies and collisions can be handled on a broader range of mobile hardware etc.

Profiler being able to store snapshots to look back on, so making comparisons in code changes would be easier.

1 Like

I’m not sure what you mean “profile the game.”

The profiler, in Unity. Use it.

–Eric

No point even talking optimization until you learn profiling.

https://unity3d.com/learn/tutorials/topics/interface-essentials/introduction-profiler

There are a couple of key reason most devs advocate ms instead of fps.

  • ms is linear. A change from 2ms to 3ms and a change from 15ms to 16ms both represent an identical 1ms change in performance. A change from 500 fps to 333 fps and a change from 67 fps to 63 fps are also identical performance changes, however in on scenario we dropped almost 200 fps, and the other dropped only 4 fps
  • On a complex project you might not be working on the entire game at once. Its common to split the budget up between different systems. This is much more practical in ms
  • On a complex optimization you don’t do everything every frame. Thus fps is a poor measure
  • Long frames are often a performance issue, and these don’t typically show in fps measurements
  • fps is often dictated by screen refresh rates, and thus can be harder to get accurate measurement
  • ms is much simpler to bench mark with
5 Likes

OK your getting some good advice here but there is another approach that I don’t think has been mentioned:

Stress Testing your game.

In your case build a supersized level with loads more blocks, paddles and balls then you will ever have in any level.

e.g. 4x the resolution, 4x blocks, 4 paddles, 40 balls.

Run it in normal profile mode and see what happens, then run it in deep profile mode so you can dig down into the problem areas.

Optimise this version of your game, you want it to be at least running at half your desired FPS on the target platform.