Letou nhà cái đánh giá



Subscribe to the Droid-Blog.net newsletter Johannes is the co-founder of , .

A company specialized in Android development

Starting his mobile career in 2008, .

He has been building up Android expertise since the beginning

He has helped several bluechip companies get their Android apps ready

gives talks on conferences on a regular basis and published several articles in field-related journals.
CategoryGame Development.
When creating a game, the About screen is probably the part of the game that is given the least effort.
It does not give much benefit to the gamer and usually consists out of information such as credits, licenses and privacy information.
However, it is still part of your game and should therefore be a nice part of your software with a pleasant user experience and a design fitting the rest of your product.
With our Game Tumble Panda, wie  went with an  and tried three different types of About screens, which I want to show you and discuss the good and the bad sides of.
But before, let’s take a look at what you need to think about before building your own about screen.
The content of your About screen determines its design and placement.
Hence, you should think about it a lot.
Should it show only credits or also your privacy policy and EULA.
How about license texts.
And what about Links to social networks.
Some apps just show a three lines of names of names while others show a rather long list, licenses or even settings.
In our case, we wanted it all: Credits, our privacy policy, licenses, social media, a way to contact us, access to signing in and out of google play games services (which is ) and even the possibility to enter promo codes.
Also, we wanted to list all the software we used to create our game.
Depending on how much stuff you want to put in your about, you might want to chose its placement.
Angry Birds for example uses a little info-button in the settings drop-up-menu in their starting screen, an approach that many seem to like.
For us, we decided to make the about accessible via a button on the main menu, which is not hidden but smaller than all the other buttons (see to see the size of our “About”-menu-button).
How to create a Game’s Store.
2015/03/03 1 Comment 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: The design should fit the rest of the game.
The design should be as minimalistic as possible while still highlighting the different functionalities of the virtual goods.
Animations should be as quiet as possible.
There should be little  enough goods to not confuse the user while still providing enough variety to make purchases attractive.
The flow from overview to purchase should be done with as little clicks as possible.
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 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, 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 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 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.
S.: We are looking for beta testers for Tumble panda.
If you want to join, please let me know.

Getting started with the Universal Tween Engine

2013/09/13 This is a guest post by Alexander Fröhlich.
Alexander is a freelance developer and is supporting at its libgdx-based development.  If you are not familiar with libgdx yet, please check out the first part of this series, the Getting started with libgdx-guide.
1 Tweening?.
“Tweening” in games is the process of creating intermediate states and thus frames between two or more given states.
Example (Sprite Translation): The most simple example would be moving a sprite or image from one x1, y1 position to another x2, y2 position on the screen.
Yet, as you might already suspect, this “Universal Tween Engine” is capable of manipulating not only x, y coordinates for sprite objects….
no, this cross-platform-engine written entirely in java language lets you tween every property of any object given that it has its getter/setter methods attached.
In this tutorial I will show you how this comes in handy for game developers when building ingame hints or tutorials for their game.
The following sample code illustrates basic use and setup of the universal tween engine in a libgdx code project.
2 Ingame Tutorial Tweening.
First of all, declare your tweenManager instance.
The tweenManager lets you keep track and manage all your tweens (i.e.
tweening, tween actions and so on) public class MyGame implements ApplicationListener { // Only one manager is needed, like a // libgdx Spritebatch (MyGame.java) private static TweenManager tweenManager; } Instantiate the manager inside create() of your libgdx lifecycle: Register an accessor class, which is the key binding between the manager and the object to be tweened.

Here this will be the TutorMessage class

(see below).
So after calling registerAccessor every single object of class TutorMessage we create can be tweened by the TweenManager.
@Override public void create() { setTweenManager(new TweenManager()); Tween.setCombinedAttributesLimit(4);// default is 3, yet // for rgba color setting //we need to raise to 4.
Tween.registerAccessor(TutorMessage.class, new TutorMessageAccessor()); } The TutorMessage’s are the internal game objects for this sample which hold the position, scale and color message attributes.
public class TutorMessage { private String message; // string objects can not be tweened private float x; private float y; private Color color; private float scale; } To tween these message properties and make them accessible by the manager we have to declare how getting and setting every single attribute works.
Getter/Setter So we define 3 sections (POS_XY, SCALE, COLOR) that process the current float[] values, handled over by the manager during runtime when tweening is active.
Of course same applies for the setters.
public class TutorMessageAccessor implements TweenAccessor {     public static final int POS_XY = 1;     public static final int SCALE = 2     public static final int COLOR = 3;     @Override     public int getValues(TutorMessage target, int tweenType, float[] returnValues) {         switch (tweenType) {             case POS_XY:                 returnValues[0] = target.getX();                 returnValues[1] = target.getY();                 return 2;             case SCALE:                 returnValues[0] = target.getScale();                 return 1;             case COLOR:                 returnValues[0] = target.getColor().r;                 returnValues[1] = target.getColor().g;                 returnValues[2] = target.getColor().b;                 returnValues[3] = target.getColor().a;                 return 4;             default: assert false; return -1;         }     }     @Override     public void setValues(TutorMessage target, int tweenType, float[] newValues) {         switch (tweenType) {             case POS_XY: target.setPosition(newValues[0], newValues[1]); break;             case SCALE: target.setScale(newValues[0]); break;             case COLOR:                 Color c = target.getColor();                 c.set(newValues[0], newValues[1], newValues[2], newValues[3]);               target.setColor(c);                 break;             default: assert false;         }     } } Having bind our TutorMessage class to the TweenManager we can now integrate it into the game.
We want to provide a kind of ingame tutorial system.
So every time our user should see an animated on-screen help, we call the now defined method. The tweenHelpingHand method takes the parameter targetX, targetY that indicate the position where the helping hand (sprite) and its bound message (bitmapfont) should move to.
Then we say Tween   .to (       – TutorMessage currentTm ( the message to be moved )       – int TutorMessageAccessor.
POS_XY (constant to select which property should be tweened)       – float 3f (total tweening duration)   )   .target (     – targetX, targetY ( the final screen position of our tweened message )   )   .ease (     – TweenEquations.easeOutCirc ( one possible interpolation pattern – i.e.
moving pattern here)   )   .start (     – MyGame.getTweenManager()  ( binds this tween to the manager )   ) private void tweenHelpingHand(int targetX, int targetY) { // kill current tween – or pre-existing MyGame.getTweenManager().killTarget(currentTm); // move     Tween.to(currentTm, TutorMessageAccessor.
POS_XY, 3f)         .target(targetX, targetY)         .ease(TweenEquations.easeOutCirc)         .start(MyGame.getTweenManager());     // colorize     Tween.to(currentTm, TutorMessageAccessor.
COLOR, 3f)       .target(1f, 1f, 1f, 1f)     .ease(TweenEquations.easeOutCirc)     .start(MyGame.getTweenManager()); } Finally we have to call update inside the libgdx render() method to have the started Tween be updated constantly.

MyGame.getTweenManager().update(delta); Here you go

Enjoy this very powerful any easy to use tweening library.

Combining Scene2d animations and Tweening is also possible

You just have to write the ActorAccessor binding class and provide access (getter/setter) to its properties.
Like with Scene2d actions, the universal tween engine also allows sequencing of multiple tweens.
If you have any questions or suggestions, please leave a comment.
Getting started with libgdx.
2013/09/05 This is a guest post by Alexander Fröhlich.
Alexander is a freelance developer and is supporting at its libgdx-based development.  libgdx is an open source, Open GL based, cross platform game development framework.
It’s supporting Web, Desktop, Android and iOS.
This step by step introduction will teach you how to get started with the initial setup and your very first hello world in libgdx.

1 Prerequisites Get the Android SDK and set up a functional eclipse environment

Go to libgdx and checkout the general “libgdx-Wiki-Guide“.
Go to “Project Setup” where you will find a download link to.
“Setup the application” – either start it from command line “java -jar gdx-setup-ui.jar” or just double-click on the downloaded file.
2 Setup a new libgdx project Choose “CREATE” in order to create a new project and enter the following setup screen.
ConfigurationTab lets you set names for projekt/package/mainGameClass and the destination folder.
Library Selection lets you download all required libraries (libgdx as the core libs are always required).
Overview gives you an outlook on which projects will be created.
Generation checks for a valid setup (green colored) and when read you can open the generation screen (launch window coming up).
Launch displays the log output while creating the project.
Here just click “Launch” to finalize your setup and create all chosen libgdx projects.
3 Import libgdx projects into eclipse Now we need to import these project into eclipse (other IDE provide similar options -> wiki) NOTE: iOS projects have to be imported with XCode only (apple-mac) -> wiki 4 Project launch configurations You now should see four projects… YourGameName, YourGameName-Android, YourGameName-Desktop and YourGameName-html within eclipse’s package explorer.
The first one being the core source project holding all your game logic and the latter being launcher projects holding only one starter class.
DESKTOP Go to your newly imported desktop project and launch its Main.java (run as java application) This should bring up this demo screen.
As you can see libgdx already provides you with a small hello world application.
ANDROID Your eclipse android project should have been marked with a red x (eclipse way of telling you something is wrong with your setup).

Go to project properties (ALT-ENTER) and select your available Android-SDK-version

NOTE : on versions prior to 4.0 you might have to remove the line android:configChanges=”keyboard|keyboardHidden|orientation|screenSize”> from your AndroidManifest.xml as this option being unsupported After this, refresh both your core source project and your android project and rebuild both projects.

Now right-click on your Android project and choose “Run as Android Application”

A dialogue will come up showing all connected devices and you may either want to push it on one of these or use the emulator (which will automatically start without any registered devices).
Make a choice and the game will be transfered on started on your device.
HTML5 A red cross over your project might mean that you have to install GWT.
After having GWT set up correctly, right-click on your HTML5-project and choose “Run as Web Application”.
Double click on the provided link ( e.g. A browser window will show up maybe requiring to install a GWT Developer Plugin (Development Mode requires the Google Web Toolkit Developer Plugin).
If so, do restart the browser and you should see the libgdx logo screen.
Now you are up and ready to start building your own libgdx-based game.
If you have any questions, please post them in the comments.
Update [2013-09-13], important links: Starter Tutorial: http://bitowl.de/day1/ Libgdx Wiki https://code.google.com/p/libgdx-users/wiki/AAATopPaaage Forum: (most problems have been solved already.
just learn to query it wisely like the web 🙂 http://www.badlogicgames.com/forum/ Older © 2020 Theme by —.

Have a great idea for Analog Game Studies

Have a great idea for Analog Game Studies.
We’d love to hear from you.

After having a look around our site and reading our About section

please read through the following guidelines before emailing us at [email protected]
After submitting your pitch, one of our editors will contact you shortly.

Image CC -BY Kristina Alexanderson @ Flickr

AGS Submission Guidelines Thank you so much for considering submitting a piece to Analog Game Studies, the journal dedicated to academic and popular study of games containing a substantial analog component.
Before you submit to the journal, however, have you considered… * … if your submission is of the appropriate length.
Our standard article is approximately 4000 words long, and we’d like your piece to be about that length too.
* … if your piece has a strong argument.
Audiences tend to remember and cite essays with clear arguments supported by compelling evidence.
Make sure yours has both.
* … if your piece advances broader discussions in the field.
Take a look at some other articles – both popular and academic – concerning the topic you’re discussing.
Ensure that your point is in dialog with theirs, rather than ignoring or trying to overwrite the important insights and concessions of the other authors.
Remember that if you want your work to be heard, it is best heard in conversation with other works.
* … if your piece offers us something new.
Given other discussions in the field, make sure that the point you’re making is something new, interesting and useful.
We want to publish articles that are worth reading, i.e., only those articles that an author like you finds worth writing.
Push yourself to innovate, and seek the boundaries of previous conversations.
* … who are three academics who would be directly interested in your post.
If you can’t name three, your post may not have an audience among scholars.
* … who are three game designers who would be directly interested in your post.
If you can’t name three, maybe you’re not reaching the designer segment of our audience.

We’d like for you to reach both scholars AND designers

if possible.
(Feel free to use other Analog Game Studies authors to answer either this or the above question.) * … thinking beyond a role-playing game audience.

Let’s face it: most of our authors and audience are concerned with RPGs and

sure, we’ll give them what they want.
But the title of our journal is “Analog Game Studies,” so your argument must have some broader “analog” applicability beyond your narrow field of interest, right.
Without getting too ambitious, think about the ramifications of your argument for other sorts of games.
Explain the concepts and games involved as if your audience were your grandmother, your English professor, and a board-gamer from your local gaming store.
* … what images the post should use.

Analog Game Studies requires  about 5 images per post

The more good images you supply, the happier your editors are.
What makes a good image.
Well, we’re always looking for an openly licensed featured image that’s at least 1038×576 pixels large.
More generally, 4-5 open-license, eye-catching images with all the necessary attribution that have to do with the content of your post are preferred.
Check out creativecommons.org and flickr.com, if you are looking for good search engines which allow to filter your search by license.
Be sure to provide details about the original author of the image, too, when you submit your images, as attribution is an important part of the open license structure.
This is also not to say that your editors won’t post your article unless you provide images, but that the process will run smoother with your input.
* … if you have a bio on the website.
If you’re a new post author, we’ll need a bit more information from you about yourself (as well as a headshot).
Please look at the other bios and provide us with your own short one along with a picture of yourself.
Good bios are brief and answer the reader’s question “Why should I care about what YOU have to say?” * … the possibility that you might disagree with the editor’s decisions regarding the layout of your article.
Although we greatly value and appreciate active input from our authors, the editors ultimately have the final say on how an article will look on the website.
We will take your advice into consideration.

But Analog Game Studies is – at present – not a democracy

so as to expedite the whole process.
We appreciate your cooperation and patience on this front.