We hope this message finds you in great spirits! 


As part of our commitment to providing an unparalleled gaming experience, we are thrilled to announce that all our Android games have received exciting updates, ensuring seamless performance on the latest phones and tablets.


To take full advantage of these enhancements, simply click or tap here to visit the Google Play store


Once there, explore our diverse collection of games and choose the ones that resonate with you. Whether you’re a casual gamer or a dedicated enthusiast, we have something for everyone!


Update or install ALL your favorite games effortlessly and embark on a gaming journey like never before. Your entertainment is our priority, and we can’t wait for you to experience the thrill of our latest updates. Happy gaming!

Thanks a million for being part of our gaming journey!

Farkle Dice, WordPop! Farkle Solo

Smart Box Games Android Icons

Threeze – A Numbers Combination, Farkle Diced, Farkle Dice DLX

Smart Box Games Android Icons

One more thing, we need your help.


Your support fuels our growth, and we’re incredibly grateful. Today, we’re asking you to be a true game-changer by sharing the joy of our games with your family and friends.


Your recommendation is invaluable, a key to expanding our gaming family. Ready to make a difference? Share the excitement now. Your word of mouth is our most powerful asset, helping us craft unforgettable gaming experiences.


Thanks for being a crucial part of our journey!

Introduction

Embracing asynchronous work can be a game-changer for distributed teams, enabling increased productivity and efficiency. What truly brings this concept to life are real-world examples. In this article, I’ll briefly describe one of our Smart Box Games projects to demonstrate the power of asynchronous collaboration using the simplest of tools, email.

Background

Our most popular game, Farkle Dice for Android, enjoys a global player base. Over the past two years, Google has progressively limited Android device backward compatibility for apps that use Google AdMob and other SDKs. Initially, they used the carrot approach and encouraged updates for better device performance, but then switched to the stick to enforce compliance by threatening app removal from the Google Play store.

Our team is spread across the globe: our Art Director, Jim, resides in Tokyo, our lead Android Engineer, John, is in Bozeman, Montana, and I serve as the Product Manager and QAE and I live in Bellingham, Washington. We embrace asynchronous work due to our experience and confidence in this approach.

Tools We Utilized on the Project for Asynchronous Collaboration:

  1. Email
  2. Google Docs and Sheets
  3. Bitbucket
  4. Firebase for app testing distribution
  5. Google Play Console

Our Project Goals

Our journey began with a high-level email outlining the basic requirements:

1. Update the code linking in the newest SDKs

2. Convert all HTTP links to HTTPS across all app languages

3. Allow players to opt out of Google Play login (we use Google Play for high-score sharing)

4. Modernize launcher icon

5. Integrate Firebase Crash Analytics

6. Address all issues found during testing

Progression of the Project

John took the lead by updating all relevant SDKs and then addressing all errors and warnings until he successfully built the project. He also updated the copyright information, URLs, and menus. 

During this process, John discovered Google had made significant design changes in how Google Play integrates with app, which he communicated via email, seeking input from the team. We installed the latest build from John and collectively examined the design changes to better understand the user experience. After exchanging a few emails with images we arrived at a design that John swiftly implemented.

As the day ended for John and me, it began for Jim in Japan. He researched how to create full-size launcher icons and by the time we started our day, provided us with educational YouTube links to get us up to speed. Jim then handed off new art to John. After a few iterations, the new launcher icon was integrated into Farkle Dice, and wow, it looks great.

The majority of testing was regression, validation and verification. Testing occurred on each build, with any issues found sent to John, with images and steps to repeat.

Once all issues were addressed the final chapter was distribution and user communication. Wearing both my Project Manager and Quality Assurance hats I wanted to limit risk and decided to do a gradual rollout release, starting at 10% and ramping up daily to 100%. Release notes were added to Google Play and a push notification is scheduled for next week.

Key Takeaways for Successful Asynchronous Work

Clear Communication: Effective asynchronous communication hinges on accurate descriptions with images and links to videos. I avoid abbreviations or acronyms. For example I always wrote “Firebase” and never “FB”, because in my brain “FB” = Facebook. 

Visual Aids: Enhance issue reporting by incorporating screenshots with prominent annotations (I’m a fan of using large red arrows), making it easier and faster for team members to understand and address problems.

Organization: Keep conversations focused by retiring resolved email threads and initiating new ones for fresh topics.

Encourage all team members to collaboratively edit documents for clarity within Google Docs. (I am thinking of switching to Notion or Confluence to take advantage of their comprehensive editing tools).

Time Zone Advantage: Leverage time zone differences to your advantage, if possible, by scheduling overlapping working hours for quick responses. For instance, 4:00 PM Pacific Time is 8:00 AM in Tokyo.

Trust Your Team: There were times I was tempted to send John a Slack message on an issue I found because it felt urgent. In reality, it was important but not urgent. Not dm’ing John and sending him an email instead prevented interruptions to his coding flow and allowed him to manage his time to its fullest efficiency. 

Conclusion

Our project progressed quickly without the need for any meetings. The entire software development life cycle was efficiently navigated through asynchronous collaboration. Now, we’re ready to replicate this success with our remaining five apps, with Farkle Halloween and Farkle Solo already underway. 

We have used asynchronous tools in the past and we are always reviewing new and interesting solutions but no matter the tool it is people who make great software. 

I encourage all teams, especially dispersed ones to embrace asynchronous processes to unlock your team’s full potential.

We went from, “Wouldn’t it be fun to create a Halloween version of Farkle!” to submitting it to Apple in 13 days flat. That was fast! The app came out great and is now with Apple pending approval. The Android version is not far behind.

 Click on image to see the entire art.

How we did it.

Zombie Asset Management – The entire team is required to use SVN to check in and out files. Thus all code, art, sound, text changes, even marketing material goes through this system. We decided up front that we would see how far we could get, in 7 days, by simply swapping out the current Farkle Dice files with new Halloween files, this is often called as skinning. Wyatt quickly made a branch off the trunk for the code and we dove in with our eyes wide shut. So like Zombies, no thinking allowed, simply replace what we had, one for one, a rule we had to break several times.

Terrifying Text – My first task was to change the localization text to terrifying text. Not every developer  makes a single file for all the text for the app, but we do, as we localize our games into other languages. Creating this file really paid off when making the Halloween version. Because instead of having to track down all the text strings, I had one file, that I was translating into something scary. So Player 1, became, Undead Player 1, AI player Stead Stan, became the Grim Reaper. Winning the game became Surviving. It was really fun thinking of ghoulish words to use.

Spooky Sounds – Finding new sound effects was very time consuming. I don’t have a library of Halloween sounds so I spend hours going through several sites I commonly use and gathered an online library of sound effects. While I was doing this, Jim was starting to hand off some art. After I saw the style of the art and the theme he was going for, I tossed many of the sounds I found and searched for new ones. Jim was creating art that reminded me of classic horror movies while I was headed in more of the modern Zombie direction. But his art was fantastic so I found werewolf howls, screams, blood splatters that I liked, purchased them, then renamed the files exactly what existed in the code for the non-Halloween version, and then checked them in. The hardest sound to find was for the title screen. I really wanted a spooky theme song, but I did not like anything I heard. They were either too dramatic, like Jason chasing you with a knife or the song reminded me of some satanical ritual. I did find some great ambiance tracks and the one I purchased worked great. I used Audacity to do some basic mixing of sound effects and editing. What a great free tool.

 Killer Art – Jim has been responsible for all the art for all our games for years. He was instantly enthusiastic and I think started to draw before the meeting was over. He handed off the title page first with some witch and bat animations and replaced the dice with pumpkins. This visual was a huge WOW. It also let me see a different side of Jim, a scary ghoulish side, which was great, although I am locking my doors now at my house. As I mentioned above, the art helped me focus the sound files. I think Jim must have drawn with both hands and feet because in about 5 days he had handed off most of the art for iPad, iPhone, including retina. We had very few discussions around the art as we trusted Jim to deliver.  I especially like the little things he added, like blood dripping on the characters name on the game board. Jim is now converting the art to work on Android tablets and phones.

Eerie Engineering – Wyatt quickly made a branch of the existing Farkle Dice code for the team to access and provided constant direction to the team when we had hand-off questions. Wyatt, took the lead designer role for the title screen and other areas. Jim handed off the art and I handed off  the sound effect. The only direction we gave Wyatt for the title screen was, “Make it fun” and he did. The bat flying around and the witch swopping by are some of my favorite parts of the app. To keep the QA minimal, we dropped iOS 3.x support and concentrated on 4.x – 5.x beta. Wyatt was making builds for us to try on a regular bases. And although we started out with the rule of one to one replacement, we handed off to Wyatt sounds that needed to play in new spots and new animations. Then at the very last day I asked Wyatt to add two custom fonts.  We were all tired by now, but Wyatt did it and now the menus and dialogs have that extra scary look.

Morbid Android – We are now repeating the process for the Android version. John is lead engineer and is having a lot of fun with the build. Because of the lead time needed for Apple to approve and since there is no approval for Google apps it made sense to start with the Apple version. John is rapidly creating the app and he is about 85% or more done. We converted the sound files to MP3 and Jim is redoing the size of the art. John has been sending builds almost hourly for us to review and adding his own design style to make it great on Android.

The App was the Spec – Beyond basic notes from our meetings, emails flying back and forth, and a few spreadsheets in Google Docs, there was no traditional specification. The App was a living prototype and specification along with the code.  When we discussed a design issue, we were either pointing to the game or to the code repository. Such as, look at this file, or here’s a screenshot, can you change this to that. This worked well given the time frame and our past experience working with each other paid off.

Email me at tsherman@smartboxdesign.com if you have any questions. I will post links to the stores as soon at the app is approved in iTunes and uploaded to Google Market and Amazon.

 

Last week, on May 13, we submitted an update to WordPop! iPad to Apple. We were excited about this new release because it supported landscape. Players would be able to enjoy WordPop! Volt on the iPad in all orientations. I personally really enjoy playing in landscape mode a bit more than portrait as I find holding the iPad horizontally easier.

After a week, we heard back from Apple, the update was REJECTED. To quote Apple, “The iPad Human Interface Guidelines state that only one popover element should be visible onscreen at a time. On launch, and when the user taps the “Add Player” button, and additional popover is displayed for the user to enter a player name. Screen shots are attached for your reference.”

My team and I are aware of the one popover limit but the second popover is a dialog which I did not consider in the same class as a popover. Additionally, Apple had approved the two previous submissions of WordPop! Volt which has “Add Player” working exactly the same way.

Apple has been very good to us in that they usually provide a screen shot and description of what is wrong.

The fix is straight forward, we need to remove the first popover “Change Player” when “Add Player” is selected. This should be done any second now and we will resubmit.

Lesson learned, it does not matter what Apple calls the widget being used in the iPad User Interface Guidelines, only one “popover” at any given time.

Update: May 24, 2010 – We resubmitted WordPop! Volt. Below is a screen shot on the change. This new look conforms to the iPad UI guidelines.