Timbertales open beta – Android
Hey guys,
today I started the open beta version on android. If you would like to join follow the link:
I am looking forward to your feedback! Have Fun!
libGDX performance tips, what I have learned so far!
Hey everyone!
Today I wanted to write about a more technical topic – libGDX Performance. I spent the last week in improving the performance and memory usage in Timbertales. Since it is my first libGDX project and even my first openGL project. I am still at the beginning, but I wanted to share my experience so far. The first problem I faced off was: I usually test my developer version on my macbook (compiling is faster than testing on phone/tablet or simulator). On the macbook we have a lot of cpu power and memory. So I often ended up with 60 fps and the usage of memory was also quite ok. But when I test the same version on my kindle fire the fps break down to 20fps and the memory allocation is out of control which ends up in heavy garbage collecting and resulting in a stuttering software.
Tip number 1: Always test on different hardware! Make sure to test on slow hardware
A slow hardware also have the great advantage: You can see improvements immediately. For example I had parsed a JSON string on my macbook, which was quite big. It took 90ms, so I reduced the size of the string and ended up with 79ms for parsing. This is quite good, but it don’t feel very impressive. Then I checked the same JSON string on my kindle with the original length of the String it took 350ms, after my reduction the kindle just took 90ms. As you can see the improvements scale better on slower hardware or is better visible 🙂
Tip number 2: Avoid String concatenation in the render calls
I used a lot of String concatenation in my render calls first for example
int score = 3;
font.draw(batch, "" + score, x, y);
This one seems pretty simple and shouldn’t do that much. This was at least what I thought, but this one always creates a new String, every single time its called, which is normally 60 times in a second, since we want to achieve 60fps. So what it does is: Allocate memory for the new String Object with every call, if you have multiple calls like that and just a little bit of free memory it will fill up fast and the garbage collector has to do his work. This will not leak memory or something, but it will call the garbage collector very often, which can result in stuttering (The garbage collector is not running for free). To avoid that problem make sure to set up your strings, objects outside the render calls.
font.draw(batch, scoreString, x, y);
Tip number 3: Avoid to create new instances of any objects
It is related to tip 2. You should never create an instance of a new object inside the render call, because it will create a new instance every draw call. As I said before these are 60 calls / second and java will always allocate new memory for the new instance. So avoid stuff like that:
pubic void draw(SpriteBatch batch) {
Effect healEffect = new Effect(); // this one should not be instantiated inside the draw call
healEffect.draw();
}
Tip number 4: Assets and other resources
As I said I am new to the whole openGL and libGDX stuff, so maybe the tips I write are pretty obvious for other people. I often made the mistake to get resources or translations out of my asset manager while rendering, this resulted often in terrible much memory allocations.
public void draw(SpriteBatch batch) {
batch.draw(Assets.instance.getTextures().unitTexture, x, y);
font.draw(batch, Assets.instance.getBundle().format("translation", "text to insert"), x, y);
}
The texture call isn’t that bad at all, but it is always better to have a local reference. The second call with the bundle was actual a very big problem. As the string concatenation problem, the format always creates an String Objects in background which also allocated a lot of memory. To avoid these problems I use the approach to create my Strings before rendering and save the assets as local references:
public void draw(SpriteBatch batch) {
batch.draw(this.unitTexture, x, y);
font.draw(batch, this.translationString, x, y);
}
Tip number 5: Do manual iteration over Array lists
This one was mysterious for me 🙂 I read through a page for java performance and improvement, because I always had the feeling that there was a lot of memory allocation ongoing when I used Array lists and I couldn’t understand why? So on this page I just read that the standard iterator for array lists is creating allocations, where the manual way doesn’t so what I did was to change every “for” loop in my code inside the render calls:
// old usage with lot of allocation
for(Object object: objects) {
}
// new manual way with no allocations
int length = objects.size();
for(int i = 0; i < length; i++) {
Object object = objects.get(i);
}
// UPDATE you can also use libGDX Array
So I had to write a little more code, but the result was – no more allocations inside my draw calls with array lists.
Update:
I hope this post can help people, who also have some issues with allocations or performance. I guess for more experienced people these tips are more obvious, but maybe you can give us some more tips on this topic? Feel free to comment or discuss with me.
Make sure to check out my games written in libGDX: FlatFatCat and Timbertales
Kickstarter news
Hey everyone,
unfortunately one of our main investors on Kickstarter cancelled his pledge. So we are in a bit of trouble right now to reach our funding goal! This is very sad, since I was sure we are already funded. I did not know that cancellation is even possible so short before the end of a campaign is reached. Anyway I will try my best to gain more supporters through all my available channels to secure the release of Timbertales at October.
If you are interested in the game consider to help me out in this dark time 🙂 There are still 24 hours left until the campaign ends and I am sure we can make it!
Kickstarter t-shirt design is up and a small outlook
Hey everyone,
after some really hard weeks of promotion and social media effort, I am back to development business 🙂 Meanwhile we got some supporter for our Kickstarter and I am looking forward to reach the goal. Keep it up! But it is not done yet. We are about 80% funded at the moment, so if you want to receive cool rewards you should support the game on Kickstarter! Some of the rewards such as the master account won’t be available after Kickstarter anymore.
Before I start to give a small outlook about the upcoming features and things I am currently developing I want to share the T-Shirt design for the “Representation” – Reward (75 Eur) and the Kickstarter portrait, which every supporter on Kickstarter will receive in game.
As you can see we offer all kinds of colors for the T-Shirt, so you can choose your favorite 🙂
The portrait can be chosen in game for your account and will be shown every time a match is started.
Outlook – what is actually going on and what is up next
I am not sure if I mentioned it already, but in the actual beta build I added translations for english, since some supporter on Kickstarter are native english and got early access 🙂
Also the introduction of the players animation before a match started was added to the last build. Last but not least the spheres, which can be dropped, if a unit dies were also added.
At the moment I am working on the topic “Map diversity”. I already finished the first map with its own mechanic which is explained in this video:
In the second map I want to introduce a new mechanic, which I will also need for the upcoming campaign. Collecting and returning. There will be random spawns of acorns on defined map areas. You can pick up those acorns with any kind of unit by simply moving your unit towards the acorn and click on it, like you would attack normally. If you picked up an acorn it is displayed above your unit, so your enemy can see that this unit carries an acorn. If the unit dies while returning the acorn to a special place, the acorn is lost. By arriving at the special place you can drop the acorn by clicking on the special place. The first player, who returned enough acorns will receive a gift of gods. This gift will help you a lot to win the actual match.
I plan to create 4-5 maps with their unique mechanic for the release, more will follow afterwards. So we will have a map pool for challenge, arena, ranked and unranked mode consisting of 4-5 different maps.
After those maps are done I want to finalise the heroes concept and implement the first heroes. Of course the sylvan and vermin campaigns are still missing, so there is a lot of story and content todo. The rest of the time until October, if there is a rest :D, will be used to stabilise and improving the code and server.
Thats the actual plan for the next weeks, I hope we get funded to be save of course. Please share your opinion or feel free to ask about more details if you like.
Upcoming features
After evaluating the feedback, I decided to develop two new feature to become more outstanding. You should definitely want to watch the video until the end for a surprise 😀 These features will be implement in the near future.
Map diversity
To give maps more influence on the game. I want to create more new cool maps with their own mechanics. For example on the map: Plague of insects, you can destroy an insect nest and the insects will hunting down your enemies in return. I have a lot of concepts in my mind. Another example would be a map, where you have to collect acorns and bring them to some kind of god. The first player, who collected the required amount receives a strong unit in return or the god attacks the base of the enemy. There are many ideas in my mind and I need time to sort and evaluate them 🙂
Heroes
With heroes I want to bring heroes into the game. Every race will receive their own unique Heroes. Heroes will be stronger than units and will have two special abilities. If a hero dies the game is lost immediately. This will give a strong focus on the hero. I imagine that the hero will also gaining experience while playing maybe permanent, maybe just for the game. The concept is very raw at the moment and I have to specify it even more.
I would love to hear your feedback and comments.
Timbertales on kickstarter!
We reached a closed beta state of timbertales and i try to finish the game as soon as possible. My budget is nearly empty and will definitely depleted this month. This means i need to get some more budget to finish Timbertales. My idea was to start a kickstarter to get the small amount which is needed to finish Timbertales and of course I hope for your support. The big advantage of kickstarter is: I can give out cool rewards for every supporter!
I already receive some funds and appreciate that a lot. It is very important to outline, that only if we reach the goal the money is funded!
So I created some cool rewards for your support and want to tell you more about them:
- 1€ – 2x random ingame units, you receive news & updates around Timbertales
- 5€ – You will receive an unique Supporter-Skin for our badger “Rainy” & You also will be listed on the credits page
- 10€ – You can choose to support the Sylvan or Vermin, this means you get one campaign for free and the rewards before
- 20€ – You will receive the rewards before + the first two campaigns for free which will be the main campaign for the sylvans and the main campaign of the vermins
- 50€ – You receive a ‘Master Account’ with the master account you will never ever have to pay for anything in the game
- 80€ – You receive a ‘Master Account’ and a special Timbertales T-Shirt
- 125€ – Sponsorship in game with your personal logo and link + Master Account
- 250€ – Create your own game elemen
- 1500€ – You are allowed to define a 3rd race for timbertales with all its units and naming them. You can also define their look and feel and discuss it with our graphic artist + Master Account + Sponsorship
I hope for your support to be able to release the game as soon as possible, check out the Kickstarter page for more details
Recent Comments