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.

 

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.

 

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

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.

 

Code (CSharp):

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

 

Boredmormon's laptop, powered by gerbil technology TM..

 

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.

 

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.

 

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.

 

"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.

 

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

 

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.

 

Q: 2D or 3D physics?

 

You might want to check out this thread another developer goes old school* in Unity with Space Invaders to gain performance benefits, so I have a go at getting similar performance just using the regular Unity way.

I use lots of profiler feedback to improve my version of Invaders and we take it to the max with stress testing. It's amazing how much you can squeeze out of Unity but it was hard to keep up with his old school techniques.

*He did not use any of the out of the box Unity components or even physics. Unity was just used as a display layer.

Not surprising really as the original arcade games like Arkanoid ran at 60fps on a 5Mhz Z80 processor (wiki).

 

This!

Yes, the numbers are interchangeable... if you look at the whole frame.

The first issue is that when you're optimising you're not looking at whole frames, you're looking at how much time is taken for each task within the frame. When you think in terms of milliseconds you can assign things meaningful budgets, eg: "I need to get my AI taking less than 2ms per frame". When you're thinking in terms of FPS you can't.

Which brings me to the second issue. I often see newbie developers try to measure the performance impact of changes in FPS without realizing that they've got a meaningless number. Consider:

The issue is that the measurement of "200fps" is dependent not only on the speed of the computer but also on what else is going on. You also need to know more numbers to be able to work out the same useful information. Just knowing a change was "200fps" tells you nothing - you also need to know whether it was a drop from 1000fps to 800fps or from 220fps to 20fps, otherwise it's just useless.

On the other hand, if they'd measured it as 2.5ms that's a number that won't change depending on what else is going on.


On top of those things, regardless of which metric you use you also need to consider it in the context of the target platform. Measuring performance on your dev machine can give indicative results, but at some point you need to test actual performance on your target hardware. There's no point wasting time optimising something to be faster on your dev machine if it's already fast enough on the target hardware, and nobody cares if something's silky smooth on your dev machine if it's a slideshow on their device.

 

So you're suggesting that someone spend time building and then optimising a thing that is different from their game and may well exhibit different performance characteristics? For... what, exactly?

"Stress testing" isn't a buzz word. It's a thing that you do for systems that will undergo unknown variable stress. The point is to measure or validate the extent of the stress that can be effectively managed so that safe/useful limits can be established. This might be relevant for some video games, particularly where users create things, but if your game doesn't have that then why waste time testing with anything other than your actual, known limits? It's just more work to get information that's less directly applicable to achieving your goal than if you just tested the actual thing.

 

No I'm suggesting they produce a turned up to 11 level of their game, that will push all the elements of their game beyond anything they expect to build and release.

Stress testing gives you:

1. A good idea of the biggest baddest level your game can handle so you can ensure all your levels are built to run well.
2. It also allows you to get an idea of how your game will perform on slower hardware.
3. Provides a platform where you can optimise early knowing that your optimisations will boost your games performance.

 

How is "beyond anything they expect to build and release" not "different from their game"? How does it not potentially "exhibit different performance characteristics"?

 

In the thread I link to above I and @GarBenjamin built a stress test version of space invaders, with many more aliens and ships than the standard game, the aim was to see how performant our approaches were and to allow us to improve their performance.

So for Arkanoid you could make the arena larger with 4x the area for more blocks, bats and balls. You are then stress testing their "Arkanoid system". It is the interaction of the elements in their "Arkanoid system" that are being stress tested, the same elements they use in the game.

And you want it to exhibit different performance characteristics, as this is the aim of a stress test to try and "break your system" or in this case to push your system to a level that highlights its performance problems. Although you might also find bugs.

After doing a successful cycle of stress testing and performance optimisation you should see a marked improvement in your games performance and know that even under load or on slower hardware your game should still run well.

 

Making a different level only tells you how a different level runs on your current hardware, it does not tell you how a normal level runs on slower hardware (whatever that means—what is slower? CPU? GPU? Graphics API?). Sorry but you haven't thought this through logically.

--Eric

 

You are absolutely right without running and profiling on minimum spec hardware you do not know how your game will run.

Now unless you are releasing on console, which the OP is not, he cannot predict what level of hardware people will be using.

However he can push his game system beyond what it will need to do on his hardware, this will highlight performance problems that will probably appear on lower spec hardware and allow him to optimise these areas.

 

That's not how it works, though. In order to test performance on different hardware, you test on that hardware. There isn't a way around that part. You use real-world tests to figure out what to write down for minimum specs on your store page. The "stress test" might indicate areas that are a problem on different hardware, or it might not—the point is you don't know, because you haven't actually tested.

--Eric

 

You would also run the stress test on target hardware, especially if different from your development platform!

 

Running your game on a larger scale can sometimes highlight areas in your program that take a long time. However this only really works if your game has linear complexity. If you have non linear complexity then it will actually start leading you in the wrong direction. And many, many game systems have non linear complexity.

Testing your game out on the worst possible situations the player can create makes sense. Testing it on situations the player can never create is a waste of time.

 

I would disagree as most games and the systems or mechanics in games have linear complexity.

Actually could you give some examples of games with non-linear complexity, as we may have different opinions on complexity?

For me stress testing is putting way more of the elements into your game, so a larger level with way more NPC's or enemies than you would reasonably need in a level.

To have non-linear complexity you would need things like multiplying balls in Arkanoid, enemies that explode into more exploding things. Exponential chain reactions where elements affect sub elements that subdivide recursively.

IMHO very few games or game engines can handle exponential reactions or interactions without strict limits or for that matter game hardware. Exponential reactions are the fields of and for supercomputers.

 

Run the game through a program called "profiler" which gathers performance data and returns information about bottleneckcs. Unity has built-in profiler which is good enough for most purposes.

https://docs.unity3d.com/Manual/Profiler.html

 

Sure. Collision detection, sight detection, anything that requires broadcasting or notifying multiple objects at once.

Basic example:
An autonomous agent in the scene that runs "Overlap sphere" and then raycast to determine visibility.

2 agents in the scene within vision range: each one will run one overlap and one sight check. Two sight checks total.

100 agents in the scene. Each will run an overlap sphere and then 99 sight checks. 9900 sight checks total. Non-linear complexity. You can reduce it to about n^2/2 and optimize it a bit, but in general, it is nonlinear.

Something like boid collision avoidance will have similar characteristics.

 

In which case your stress test has highlighted a problem with your system.

Potential fixes:
Introduce a sight test manager, that limits the amount of sight tests per a frame.

On a side note: it would be amazing if Unity's camera occlusion system could be used to run tests like these, it can probably run a occlusion voxel based test between two points in a fraction of the time it would take the physics engine.

 

Games? Think more of algorithms, and maybe look up algorithmic/time complexity.

 

Which is fine for slow games where you are searching for strategic moves like chess. But inherently with a high FPS game you are not going to be doing complex searches.

 

https://docs.unity3d.com/ScriptReference/Rigidbody-sleepThreshold.html

Doesn't that do what you want?

 

Thy who burns with milk, sees the cow and cries. ~

Make the mistakes, then pre-optimizing will come naturally!

 

I would disagree that you know a thing about making games.

It's entirely common for games to have search problems with non linear complexity. Collision detection is the most obvious, as mentioned. AI target finding is another. Any system where you have to compare every entity to to every other entity is non linear.

Except no.

By testing a system beyond the maximum capacity of the game, you have just introduced a new optimisation that doesn't actually help at the capacity your game runs at. The techniques used to handle a hundred agents will hinder you if you only ever need ten.

 

Err, no, nope.

Non linear complexity pops up quite a lot. Trying to insist that "complexity is linear" is simply incorrect.

When objects can interact with each other, you'll run into n^2. n log n and all that stuff. Heck even sorting algorithms tend to have average n logn complexity at best, and they're used a lot. In case of mass broadcasting any event, n^2 is pretty much unavoidable.

You will be doing complex searches a lot, possibly every frame, they're foundation of all meaningful operations in a game world. Even if you're not doing them yourself, they'll be running behind the scenes. Sweep and prune, for example, relies on sorting algorithms heavily.

You're absolutely off the mark with those ideas this time. Non-linear complexity is very common, and happens very often, especially in a system where objects can interact with each other.

 

Your game probably has 16ms to do it's thing. If you go over by even 1 ms you step down in frame rate e.g. 60fps to 30fps.

Considering that Unity will probably use up about 10ms leaving you with 6 ms a frame to do your thing.

Now if you ever have a level where you have 11 units, you have doubled the workload of your LOS system. Your approach you get a frame rate drop until that extra unit is removed.

With my system that manages it's LOS checks per frame no hiccups, smooth FPS.

But I obviously know nothing about making games!

 

Dude, get your facts and ideas right, because at this point this is not even entertaining.

16 ms per frame = 62 frames per second.
17 ms per frame = 58 frames per second.

Then why the hell do you argue with people that actually know things about it?

 

I think he was talking about certain vsync setups.

 

This.

There are tons of factors that can cause performance issues. Using "more stuff" as a benchmark is probably least practical/informative way to test. In some situations it could provide some info, but not much you cant glean through other methods. Pretty much profiling and platform testing is the key. Just doubling stuff on the screen may lead to the wrong conclusions if the problem is actually a shader issue with certain hardware (... Grr android). You have to test on target hardware.

 

That's got nothing to do with what's being talked about here.

Like I said, "stress tests" can have their uses. However, for figuring out where to optimise to meet performace targets on target hardware they're additional work for inferior data.

And this (apologies for the cross post, but it's direcly relevant) is precisely why:

 

The topic is Pre-optimizing a game, my point is you can Pre-Optimize if you use a stress testing approach. The aim being to improve the performance of your game in Unity.

The OP mentions that in this case the target platform is WebGL, so would you recommend buying a minimum spec platform to test a WebGL game?

But you are correct if you are building to a specific hardware platform with a minimum spec you should build, run and profile on that hardware.

If you have enough money/budget to buy the hardware.

 

The point is that you are wrong, as has been explained in detail by several people, including those with a great deal of actual experience in the industry.

Yes, obviously?

If you don't, you're not really in a position to be publishing games professionally. At the very least you can hire testers who have access to such hardware.

--Eric

 

We can agree to disagree.

As quite frankly if you stress test and optimise your game you will produce a better product than a game without stress testing.

How many projects have game developers worked on where the crunch to get everything in and running at 60/90/120 fps at the end of production for that last few big levels was a nightmare.

If you had built an early and regularly updates stress test level for you game you probably would have breezed through that last level knowing what your game can handle and that you have optimised it for performance above and beyond what it needs.

Actually I would especially recommend this approach for VR/AR games where high fps is paramount.

Or even in this case for an Arkanoid clone, especially one running on WebGL which is inherently slower than native.