Archive for category: Game Design

You are here: / / Game Design
, , , , , , , , ,

Remote Work: Asynchronous Collaboration

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.

/by
, , , ,

Create a Great App or Web Site by Getting to the Screen Quickly

Triples Game Screen Placement Phase

As a Project Manager, one advice I always give to my clients is to get to screen quickly. No matter how great the specification or how well the wireframes and mockups show the flow, getting the app up and running will:

  1. reveal problems early when they are inexpensive to fix
  2. generated feedback to improve the app
  3. create a common vision for the team and stakeholders

But most of all, it is incredibly exciting to see something working. It will energize you, your team and the stakeholders.

Taking my own advice, Wyatt Webb, our lead iOS engineer posted the very first build of Triples, a new strategy board game. Below is a screenshot of the first internal release and a polished mock-up from Jim Patterson on where we want to wind up.

By getting to screen early we are able to:

  1. Test the ease in moving and placing pieces
  2. Test capturing opponent pieces
  3. Test the relative size of the board
  4. Test horizontal vs. vertical layouts
  5. Test how robust the code is on key devices

But most important, I can test this and future builds with players and get important feedback on how they interact with the game. Players might move pieces differently then what I imaged. Players might prefer one orientation over another. The more you test these early versions with people the more you can improve the app.

This first build is human vs. human, the next build will have the first pass of human vs. computer. Leveling the different computer levels will be a challenge so the sooner we start on that process and get feedback the better.

Don’t wait for your team member to say they want it perfect or polished before they show their work. The goal is to get to screen early then learn, iterate, repeat, improve, and have fun.

If you would like to try Triples and give us feedback, you can sign-up at https://smartboxgames.com/support. Simply fill out the form provided on the page.

Please share this article with your team members and clients. Thank you.

I am a freelance Project Manager, wire-framing aficionado and QA Engineer. If you are in need of a Project Manager please contact me through LinkedIn or email me at todd@smartboxgames.com. I love designing Android, iOS and Web Apps.

/by
, , , , , , ,

Farkle Dice for Halloween – Behind the scene development

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.

 

/by
, , , , , ,

WordPop! for iPad – Who’s iPad is it?

The iPad is being marketed as a very casual device as demonstrated by Steve Jobs on stage while sitting on a couch. The only way he could have looked more relaxed would be if he was in a t-shirt and boxers drinking a beer. His point was well taken by many including my team, the iPad will be used in the living room, den or some other communal space. This makes the iPad a shared device. Let me say that again, unlike the iPhone, which you might loan to someone for a brief moment, such as a friend at a coffee shop, the iPad is meant to be a shared device.

What does this mean for WordPop!? We’ve concluded that WordPop! will be shared among family members or friends, thus we will need a sign-in. This will allow several family members to start and play their own games and it will allow individual players to save multiple games. This is fantastic feature. One game could be played with the goal of getting the highest score ever on Medium Level while another game could be dedicated to making high scoring words for the Global All Time Best Words List. Even better, another game could be saved for a child who wants to practice making words (we’ve heard from several parents they use WordPop! in this way). Another advantage of having a sign-in is we can get a name up front for the High Score and Best Words pages.

I for one can’t wait until Wyatt finished with sign-in as I too want to play several games at once each with a different goal.

Sign-In Peek

If you are a developer and thinking of having sign-in make sure to plan this up front as it is a complicated feature if not thought out early. You will want to list out which items are saved per player and which items should be global, such as posting scores to our server. If you would like further information about our sign-in flow, please feel free to email me.

Look for more peeks into our development of WordPop! for iPad in coming blogs. Please share this blog and follow Smart Box Design on Twitter.

Share/Bookmark

/3 Comments/by
, , , , , ,

WordPop! for iPad – When to Use iPad UI Elements

WordPop! for iPad  – When to Use iPad UI Elements

The iPad Human Interface Guidelines describes split view, popover, modal dialogs, toolbars, keyboard and other readily available user interface elements built into the iPad. Usually productivity applications will by default use many of these UI elements, but what about games? Games designers typically create their own dialogs, tool bars, menus etc in the same style as the game itself with custom art and code.

Suspension of disbelief is an important psychological factor of game play. The more the player buys into the game environment the more engaged he or she will feel. Using iPad built-in UI elements chips away at this because they use the OS look and feel and reminds the player that they are playing a game. I like to think of it this way, if I am watching a movie and during an action scene the leading man suddenly turned to me and asked if I was enjoying the movie I would no longer be caught up in the moment and would enjoy the movie less.

In designing WordPop! for the iPad, Jim, Wyatt, and I had to decide if we would use the iPad UI elements or create them from scratch and if we do use then when and where? We decided to use several built-in elements for the following reasons.

1.    They are quick to implement.
2.    They are flexible.
3.    They are stable
4.    They are agile
5.    They are already compatible with the hardware

We decided to use the toolbar element. The toolbar will hold New Game, Preferences, Word List, Help, and About Us. Since all of these items are not part of the immediate game flow the suspension of disbelief is minimized.

Look for more peeks into our development of WordPop! for iPad in coming blogs. Please share this blog and follow Smart Box Design on Twitter.

Share/Bookmark

/2 Comments/by