CategoryDevelopment – Theory

How to create a Game’s Store

When creating a game, the in-game store or shop is one of the most critical parts of it. It is the part that has the tendency to be the least fun for the user but is the most crucial for the developer. Without a shop, most in-app purchases won’t happen in your game. This is why, even though it may not be fun, a developer should pay close attention when building up his shop. For our upcoming game, Tumble Panda, we put some effort and time into our shop and went through some iterations. With this game as an example, I want to show you how you can build a nice store.

 Step 1: Identify your store’s criteria

First, you might want to identify critical criteria for your game’s store. As for us, we worked out the following points. Now, as I’m a lover of simplicity and like having one screen doing one thing, I like to also have a more minimalistic design, for example with rather big instead of many buttons. Of course, this criteria may vary from individual preferences and from game to game: Our biggest point was that it should be easy and seamless to use. This is a very soft formulation, so soft, that it is probably a criteria for every app ever specified. This is why, from this starting point, we worked out six other, more specific points:

  1. The design should fit the rest of the game.
  2. The design should be as minimalistic as possible while still highlighting the different functionalities of the virtual goods.
  3. Animations should be as quiet as possible.
  4. There should be little  enough goods to not confuse the user while still providing enough variety to make purchases attractive.
  5. The flow from overview to purchase should be done with as little clicks as possible.
  6. There should be possibilities to gain in-game currency without having to pay “real” money.

Furthermore, in order to keep it easy for us, and since we would need to experiment a bit to create a balanced variety of goods, we wanted to have the content easy to configure.

Step 2: Implement

Once the soft and hard criteria for your game are done, you should start implementing according to them. You will probably go through some iterations in which you will experiment, test and refine your shop more and more. Usually there area many ideas in the beginning, so it is probably the easiest to simply start implementing analog by sketching your shop and its transitions first. Here is how this looked in our case:

The first sketch of Tumble panda's store

The first sketch of Tumble panda’s store

From the number of screens, your store will probably look somewhat similar. A screen to purchase items and a screen for purchasing your in-game currency with “real” money are the vital parts of it. Then it is time to test and try out.

First, we thought about a simplistic design that would show all the items we offer represented by icons. Once the user clicked on one of these items, he would be taken to the next step of the shopping procedure in which he would see the item’s details, like description and price, a bigger image of the item and confirm and cancel buttons.

Steps 3, 4 and 5: Iterate

When testing this approach, we found that the initial display of small  icons for all the items and details to them on click was simple, but only on the first view. Because for the user to find out about the different items, he would need to click on each, read through the description and then click on the next item. We had a trade-off between a simplistic design and a simplistic user interaction path.

The first implementation of our store

The first implementation of our store, with one icon for each element

This was the reason why we decided to go with a design that displays more information, which can be positive but also negative. We decided to put our items in two categories which can be accessed by tabs. For the item’s representation, we chose lists:

Our store with tabs and a list

Our store with tabs and a list

This changes are the reason why it is important for you to chose a method in which you can quickly test rough concepts and ideas, like just sketching them first, then implementing a basic version and putting the final finish only in the end. This way, major changes will be less pricy when they appear on  this stage. Imagine you implement your complete store and then realize you sticked to the wrong concept and need to implement the whole UI interaction again.

You need to as well talk to your users and have your different ideas tested. Then implement changes, based on your user’s feedback. In our case, the testing team consists of a mixture of employees, friends and relatives which span from the age of 7 to 52. This test-team should be not too big and fast in making responses so that you can really have a process of showing your work, receiving immediate feedback, improving upon this feedback, and showing your work again.

Once you decided on the basic way your store’s design and interaction  works, it’s time to go over the smaller parts. It should be a set of iterations with continuous improvements, followed by tests, followed by the next iteration.

Here is an overview over the various iterations we took on our store. As you can see, we sometimes only did small graphical changes, trying to improve more and more. Then, in the end, we gave it the final touch and it is now in the state in which it will go into the beta testing phase.


The iterations of Tumble Panda's shop

The iterations of Tumble Panda’s shop

Step 6: Balance your content

When you look closely to the changes we made, you may notice that not only the graphics changed, but also the content of the store. In the process of development we found out, that some of the items we thought would be good to have in our store weren’t but others were.

The items in a store should be useful and affordable enough to make some of them easy to purchase, but not cheap enough to buy through the game without making real money purchases. The prices of your store and your virtual currency determine the value you give to the user’s time. If you for example give up to 50 gold coins for a level for which the user needs 2 minutes to play and offer 1000 gold for $0.99, that would give the users time a value of $0.02475 per minute. Obviously this value shouldn’t be too high nor insultingly low.

Furthermore, the items in your store should provide some use to the user. In our case, we created two categories for Tumble Panda, items that are consumable and which can be used once and need to be re-purchased, and items that improve the protagonist’s power gradually and stay forever.

To balance your content well, I recommend to do some more iterations with your Alpha-testers, track their behavior, for example with Flurry (we use this one) or Google Analytics, and ask them for more feedback.


In the end I hope we met all the criteria we specified. Some things may still need adjustment, but the beta phase will show.

Besides a clear set of criteria to measure against, consecutive iterations with a set of testers involved are crucial to creating the store that not only you but also your users love. Personally, I also like to break the content down to the essential elements with every screen being responsible for exactly one thing, while keeping buttons and touch areas big, since the store is designed for a mobile device. The store of Temple Run for example really appeals to me, since it has all the stuff in one place, while items are still clearly grouped using separators and the user does not need many clicks to purchase an item.

I’m interested in unconventional and great ways of implementing stores and monetization systems. If you know any, please feel invited to share in the comments.

P.S.: We are looking for beta testers for Tumble panda. If you want to join, please let me know.


Creating an Awesome Game Menu – the Process

Today I want to talk about one of the games we have currently in progress. The game’s name is Tumble Panda, it’s a physics based casual game and so far, we have never shown it to the public.

In this post will cover the process of creating the menu. We are not done yet, some assets are still placeholder. But I think you will get the Idea of the concept, both in terms of design and user experience.

Fortunately we are in the lucky position of having a lot of great people supporting us at Andlabs. That’s especially true when it comes to graphics design. For Tumble Panda, our lead graphical hero, Fabian, and his friend, the illustration-master Darren, are helping us.

0 Prerequisites

The general guideline for the game are:

  • It should be kids friendly
  • It should copy existing patterns as little as possible
  • The user experience should be as smooth as possible

Especially the last point seems to be mutually exclusive with most of the existing monetization strategies for mobile games, but that will be part of another post. Back to the menu.

1 Setting

One of the first steps we took was to decide on the overall setting the game should be in. Since Darren is a great fan of comic books and the main character was set to be a Panda, we decided to have a combination of a comic and an asian style.

Comic style

Comic style

Asian style

Asian style

2 First, rough, attempt

Fabian suggested doing the menu in a style that’s really close to a comic. The whole menu should look like the grid of tiles a comic usually is drawn in. I couldn’t really imagine what he was talking about, so he quickly created a quick and dirty first draft of the main menu:

First menu draft

First draft of the menu

This draft very clearly shows the basic structure. The different entry points to the submenus are comic tiles. The importance of the different submenus is shown by the tile’s size.

3 Navigation

Next was the navigation. Since comics don’t consist of five boxes only, we decided to have all menus in one, with the main menu in the center. Whenever a tile in the main menu – the entry point to a submenu – is clicked, the camera moves to the corresponding part of the screen – just as the eye would when reading a comic:

Draft of the menu and submenus

Draft of the menu and submenus

As you can see we already balanced the importance of the different submenus a bit by changing the sizes of the tiles in the main menu.

On the top left stays a promo graphic. On the top right is the most important part of the screen, the tile that leads the user to right, to the menu in which he can select the level he wants to play. On the bottom left is the least important, the ‘about’-button, which leads to a submenu on the left. In the center is the ‘highscores’-button (which will soon change into ‘achievements’), that leads down and on the bottom right is the button that is most important for us, the button which leads the user to the store. Controversially this button navigates to the top instead of the right, as one would expect.

4 Animations

We decided to implement animations that don’t make a lot of visual noise in the menus. The movement from one menu to another is simply done with a move animation with a cubic ease in and out.

Take a look at the main menu, which now is very close to its final design:

Main menu

Main menu

Please notice that the final design of the main character is not yet decided, which is, why you can see three different types of Panda illustrations in the above screenshot.

The clouds that are visible in the background of the store-tile are constantly moving. This kind of moving clouds can also be found on each of the submenus. Furthermore the Panda in the play-tile is moving (‘tumbling’) from side to side.

When looking at the store:

Menu store

Menu store

You will notice the two placeholder-graphics on the left side, saying “goodies” and “upgrades”. This areas work as tabs. The transition between the “goodies” and the “upgrades” content in the list on the right side is done by an animation that moves the complete list out of  and then back into the screen, with changed content. The same animation is used when switching between different worlds in the play-submenu.

That’s almost all we have on animations in the menus. A bit more is to come when I will write about our store.

5 The big picture

Here’s the current state of the menus in  overview form:

Overview over current state of the menus

Overview over the current state of the menus

While it is obvious that some of the graphics will still be exchanged, you probably get a good picture of where we want to go with this game. Since it runs in immersive mode when possible, every screen also has its own software back button.

6 Too little moving images!

Here’s the tl,dr-part. Since talking about animations and graphics doesn’t give me the best idea of the way something will finally look, I assume there are some people among you that feel about it the same way. That’s why I made a short video:


In the next posts I will talk in a bit more detail about the thoughts we had on the individual submenus of the game.

In the meantime, while I think the menu we’ve created is pretty awesome, I’m really curious for your feedback. This is Tumble Panda’s first public appearance on the internet and I’m very curious about the impression it gives you – so please give me the honor of sharing your honest opinion with me.

Tutorial: Android Spieleentwicklung – Theorie

Spiele: Hat wahrscheinlich jeder schonmal gemacht, die meisten wahrscheinlich auch schonmal auf dem Computer, einige auch auf ihrem Android-Device.

Spielen ist das Eine, Spiele entwickeln das Andere. Und Spiele machen für die Android-Plattform ist auch nochmal was anderes. Im wesentlichen kann man dabei Spiele mit Animationen, also alle Spiele, bei denen sich etwas bewegt, oder Spiele ohne Animationen, zum Beispiel textbasierte Spiele, unterscheiden. Ich will hier auf erste eingehen.

Animierte Spiele können in Android entweder in 2D mit Hilfe von Canvas und SurfaceViews oder in 3D mit Hilfe von OpenGL ES geschrieben werden. Dabei sind mit OpenGL ES auch 2D-Spiele ohne weiteres möglich. Bei der Entscheidung OpenGL ES oder nicht sollte man sich darüber im Klaren sein, dass OpenGL die wahrscheinlich anspruchsvollere Variante ist, da mehr mit Matrizen und Vektoren umgegangen werden muss als in Canvas-basierten Spielen und die dritte Dimension durchaus einen Unterschied macht. Für  OpenGL ES – basierte 2D – Spiele kann man sich zum Beispiel die andengine anschauen (sehr zu empfehlen).

Worüber ich jetzt schreiben werde hat aber weder mit OpenGL ES, noch mit Canvas-basierten Spielen zu tun, es ist etwas genereller, es geht um Loops und Threads.

Generell heißt es, dass ein Spiel eine main Loop haben soll. Diese main Loop ist eine Schleife in der alles geschieht, was sich um die Animation (Rendering), Simulation und Eingabenverarbeitung dreht und die so lange läuft wie das Spiel selber. Das heißt zum Beispiel: ein ball ist in der Mitte des handys, die main Loop macht eine weitere Iteration, stellt dabei fest, dass das Handy nach rechts geneigt wurde, weshalb in der Simulation berechnet wird, dass der Ball drei Pixel weiter rechts dargestellt werden soll, was dann in der Animation gezeichnet wird. Diese generelle Aussage ist falsch oder sollte zumindest so nicht umgesetzt werden.

Das Stichwort heißt Nebenläufigkeit: Anstatt in einem einzigen Thread alles auszuführen sollte klar zwischen den drei Spielelementen, Eingabeverarbeitung, Simulation und Rendering, getrennt werden.

Zunächst einmal zum Rendering-Thread: In diesem wird alles gezeichnet. In OpenGL macht man das ganz einfach, indem man das Interface GLSurfaceView.Renderer implementiert und dann alles in der onDraw()-Methode malen lässt, OpenGL ES kümmert sich dann um einen eigenen Thread. Bei SurfaceViews schaut man sich am besten auf dem offiziellen Blog und im SDK-Beispiel LunarLander um. Das Rendern auf normalen Views ist für viele Zwecke viel zu langsam, weshalb hier nicht näher darauf eingegangen wird.

Als nächstes benötigt man einen Thread, der sich um die Simulation kümmert, das heißt der alle Objekte, deren Verhalten und Position verwaltet.

Als drittes müssen noch die Eingabemethoden ausgelesen werden. Legt man die Werte aus diesen nicht in plain old dataobjects ab (was man aber oft tut), muss hier beim Zugriff auf die Threadsynchronisation geachtet werden.

Das gilt auch für den Zugriff auf die Simulationsobjekte: Auf diese wird sowohl vom Simulationsthread, der diese berechnet, als auch vom Renderingthread zugegriffen, es ist also für Synchronisation zu sorgen! Das bedeutet: Wenn ein Thread eine Methode oder ein Objekt, die oder das als synchronized gekennzeichnet ist, bearbeiten will, kann er das nur, wenn das kein anderer Thread tut.

Hier ein konkretes Beispiel, im Simulationsthread:

final List<GameObject> objects = simulation.objects;
for(int i=0; i++; i<objects.size()){
     GameObject object;

und im Rendering Thread:

final List<GameObject> objects = simulation.objects;
for(int i=0; i++; i<objects.size()){
     GameObject object;
        //in diesem Fall wird eine GLSurface View übergeben.
        //es wäre auch möglich das Rendering außerhalb des
        //GameObjects durchzuführen, z.B. in einer Renderer-Klasse.

Eigentlich alles ziemlich einfach, oder?

Wir iterieren zum Einen im Simulationsthread einmal über alle Simulationselemente, dies machen wir mit einer normalen for-schleife, weil diese bei Listen performanter sind als foreach-Konstrukte. Wir übergeben einer update-Methode aller Spielelemente eine delta-Zeit und das war’s. Die Deltazeit bezeichnet dabei die Zeit, die seit dem letzten Zeichnen des Bildschirms vergangen ist. Somit kann gewährleistet werden, dass ein Objekt sich immer in der gleichen Zeit gleich weit bewegt, auch wenn unterschiedlich viele Frames pro Sekunde gezeichnet werden können. In der Update-Methode der jeweiligen Spielobjekte muss dann alles berechnet werden, was das Verhalten des Objekts ausmacht, wie zum Beispiel die Position.

Im Rendering-Thread das Selbe: Eine Iteration über alle Spielelemente, wobei jedes Element über eine render()- Methode verfügt, die mit einer übergebenen GLSurfaceView umgehen kann und sich selbst darauf zeichnet. Das funktioniert natürlich auch mit normalen Views oder SurfaceViews. Hier wird auch die Wichtigkeit von Synchronisation deutlich: Stellt Euch vor ein GameObject hätte eine Position{x,y,z}. Gerade als der Rendering-Thread ein Objekt zeichnen will und bereits x und y verarbeitet hat, manipuliert der Simulationsthread den z-Wert, weshalb das Objekt an einer ganz anderen Stelle gezeichnet wird als es eigentlich vorgesehen gewesen wäre. Darum wird das Objekt während es gezeichnet wird einfach von gelockt, weshalb die Simulation nicht mehr darauf zugreifen kann bis das Malen abgeschlossen ist.

Fehlt nur noch… Die Nutzereingabe, richtig! Diese wird normalerweise gepollt, d.h. man fragt zum Beispiel immer nach dem Ort, auf den der Nutzer das letzte mal gedrückt hat ab. Wenn sich dieser nicht verändert hat, bewegt man zum Beispiel eine Figur dort hin, wenn er sich verändert hat, bewegt man sie zu dem neuen Punkt.

So viel zur generellen Theorie der Spielentwicklung. Wirkt eigentlich gar nicht so schwer, muss es auch nicht immer sein. Teil zwei wird ein kurzes praktisches Beispiel der obigen Theorielektion auf Basis einer SurfaceView sein, lasst Euch überraschen.

© 2017 Droid-Blog

Theme by Anders NorenUp ↑