If you’ve read this blog long enough, you already know: I use Unity3D a lot, and I love it. Not just for 3D games either! Making a graphic user-interface for a computer program is one of the last things a school ever teaches to Computer Science students, and in most languages, it isn’t easy. In comparison, Unity3D makes it practically instantaneous. Either with their built-in GUI objects, or by programming a custom library of clickable objects, Unity3D is by far the easiest way to make a program that requires any visual interface. Personally, I use it to make a variety of things, the most common I use being a customized text-editor to catalogue my library of DVD’s.
Yes, I used Unity3D to make a text editor. Stop laughing.
… but there are reasons why you shouldn’t use Unity3D for everything (I said stop laughing). For one thing, a compiled build of a Unity3D app has gotten bigger and bigger with each version, currently about 45 MB for an empty Windows game (I made a completed promotional demo recently, coming out to 46 MB… imagine if I had used a lower-level language, I might have been able to create a similar app for less than 1 MB!). Second, while simple Unity3D games can run on low-end GPU’s, it probably doesn’t fair well if you are using an older device without a GPU entirely. And third, and most importantly, is battery life: when using my simplistic text editor made in Unity, my Surface Pro device barely lasts 2 hours, when it can normally run for over 8 hours using other software (Microsoft Word, Adobe Photoshop, Google Chrome, etc.). Even the Unity3D editor doesn’t drain my battery as much as a compiled game does!
I only just recently found a solution to make Unity3D apps use less battery life. It isn’t perfect for all cases, but it works well for me.
The solution has to do with frame rate. Normally, a user wants a video game to run as fast as possible, at the highest frame rate as possible. This affects both simple and complex games: even if you have a game that easily runs 60 fps, why wouldn’t you want it to run 90? Or 120? or 240? The CPU doesn’t really know the difference: it just completes each frame as quickly as it can so it can immediately work on the next one. This means the CPU (or GPU, or whatever the weakest bottleneck is) is ALWAYS busy, even on the simplest games and on the lowest settings.
(The exception to this is if the game or graphics card is aware of the frame rate of the display; if you are using a 60Hz monitor, there is no reason for the game to run more than 60 fps. For now, I’m ignoring this.)
To solve this, you can choose to artificially restrict the frame rate of your Unity3D game. This can even be dynamic, reducing when the game is paused and set again to higher numbers during faster action scenes. An example to this can be viewed in the photo below.
An example of how to force your Unity3D game to a lower frame rate.
There are 2 settings. One, under “Edit -> Project Settings -> Quality” in the Edit menu, set V Sync Count to “Don’t Sync.” VSync is meant to sync your game to the monitor refresh rate to reduce screen tearing, but also tries to enforce the frame rate of the game. In your code for your game, add a line to set “vSyncCount” (the number is already 0 when you set it in the inspector, but this helps set it again just in case), and set “Application.targetFrameRate” to your ideal frame rate. I chose 15. You can read more about this (and how certain platforms won’t be affected by this setting in the code) in Unity’s documentation.
But why would anyone want to limit their game to 15 fps? Again, for most games, you don’t, or perhaps you want to only while the game is paused or while the user in in the main menu. But I made a text editor. I cannot personally type as many as 15 characters a second, and don’t personally notice if a button takes a few extra milliseconds to register on my click. In fact, I could probably get away with as low as 8 fps if I had to. When you think about it, most applications probably do something very similar, only increasing the frame rate if you are dragging an object with a mouse, or if you are drawing with a stylus. Otherwise, normal clicks or idle viewing can be kept at a low frame rate.
It’s a simple change, and did it make a difference? Now, my Surface Pro can last for over 7 hours with my Unity3D app open, an almost direct multiple of it running at a default of 60 fps. Sweet!
If you were hoping to find an answer to make a proper video game take less battery life, you might be disappointed… sorry. But now, I have one less reason not to recommend creating software, even just prototypes, with this game engine.
