WordFrolic! is a parlour-style game from LeftSide-RightSide Games, an independent publisher of educational games and online videos. WordFrolic! focuses on teaching English idioms to children and non-native speakers: for example, a buzz word is an over-used cliché or piece of jargon according to the game. It’s part of a series that includes other titles such as Smarticulation and Hit or Myth.
The game consists of 52 flip cards, with one idiom per card. Each card has three parts. The Primary Challenge is in the form of a short story and a fill-in-the-blank space for the correct idiom. The story is usually based around some pun that suggests the idiom, and three answer choices are provided on the flip side. There is also a Bonus Question and a Talk of the Town discussion section which are more open-ended. While it can be played alone, the flip-card nature of the game makes it work better with two people and best with a group.
A few years after the game was originally published, I worked with Michael Kaulkin at Cantus Firmus and the folks at LeftSide-RightSide to create an interactive iOS version of the game.
Initial Prototyping and Evolution of the Game’s Style
When we first considered the project, some parts of the game were easier to imagine as an application than others. To keep things simple we planned to support only solo play, at least for the initial release. For our prototype we focused on the primary challenge, which was already in multiple choice format, and hence the easiest to run in solo mode. We used a couple of the sample questions from our client’s website and borrowed heavily from the style of the printed cards, even including a basic “flip” animation from front to back.
This was just a departure point, though; we knew that simply mimicking the flip-card style wouldn’t make for a very compelling experience in the final project. We also had the bonus questions to consider, which often didn’t fall into a standard pattern. On one hand, we needed to bring some structure to these in order to develop gaming strategies around them, but on the other hand, we wanted to break away from the strict multiple-choice format of the primary challenge. We came up with several ideas for interactive, gesture-based games during the initial prototyping, and brainstorming with the folks at LeftSide-RightSide led to additional ideas during development.
Once we had a stronger conceptual idea of how we could structure games around the content, the main challenge was the actual visual design. The designer who had produced the artwork for the original games was no longer available, and we had to find some creative ways to use the limited number of images that we had. In addition to various logos and the swirly background pattern from the cards, we had several portraits of the company’s fictional character Arthur Q. Pebbleton, or Artie as he is commonly known.
The main conceit of WordFrolic and the other games in the series is that they were written by Artie himself, a friendly, slightly eccentric academic type who likes to sprinkle lots of trivia within his main lessons. Artie also has an online blog and is the persona behind LeftSide-RightSide’s YouTube video series called Chalking Points, where he uses stop-motion animation technique on a chalkboard.
Behind the scenes, the blog and videos were being produced by LeftSide-RightSide’s in-house editorial director, and one goal from our client was to build an association between the application and the online content. Partially as a consequence, we decided to gear the style of the game more towards the Chalking Points videos. Our other motivation was that it allowed the possibility of having a lot more artwork in the game, because instead of relying on only a few professionally drawn images of Artie, we could now potentially have many more drawings by Artie. His ghost writer was able to lighten up on the blog and videos for a while and spend some time on the game instead. (In fact, in addition to the drawings, he also provided sound effects and a spoken introduction to the game.)
Primary Challenge
In the early prototype of the game (while still mimicking the style of the printed cards), we had introduced the idea of Artie next to a chalkboard as a transition from the primary challenge into the bonus question. During development, we moved this concept to the primary challenge screen itself, but we placed Artie in front of the blackboard:
With some later refinement, this eventually became the final design for this part of the game. We kept the swirly design of the printed cards behind the blackboard, but gave it less contrast against the background, and instead of keeping the white and purple scheme of the cards, I used a dynamic scheme based on the colours of the character art that we had. There were four different images that we could realistically use:
I used a split complementary colour scheme, taking the character’s main shirt colour as one of the complements (rather than the base) and then randomly selecting which direction to rotate around the colour wheel. The resulting base colour was assigned to the background and the other complement to the buttons, so this gave us two different palettes for each image. In addition, I also mirrored the image at random and then layed out the rest of the screen accordingly. Together these two techniques together gave us a reasonable amount of variety for the main challenge screen, while still adhering to an overall theme:
The change in metaphor from flip-card to chalkboard naturally affected how the answer text and choices are revealed. Rather than flipping the whole screen horizontally as if it were a card, I flipped just the chalkboard part vertically behind Artie, as an allusion to one of those old free-standing, double-sided models. For a little while I considered adding more illustrative elements around this notion, such as legs, a base, and knobs at the sides of the board, but I soon decided that it was better to keep the design cleaner and more figurative.
Multiple Choice Bonus Questions
In our prototype version of the game, based on the flip-card style, it was the bonus questions where we had originally expected to use the Artie-and-the-chalkboard theme, although the styling at the time was very abstract. We used the background swirly pattern from the printed cards on a different colour background, and the main text we placed in large, pastel bubbles with asymmetrically rounded corners.
Originally, we had planned to include both the question and answer texts on the same screen in separate bubbles, but we found that in some cases it was too much business on a single page. As in the primary challenge, we opted for an overall static design where only changes in the text and the answer choices are animated.
We also wanted to avoid repeating any of the same four character images that we had used for the primary challenge, but we had just one more that we could consider, a leaning pose from the box cover that was especially difficult to work with:
One idea was to tinker slightly with the image to make the lean less pronounced, and another was to just use the top part of the image, as if the character is behind a desk or a console. The second idea turned out more workable, but we used elements of both concepts for the final design:
Other Bonus Questions
There were two other types of bonus questions that did not fit into the multi-choice format. One type challenged the player to name all or a number of items from a particular category, such as “Name five citrus fruits” or “What are the five boroughs of New York?” For these types of questions we designed a game called answer cascade, in which a mix of answers rained down quickly from the top of the screen for the user to tap, the goal being to select a certain number of items correctly within the time limit (incorrect choices counted towards the total number of guesses, but didn’t score any points).
Another type of bonus question involved word definitions, breaking a compound word into its root components and choosing meanings for them from a list. For example, the word mesopelagic can be broken two parts that translate as middle and ocean. In this game, users must drag the selected word parts and drop them into their correct places in the middle drawing (the two correct choices happen to be at the top, but this is random).
This game was probably the most enjoyable to develop in terms of the user interactions and animations. In its initial state, the draggable elements are arranged around the central target without any overlap. But when the user drops a component onto the drawing, there is a potential conflict. For example, from the above screen if shark is dropped onto meso, then there is no issue, but if middle is dropped onto meso, it will overlap the shark image and be difficult to read. To avoid this, I added an autoarrange mechanism to shift items around if necessary. A related problem occurs if the user drops one item onto the target and then wants to replace it with another item; in this case, when the second item is brought over to the target, the first one flies back to an available slot as the list is rearranged.
This view was also used in two other drag-drop style games that were based on multi-choice questions. The arrangement of the selections around the central image and other behaviours were a little different, so while there was a single view, I used a set of helper classes to manage the variations.
In-App Purchases
WordFrolic! is free to download and comes with ten idioms to start. An in-game app store allows to user to purchase additional game packs of idioms. The first downloadable game pack consists of the 52 idioms from the original printed game, and a second pack was being prepared at the time the app was released.
Our in-app purchase module worked with Apple’s StoreKit framework and supported all of the required actions, including checking for package updates, downloading content, and restoring transactions across devices. The game content is hosted on Apple’s servers, but the master list of available products is hosted on a separate Amazon S3 server because the Apple store interface does not provide a wildcard search across product IDs.
Apple provides a sandbox environment that can be used to test in-app purchase functionality, but it can only be used once the application and content bundles have been registered with Apple. Since there is a limited time window to finally publish an application once it is first registered, I wanted to develop as much of the local code as I could beforehand. I did this by wrapping an abstract interface of our own around the necessary StoreKit APIs and following with two separate implementations: a real one using calls to Apple’s servers, and a mock one that used shared files on Google Drive. The latter allowed me to build and test almost all of the surrounding code and the user experience without worry, and once the app was registered with Apple, it only took a couple more days to clean up the Apple-specific implementation. Using Google Drive as the backing store even helped me test versioning of content bundles, as it has a simple file versioning system built in.
Additional Features
A few other screens round out the application’s basic functionality.
A score sheet at the end of a round lists each idiom played, regular points and bonus points earned for each, total number of points, and a letter grade. If the user’s score is high enough and there are unpurchased game packs available, the user is encouraged to visit the app store.
A settings page allows the user to control music, sound effects, and game tips.
Finally, there was an about page, including links for further help, a short marketing description of LeftSide-RightSide Games, and credits. In addition to the professional artwork and drawings by “Artie” in the game, we also used several public domain fonts, music, and images that we wanted to ensure were properly acknowledged here.
Game Content and Development Tools
During most of the course of development, we used Google Sheets to maintain the game’s source content. Editing the content to make it suitable for the screen was truly a group effort, and this was the easiest way to give everyone access. Each row in the spreadsheet represented a single card (primary challenge plus bonus question), and each game pack was on a separate tab.
In the application itself, the game content is managed with CoreData, and each row in the spreadsheet actually corresponds to several related entities. I wrote a separate, stand-alone utility to import the data from Google Sheets via an intermediate CSV format and browse the results.
While minor edits could be made directly in this utility if needed, Google Sheets remained the authoritative source for all the content, and every time changes were made, they had to be downloaded and imported again (which also meant rebuilding the application bundle). This process was fine early on during development, when the content changes were bulky and infrequent, and the game’s layout was more in flux. After the basic layout was complete, however, I needed to clean up and tweak the content in a much more precise and iterative fashion, and this was too much to go through for each iteration, especially when I potentially needed to preview each change.
At that point, I started adding a number of content editing facilities directly into the application itself (only when compiled with a special flag). These were context-sensitive overlays that could be called up to edit and preview changes on the active screen. Once any number of edits had accumulated, I could log them all to the console and then copy and paste them back into the spreadsheet to be imported later at leisure.
While the main application is written in native code, we used web views and HTML to present much of the content. Snippets of this came from the spreadsheet, but the pages themselves were generated dynamically within the application. This overlay allowed me to edit the fully generated HTML, which was more helpful for tweaking the overall design than it was for editing individual content records.
This overlay was for fine-tuning the text wrapping around the Artie figure. The length of the question and answer text varied considerably across the whole set of cards, and the longest examples had to be wrapped quite tightly. This was done in the generated HTML with a series of empty DIV elements. This screen allowed me to draw a continuous contour around the figure, and then convert that to a set of discrete measurements for the DIVs. Across all the images and cards, there were almost a thousand permutations that had to be accommodated. Rather than custom wrapping for every single one, I created a small library of 10 sets. I could then simply browse through and assign each text instance to the best fitting set also using this editor.
This overlay allowed me to edit a grab-bag of miscellaneous properties for each question. This was stored in JSON format in both the spreadsheet and CoreData (hence handled as a generic dictionary). The specific keys used for each question depended on the type.
This overlay let me edit individual answer choices, which was most useful on the drag-and-drop games. Things like the placement and alignment of the text and image, mirroring, and the drop target area could be edited graphically, rather than having to manually edit the parameters in text form in the spreadsheet.
You can find WordFrolic! in the iTunes App Store at https://itunes.apple.com/us/app/wordfrolic/id1063076859?mt=8.
More information about the original printed version of WordFrolic! can be found on LeftSide-RightSide’s website at https://www.leftside-rightside.com/product/word-frolic-village-idiom-i/.