While trying to get a game done, bad luck always tricks with you.
So this time my intentions to implement everything needed into the game,
to fulfill my “featuritis” (actually a nice german word creation, for feature creep), has gone to a screetching halt: Everything has gone to slow.
Today: Developer Blues.
Quite intentionally I do not develop on a fast Android phone, quite contrary my
Motorola Droid has quite a bit low cpu and gpu specs for its high screen resolution. But besides me liking its hardware keyboar a lot, I think its good to develop on a medium spec machine in order to get games running on more consumer owned phones.
So from the style point of view the game features intentionally no textures on landscape and objects, and thus is already running quite fast from the pixel performance point of view.
Nevertheless, the games basic idea managed to criple its performance a bit: I wanted the game to show what was so cool about Yanns processing based applet, which is the fact that you can play on the games background. Nearly all platformers do only have decorative paralax backgrounds, and we wanted to make it playable.
To be absolutely honest, we had quite a struggle with our first ideas to include the background into actual gameplay, and finaly our design resulted in the fact that the background is just a foreground, because you can travel to it. Nevertheless, my aesthetic mind feels quite pleased by the look alone, so i think its worth a try to keep this as it is.
The background layers become smaller when farer away, more or less imitating a 3d perspective. But this brings us back to the current problem: When on screen only 10% of the foreground layer is visible, the 7th layer shows aprox. 95%. Which means that, on average two third of all objects in the game are visible at all time.
Which makes the game currently run on my phone with less than 30 fps. So last thursday from 8pm to friday night at 3am i used Google supplied tools to profile and analyze the performance bottlenecks. Tried to handtune code parts, read (again) about all basic tips to speed up java code on Android. All failed! In the end i managed to win aprox. 5%, which is less than 2fps, and probably the worst performance optimization session i ever had.
My resulting opinion: Java is unbelievable slow.
One of the bottleneck calls that eats up most exclusive time is a static function that does two adds and a divide. Yes, it is using floating point, which are done in software on android, still my benchmark doing floats in a C lib via JNI results in only 60% performance gain overall for massive float calculations.
But here its not possible to place the calls into a lib without to much overhead from the JNI calls themself and also we are talking about 10.000 cals per second, not about the millions a benchmark can achieve per second.
To be fair, the official Java virtual machines actually are not slow anymore, since more than 5 years JIT (Just in time) Compilers rule the Java world. There are even some benchmarks arround showing that Java code with proper JIT outperform C code (even when compiled by an extremely opimizing compiler).
But Google did not manage to include a JIT before Android version 2.2. And because over 25% of the currently customer owned phones are less than version 2.2, i think one can not rely on JIT to safe the day.
Of course my code could be better. There will always be some details i missed – but from day one i talked with Yann about the performance and how we should be careful about it. I used my knowledge from my previous 2 prototypes and from my first released game and thus conceptually my framework must atleast be okay from the performance point of view.
Which must also be due to the fact that it is truly not doing much, Silent Totems still is a simple game, with quite few active objects (compared to an Real Time Strategy or even Tower Defense game).
As a result I’m pretty pissed.
In the end easter- and 1st-may-holiday-weekends are over and i haven’t gotten much further with the games intended features. And additionally the performance got slow when not even all intended features are implemented!
The only way to reduce the performance drastically, is to display fewer objects. Only two tools to do this are available: The first one was a redesign session, where we talked about all possible objects and how to reduce the amounts of them in one play session.
The second one, is scalable, working extremely well, but makes me quite sad: reducing the amount of background layers visible. Take a look at the screenshot.
I adore it: Many layers with many objects look so life-like.
Todays diary ends with the following request: Please do me a favour and post into the comments… and tell me your subjective opinion: how many layers do you think it looks really good. Is it still as “great” with 6 or even only 5 layers?
I think 6 layers would still be okay, but 5 layers would be a bit too few.
To increase performance, maybe you could display fewer of the objects in the layers, that are far away.
thanks swante, for the input. how to decide which objects far away not to draw? all objects are large enough so that its clearly visible when they are missing. for you on the screenshots the objects look unidentifiable, but when you play the game and travel to other layers, you clearly recognise the objects – and thus i would fear that players may think objects vanishing on last layer has something to do with gameplay…
yann and me also think about a setting, where the user can control how many layers the game should display. but intentionally we do not have any settings menu or something like that. so we think about placing a character in the world, whom you can talk to and he will change the “how many layers to draw” setting … now just a gameworld justificiation / explanation would be needed. weather change? more “fog” in the background? well, to make that “good”, we’d actually need to fog (draw “clouds”) where the layers would be… so that sounds like more trouble.
It’s a difficult decision.
I think the comparison you made here is a bit unfair. In the 4 examples, you removed the layers on the back first. From a visual design standpoint, that’s the easiest way to lose depth. The perception of depth should be depended on the contrast of size (and shade) between the smallest background layer and the largest foreground layer.
My suggestion: try keep the layer furthest away the way it is. Successively remove the layers in-between and spread them out evenly. You should be able to get rid of a lot of them without lessening the impact of the visuals.
On the other hand, I presume the layers in the back cost most processing power.
So if that doesn’t work I would experiment with some LOD solutions like swante suggested. Even if you end up with pop-ins. As far as I understand, the game started out with a specific visual idea. You should drop/redesign everything that prevents you from achieving it.
Still liking this a lot! Don’t get discouraged! <3
yeah, thanks for the good hint. it would help visually to not remove from the back. of course performance wise its good to start there.
another idea would be to only remove rendering objects in the back, and still render the ground-layer.
but my problem with partially rendering, and also with removing a full layer in between is the fact, that i expect people to get used to the game. get used to the objects and understand that the background is the gameworld, and then start looking in the background and will wonder if its not “physically” correct. i.e. objects vanishing, or a layer “in between” missing. i fear abit that they might wonder about it or think this is a clue to our puzzles …
removing the layer from behind, just feels okay, like “not all is always showing”, its still just a game. but only removing objects, while still rendering landscape – and the same with removing layers in between … i donno.
thanks for your input, K!