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:
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!