Monster Roller
Project Description
2015 saw the rise of the midcore genre in mobile games and the emergence of the Chinese market. Fueled by those trends, developers sought to create games with indefinite play times and a free-to-play model, either through subscriptions, micropayments, ads, or some combination of all three. Predictably, the market was (and has been since) dominated by content-heavy, collectible-based, multiplayer games centered on events/arcs with multiple revenue streams. Monster Roller was my team's attempt to give the users options on how they'd play (and/or pay) the game while balancing the "grind" as well as tactics and mechanics.
Unlike other projects, where I pitched to a publisher, from the start of Monster Roller the concept was given to me. I was instructed to make a game using a slot machine design — a gambling mechanism so culturally associated with luck and a lack of control that it's called "the one-armed bandit" — while still ensuring the game itself would be a battle of skill through good player choices, not randomness. This assignment was something of an uphill battle, working in reverse to convince players "we're not luck-based, really!" We were also mandated to make the game fully PvP (Player vs Player) with a single-player campaign for offline play. I did scream, in public, at work, but then I went to my corner and started sketching.
For this project, we researched player expectations on midcore games, specifically deck building games. (As in many studios, Hearthstone was constantly mentioned, though the game bears little resemblance to Hearthstone.) Unlike with pure casual games, midcore games have a built-in language that we could build off of; we didn't have to start with an empty slate in the player's mind.
A Blend of Deck Management and RPG Mechanics
The original inspiration for Monster Roller came from turn-based trading card games and RPG (Role Playing Games) battle systems. In most battle systems familiar to hardcore gamers, a blow during a fight can either be:
- a regular attack, dealing damage based on a strength stat,
- a critical attack, dealing more damage,
- or a fumble, where the blow doesn't land or does minimal damage.
In classic games like Dungeons and Dragons, the chance or degree of success of that blow depends on the roll of the die. Instead of die, Monster Roller used slots so the difference was in how the RNG (Random Number Generator) was presented.
The linchpin was how well we'd communicate to the player that "it's just like the RNG in your typical RPG!" The typical mapping in a gamer's mind would be that the slots corresponded to random actions (attack, defend, skill/magic, etc.) — we had to make sure it was clear this wasn't what the game would be like. This is not easy, because die make it clear that some variable is manipulated by degree while slots imply that the variable is manipulated is type.
We also kept the concept of a "party" of monsters/companions traveling and fighting together. In most RPG games there are 3-4 active participants in a fight, with the option to swap out. In Monster Roller, in order to give the player more ways to respond to an enemy strategy, we had a total of 6 monsters per battle, with three (which we called the frontline) fighting at a time. The next three monsters in a party were called the bench, and could be swapped out at any time during the player's turn.
Then the slot concept was molded around sensible, well-known mechanics, to work with them rather than against them. Say you're a fighter with an assortment of punches and kicks that do roughly the same amount of damage. They'd all deal a "normal" amount of damage, but are different types of attack. We applied that to Monster Roller (albeit with more clawing and biting) in which a viable strategy would be to create a party that maximized having attacks of the same type — because they all had the same icon, and having the same icon in slot machines means hitting a jackpot.
This introduced the importance of "party management" in a manner distilled for quick mobile gaming sessions. We further built on this system by having roles for monsters: some monsters can attack, but some monsters can heal, can poison the enemy, can defend others, and so on. Thus, the core mechanic of Monster Roller was much the same as many card games: it boiled down to what cards are in your deck, which are then use to create certain plays and card combinations — basic deck management. Below is the Team UI screen which helps users decide on what monsters to group together. Through the creation of a visual and textual language, mechanics such as Roles and Jackpots are clear and intuitive to the player.
Two other ingredients rounded out a player's decision-making process in battle: the order in which monsters play their abilities (the Switchout system), and the Auto-Targeting system, which was influenced by monster elements and area-of-effect. But these systems are beyond the scope of this portfolio. More in-depth information on how we prototyped these systems to work together, and what these systems are, can be seen in my Monster Roller Retrospective (link forthcoming).
The Marketing-Design Connection
Because the game was self-published by Boomzap, marketing and design worked together to get the word out.
- Marketing and design jointly collaborated on the press kit. I wrote all the copy for both iOS and Google Play stores; our Marketing Head edited everything I wrote and provided me with a requirements list with word counts and descriptions.
- Either I or an artist contributed weekly content to a Wordpress blog for a year, detailing the process of creating the game. This also helped Marketing provide content in case they needed to do press work while I was unavailable.
- We attended local gaming cons to spread the word, such as ESGS 2015, where we were able to present a beta build in their indie corner and ramp up awareness of the game.
My Role and Responsibilities
| My role | Designer / Team Lead |
|---|---|
| Core team size | 10-15 |
| Responsibilities | Design & Writing, Project Management, Prototyping |
| Documentation produced | Pitch Deck, Prototypes, Tasklist, Feature Request Documents, Player Feedback Reports, Analytics, Bug Reports (Mantis) |
| My tools | Photoshop, Excel (as game data exporter), Google Docs (pitch, feedback, and GDD), Google Sheets (task sheet, walkthrough), Basecamp, Flurry, as well as proprietary company tools for level, video and UI elements |
| Credits | Mobygames |
- I did product research, specifically for midcore mobile games, board games, and card games. This included industry research such as compliance for region-specific laws such as COPPA, indie publishing models (Kickstarter was on the rise) and self-publishing analytics.
- I designed the rough look of the UI and the flow for the UX. I decided on the text of the buttons, the grouping of information in each screen, and the way the information would be presented (whether card, list, or some other pattern.) This includes making prototype animation, drawing roughs, etc. The artists would then finalize my sketches.
- I handled the stat balancing, which we did based on percents of a character's HP.
- I handled the events funnel of the game through analytics. We used Flurry to drill down to what stage or event the user had given up on, giving us the opportunity to "smoothen the funnel."
- Through collaboration with the marketing team, we created a press kit with a trailer, screenshots, and text (my contribution) for both iOS and Android stores.
Project Specs
| Project | Monster Roller |
|---|---|
| My role | Designer / Team Lead |
| Developer | Boomzap |
| Publisher | Boomzap (self-published) |
| Genre | Midcore RPG / Deck Building |
| Release Date | Oct 17, 2013 |
| Platforms | iOS, Android |
| Localization | SEA Localization: English, Taglish, Vietnamese, Thai, Indonesian |
| Online Stores | Google Play Store (Archived) - iOS App Store (Archived - link may not load) |
| Let's play | PROAPK on YT |
Production Gallery
Whereas my previous adventure / point-and-click games were content-heavy with plenty of story writing and assets, Monster Roller was the opposite, where we made iteration after iteration of new UI patterns and UX tweaks. First we did these on cards, then on Excel, then we went through a new UI again and again. At no phase of alpha or content development was the UI / UX held sacred or final: it could change at any time, and as soon as the next day's build. We stopped touching the UI / UX flows only when we hit beta (content complete).