by Rainware | Nov 14, 2016 | Allgemein
Introduction
A short introduction of my new project: Timbertales Puzzle. Currently I am developing a puzzle game based on Timbertales assets. I want to give you a short insight into my current state of development. Let me introduce the game in detail first. You will have to move tiles around in a specific level until your turns for this level are depleted or the level is finished.
Goal and mechanics
To finish a level you need to clear the way for rainy to reach his badger set with limited turns.
To control the tiles you just need to drag them around. It is very intuitive as you know the touch gesture from many other apps or games. There will be also some special mechanics: Tiles, which are blocked and cannot be moved or other obstacles to pass.
The game should contain round about 40 different levels at release and more will follow. The difficulty will of course increase with each level. I plan to offer different level packages, so it will be possible to continuously release updates with new level packages. The development time is scheduled until mid of December. Of course Timbertales puzzle will be released as android and iOS app and will be for free. Some level packages might cost a little fee in future.
by Rainware | Nov 1, 2016 | Allgemein
Short Summary about Freelancing building up the brand of Timbertales with a puzzle game and creating some ways to actually earn money to provide a better Version of Timbertales!
Whats going on
Meanwhile I am able to earn some money with my freelancing project yeah! My first investment – a new Asus Zenbook. I had to buy a new notebook, because my macbook finally died 🙁 So I will be back on arch linux for now :).
But lets get back to the topic. With the upcoming money I will be able to finally finish Timbertales within the next couple of months. Unfortunately at the moment there is a very short time frame to work on my Rainware projects.
Timbertales puzzle
With the short time in mind I came up with a new game idea: A Timbertales branded puzzle game – a tiny single player puzzle game based on the Timbertales Brand and assets, which already exists. The game should contain round about 40 levels. I reuse many of the assets I already use in Timbertales and also some of the code. This allows me to keep the development time for the entire game very short. My goal is to strengthen the Timbertales Brand and to create more attention for the upcoming Timbertales game. In addition I want to deliver something, earning money and so on 🙂
Whats about Timbertales?
This won’t delay Timbertales even more, because as I said for the moment there isn’t much time for it anyway. I will need to redefine some things and refactor a lot to improve the quality. That will make sure to reach the quality I was aiming for and deploy a game, which is fun for everyone. I want to release the puzzle game in between.
Shopware Plugins
Just another topic or opportunity for me is to distribute Shopware – Plugins. I am quite experienced in this area and just want to try out how the money can flow in this business 🙂 Of course this involves only small Plugins with a development time of less than 1 day. It should be a one time process to create the plugins and sell them over the store. Observe how its working.
For continuous news / updates about Timbertales – make sure to follow me on twitter! 🙂
by Rainware | Sep 30, 2016 | Allgemein
[:en]
The last weeks …
First of all I am sorry for the silence the last couple of weeks. I had a lot of stuff ongoing and wasn’t able to spend my time to keep you informed. Anyhow I will try my best to catch up. Bad things first I think, I will not be able to release any stable version of Timbertales soon. I did a quite unrealistic estimation with being releasable in October. Everything costs more time than expected and I also have to say I am not very happy with the gameplay itself at the moment. For this reason I want to delay the release – to craft a game, which fits my idea of quality and fun. But let us talk more in detail …
Money, resources, budget
September was the last month I could afford to be independent with my resources. So I needed to find a solution to keep the project ongoing. I had the opportunity to work as a full time freelancer for a project, which is scheduled for 3 months. This is one of the reasons, why I was such busy the last weeks and will be the next weeks. With the full time job it takes me a lot of energy to work in my spare free time, but I do my best to work on Timbertales every day. At least one problem will be solved: The money. After the project is finished I will have enough money to focus on Timbertales again completely for a long time.
Quality, concepts and more
Another reason for the delay as I mentioned is the quality of the game at the moment. I am not very happy with some parts of the game.
First the graphics, I actually like the graphic style and think for an Independent developer without any real artist resources its quite good. But I would love to offer more effects, animations and stuff like that. I think there is a lot of space for polishing and make the style more shining even with the limited resources. Of course it will take some time to implement such stuff, but in my opinion its worth.
Second I missed to design Timbertales with a mobile focus. I started to develop Timbertales as cross platform game, but with the lack of mobile game experience and testing everything on desktop version I lost a little bit the view for mobile. The last weeks I played a lot of mobile games to keep up with experience and concepts how to change Timbertales. The biggest problems I am aware of at the moment are: The registration, payments and the look and feel.
Registration: As known from most of the mobile games I played it is unlikely to register yourself an account today and is a barrier for new players, since there are google play and the iOS equivalent, if you want to persist your progress. Also on steam we don’t need a extra registration, so I will remove this part from the game with the next update. New players will also instantly start with the first tutorial mission after downloading and starting.
Payments: I spend a lot of time to think about how to monetize Timbertales and wanted to be innovativ with the start of development. Unfortunately that doesn’t work out and I have gone into a completely wrong direction. Instead of focusing on developing a good game I started to make myself to many thoughts on this topic. I received a lot of negativ feedback about that topic.
Simple Solution: Simple approach will be a place to exchange money for acorn points. Everything in game will be paid by acorn points except skins. Of course acorn points can get collected by playing and don’t have to be bought. I am absolutely open for suggestions on that point. Feel free to contact me!
Look and Feel: I think it is possible to create a better look and feel with using touch technologies of smart devices. Since most parts are tested and played on desktop version I missed to apply touch events for several actions. For example to collect acorn points in game you have to move your unit on the acorn point, why not touch it to collect? Presenting rewards will be also improved for mobile devices.
I am currently working on performance. I refactor a lot of old code, since my first approaches on openGL wasn’t the best. I learned a lot about openGL and libGDX the last couple of weeks and trying to improve a lot of parts through the game to minimize draw calls, memory usage and space usage. I am nearly finished on that topic so with the next update you should also receive a much better performance.
Outlook
This is the road map for the next updates. I think the game lacks a bit of long-term goals at the moment, but I can’t focus on everything and have to be more focused on single parts. My goal is to release a version as soon as possible, but it must fit my expectation of quality. For the moment it is really hard for me to say how long it will take until Timbertales is release able. I will provide an update as soon as possible with the mentioned changes. I hope to receive a lot of feedback and we can plan the next steps[:de]
The last weeks …
First of all I am sorry for the silence the last couple of weeks. I had a lot of stuff ongoing and wasn’t able to spend my time to keep you informed. Anyhow I will try my best to catch up. Bad things first: I will not be able to release any stable version of Timbertales soon. The estimation with being release able in October was quite unrealistic. Everything costs more time than I expected and I am not very happy with the gameplay itself at the moment. For this reason I want to delay the release – to craft a game, which fits my idea of quality and fun. But let us talk more in detail …
Money, resources, budget
September was the last month I could afford to be independent with my resources. So I needed to find a solution to keep the project ongoing. I had the opportunity to work as a full time freelancer for a project, which is scheduled for 3 months. This is one of the reasons, why I was such busy the last weeks and will be the next weeks. With the full time job it takes me a lot of energy to work in my spare free time, but I do my best to work every day on Timbertales. At least one problem will be solved: The money. After the project is finished I have enough money to focus on Timbertales again completely for a long time.
Quality, concepts and more
Another reason for the delay as I mentioned is the quality of the game at the moment. I am not very happy with some parts of the game.
First the graphics, I actually like the graphic style and think for an Independent developer without any real artist resources its quite good. But I would love to offer more effects, animations and stuff like that. I think there is a lot of space for polishing and make the style more shining even with the limited resources. Of course it will take some time to implement such stuff, but in my opinion its worth.
Second I missed to design Timbertales with a mobile focus. I started to develop Timbertales as cross platform game, but with the lack of mobile game experience and testing everything on desktop version I lost a little bit the view for mobile. The last weeks I played a lot of mobile games to keep up with experience and concepts how to change Timbertales. The biggest problems are: The registration, payments and the look and feel.
Registration
As known from most of the mobile games I played it is unlikely to register yourself an account and is a barrier for new players. So I will remove this part from the game with the next update. New players will start with the first tutorial mission after downloading instantly.
Payments
I spend a lot of time to think about how to monetize Timbertales and I wanted to be innovativ. Unfortunately that doesn’t work out and I have gone into a completely wrong direction. Instead of focusing on developing a good game I made to many thoughts on this topic. I received a lot of negativ feedback.
Solution – Simple approach: A place to exchange money for acorn points. Everything in game can be paid by acorn points except skins. Of course you can collect acorn points by playing. I am absolutely open for suggestions on that point. Feel free to contact me!
Look and Feel
I think it is possible to create a better look and feel with using touch technologies of smart devices. Since most parts are tested and played on desktop version I missed to apply touch events for several actions. For example collecting acorn points in game: You have to move your unit on the acorn point, why not touch it to collect?
Currently I am working on performance. Since my first approaches on openGL wasn’t the best, I try to refactor a lot of old code. I learned a lot about openGL and libGDX the last couple of weeks and trying to improve a lot of parts through the game to minimize draw calls, memory usage and space usage. I am nearly finished on that topic so with the next update you should also receive a much better performance.
Outlook
This is the road map for the next updates. I think the game lacks a bit of long-term goals at the moment. I can’t focus on everything and have to be more focused on single parts. My goal is to release a version as soon as possible, but it must fit my expectation of quality. For the moment it is really hard for me to say how long it will take until Timbertales is release able. I will provide an update as soon as possible with the mentioned changes. Hopfully I will receive a lot of feedback and we can plan the next steps[:]
by Rainware | Aug 23, 2016 | Allgemein
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 class
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
Recent Comments