Exercise to develope and promote a simple mobile game

In an effort to understand what is involved in developing a mobile game and get it noticed I decided to try out developing a small game.

I hope to document all my efforts, mistakes, challenges and solutions. The main idea of the first little game is to understand what's involved and to learn from the whole process. Perhaps it will lead on to developing and promoting a better game in the future, but for now, the idea is for a trial run of the complete process. Add some polish to a simple game idea, and lets see how it goes.

When I first got into Unity3D one of my early projects was converting an old DirectX 9 VB.net game into Unity3D. That process helped me find my way around Unity3D and get up to speed with C# (the superior Unity3D supported language).

That early project was a 2D grid based puzzle game called Repton Returns. As based on the 8-bit classic Repton (like Bouder-dash). However I wanted to focus on an even more simplified game for the process of learning mobile games development, and so I chose the Sokoban transform puzzle game. I enjoyed playing the little Windows version of this genre named Boxworld, and thought it was simple yet interesting enough for the exercise.

However, of course it had to be one up from some of the Sokoban games that can be found already on the store, I noticed most of them faired poorly in terms of graphics and presentation. I guess its not critical for this type of game, but making the graphics 3D seemed an attractive direction to turn.

So using the now re-factored Repton code to manage loading in a 2D grid level, and moving objects about within such levels, it didn't take long at all to derive a basic prototype of the game in motion.

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.