Better workflow: From design to production

Today I was looking at a better way to improve workflow with regards to converting designs to in-app screens.

This artical caught my eye stating:
"A great workflow can really make the difference between a project succeeding and a project failing. You can have the best designers and developers on a project...".

It seems Adobe Device Central and Adobe Fireworks seems to great for working with the same project that has multiple screen sizes at design time.

This relates to my post on PPI / DPI and resolutions.

Tokens and Coins explained

This is my explanation/research on the difference between online game currency and point system that is used by every major online games company out there.

Let's look separately at Game Points (Coins, chips)

..and Game Currency (Cash, Gold, credit, or "Tokens")
  

Game points; 

Or Coins; They are worth very little but can be earnt in the games. Usually low-medium valued shop items items can be bought with 'Game Points' (GO Coins), although there may be an option to buy these items with 'Game currency' too.

OMGpop also uses the term 'Coins':

..notice they must be bought with OMGPOP Cash (their Game Currency), that is not USD, but represents USD in their system that has already been purchased.

Also notice in the top left they have 'Balance' which shows I have never given them money (Game currency), but have been awarded with some OMGPOP Coins :)

Zynga do something similar, but they seem to have the currency/point system unique to each game, so cash and points are not interchangeable between different Zynga games (unlike OMGPOP):

..for poker, they call their points 'Chips' (and they call their currency 'Gold').

Notice they probably gave me 5 Gold (cash) for signing up, doubt that can buy you much.

However, I've earnt over 50000 Chips (in our case GO Coins). But I'll never be able to buy premium shop items with that, no matter how much I win.

Game currency;

This can be called gold, or cash, and this basically directly represent USD in the online games company's bank account!

They can never be earnt, only bought with real money. The advantage for the customer and the company is that they can be bought as a set of say £5, $25, $50, etc..

Usually some bonus will be included with bigger purchases.

All shop items can be bought with Game currency, and some items may be exclusively available only by paying with gold (ie they can never ever get this item from just playing the game, and must cough up the real money).

Here's OMGPOP currency:

..or OMGPOP CASH, as they call it.

Notice they are implementing 1 OMGPOP CASH = 0.01usd. Plus they are giving a little extra for your generous payout (which will go straight into OMGPOP's wallet). They are not loosing 7usd directly. It is an intensive to entice players to part with larger quantities of cash. Players don't need to keep getting out their wallets every time they consider to buy something, plus they are getting more for their buck for clicking a higher number.

In the end it promotes more spending.

Here's Zynga's Poker credit implementations for their various games:

and for another one of their games they call it something different:

.. Blast Cash? Whatever, its still represents money (Game currency) + a bonus for paying out a lot.

And is separate from their earn-able coins. 

Let's look at OMGPOP's shop to see how they are selling point items and currency items:

..and there you go.. The gold coin items can be earnt from playing the games. The green dollar items only if you have OMG Cash game currency. (no sign of USD here. By the way, their animated avatars are looking good!)

Somehow players get it. They play more, they can get free stuff. They part with their cash, they can get the free stuff much faster, plus have access to exclusive items.

And that's it. We need both Coins and Tokens if we want to be able to both reward players, and want them to part with their cash. They are two different systems with only a one way transaction path Gold to Coins, Coins can not be converted to Gold, and Coins nor Gold can be converted back to real money.

On Pixels-Per-Inch (PPI / DPI) and app design

Overview: Facebook sizes, game design, app design, Apple and Android, screen sizes, screen design sizes, etc.

Cool, so the reason why OS screens are set to 72dpi by default is because of an 1984 Apple computer.

Basically my understanding is that DPI is purely for printing, and if
you wanted to show a 600DPI image on a 72dpi OS then the image will
look huge in relation to the OS's UI (and basically it wouldn't fit on
the screen, probably).

Referring to PPI in regard to screens is a different matter. For
example if you loaded a game/app design on a low end PPI OS on a high-end PPI device, then all the
buttons would look tiny, unless the OS scaled the game (think about playing a iPhone game on iPad, they have the zoom option), or the game
was able to cope with different PPI and dynamically scale things
(which is more technically involved in design and development).

iTune Apps are successful this way, because the designers/developers
only need to consider a few different resolutions. One of the reasons
(for now) developers stay away from Android is because of all the
device screens are different and so the game/app MUST scale
dynamically. Google are addressing the issue, but its something that
will be unavoidable and inherent by being open to different
manufactures. Even for Apple as they release more devices with
different resolutions they will and are encountering the same problem,
iTune Apps now have to be available for iPhone, iPad, iPad 2, iPad 3,
and iPhone 5, all which need a slightly different design unless the
App can dynamically adjust for the different resolutions.

Things will calm down regarding this problem once all screens are
600dpi (and/or there is a standard set of PPIs and set of aspect
ratios), which could be several years away. Google has already propose
a set a of PPI standards for Android which may be adopted as an ISO
standard.

Film directors have been arguing and pushing for
a standard aspect ratio for decades, so I am not expecting any agreed
set of standards anytime soon. Its an interesting topic though which
applies directly to all digital media design and particularly to games
and mobile devices.

Dynamically loaded asset and asset format considerations in AS3

I use external loading for assets in flash for more then one reason
and there is no best way to do it it has to be a balance depending on
what you want to achieve.

There are two things to take into account when we talk about flash and graphics:
- .png and .jpg images require more RAM but lot less CPU time to process
- vector graphics are very light but require more CPU time

In flash applications that run in browser, the flash runtime is either
on a thread or child process of the browser and this means its
dependent on the browser for resources and not only. To much CPU used
by flash makes the application unstable especially in the frame rate
witch is very important for a game. Most CPU consuming parts in a
flash application are vector graphics and to many elements in the
display list and especially to many movieclips (movieclips have a
time-line witch makes them more processor intensive in use then
Sprites). These are some of the reasons way it is a good idea to avoid
having too many movieclips or too many vector graphics on the stage,
especially for FPS critical apps.

Another reason to use external loading assets is the size of the flash
file witch is important in web application for bandwidth reasons and
also to make it more difficult for someone to take the flash file and
use it. There is no way to prevent people from downloading the flash
file but if the flash file is only an empty container even if you
download it you cant use it. I also tend to use external loading and
less stuff imported from different programs directly into the library,
because from a design there is no need to use everything and big areas
of the same colour or even a lot of effects can be achieved directly
in flash and that can lower a lot the resource consumption.

As a conclusion each application has different needs and there is no
right way but generally and especially for web games i found that
using external assets and avoiding importing stuff from AI is a good
practise for application optimisation.

I agree loading screens/assets dynamically helps, but I don't think it
should be done for everything, especially the main screens. Its better
to load all the main required assets in the preloader as it makes the
app feel more responsive. Loading content dynamically would be more
suitable for screens like shops, awards, profiles; screens that not
every player session would necessary need to load.