Origin Story

I've wanted to create a mobile game since I was in college (when the PlayStation game LittleBigPlanet was released) but I thought learning to code would be too difficult on my own. However, as I started working in digital design I began tinkering with HTML and CSS and I realized there was a wealth of information and tutorials online. From there I decided to learn JavaScript so I could create fully interactive prototypes and, at that point, I was confident I could learn any programming language with enough time and practice.

So a few years ago I decided it was time to pick a framework or game engine, learn what ever languages and systems were needed to use it, and finally make something on my own.

The Tech Stack

When I started exploring tools and engines for building a mobile game, I was a bit overwhelmed with all of the options. I tried a lot of products, from no-code visual GUIs to super advanced 3D tools like Unity. In the end I landed on something in the middle: a 2D game engine called Corona that uses the lightweight scripting language Lua.

Corona provides cross-platform builds, an extensive set of APIs, and has one of the most helpful forum communities I've ever been a part of. If you're looking to get started with mobile app or game development, I can't recommend it highly enough.

An example of Lua syntax from the Word Shift codebase.

A Simple Idea

Before settling on the idea for Word Shift, I created 100+ various demos, examples, and proof-of-concepts as a way to learn Lua and the Corona engine. At some point while experimenting with generating dynamic grids, I had an idea and scribbled this little sketch on a post-it note at my desk. This would eventually become the concept for Word Shift.

Core User Flows

Since I was going to be the only designer and developer on this project, I knew I needed to keep it as simple as possible – or I would never finish it. One of the first artifacts I created was a simple flowchart to map out the critical paths and make sure I wasn't over-looking anything. Due to the way the game engine works, this also laid the groundwork for the project's file and folder structure.

V1 of this flowchart even omitted the Shop and Category Select Screens.

Defining a Visual Style

Once the functional proof-of-concept was built, I decided to figure out some of the visual design components. I knew I wanted something clean and minimal that wouldn't distract from the puzzles, but I also figured keeping the art to a minimum would mean less for me to create. For inspiration I looked at other minimalist games like Dots, FLO, and Ballz, as well as the usual suspects: Google and Dribbble. I took those ideas into Sketch to come up with something similar but unique.

Some of the visual inspiration behind the game's style. All designs © their respective owners.

One of the final design questions was the choice of typeface. Since I already had a visual style laid out, I had general guidelines to work within: sans serif, rounded corners to match the blocks, thick enough to be readable on light gradients, and no oldstyle figures. Rubik was a pretty obvious contender from the beginning and, once I added it to the design mockups, I was sold.

Visual iterations from my initial proof of concept to final(ish) design style.

User Testing

While I'm making this game primarily for myself as a learning experience, I still want it to be usable and fun. Of course the best way to remove my own bias and see if the game is meeting those goals is to let people use it and share their feedback (or watch them use it). However, with other game concepts, I made the mistake of trying to user test too early and, as a result, received shallow feedback about the unfinished look of the game and how it needs XYZ feature to be fun. So for Word Shift I waited until I had a quasi-polished style and most of the core features in place before I began sharing the game with others.

User testing up to this point has been very informal and I rely heavily on my family and friends for feedback. I won't get into all of the advice they've given, but a few notable issues and features they've brought up are:

Luckily, given the nature of this feedback and the current stage of the product, I've been able to implement and iterate on a few of these points already. As development progresses I plan to continue soliciting feedback from an expanding audience so that, when I launch publicly, the game is free from usability issues and (hopefully) fun to play.

A few of the fixes and features directly inspired by user feedback.

Building Levels

With the core interactions in place and polished, I began the process of designing and building levels. Taking cues from the incredible level design of the original Super Mario Bros., the game starts off as easy as possible and the difficulty ramps up as the player progresses. Normally I wouldn't go into much technical detail about building levels, but I'm actually a little bit proud of the system I created for it – so bear with me. (But if you're not interested in a technical explanation, feel free to skip this part.)

Okay, so before I get into the technical details, it's worth mentioning that my goal is to release the game with at least 1000 different levels. With that number in mind, I set out to create a quick and easy way to build levels. Here's how it works:

Each level is defined as an table consisting of 3 types of input: 0's, 1's, or a letter.

Side by side comparison of code and the level it generates.

Currently there's a huge file with about 200 of these tables, each defining a single level. When the player selects a level, the game controller loops through the table and, for each index in the gridTable, determines what type of block should be placed on the screen. The other few attributes define the word, the sequence of letters needed to win, the number of stars awarded, and the number of total starts needed to unlock the level. I use these attributes not only on the actual gameplay screen, but on the category select and level select screens.

This level building technique allows me to create roughly 50 levels per hour, but it comes with one major setback: I frequently create unbeatable levels.

So naturally the second part of my level building process is play testing. While this is far more time consuming, it forces me to play and replay each level trying to get the best score (so I can fairly award stars based on the number of moves required to beat it). This gives me a solid idea of the level's difficulty and has, in many cases, forced me to reorder the levels for better difficulty ramping. I've also enlisted the help of a few friends to play test levels and report their best scores so that my own skill level is not solely dictating the high scores. On a number of occasions I've had to raise or lower the starScore3 and starScore2 attributes, or modify the level layout, based on feedback from my play testers.

Where We Are Now