[Suggestion] Low battery mode for Non Game Apps

This strays a bit beyond my functional knowledge of the details, I've monkied around a bit with the source but only in a few areas. But my understanding is that the 'main thread' is effectively is the game and runs the show. I don't think you can pause or sleep it. Well, you can, but that would quiting the the game, or backgrounding it. All game functions would stop. Basically you can do that now by quiting or switching apps on your phone.

 

Thus my comment on needing an alternative way to monitor for I/O events. Most likely native as you wouldn't be able to depend on any of Unity's APIs. Triggering one would allow the main thread to run for a period of time with the length depending on the event.

Alternatively you could simply play around with Application.targetFrameRate based on the needs of the application.

 

The whole thing is kind of a non-issue. Playing games is going to take more battery life, some more than others. Even so, it is pretty minimal impact. Any resource intensive app will suck more power. Proper optimization can minimize the impact and is the responsibility of the developer. If your game or app is killing battery life to an unusual or significant degree, your doing it wrong, time to learn more about your trade.

Unity is a game engine. It's UI is optimized for general gaming needs and context, and does it well in that regard, and will continue to improve. It isn't designed for pages of text, complex layout and structure and advanced typography / controls and advanced content display/management. It's optimized to display enough of that to support common use cases for games, optimized for that environment.

Native/frameworks/libraries/pdls, are built for specifically that purpose, and support it at a much deeper and optimized level.

Creating a pure UI type app is faster, easier and much more feature rich, robust, performant, and flexible in a tool designed for that purpose like uikit, cocoas, starling or any number of other tools. In pretty much same way that unity is vastly easier, robust, etc... in creating a wide range of games. Sure you can do it in unity, but there is a reason virtually no one professionaly does, it's not what unity is built for, and not effective.

Expecting unity to optimize to retool to complete in separate industry, when it has come dominate it's own industry by being highly specialized and focused is a failure in logic and wasted energy. Just learn and use the correct tools.

 

It is possible to 'wrap' unity with another app, but really awkward , and frowned on by unity an apple. IIRC, Apple pretty much disallows the practice. We tried something like this a couple of years ago for MAA. We built the UI and came core in uikit, and attempted to build the combat engine in unity. We got essentialy got it to work, but highly problematic on many levels. Not least of which was effectively running two apps simultaneously interacting with each other. Even if we ironed out the kinks, Apple wasn't cool with, and would have shot us down. (And apple often let's us do things others can't.)

Still, your concept would make an interesting experiment. While there are more practical approaches to the core issue, attempting to do what you are suggesting (fail or succeed) will gain better understanding. Knowledge and experimentation is always a win.

 

An empty Unity app uses 13% of my LG G3's battery. After optimizing the rendering (which was constructively shown in this thread) it is down to 8%. This is compared to Facebook which yields 5% and an empty Xamarin app which was less than 1%.

I think in large you are judging a book by its cover. Who care what that the marketing describes unity as a game engine. Unity's most powerfully asset is the fact that it can render a uniform, rich, presentation layer across all platforms. Being able to write once and run everywhere is its own reward. No one wants to support multiple code bases when they can consolidate into one.

The fact that we were able to make a 40% jump in performance without any involvement on the Unity side shows that this is possible. Considering that vertical apps pay the bills for most developers (and that indie developers largely loose money) this is really a win win.

Can you cite this ? There are plenty of other code once run everywhere frameworks (webkit, cordova, ect). None of these have this problem. Truth is the "Apple will ban it" argument is nothing but a thought halting cliche.

Personally, why are you so against people using Unity to its full potential ? Whats wrong with people using unity to solve enterprise problems ? Especially considering the few resources It would take. Ive already offered my time

 

Nobody cares what it's called. What's being explained is how it works in a fundamentally different way under the hood. There are very solid reasons for the difference between the 8% used by Unity and the 1% used by a Xamarin app. Those reasons are why we think you should use the appropriate tools, it has nothing to do with it being marketed as a game engine.

... you'd think they'd be happy enough to invest in learning tools optimised for that kind of work.

On another note...

... this information alone doesn't actually tell us anything useful. Sure you've got some big numbers and some small numbers, but we need to know (at least) how long it took the relevant apps to chew up that percentage of your battery for the comparison to be of any use. And that's putting aside things like wi-fi usage, what the app is actually doing, etc.

It's kind of like saying "I drove 14km in a Ford, and 7km in a Holden" - that doesn't tell you anything about either car without a bunch of other information I've omitted. I could have been driving one up hill in dense city traffic and coasting the other downhill on an empty highway.

 

Is it actually using 13% of your battery though? The image you showed earlier is CPU usage. It may not be doing a whole lot with an empty scene but it will still be interacting with the GPU too.

 

Using Trepn profiler. Reset before each test. Each test was for 30 seconds. I ran the test about 5 times each per application (to cut out outliers). Its not the best, but it is a step above anecdotal assertions. Trepn supports logging wifi, but, that is really a separate issue (your either using it or your not. I was not).

 

Ok then, can you give us more info on what that means? If it truly used 13% of your battery in a 30 second test then that means battery life is less than 5 minutes.

 

What is the difference between CPU Load and CPU Load Normalized?
CPU Load reports the usage with respect to the operating frequency. CPU Load – Normalized reports the usage with respect to the maximum frequency. For example, if a single-core CPU has a maximum frequency of 1000 MHz but the workload is low, the system scales the CPU down to 500 MHz (in one second, there are 500M clock cycles). If the device uses 100M of those cycles for work and is idle for the remaining cycles. CPU Load would show 20% (100/500). However, the maximum potential of the CPU was 1000M cycles, so CPU Load - Normalized would show 10% (100/1000).

https://developer.qualcomm.com/software/trepn-power-profiler/faq

 

No, I judge from extensive experience. And what it actually is. It's not actually a debateable point. Unity is a game engine. Sure you can do other things with it, but you can also throw a teapot, but that doesn't make it an airplane.

It can, but most other tools do that specialized part better (because they aren't running in a full blown game engine), faster and more efficently. Unity's most powerful attribute is that it is a kickass game engine.

 

And that is why I posted this on the forums for review. Youve made your case, now it is time to be constructive.

 

Most of us are being constructive, and productive.

 

Bah, the forums are not a place for productivity.

In fact I can't think if anything less productive then trying to strip unity of the game loop.

 

I have a good excuse, we just delivered and got approved our vertical slice, I'm enjoying a few chill days before the long crunch to geo-beta. I probably go dark again for a couple of months.

How about a full a day meeting to plan how to create plan to finish a game? (Yea! Monday) :/

 

I haven't done it with games. But I've attended plenty of pre-planning meetings on engineering projects.

 

Very Relevant

 

I want to believe.

 

Why do you think Unity's "full potential" is to pivot towards a well serviced market into which it does not optimally fit?

You've shown yourself that even when it's not doing much it's using 8 to 15 times more CPU than frameworks designed for the kind of tasks you're talking about. Do you honestly think that there's no good reason for that, and that it's just because Unity's engineers couldn't be bothered optimising it more?

 

I disagree with the use of the word pivot. Pivot suggests turning away, something which I am not advocating.

Whats wrong with exposing more optimizations ? After the render loop, what remains is the update and physics loop. Why not expose those for optimization ? The Unity 2015 video shows I am not alone in this thinking.

 

While I appreciate your passion for Unity in non game apps the amount of work required to make Unity energy efficient is being underestimated. I can see them undertaking and think it would help them to do some baby steps and low hanging fruit, but it won't make it far enough to compete on energy efficiency. You are definitely not alone in non game apps thinking and Unity could and should be more energy efficient but only by small factors. That will be welcomed by most but is still in a different league from other frameworks that are designed from the ground up differently to the point where users will still notice the battery drain vs even a heavy app like Facebook.

Also, your 50% improvement was at 1 FPS which is not acceptable to even a forms application. At that slow of a rate users get a bad impression even on simple things like button clicks and links. Also, I think even you realize that at each rebuttal the scope of work your describing keeps increasing. First, just exposing options to slowing the loop was mentioned (this part I think would be welcomed and is about as far as I see them going). Then coming up with a way to stop the loop but yet get input on the side was mentioned. Then shutting down rendering frills and fancy things. Then coming up with a GUI that is more similar to the design standards for IOS or Android. Then shutting down physics. There are also plenty of other things that if your were serious about non game apps that haven't been mentioned yet (ie. networking, security, etc). The amount of investment Unity would have to make would be huge and it's against their core business.

No matter how many times you hit a square peg with a sledgehammer it won't fit into a round hole.

 

All of the hard core game programmers here have indicated that making unity suitable for non game aps would require turning away from the core game loop. You either end up with a nasty hack sitting on top of the game engine. Or you end up breaking the fundamental game engine loop. The hack solution cannot ever be competitive. Breaking the game loop is turning away from its core business.

Some very clever people have commented on the thread, and nobody with any feel for the internals of the engine has provided an even remotely viable solution. I'm fairly sure by now this cannot be done in a way that is both competitive and does not break the engine for game developers.

 

So absence of evidence is evidence of absence ? All because no one from internal has spoken out (with the obvious exception of the Unite 2015 video...) does not imply that in the least.

 

You are of course entitled to your dreams. Scan through the other threads on the topic. Unity devs are pretty clear that their are other tools better suited for non visual applications.

Just because no one has commented on this thread doesn't mean they haven't commented.

 

Since when are we talking about non visual applications ? Perhaps the unite 2015 video does not exist either ? Its one thing to voice an opinion. Its entirely another to misrepresent my position... and the official position of Unity at that.


The bottom line is we will all benefit from improved engine efficiency. But don't let that stop you from your bad mood.

The fact that you are still here several days later tearing the idea down and not yielding any positive input only shows you to be a troll. Grow up and move on. Don`t you have better things to do ?

 

Unity is not the only framework capable of this though. You would be far better off picking up one of the alternatives that more closely matches your goals. With the popularity of web-based technologies we're starting to see decent solutions for bundling HTML5-based applications with a lightweight browser.

Simply build your application as you would any other web-based application and then bundle it with the solution(s) for the platforms you need to support. Electron, for example, supports Windows, OS X, and Linux and is the one currently being used for Visual Studio Code.

http://electron.atom.io/

 

Webkit, Cordova, PhoneGap are good solutions for many applications. They however run inside of a web view and can have some performance issues for non-basic apps. For instance I have an app that works with video, and I did not feel that webkits were the right solution. Another benefit of Unity3d is C#. Not only do I prefer it over javascript (by miles), but my servers all run on C#. Being able to share my libraries between server and client is awesome.

In the end, its all about the right tool for the right job and I feel that Unity3d can be the right tool for many non-game applications... especially if the power efficiency can be improved.

 

Ok then, lets not nitpick that, how about the spirit of the rest of the sentence?

Can you give a few examples?

Just because people don't agree with you doesn't mean they're trolling. You've got two pages of great discussion about the topic you've raised.

Ok, this is something concrete! What made you think a web-based solution was sub-optimal? What makes you think that Unity would be a superior platform for this if its power usage was significantly improved?

(For what it's worth, my questions there aren't meant to "tear down" anything. I'm asking because I'm interested in discussing. I hope you are, too.)

As someone who's worked with video in Unity a number of times I certainly wouldn't consider Unity to be optimal for that. For starters, movies behave differently across platforms (specifically, you can't play movies on mobile platforms the same way you can on other platforms), so you lose out on the whole "code once" thing there. Secondly, while it's fine and easy to just play a movie from end to end, implementing any form of user controls is a nightmare, for such reasons as the texture not being updated immediately upon the playback time being modified (so you have to 'play' for one frame's duration). (Caveat: Last time I did this was in Unity 4. They may have improved things since then.)

P.S: Making "non-game applications" in Unity has been my bread and butter for over 5 years. I do it all the time. I don't care if something is a game or not. What matters is whether it's a better fit for a real-time interactive framework (like Unity, Unreal, etc.) or something more event and GUI based (like the others mentioned in this thread).

 

Like was mentioned earlier there are other solutions than webviews, have you tried Appcelerator or etc? even webview you will have less issues than Unity setup and nothing prevents you to invoke a native view videoplayer from the webview interface. Xamarin is probably the best and most professional solution and has C#.

Anyways heavy optimizations or not depending of your app type the Unity is not a solution either way as you still wont be able to follow the iOS guidelines.

 

Yes. Big fan of Xamarin in principal and actually use it quite a bit. I however hate it's presentation layer. Writing xaml which outputs differently across each platform is painful. Write once, tweak everywhere. Now if they replaced native rendering with custom rendering such as kivey or *cough* unity3d has... now that would be perfect.

 

• Applications which require a world class presentation layer. Unity3d has some really awesome animation tools. When you take things like MaterialUI for Unity, its a real joy to work with. Lets also not forget the great editor.
• Applications which have a heavy 'code behind'. I am not a fan of Java, Javascript, or Objective-C. C# on the other hand is fun.
• Applications with server models written in C#. being able to share logic between tiers is always good.
• Augmented reality applications. I can see their use everywhere. Retail, real-estate, interior design.
• GUI heavy apps that you dont want to write 3 times.

No worries. There are only 2 people on here that are going out of their way to misrepresent me. Constructive criticism is fine.

Just use. It felt sluggish compared to the competition. Moreover you might went to check to make sure the native APIs you plan to use are exposed. If not, you will need to author js bridge applications.

Thanks for your experience. I have not run into those issues myself.

Even in games I find myself spending most of my time fine tuning the UI. Having to redo it multiple times for each platform is just painful.

 

Well your concept of getting rid of native just to save dev time brings us back to the dark ages where the user experience will not be consistent. Why do you think Apple has succeeded so well on the user front and on the first years and beat Nokia and Android? well they had pretty strict review proses where half-assed apps were mostly rejected and the same thing is still going on.

https://developer.apple.com/app-store/review/rejections/

 

Obvious poor applications aside , Isn't that just a cliche? Have they rejected any quality PhoneGap, app accelerator, Cordova, Kivi, or unity3d non-game applications for that matter?

No all of these competing frameworks are doing fine.

 

No, and you are still missing the original key point, most of these frameworks provide controls and features that are specific to the platform (aka native controls and behaviour). How were you planning to do that in Unity when you said you don't like different UI for different platform?

 

It is very relevant, especially the part where he recommends using native tools.

 

Of the 5 I mentioned only 1 uses native controls. What are you talking about ?

 

As I mentioned earlier, not only non-game apps would benefit from this - there are a lot of games which would benefit from lower power usage as well. Board games, card games, anything turn-based and/or very text heavy etc.
Currently (slowly, in the background) designing a turn-based strategy game which would benefit from lower power usage. I am planning on using Unity, because certain Unity features - such as a decent 3D engine - will be needed for parts of the game.

 

The game loop does drain the battery. Other game engines offer some options to game devs for a competitive edge. I don't think it's a bad idea if Unity gave battery usage some attention.

libgdx offers a way to suspend rendering until something interesting happens. https://github.com/libgdx/libgdx/wiki/Continuous-&-non-continuous-rendering

Obviously not useful for all game types, but definitely useful for some game types.

 

This is the other half of the solution. Other people have come up with a hacked version of this which included putting the main thread to sleep and then using an native plugin to wake up the main thread when something interesting happened.

While I am skeptical of the hacked solution, I think this is a good next step for Unity Technologies to take.

 

That's a great concrete example of the niche @zombiegorilla mentioned earlier.

 

@angrypenguin What do you mean? You'd consider a turn-based game as a great example of a non-game niche app?

 

More likely a niche of games that would benefit from having control over the main thread's execution.

 

Those type of games will benefit heavily from properly optimized code and app design. Like so often in these forums, people run into a "problem" and instantly start coming up with reasons/excuses/justifications why Unity should address their challenges on a global scale by retooling the app. (Usually making broad, unfounded claims about easy it would be.) This the "magic button" solution.

While Unity will have some overhead, (and I am sure that is something that is constantly being addressed and looked at), but, it is really only a problem if you don't optimize or simply don't understand what you are doing. If one's game is a battery killer, they need to fix that. The way to fix crappy game code isn't to turn it off stuff at a higher level.

Non-visually intensive/heavy games (or ones with big gaps between those moments), can be easily made to run very efficiently / battery-friendly by just coding/planning them properly. If you have built your game correctly, then you won't need to turn off the main loop (or whatever people are imagining the magic button would be).

Card games and board games are not really different than other games, stuff moves, probably you will have vfx, sound, etc. There isn't really a place to insert these imagined solutions that would have a significant impact. Having written a couple of them, they can have very low cpu/gpu usage. Heck, even our RTS that practically uses all device resources in battle, is very low outside of battle/stage editing.

Yes, improved battery efficiency in general would always be welcomed. But it really isn't a significant problem making games in Unity if you are competent. For more extreme solutions like stopping the main game loop (or whatever), that would have a minimal impact if you have already done things properly. Apples to apples, battery usage in Unity isn't something to worry about if you are making games, (assuming you do it correctly). Apples to oranges, battery usage is not great if you using Unity to make non-game, non-3d, UI heavy apps. Switch to the correct solution for those type of things. For Unity games, just be efficient in the first place, make trade-offs where needed and learn how to profile and optimize.

 

If someone can't make those type of games run acceptably efficient in the first place, more control over higher level functions is not a solution, only a way to get in more trouble. If you can't use a screwdriver properly, the solution isn't to switch to hammer.

 

Excuse me? Blaming 'crap code' is a non answer. It is a distraction and an insult to everyone involved in this topic. Other engines (Kivy / libgdx) are exposing options that allow developers to optimize their energy efficiency and so should Unity. Blaming 'crap code' is apologetic at its saddest.

 

No, as a great example of the niche where there's a heavy mix of both real-time and event-based interaction. I've already pointed out that whether something is a "game" or not is entirely beside the point.

But those tools are all really different to Unity in a number of fundamental ways.

 

I'm sure you can understand my confusion since I didn't see zombiegorilla say anything about mixing real-time and event-based interactions as a niche.

 

Please do explain.

 

Game code is always the first place to start. Since clearly most other games/developers can build games that aren't battery killers, it obviously can and is being being done.

 

Yes, but in terms of mixing both periods high real time activity and longish inactivities it would be super useful to be able to do stuff like drop the frame rate while still having responsive input (upon which you increase the frame rate again straight away). That way when you know nothing is animating or that all current animations are slow ones then you can render, say, 5fps instead of 30fps, significantly cutting battery usage*.

The thing is that this is all a big trade off, and each tool/library/platform/etc. has to pick their own balance in that tradeoff. Unity isn't set up like the lower-level libraries given as examples of how it can be "optimised". Those libraries come with a bunch of stuff that you can integrate, or not, at your leisure. When you integrate them you get some level of control over how they work, with the downside being that you have to do that stuff - you don't get to just open an Editor and start importing assets. With Unity, everything is ready to go out of the box, with the downside that you don't get that same level of configurability. It's a tradeoff.

* For what it's worth, this might already be possible with a native plugin for your various platforms. I haven't tried it, but I imagine that if your plugin listened for appropriate forms of device input or relevant in-game events and set the target FPS to your 'performance' target, and had an 'efficiency' target for when all input/animations/etc. are finished, you could get a pretty good compromise. There are potentially a few catches there, though, like whatever might go on with the physics system and its fixed update rate.