Hello. We (a small team of two) are developing a topdown (isometric?) type strategy game targeted to mobile devices. This game will look similar to popular games such as Clash of Clans, Star Wars Commander, Command and Conquer - Red Alert, etc. We would like to target iPhone 4+ and iPad 2+, and equivalent Android devices.
We have began developing and have created a rather slick interface in 3D. The interface allows you to move the camera on a large circular track around the battlefield and zoom in and out, seeing the battle from all directions. We really like the way it works and we think it will be a great gameplay mechanic.
However…
We are already running into performance issues. All of the static meshes we have brought in have had their poly count reduced. The animated character we are testing with has been reduced down to just under 500 polys, which is already degrading the appearance slightly. We are using LDR mode with no post processing, and textures are at minimal levels to achieve the look we want. There are no physical bodies as we do not need to use the physics system. And yet, when we have 100 animations on screen at the same time (characters moving and fighting, turrets aiming and firing, etc) everything slows down to a crawl, and the FPS is at unacceptable levels. (This is testing on an iPad 3 and iPhone 4s at non-retina resolution.)
I realize that there are probably some additional optimization techniques I can use, but I am getting a bit worried that this is going to be a constant problem. With all this in mind, I would like advice on the following:
Does it seems to you that we should be able to achieve the desired amount of on-screen animations with proper optimization?
Should we immediately convert this game to 2D? By pre-rendering our models into 2d sprites and creating a fixed (isometric) camera angle, it would probably be trivial to achieve the desired concurrent animations. But this removes the full 360 view of the battle, one of our favorite features.
If we do convert to 2d, is Unreal Engine the best solution for us? I have heard that Paper2D is still not very stable, and we are in active development now, and would like to release in about 6-8 months.
I apologize for the long-winded question. Any advice is appreciated.
Have you ran unit tests yet? You can enable performance checks to see exactly where you’re getting killed on FPS. My guess is that it’s the collision checks for each animated object as it’s trying to navigate through your world. How many bones does each animated object have?
Check out the STAT commands while you run your game (you can have these display on the device while playing as well through some minor blueprint enabling).
That’s not the case here. There are no collision checks in the system yet. All of the objects (characters) are programmed to know the location of every other object, so that they automatically find a path around things without bumping into them. The animation rendering is the major bottleneck, and you may have a good intuition about the number of bones.
My current strategy is to reduce the bones and animation frames of each object, and it seems like this is going to have positive results. Next I am going to look into some method to optimize the animations when there are many identical pawns being animated on screen. There must be a way! I have not given up yet.
I’m assuming that even in your logic to avoid actual collisions of assets, you’re doing line traces or sphere/capsule traces to determine distance to walls/floors/solid objects/other animated objects. Those are “collision checks” and they’re done every frame to ensure navigation in your world works as intended. Running a trace every frame isn’t that demanding, but if you’re tracing for 100 assets you’re going to notice a hit in performance. I have no idea what the complexity is on your traces and how you could optimize them without knowing the game itself, but the best idea would be to make sure all of your collision volumes (in the world and on the animated objects) are as simple as possible. I think the simplest form is a sphere trace since it only requires a radius to calculate rather than several points in a basic square.
Someone else might be able to chime in with more details here though.
I am curious, as our target is also iOS but we are still in the design stage of the game vs performance tweaking.
Are you running any of the new Metal code in the tests? I wager after tomorrow the NDA will be lifted and we might hear something from the UE4 team, but curious if it is as indeed as powerful as it seemed from the dev conference earlier this year.
I don’t think you can have a hundred independently bone-animated models moving around and firing projectiles that explode run at acceptable performance on an older iOS device like the iPad 3. That’s too much, even if you write your engine from scratch in XCode.
You need to do some in-depth profiling now to find what compromises must be done to make your project viable. Disable/remove features one by one to find your bottlenecks: replace the animated models by rigid ones to see how much the animation is weighting you down, then test using unlit materials to see how much the actual rendering is bogging you down.
We are working on a iOS game and we get a solid 30fps on the iPad2 using unlit materials (our levels are dynamic, so we can’t use lightmass). Also, don’t use any engine-provided or sample-provided materials, they are often way too much for mobile. For example, we had a skyphere on our level that was killing the framerate on the iPad2: it’s material used over 80 instructions on mobile.
Actually, not so much. The system uses a 2D plane (even though it is 3D, everything is on ground level) and when a unit is spawned, a method is run to determine where it should go. It then moves along that path until it fires the “reachedDestination” event OR another event is fired that the unit listens for, such as a building being destroyed. This system uses very little processing power compared to other systems, as it only does waypoint calculations when it has to.
Right, Pedro. I have been doing this and the animations are the major bottleneck. Even low-res characters when animated with bone rigs use up processing power pretty quickly. I have already been using simplified textures
At this point we have decided to target newer hardware only. Tests on the iPhone 5s and the iPad air are running buttery smooth and I believe we have room to even increase the image quality. After the announcement today from Apple about the iPhone 6 and iPhone 6 Plus with greatly increased performance, I believe we will have the necessary market for our game in 6 months. There may be a lot of developers doing the same thing as us, I imagine, especially if the Metal shaders are as good as advertised.
If you go that route make sure you remember to uncheck the unsupported devices when submitting your app. You cannot remove supported devices after the first version of the app has been submitted to Apple. We made this mistake at my past job and we had people trying to run our game on 256MB devices (iPhone 3GS and iPad 1) and complaining about crashes, when the app shouldn’t even show up for them if we had did it correctly.
Really curious to see what the profiling data would look like. I’ve had performance issues where draw calls were the enemy, and some where it was (as mentioned above) too many things checking their collision at once.
+1 to pedro_clericuzzi’s suggestion of pulling features one at a time and re-testing. It takes some time, but you can typically find a lot out about what is and is not a good practice
in regards to the iPad 3 - I’ve historically removed it from my target devices due to it’s inability to keep up with it’s own retina display. The iPad 4 is already 2 years old, and if you’re making any sort of performance heavy game, you’ll see *drastic *differences between those two gens.