Mixed bag of updates this week. I’ll be going over them in more detail in the weeks to come.
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.
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.
New 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’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
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.
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.
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.
Meet us at the Global Mobile Game Congress at the China National Convention Center in Beijing on April 24 to 25 and check out our latest demo for Monster Roller!
Contact us at bizdev[at]boomzap.com to schedule a meeting!
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):
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:
Hope you guys enjoyed this short post on animation. Stay tuned next week for more.
This video outlines the changes that we’ve been working on:
- We build 3 builds every evening (Android, IOS, PC build)
- We’ve changed the UI (flow, skin)
- We’ve added way more slots and monsters
- We have a team builder feature now
- Battles are 3vs3
- Battle flow has changed
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:
You: Okayy… this is kind of intense.
You: So this is kind of awesome, but the writer hasn’t exactly provided context.You: 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:
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!
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:
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!
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!
For this week, we’ll be showing some sample animations of new monsters:
This guy is currently a support type Magma monster.
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.)
We’ll be showing our latest demo!
P.S. This dude is Christopher Natsuume, Creative Director of Boomzap. Contact us at bizdev[at]boomzap.com to schedule a meeting!