Introducing and deriving the idea of Jelly Chef as a Sokoban game

This post continues on my endeavour to understand what is involved create a mobile game by creating and deploying a simple mobile game. This post continues on from my previous entry post.

In an attempt to create a more interesting slant on the game of Sokoban I considered to change the boxes. I found boxes to be dull and uninteresting. They appear in many Sokoban titles as the original game (as created by Hiroyuki Imabayashi, in 1982) was based on the problem of transporting and organising creates of boxes in a warehouse. In fact the name Sokoban means "Warehouse worker" in Japanese.

So I started looking at a replacement to the box. I found jelly to be an interesting object to use. It is fragile, so you have to be careful on how you move it, you can't easily pull it for example, which is a characteristic to Sokoban game-play. I guess also (although I have not tried it myself), pushing two jellies at a time might work out to be messy. Again that is another characteristic. And I liked the idea of the jelly wobbling about as you pushed it around.


Immediately the idea of using a classically shaped jelly came to mind, as below:

The colours of the jelly set the theme and colour tone to the game overall too.

Of course the X's which mark where the box should go naturally should be plates. The classic English children's song "Jelly on the plate" is a nice link in to that too. So plates it was to be, and fairly easy to create using a 3D software.

Now for the character of the game, the classic warehouse worker needed to be something related to foods, deserts, jelly... As it was serving up jelly onto plates, I thought of a waiter, but to give more visual features to the character, I considered a classic chef's hat would suffice. 

So it was, "Jelly Chef" would be the title of this simple (yet slightly obsessive) exercise.

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.