I was looking at some resources for developing to Mobile and i had some question that i couldnt clarify! Lets say we are making a racing game for mobile(Android 4.4 and higher, IPhone 5s and higher)!
The game lets say includes 20 cars.
Each car specification :
We are using PBR Specular!
Now lets say there are 4 vehicles on screen and each vehicle uses a script to be controllable(lets say a Car Physics Template Script).
Would this be too much for the phone, what is convenient and what is not?
I think its an interesting topic for every dev trying to build for Android/IOS
Just the car model that i described! If it would have been the whole scene, i wouldnt have worried a lot about that, but i dont know how many draw calls are good for mobile!
The general rule of thumb with draw calls, especially on mobile, is “lower is better,” with some caveats that apply.
Try getting the draw call count for a single car as low as you possibly can. If you’re having a hard time, consider using a simpler shader for the model.
Try it on the slowest device you expect it to be played on, like an older cheapo android phone or the iPhone 5 or something. If it runs on those, it should run fine on your targeted hardware.
Test it on everything though, the only way to know for sure is to test.
I’ve heard 250K polygons is max for mobile of 100 draw calls but that’s a while back now, as KnightsHouseGames says if you run it on the slowest device that you are going to publish to and it runs good the numbers aren’t that important.
If you look at the majority of Android & iOS devices in use now they are pretty modern & capable. I wouldn’t wasn’t time & money trying to get preformance out of your game so you can publish to Gingerbread Androids or iPod touch 4th Gen and such thing.
In Canada we have tax credits for doing R&D and this type of testing qualifies. But audits can be frustrating. Last time, the auditor asked me “if the frame rate is too low, why don’t you just turn it up?” and he made a knob turning motion in the air.
I placated him by explaining that this type of work is like multi variable calculus: You can make a lot of intelligent design decisions but, at the end of the day, you have to spend time testing directly on target hardware because of the complexity of variables.
Your very nice - I probably would of given him a blank stare as I closed the door in his face. Although I guess it’s a good idea to be extra nice to the tax auditor!
I rarely work on hard surface models, however I remember someone very recently having an issue with a specific shader on a car model - with a normal map applied.
Another gentleman responded to the issue (worked for EA or something) that they never used normal maps on car models - specifically for mobile development. He suggested it was better to increase the poly count by 2k instead of using normal mapping to get the detail desired.
I’ve not tested this - as I said I’m more of a character guy - but would be a good test for you to perform since you have a high number of cars to create. Wouldn’t hurt to create one with 2k more polygons without normal mapping to see what the difference in performance is.
Hmm… I think there was a nice paper about mobile optimizations…
Aha! here it is:
Basically, I recommend to test directly on target hardware. The first time I tried to run one of my application on my 3 years old android tablet it crashed on startup - because whoever made a “mobile friendly” object pack made sure to make every texture in the pack was imported and 2048x2048, RGBA, uncompressed and had 7 recolored copies of it hiding in nearby folders. Meaning the program was running out of ram on startup and getting killed by android.
I’ll chime in having a good amount of experience with car racing games on handheld platforms. I’m going to put a link to some cars I created some time back (just use for reference) __Unity Asset Store - The Best Assets for Game Making.
My suggestions: Try to set up your cars with at least 3-4 LODs (level of details). Shoot for 5-6k triangles on the LOD0 (highest resolution car), 2.k triangles for LOD1, 1k triangles for LOD2 and so on an so forth. Your LOD3 and LOD4 can be very, very low polygon, sometimes barely more than a cube. You’ll want a good system that swaps these LODs out at good distances for all of the AI vehicles. Unity’s built in LOD Groups might just do the trick or you can roll your own like I did. The only difference with my system is that, car’s that are behind you (a certain distance) are not rendered at all. Now understand I never used rear view mirrors, so that’s a consideration.
Use very simplified but great looking shaders. Shader calculations on mobile need to be as simplified as possible and still achieve the minimum look your going for. I found an amazing set of free shaders on the asset store that can do car paint convincingly well on mobile (and they are very low cost). You can tweak the matcap texture for them to look really good.
Matcap Shaders [FREE]
Your track environments should run around 12 to 18k Triangles at the top threshold. This can probably go a bit higher, will take serious testing to be sure. You’ll need to combine sections of your environments into chunks as well. You will then use these chunks with occlusion culling, so basically sections not seen by the camera are completely hidden. You can rely on Unity’s built in system, but I love setting up my own culling and having 100% control over it so I use the M2H Culling System that’s free on the Asset Store.http://www.assetstore.unity3d.com/en/#!/content/221
It still works fine in Unity 5, at least for me, and I’m using 5.3 at the moment.
Atlas all textures for the tracks. When I create a track for mobile I will usually end up with less than 10 textures for a track. Ideally everything for a track environment will fit onto about 4-6 1024px x 1024px atlas textures and a few textures that are unique tileable textures, like a decal sheet, the asphalt, the grass, etc. This also plays back to the vehicles. There is no need for a texture map higher than 1024px x 1024px for a vehicle in a mobile game. The tires and rim can be on their own 256px x 256px texture map as well. I usually do that to allow for wheel and tire customization in a garage menu. You don’t need PBR shaders or even anything with a normal map. Most car games, especially on mobile do not use normal maps. If you must use a normal map on mobile use Forest Johnson’s optimization tool to bake the normal map lighting down. Found Here → __Unity Asset Store - The Best Assets for Game Making
Use the simplest form of vehicle physics you can use and get convincing results. I have a tutorial I guide people through that shows them how to create a car that uses no Wheel Colliders, or any physics wheels at all.
You can think of it as an ice cube sliding around, except it has friction and you basically turn and rotate the ice cube in the direction you want to slide. Combine that with realistic looking faked rotations on the models’ wheels and you have very convincing feeling physics that are extremely simple. You don’t want to use WheelColliders, (4) per vehicle and attempt to have 5-10 AI on screen also using WheelColliders. It’s just unnecessary overhead on a mobile game and not needed.
At the end of all of this, you want to think of your consumer. You want to always make sure you support the latest devices out there, but also a good portion of the last generation. I don’t suggest supporting back several generations as it becomes futile. Knowing that you have to support slightly older devices means to be optimized in every aspect of your game, the audio, the 3D meshes, the texture sizes and formats, the shaders used, and so on and so forth.
http://hwstats.unity3d.com/mobile/
Look at this page for detailed device information for Unity game users on mobile. It’s interesting to see that the majority use devices with only 1GB of memory.
Drawcalls don’t seem to be as critical as it used to be pre iphone5/galaxy s3, though 15 draw calls per car, per 20 cars + environment + particles + gui. You’ll have to reduce, a lot. Maybe player’s car can be more detailed than the rest, have a good LOD system.
Also keep garbage collection under control. I’m pretty sure too much Instantiate() and Destroy() will make it busy, it’s always working on the background, and can give you possible hiccups, slowdowns, etc.
Yeah the fillrate and overdraw stuff seems to still be a huge performance killer as well. Make sure to keep an eye on transparency objects covering large sections of screen real estate. We kept getting fps drops on Skylanders and couldn’t track it down for a while. Finally we discovered that these large cloud sprites rolling by in the background were the culprit.
