Monster Roller is a monster strategy game with a hybrid slot machine combat system for mobile by Boomzap Entertainment. Hatch, raise and train monsters to fight against your friends in online PVP or explore solo adventures offline!

All posts by Sara

Monster Roller is a monster strategy game with a hybrid slot machine combat system for mobile by Boomzap Entertainment. Hatch, raise and train monsters to fight against your friends in online PVP or explore solo adventures offline!

Design Log: Functional Requirements


Hey guys, today’s post is about making games, prioritizing features, and breaking down functional requirements.


Industry Identity Crisis

Quick question: are you in the software industry if you make games?

The short answer is no. (The longer answer is ‘sort of.’) More accurately, the games industry is in the business of entertainment. Your job, as a game maker, is to entertain people. Make them feel better about themselves. Reduce the complexities of the world into a pixel-perfect, enjoyable experience. Games have objectives that have tangible rewards (story progression, beautiful art, nice cutscenes.)

Meanwhile, if you look at a word-processing software, like Microsoft Word, it has a bunch of functions that allow you to type in something, say, a book report – and functions that (1) save the data you input into a file and (2) transmit the data into an output device, like a printer.


Software development is about building something that fulfills a definite purpose. Nor do you need to create data for the software, unless it’s a help document. The end-user creates the data – book reports, inventories, invoices, user accounts, digital art, and so on.

The point here is that video games have a really abstract function: fun. And to fulfill this elusive human desire, we have to make some software as tools, and make the content of the game for the person to play with.

  1.  You need the tools (software) to craft an interactive experience
  2. You need the data – player classes, enemies, the story – that the user manipulates for fun
  3. You need to make sure the data and the software it uses is optimized so that people can play it

ScreenHunter_298 Jul. 16 03.41

A very, very simplified chart of what we do.

Today’s design log is about functional requirements in games. While it sounds pretty straightforward to have a list of features and the parts needed to fulfill that feature, it can get hairy pretty fast.


Making games is a mess

Functional requirements change all the time. You start out with one feature – say, a battle feature – and pretty soon you may have an item system, maybe the battle has changing environments, maybe the environment modifies the abilities of some player character type, and so on. See those old mockups for Monster Roller, the game we’re currently developing? The game would have been balanced vastly differently had we included items. Or trainers on our monsters.

The knee-jerk reaction at first for a game with an RPG looking battle system is ‘of course your game needs an item system, power ups, a store, and so on.’


“Why didn’t you figure out you’d need all this?”


“Why didn’t you figure out that you DIDN’T need all of this?”

Making games is a mess, because true innovation is a mess. The other kind of innovation is ‘iterative’ — building on known formulas. Games are made of a combination of both, in varying degrees. While developers may get tied to certain formulas (a racing game needs these kinds of tracks, these kinds of powerups, and so on), at the end of the day, you can’t serve a mojito like everyone else’s mojito in an industry where so many are willing to give eight or usually more hours at NO PAY into finding the holy grail of fun.

Making games is a humbling experience. You start out thinking you know what this game is going to be.

ScreenHunter_306 Jul. 17 17.32

It’s a tower on the verge of being unbalanced, all the time. Maybe it turns out that it’s too derivative, or the mechanics were too different to be meshed together, or it is hard to get into, but fun. A certain degree of experience mitigates this, of course, and a veteran will likely have a better idea of the pitfalls, but the true creation of something is always… unexpected. That’s what being new and innovative is about.


How functional requirements evolve:

We prioritize based on how core the feature is to the game. Then we make layouts based on what we think we’ll be putting into the game, with sample data. For this last part of the article, we’ll go over the battle system’s components. We had several functions we wanted to do, at the very beginning:

  • We would have the slot machine reel, of course
  • Which would net bonuses based on jackpots (4 of a kind back then)
  • We considered bet multipliers
  • Holding’ — keeping a slot from spinning (you would have to pay to do this)
  • Switching out monsters during your turn
  • Using items on monsters (that was the ‘obvious’ thing to do, wasn’t it?)

That is not a list of functional requirements. That’s just a wishlist. Functional requirements may include things like a proper description of what’s going to be in it (the data), how it’s going to be presented (UI), and success criteria if it’s working the way it should be working.

Let’s look at the items system for example:

  1. What would be an item’s scope? Would they be used on the player’s party, or enemy party, or both? Can they have a duration? What variables can these items act upon? HP? Attack? Heal value? In percents or wholes? And so on.
  2. Could they be reused after the battle, or are they consumable per battle?
  3. Do they have a cost to use them? How is this cost implemented? Is it the number of turns in a battle (time cost) or some other metric? Do you have to buy them in a store? Hardccy or softccy?
  4. How would it look?

… And so on. The document that answers those questions will then be the functional requirements doc.

Now, as to the evolution of all those systems and functions, let’s take a look at battle.


The left mockup was made by yours truly almost half a year ago. The one on the right was made by a real artist, and is how battle looks now. Let’s go over what we see on the screen to find out how the functional requirements changed between then and now.

Top Row Old:


Top Row New:



They both have a gold indicator and a settings button. The prototype’s Autoplay moved to the bottom row in the latest version (see below.)

The biggest change is the addition of lights around the frame that change based on what’s happening, and the timer. We added the timer because the game is PVP — it would suck to be waiting for a long time for your enemy from around the world to decide how to attack.

Battle Screen Old:


Battle Screen New:

ScreenHunter_307 Jul. 17 17.40

You’ll notice the original mockup failed to account for selection indicators (the arrows on top on the left), or showing things like negative/positive status effects (look at the super tiny monster!) There’s also the difference of seeing your monsters in battle. The other major change was simplifying from 4 monsters to 3 monsters. We did this to speed up the pace of battle and to make it easier to gain a jackpot.

Rollers and Avatars, Old & New:


Lots of changes here. Let’s look at the cherry bar first. The cherries were to be earned for every round in battle, filling up slowly. The other way to gain them was to roll them. These cherry points could be spent to use an item, or switch out characters, analogous to mana or energy in card games. However, the item system and the cherry points were both later removed.

We didn’t add in the cherry points because “it was what everyone was doing,” either. We added them in because having that choice made the game less about luck and more about strategy — choosing the ‘right’ action. Do I use THIS item or switch out THIS monster? We had a definite reason for having items and costs.

Why then was the system scrapped?

If you look at the variables of a battle game, there are plenty of factors that can be controlled without adding another system:

  1. Targeting — Will you auto-target or focus on one?
  2. Abilities — Attacking, De/buffing, Defending, Healing, Elemental strengths and weaknesses
  3. Combos — Three of a kind jackpots, monsters that can ‘buff’ other monsters’ abilities
  4. Lineups — This affects the chance to get combos
  5. Time Limit — you have this much time to decide what your strategy will be

It’s tempting to add in a feature at the beginning of development. This is because it’s difficult to visualize how features interact with each other and how it impacts the gameplay. It’s easy to think ‘this is not enough’ because we haven’t yet created content. Prototyping helps greatly in killing that feature bloat temptation. Considering all of the above variables, the item system would have been another thing to balance — not only for the devs, but for the player as well. The idea is to make each of those variables above relevant to winning the game, not to add another feature.

Amazingly enough, there are two other variables we could spend all day talking about, compressed in this section of the UI: how the roller behaves and what goes into the reels. (Does the slot machine have a ‘hold’ function? How does it process a jackpot? If a monster is stunned, how does the roller react? How are slot compositions made? Do all slots have some kind of 3 of a kind jackpot? Etc.) For now, a passing mention of all these variables is enough to illustrate the evolution of the function.

The last change in this segment is the Let’s Roll button. Although originally we were thinking it would be fun to flick the reels, quite a few playtesters looked for a button (playtesting is an excellent way to determine functional requirements) so we added one in to make the game more intuitive — just press the damn button!

Bottom Menu: Old

adfasdfBottom Menu: New


And now we get to the last segment: the bottom menu. You’ll see the price for the items and the switch out action available in the old version, which was simplified down to autoplay and switch out. Another reason for careful pruning of systems, apart from the great number of things the user has to keep in his or her head, is real estate on the screen. The language in Monster Roller is already quite dense with the icons, jackpots, elements, and targeting. Adding another visual language is another set of things for the user to memorize.

Phew. That was a pretty long post.

Quick recap:

  1. Game development is closer to the entertainment industry.
  2. Ditch the mentality of ‘clinging’ to a certain set of functional requirements. They change, a lot, in ways that will surprise you.
  3. Games are made of true and iterative innovation.
  4. Defining functional requirements is more complicated than just writing down a wishlist. Ask yourself how this feature interacts with other features, and list down all possible ways of implementing this feature.
  5. Prototype the core feature based on the functional requirement and prepare to tune/tweak as needed.
  6. You’re not done until it’s fun.

Congratulations for making it this far. Here is a picture of bacon.






Iteration, Iteration, Iteration

Mixed bag of updates this week. I’ll be going over them in more detail in the weeks to come.
Battle Flow

One of the biggest things we’ve been working to fix is the speed of battle. Here you can see 2 GIFs comparing the speed of an old fight and a new fight, up until the first round.


Above/Left: the old flow. Note the attack log, floating numbers and the ‘About to fight!’ pose before the monsters actually bop each other.

Below/Right: the new flow. Attack log has been removed, damage is in larger numbers, the way the monsters jump in is sped up, the coin flip is faster as well. And we removed the ‘about to attack’ animation.

We’ll be going over how we got from the old animation to the new animation in the future post. Moving on, we also have a few new screenshots of UI and evolved monsters.

UI Improvements:

Having nailed down the look and feel for the UI (black/yellow/red color scheme, buttons that look like you’re in an arcade), what we’re looking at now is what features the user will find useful.

OldMonsterListNew Monster List. Note the new icons below, XP bar, the ‘role’ of the monster, and the addition of the attack value. We also have a sorting function.



OldArenaNew Arena Screen. The 6vs6 fighting wasn’t so obvious back when we only showed unique ‘frontline’ monsters. Now it’s more obvious (but still WIP, because it’s showing 7 vs 6 — have to sort out how to fix that. Also, is it just me or shouldn’t the PLAYER be on the LEFT?)


New feature (still a WIP). The incubator that will close the loop of the game.

And now for some Evolutions:

magmus adult_002

Magmus’s Evolve: Volatil. Got itself more volcanoes and a larger fire fist.


Mortox’s Evolve: Mortagon. Entered the 20th century with that Gatling Gun. It’s sporting a pretty grimdark design with those bulletholed wings. Much edge.


Lectreel’s evolve. We don’t actually have a name for it yet.

Got any ideas? Let us know if you’ve got a name for Lectreel’s evolved form :)

Design Log 2: The Compellingness of Battle

Hey rollers!

This is Sara writing another post about design. There’s a lot going on in development. We recently had a major meeting to figure out how we would close the game loop, and also discuss the compellingness of the game.

We’ll skip over the game loop stuff for now and focus on the problem of being compelling.

The problem of Monster Roller is that it isn’t compelling enough. When people test the game, they give it back after a few minutes. Initially we were thinking that it was because we hadn’t closed the loop and that there was no sense of a larger progression beyond battle. But that’s because we keep thinking of MR as an RPG-like game. It looks like one, so there is that expectation.

But it’s not like an RPG at all. There are plenty of games that survive on the core mechanic of doing something well, where progression is simply measured in high scores. While MR will have eggs to collect and leaderboards for PVP, the case for games which are purely played for the core proves that compellingness isn’t really about ADDING a feature (like a Quest System). Tetris doesn’t need to unlock additional blocks after winning each stage to be interesting. It’s interesting in its core puzzle mechanic. Same thing with Flappy Bird.

Tetris-VeryFirstVersionSimple and addicting because its core mechanic shines. Image © Aleksej Patinov, as Fair Use.

The same case can be applied to Monster Roller. The point is to make battle fun. The way it was a few weeks ago was… not that fun. (It wasn’t the author that pointed this out, incidentally. Credit goes to the Creative Director.) If the core mechanic is not that great, people won’t bother to get as far as collecting eggs, anyway.

The fascinating part here is that this is the designer writing this post — and I’m more concerned about keeping balanced stats, making the UI clear — but even I have to put my head out of the sand and realize that different games have different killer features. And battle is this game’s killer feature.

Currently we’re working on making battle feel faster and snappier.

This involves playing with several variables: effects, rigs, timing, and the information that has to be displayed. For now, instead of going in depth on all those variables, I’ll leave you guys with two gifs showing different ways we’re thinking of approaching the problem. When battle is sorted out, I’ll go over these same variables and explain how they work.

4 blogpost

4 blog post 2

PS: A disclaimer — what I’m writing here reflect my thoughts as a designer. Actually the team itself has different opinions on what makes the game compelling. We’ll be seeing how those hunches develop too as the game is developed.



This Week In Monster Roller: Skeletal Animation Process

Hey there Rollers!

Today we’ll have a short post about animation. In simple terms, we have a ‘skeleton’ of the monster whose parts all move. How we define these parts (usually called ‘bones’) and animate them determines how well they move. Fittingly, this kind of animation is called skeletal animation. The process of making all the bones add up to a body is called rigging.

As a simple example, a cat animation will have the body, tail, face, eyes (separated for blinking), and 4 legs. Depending on how complex your animation must be, you can also separate the ears, the joints for the legs, the whiskers, and so on.

Here’s what it looks like, straight from our animator’s computer: (Hi Macoy!)

Defining the ‘Rigging Templates’. As much as possible we want to reuse rigging templates so that we don’t have to waste time rigging every new monster. In a game with potentially over a hundred monsters, this is very important. So we have to tell the engine ‘This rig is for this monster’. In the picture below, Puffapy’s rig is the simplest one: it only needs a body.


Then in 3DSMax, the animator takes all these cut up assets (provided by the artist):

Snap 2015-04-09 at 02.24.23


Each part (or bone) has a mesh, which is a polygonal model of the part. Pictured below are some parts (torso and shield).05 03

This ‘model’ is needed by the computer in order to interpret HOW to move the part. If you define your mesh well, you will be able to manipulate the part or model to do whatever animation it needs (like breathing, attacking, and so on.) How well something ‘moves’ also depends on what the engine can handle. Our engine supports keyframe animation (usual tweening stuff) and vertex animation. These topics will be discussed in the future, so stay tuned!

Returning to our Womburr (that’s the name of this new monster), after putting in all the individual parts together, the rigging is almost there:



And this is what the final idle animation looks like:wubber


Hope you guys enjoyed this short post on animation. Stay tuned next week for more.

Late Post Is Late, Also Heavy: Design Log 1

Quick contextual note: Everything written about ‘game designers’ here is not uniform to all companies. We all have different ways of working.


“We need more things.”

Design: The job everyone thinks they can do. Whether you’re a game designer, a product designer, a UX/UI designer — it’s all the same.

People frequently do not know what a designer is, or the problems they really solve, or the value in what they do. Ironically this is the nature of the job: if someone notices something, it’s because it sucks. Good design is something people should take for granted, because it’s just supposed to work. Naturally this means that the only time designers get feedback is when it’s bad. This is why designers are drunk all the time. This is also why everyone thinks they can do the job.

We live in a world that is deliberately designed. Most people don’t notice it. But a chair built today is made of thousands of years of iterations — what if we added rollers? What if we added padding? Someone designed those, until we had office chairs and reclining chairs and so on.

In the vast swath of the design world, today we are going to focus on the question: what do designers do? Fair warning: this gets technical especially in part 2, which is about balancing.

Designers are implementation people, and sometimes idea people. Very rarely do I, personally, get my idea into the game. When you work with a team, you will find that everyone has ideas. Everyone shouts into the room, while you and the programmer watch. Occasionally you will be required to submit an idea, because people think you’re not doing your job if you don’t have any input. The truth is that the magic isn’t in the idea, it’s in the implementation. And the truth is that it is less about whose idea it is and more about what idea is just more suited to the function and context of the game (and company tech.)

Most of everyone’s ideas will lack actual body or planning. That is the nature of an idea. Your job will be to refine and define it. I call this process foretelling the future (ha, ha, you say). It’s very easy to suggest, ‘Let’s add another mechanic,” — a lot harder to know how much concrete effort it will entail. For example: “We need more slot types,” translates to “we need code, script, animation, art, music, testing, in the following X work units.”

The concrete output of a designer is this — blogs, tasking, and scripting. Lots of scripting (this is where level design, monster design, and the like come in.) We also explain stuff, coordinate stuff, make sure the team doesn’t kill each other, and we also train staff. Trivia: a new artist once asked me what a sprite was.

That seems like a lot of work! It is. Most of the day just goes into asking myself, “What am I doing? Where did my day go? Why am I drunk?” But in all seriousness, the other task of a designer is to build tools that automate script building and other tasks. A simple example of a design task that I am working on in Monster Roller at the moment:

Problem: Make me 100 monsters that are balanced according to rarity weight.

Let’s try to visualize in our heads a similar, simpler task: try to make fifty monsters in an excel sheet, with attack, defense, and heal values, and special abilities, and try to make a basic sheet where they are fighting 3 on 3 (just repeat the battle loop until they are dead.) Just try to imagine that — coming up with 50 unique monsters, with different but balanced stats and unique abilities.

The thing is, after all of that, that’s not even really the whole picture. The question is: to what end are we refining these stats for? What are we making 50 monsters for? I won’t answer the existential reason (it’s not in the scope of this piece), but the pragmatic objective is to give the player a set of concrete, clear choices in how they will win the game.

Game design is about player choice. Game design is all about presenting those choices to the user in clear interactive language, the whole gamut of graphics, text, and animation.

Games are all about interactions. Why interact with something if it’s the same old interaction all the time?  The big chunk of design answers how to present those choices to the player, to make people want to choose.

Anyway, I think that’s some pretty heavy stuff to digest.

The next part of this post (if you scroll down) is a simplified breakdown of how we balance monsters. It has pictures, at least!


A normal day at work, versus build submission for some milestone.

How We Make Monster Stats

For the first four years of my stay in Boomzap, I was building levels — you can think of level design as that part of development where you design mazes, blocks to jump over, and decide where to put enemies. Monster Roller is a huge disconnect from that. It is ridiculously simple to build a level: you just define the enemy monsters and your own.

The interesting problem here is making the values for the enemy monsters and your own, especially considering the balance of ‘mindlessly flicking around till you win’ vs adding ‘strategy’. My current thought is that PVP will take much longer than offline play, being the more ‘hardcore’ mode of the two.

As you can see — development is subject to change. A lot of change. Instead of me adding thousands of platforms and dungeons and enemies, I am instead recalibrating each enemy and each player character a lot, especially as mechanics for the game change. During the ‘recalibrating’, this mostly means testing in iterations, hand-editing a few monsters. However, when it is time to apply it system wide, obviously hand-editing each is a bad idea (especially without structure.)

Here’s a screenshot of what data constitutes a monster:

Snap 2015-03-27 at 18.08.04You: Okayy… this is kind of intense.

Snap 2015-03-27 at 18.16.52You: So this is kind of awesome, but the writer hasn’t exactly provided context.Snap 2015-03-27 at 18.09.22You: Ok that’s it, three monsters is enough!

Let’s breathe in and out and scroll down to see a simpler, friendlier diagram explaining what all that stuff means.


Ok, I hear you say, this, I can sort of understand.

Each monster has 2 reels. One with more attack slots, another with more defense/heal slots. You can have N number of Attack Abilities or Defense Abilities. Obviously too high an N means potential frustration because you never know what you’re going to get. Too low an N is boring. Each monster has a certain amount of HP, ATK, and Heal. Lastly, they have a clan, and clans have certain weakness/specialty relationships.

I break down balancing according to slot composition (how powerful are the slots & what are my chances of getting them?), hp/atk/heal (how high are these values) and growth rates (not included in the scope of this piece, just mentioning it here for completeness.)

Returning to the previous tenet that choices must be CLEAR and CONCISE for the player, they have to assign some kind of role when they look at the monster, which encapsulates what that monster can do. Players then construct methods of play based on roles that work well together. For example, a Glass Cannon might benefit from having a Defensive Tank that has the Protect ability, because then the Defensive Tank will absorb damage aimed at the Glass Cannon. That is what we call ‘strategy’ — a very simple one, but a strategy nonetheless.

Quick note, this is what our battle screen looks like now:

Snap 2015-03-28 at 02.30.07

3on3 is now the norm.

Working with this in mind, this is how the ‘builds’ (the term used in my worksheet) are defined:


These are the Parent Builds, which control slot compositions. Attackers have 3 kinds of attacks available in their attack slots (slots 1-12, I’ve truncated it to spare your eyes). Supports have support slots EVEN in their attack slots that automatically replace depending on the situation). And Disruptors have a lot of slot types.


These are the build types. Notice that HP/ATK/HEAL are also normalized. Normalization means that duplicating values are placed in a separate table to be defined and referenced; that way, when a repeating value is changed, you only change ONE REFERENCE. What that means to say is that, by having only 1 column to reference, I can quickly change the ceiling, median and floor values. I hope that was clear.


Here are the current values for low, medium, and high.

If a battle is 3vs3, It takes 4-5 attacks to kill 1 monster; this translates to roughly 1-2 turns. With jackpot combinations, which is a mechanic that adds party damage for getting a three of a kind, the normal total duration of a 3vs3 battle  is around 4-5 turns. The complete battle cycle however allows for 6on6 — a much longer battle, which helps for strategy. Why is this so important?

Because turn length defines the pacing of the game.

You probably have some opinions on how the roles are defined: there may not be enough ‘definition’ between types, maybe, or they all look the same, or it is overwhelming.

It really is. But that is a problem for another day.

Moving on: with all that defined, you must be wondering, how do I automate the slot generator?

VBA Macro to the rescue!

Snap 2015-03-28 at 02.33.09

 I hope the programmers don’t see me programming. This is embarrassing.

Above is a tiny script that I am currently refining. Basically it accepts a range, and for each cell, gets the Build type, then references the ParentBuild from the Build sheet, then copies the slots and pastes them, then moves on to the next cell in the loop. There are some functions — getBuildSlots & copyPasteBuildSlots — that are not included in this shitty sample.

Also, you’re going to laugh, but this took me 2 days of breaking things to do. I haven’t coded in a very, very long time. For the record I was also coordinating my team! I was doing other stuff!

We’re almost done.

The slots that are copied can be seen in the first table up there (Parent Builds). They are not actually the slots of the game, but slot templates. See the table below if you’re not dead from all the lecturing:

Snap 2015-03-28 at 02.38.00

AOE means area of effect, in case you were wondering.

Anyway, hope you guys had fun with this post. I put a lot of effort into it!

A vlog with our changes is coming up next week. Apologies for the lateness of this one!

New Title Screen Art!

Hey Rollers!

For this week, we’ll be posting our studies and final output for the new title screen:


A bunch of studies for the title screen. We were pretty divided over what to show.

Eventually, we went with the 3rd study, because it focused on the more action-oriented aspect and highlighted the ‘arena’ where the battles occur.

Here’s the final product:



That’s it for this week. We’ve been busy revising the game post-GDC based on feedback. Hopefully we’ll have another one of those before/after posts soon!


Some new monsters

Hey rollers!

For this week, we’ll be showing some sample animations of new monsters:

Dancing Finnikit:



This guy is currently a support type Magma monster.


Helmish, the flying…fish:

This guy has the ability to remove status effects from the whole party. Two other wave types — Lectreel and Puffapy — inflict really annoying stuns and poisons. That’s where Helmish comes in handy!

An unimpressed Volcannon:


Volcannon’s special ability damages targets for up to 5 times its attack stat (depending on how lucky you are!)

Pyropup! He kinda looks like he’s playing baseball…


He’s a heavy attacker with high HP,  but Pyropup doesn’t have the best aim. He has a whopping three miss slots in his reel.

The updates this week are light, but next week we’ll be doing a lengthier piece on how we balance upwards of 20 monsters on an excel sheet.

We’ll see y’all next week! (And hopefully we’ve met some of you at GDC.)

This week on Monster Roller: Bugs and Revisions!

Hey rollers,

This week has been all about tightening the game to show it during GDC!

Part of being a developer means having an eye for improving things like usability. Most of it is a case of applying some common sense, while some of it is more subtle.

I’m pretty sure everyone here can see a few bugs in this screen below. Take a moment to guess:

(1) What the screen does

(2) What’s wrong with it





Continue reading This week on Monster Roller: Bugs and Revisions!