What can be more addictive and captivating than a simple, gambling game like a slot machine? Even our developers couldn’t resist getting hooked. Our client wanted us to develop a slot machine app for android phones and tablets. The app was meant to be used as a prototype for designing actual (physical) slot machines. The client wanted to gather users responses about the most useful and fun features of the app for the purpose of incorporating those features in the physical slot machines. Providing a smooth and delightful user experience was essential. It required diligent work, on both the developer and designer’s parts, to ensure that users got an experience that would drive them to use the actual slot machines of the company.

The Challenge:

Although the concept was simple there were many logical intricacies involved in the successful development of the app. The game involves 3 spinning reels. The player has the option to stop the reels by either touching them individually or by tapping stop button to stop them all. Even after the reels stop, the player has the option to nudge any reel twice or two different reels once. The app was also required to determine if the player made the best combination possible, by nudge, on the basis of which skill points were awarded.
However, putting logical complexities aside, the most challenging and time consuming task was the design of the app. The client wanted the app to stand out in terms of design and was quite particular about it. Everything had to be designed meticulously. With the plethora of different android devices in the market, each with differing resolutions and screen sizes, achieving optimal design across different screens was no piece of cake. The main game screen involved a number of elements that had to be adjusted properly. We had to ensure that the design remained persistent from 7 -23 inch tabs (yes, there’s a tab even bigger than your TV!). Moreover, the app had to be ported to phone size devices in the future.

Implementation:

We resorted to a classic approach – using Fragments – to avoid the cluttering the UI, its corresponding code and to keep dependencies of individual elements of the main game screen on one another to a minimum. Instead of designing the main game screen in a single chunk (with all of it’s design elements in a single file and all of the corresponding controllers and logic in a single place) the screen was divided into 4 fragments each with it’s own view and controller logic. This helped us divide the design into smaller manageable chunks. Not only did designing the individual elements became easier, their code too became easy to manage thus enhancing it’s readability and adaptability. The Fragment approach also proved helpful in providing different screen designs and arrangements of elements for different screen sizes.

Issues with implementation:

The main issue with the fragment approach was the interaction between elements; how were two different elements residing in two different fragments/controllers supposed to communicate? One approach was to implement interface listeners for all the elements of the fragments and implement them in their corresponding controller class (The main game class/Activity). This solution was not the most adaptable as it resulted in the cluttering the main game logic code. Plus, if we wanted to change some element from one block to another, we had to change it’s corresponding listeners too. It became clear that a cleaner solution was required.

Resolving message passing issues:

For interaction between different UI elements residing in different fragments we used Square’s Otto library. Otto follows an event bus model designed to decouple different parts of your application while still allowing them to communicate efficiently. Under Otto, every button press and user action publishes an event within the app. Those events can be picked up by corresponding subscribers to perform the relevant action. This way dependency between different game elements can been reduced as no element is programmatically bound to any other element; changing one block will not affect any other block. Taking the fragment and event bus approach resulted in more readable, manageable and adaptable code which allowed us to implement the convoluted design of the app effectively.