Unity market share

Just out of interest:

-How many mobile 3D apps are there in total at the moment?
-What is the Unity market share in 3D apps?
-How many mobile 2D apps ((ebook readers, calculators, puzzle games, etc)) are there in total at the moment?
-What is the Unity market share in 2D apps?

I think it is safe to say that the Unity market share in 2D applications is near zero. And that makes sense because why would you use a fully fledged game engine for something like a calendar, or a calculator? The file size would be bloated and worse, the CPU/GPU will run at full speed, draining the battery at an unnecessary high rate.

The only advantage of using Unity for pure 2D apps is the ease of multi-platform publishing.

With *only* 2 modifications, Unity could open up to a huge market of 2D-only apps:
-Strip out all the fluff out of the game engine you don't need to make the file size bigger.
-Let the user take control over Render calls so the battery is saved if the scene is static. Yes it can be done with RenderTextures but that is Pro only, and no, camera clear flags don't work on many mobile devices.

In Unity 4.3 there is much better build in support for 2D so it is evident that they know 2D is a market worth investing in. Wouldn't it be great, creating a simple non-battery hogging 2D app with Unity which isn't 20Mb in size?

 

Unity is a game engine, I doubt they have interest in anything that isn't a visualisation of some kind.

 

You've got to be kidding.

First off, there's no way for anyone to know those numbers.

Second, there are *tons* of 2D Unity apps out there. You could just browse the WIP and Showcase forums to see that.

 

I think he means non-game 2d apps.

 

HTML

"When you only have a hammer, everything looks like a nail"

Creating regular apps in Unity would way overkill, and it is doesn't have even a tiny fraction of the toolset available in native SDKs. That is not what it is designed for. And besides, the tools to build native apps are all free, and will always be more advanced. There is no way for them to make any money at it. Right tool for the right job. Unity is a game engine.

 

Hm, re-reading, I agree. But he does say "puzzle games" as well.

 

What point of using Unity for non-game or render apps. There are a lot of solutions for building non cross platform business app. Xamarin for example.

 

Because maybe the general workflow of development that Unity offers is too awesome to not use for non game apps? I tried Xamarin, I tried Eclipse, but neither was working for me without spending hours of reading up on new concepts I don't have to worry about when using Unity, I can just make whatever I like and it just works. And yeah I'm not the most experienced programmer but that's not the point. The way you can do things with Unity is so straightforward for me (and many others), why bother with another workflow? For now I accept the fact that my apps are bloated but in return I get a lot of flexibility how I write my code.

 

Yes Unity has great workflow and I am loving it.
But in general business app's use a lot of api's, native tools etc. With is of course can be used in Unity as well, but you have to use Native Plugins with is not easy at all, and not saving your time, besides you can not easily manage Activities on Android (you have only one).

My point that Unity is just great in creating games. And I do not want to see it as universal tool. Because most of solutions for game/business app develop is bad for business and bad fro game develop.

 

willemsenzo, you hit the nail on the head (zombiegorilla, no pun intended).

Yes indeed. The point is that quite a few of them unnecessarily eat up the battery.

Mainly yes, but puzzle like games which don't refresh the scene view much would qualify as well. 2D scrolling games or anything where the scene view changes all the time won't qualify. The target is an app which has the exact same view most of the time so there is no need to render the same thing all the time. Even the Unity editor doesn't render the scene view every frame, only if you provide some input (dragging a game object for example).

I agree. But it sure is easier to use Unity which I already know then to learn another IDE and language. I can live with the overkill. In fact, I can even live with the bloated empty scene 20Mb file. What bugs me is the fact that camera clear flags (depth only and don't clear) don't work on mobile platforms, forcing you to render each frame even though nothing changed, eating up the battery.

lacost, good point. But what if I dont need all the special API's which Unity doesn't support?

In any case, why say Nay? It only takes one bug/feature fix and this whole issue (except for the build size) is over and done with.

 

Let's just say, there is no perfect solutions for developing all what you want.

Every time you start new project you have to consider what tool is better for you.

If you for example want to create super cool calculator, Unity will work for you.
But if you what to create mail service... well I just what to see person who will do this with Unity Event with camera clear flags.

 

Not quite. Unity will eat the battery like there's no tomorrow. Can you tell me how to fix that?

 

set it to 30 FPS or maybe lower

 

That what I am talking about, of course it will eat the battery, but that is not big issue for calculator, you not using it all the time like Skype for example. And you can set even 15 FPS. In case you very good familiar with Unity, but do not know any other language and IDE, such app can be done with Unity.

 

For those of us ignorant in these areas, what's a good example of an iOS app made in Unity that eats the battery?

 

I think there are at least a few non-game apps that have been made by Unity. With the upcoming integration with Parse, having a rock solid and flexible back-end would be super easy.

Power consumption issues aside, I think Unity could be an interesting platform to create innovative apps. I know of a team creating a mind mapping app using Unity for app development and RoR as a backend.

 

Setting a lower frame rate is one step forward and one step back. Battery consumption will be reduced but user input will be more laggy. Unity only updates the user input logic every frame so even if you set the frame rate to 1 and put the user input functions in FixedUpdate(), input will still be laggy. Ideally I want to set the frame rate at 0 when nothing changes but Unity forces me to set at least a frame rate of 15, just for the user input. That is using 15x more CPU power then needed, which is quite significant.

lacost, wasting battery might not be an issue with a calculator but it is with a puzzle game which you use more then a few seconds. You make it sound like fixing this issue is going to take a sizable investment in time and money from Unity. And Unity being not designed for this in the first place, people are better off using, say, Eclipse. It would be "bad for business and bad fro game develop" fixing this rendering issue. Allow me to make the point that stopping rendering (without clearing the screen) is not rocket science. And if you think that one of Unity´s functions freezes rendering is bad for business then just don´t use that function.

Examples of Unity games where the screen sometimes does not change and thus where battery savings can be made:
https://www.youtube.com/watch?v=MsoXVMta2W0
https://www.youtube.com/watch?v=p1Cwev0Jv_A
https://www.youtube.com/watch?v=iRDuli7Ee2M
Others like solitaire, minefield, bejeweled, etc.

 

You are kind of talking about two unrelated issues here.

Yes, not rendering static screen states can produce a minor battery life increase. But with games there generally is a lot going on, not just on the screen but cpu and such. And it is generally expected that playing games (or watching movies or anything like that) is going to drain you battery more than just sitting there. While possibly more under the hood stuff could be done to squeeze a little better battery life out of games built in Unity, but really it isn't a concern. It's certainly not a problem or a "rendering issue" Most developers want higher visual performance. There is nothing to "fix". Sure, improving it wouldn't be a bad thing, but in the bigger picture, the issue is trivial to to the point of insignificant.

Second, people don't use Unity for app development because of battery life, they don't use it because it is not designed for it, and not good for building apps, or optimized for those type of apps. It is a game engine, It has a huge, robust feature set for building games. Building a calculator in a platform SDK (Eclipse is an IDE, not an SDK), is trivial. They have tool kits with robust features for building forms/ui/applications. (but not so much for games).

You CAN build a simple apps like calculators and such in Unity, but it's not efficient or practical. You CAN build games in core SDKs, but it is going to much faster and efficient to build them in Unity.

 

Indeed. The "problem" here is that something inherently designed for real-time applications is not optimally suited to creating inherently event-based applications. Sure, you can use things made for either to do the other, but you'll be making compromises to do it.

I'm surprised by how much this has come up lately. Once a fortnight for a couple of months, now?

Still, allowing users to explicitly control render calls would be useful sometimes. I wouldn't call it a "problem", but it could be useful for more event-based or GUI heavy games where things aren't necessarily in motion all the time assuming it would actually provide a battery life benefit.

 

How about these then?
http://answers.unity3d.com/questions/129268/android-quotclear-flags-of-cameraquot.html?sort=oldest
http://answers.unity3d.com/questions/319430/camera-dont-clear-flag-doesnt-work-on-android-.html

It works in Windows but not on mobile. That deficiency is not documented which means it is not supposed to be broken. So I think it needs to be fixed.

 

I am guessing what is happening is people are getting their first taste of creating something via Unity, and simply wanting to everything with it because it is what (or maybe the only thing) they are familiar with. You can really jump in, monkey with a few things and have something doing something. With something like Xcode(or any SDK), a beginner will be almost instantly confused when launching the environment, and really not be able to accomplish much at all without some knowledge going into it.

No doubt. I was just pointing out that it's not what is preventing it from being an app development tool. And certainly not a critical issue for anyone. Or, at least, if their game is a battery killer, there are most certainly other issues at play.

 

A couple of posts from 1-2 years ago on a unrelated topic? Those folks just have things set up incorrectly, or an old bug. I think you my be misunderstanding what clear flags does. You can read more info here:
http://docs.unity3d.com/Documentation/Components/class-Camera.html

I have a couple of projects where I am layering multiple cameras, and the clear flags works as expected on iOS, no problem. If there is a problem on Android, there doesn't seem to be really any complaints other than those really old ones. Its used commonly for effects and certain types of setups, I would imagine if were indeed broken there would be more info on it.

 

I have seen that page but let's go over it.

That is exactly what I am looking for. The smear-looking effect, because in essence you can draw something once and have it displayed for much longer. If you don't move the camera or the objects then it doesn't smear at all and displays quite nicely, for free.

No, because I have tried and and it works, but only on Windows (maybe MAC, didn't try).

Well, I can assure you that this "old bug" is still here. Go and try it. Show me that smearing effect on Android. Even the guy from 2D Toolkit confirmed to me that this doesn't work on all platforms.

Well, you can add me.

 

No, that's not the case.

Clear flags don't stop the camera from rendering. It changes what it clears, which just changes the result of a render. Stuff being clipped from rendering as a result of uncleared buffers won't be getting clipped until some way into the rendering pipeline, because it still has to get as far as calculating a new depth value for the pixel and testing that against the existing one, once per frame, for every fragment (or possibly fragment groups, not sure about the details on mobile GPUs).

That's not necessarily an issue with Unity. It's quite possibly that things work fundamentally differently on the different types of GPU or drivers. If that's the case then it's just one of the (quite few) cross platform issues that you'll have to handle in your software's design when using Unity.

 

Yea, I am having a little trouble following what exactly he is trying achieve as it is kind of all over the place. But if the goal is to replicate that smearing effect (which is generally what others are trying to avoid), it could be done with a shader effect.

 

It is not only the clear flags I am using but the culling mask as well. I set the culling mask to 0 once the camera has rendered one frame. That should stop the camera from rendering anything else. I confirmed this actually works using the profiler.

I hope it is not a hardware/driver/platform issue because other then RenderTexture, I don't know of any other way to force the camera to display one frame without rendering anything more then once. In any case, if Unity knows about this issue, they shouldn't advertise the clear flags as they do here:
http://docs.unity3d.com/Documentation/Components/class-Camera.html
Some features are known to not work on mobile (such as MovieTextures) and Unity is upfront about it.

The goal is not a smearing effect but to stop the camera from rendering anything and showing the last rendered frame instead of a black screen. If you can get the smearing effect to work, then by definition it is also possible to do what I am trying to do. So that is what I meant when I said "show me the smearing effect".

 

Form the manual "Determines which parts of the screen will be cleared" given that its an attribute of the camera its pretty reasonable to assume that this means "
"Determines which parts of the screen will be cleared by this camera."

You read it to mean "Determines which parts of the screen will be cleared, and if no parts of the screen are cleared by any camera during a frame the previous frame will remain rendered".

This is not how graphics cards/engines generally work, its very typical for an engine to render each frame and to define what will be rendered during that frame.

When you write documentation you write for your intended audience and I would expect 95% of the intended audience would immediately understand what the documentation means in this case. I doubt many of the rest would have difficulty working it out.

 

Since I am not that good with grammar, can you please explain this one for me?

From the manual:

Don't Clear
This mode does not clear either the color or the depth buffer. The result is that each frame is drawn over the next, resulting in a smear-looking effect.

 

Which is exactly what will happen as long as it continues to render. From the behaviour you're getting it seems that on mobile platforms culling everything might also be effectively turning the camera off. I agree that it's odd, and perhaps it's even a bug on some level somewhere, but it's not too surprising to me since it's a really odd combination of behaviour in the first place - "render, but don't clear and don't draw anything". Perhaps it's being detected that the camera isn't doing anything and so, being on low-end, fill-rate limited hardware it's determined that its contents need not be blitted (which under normal circumstances would be correct)?

Here's a suggestion: Instead of setting the cull flags to 0, how about setting them to render only an empty layer? It's a giant hack anyway, so maybe this'll help?

 

Sorry my mistake I was reading only the earlier part of the manual. I agree it needs to be cleared up.

EDIT: Although the urgency of such clearing up is likely to be low priority given its impact.

 

That might well be the case.

Tried it but it didn't work unfortunately.

Interestingly, this does work on Android:
http://answers.unity3d.com/questions/404637/subtractive-rendering.html
But a slight modification showing a smearing effect on Windows, doesn't show up on Android.

I'm afraid you are right.

Edit:
Perhaps it is a double buffering issue. Any way to turn that off?

 

For 2d there are far better cross platform solutions out there. And this won't change with 4.3

 

Oh? 'far better' is kinda strong considering 2+ million develop with Unity. Do tell.

 

Ok we talk about 2d games, right? No doubt for 3d Unity is one of the best choices. For 2d it's just overkill IMHO. It's just not designed for that, the resulting package size is too large.

Look I'm a programmer not an artist so I'm more familiar with source code than with editors. For me it was always easier to do the more abstract programming part. Unity's editor is great but not that useful for 2d games.

Personally (! and that's again my opinion only) I prefer a really simple solution for 2d games (even though I use Unity for 3d):

Monkey

I doubt anyone here know this. It's a cross compiler which compiles to native target projects (e.g. XCode project for iOS). You code once and get:

HTML5, Flash, Windows Exe, Mac OS, iOS, Android, Windows Phone 7/8, XNA, Playstation Portable, Blackberry...

The basic app code looks like this:

Code (csharp):

1.  
2. Strict
3. Import mojo
4.  
5. Function Main:Int()
6.   New Game()
7.   Return 0
8. End Function
9.  
10. Class Game Extends App
11.   Field _img:Image
12.  
13.   Method OnCreate:Int()
14.     _img = LoadImage( "background.jpg" )
15.     Return 0
16.   End Method
17.  
18.   Method OnUpdate:Int()
19.     Return 0
20.   End Method
21.  
22.   Method OnSuspend:Int()
23.     Return 0
24.   End Method
25.  
26.   Method OnResume:Int()
27.     Return 0
28.   End Method
29.  
30.   Method OnRender:Int()
31.     Cls()
32.     DrawImage( _img, 0, 0 )
33.     Return 0
34.   End Method
35.  
36.   Method OnBack:Int()
37.     Return 0
38.   End Method
39. End Class
40.  

That's it. This code will just display an image and works on all platforms the same above.

 

Thanks for the tip. I will have a look. What is the file size of an empty "scene" with monkey?
I am still a bit reluctant to learn yet another IDE though...

 

About 50kb for Android, about 320kb for a Windows Executable.

And of course there are others out there like Corona SDK, Marmelade, Phonegap, etc...

I've tested them all and found Monkey to be the best of them all, in terms of programming. You always get a native project so you can put in anything you like. The only drawback so far is that it mainly targets games. The creator of Monkey (What a pity about the name he did choose!) is a real good compiler dude, but he really sucks when it comes to marketing.

 

Wow 50kb is really slim!
I couldn't figure out if it is possible to code in C#, or do you have to code in "monkey" and the engine will make a C# script from that?

 

You don't code in C#. It's just an own object oriented language but very easy to learn. But it compiles to Java, C++, C#, Obj C, Javascript, ... whatever the target is. So you get a native project after all.

 

Hm. New language, new IDE. Not too excited. Cheap though.

 

Yeah it's always a matter of personal choice. I really love it when it comes to 2d games. Never found anything easier to handle with so many target platforms.