PROJECTS – EDUARDO LOZANO MUNERA

Designing progression systems

Most games run on game loops. They are repetitive processes that, when you do them, achieve a goal that can be also a part of a game loop in an upper level.

Game Loops exist because they drive incentives for a player to behave in certain ways, in order to create an experience. That is why we System Designers deal with them.

However, certain Game Loops can be used to drive a very special desire in a player: the desire to progress. This progress can mean a lot of things:

– Unlocking new content

– Unlocking new features, skills or abilities

– Performing better or more efficiently

– Discover more of the history, or the world of the game

– New game modes

And much more!

Pacing

When you create a Game Loop where progression is gradually delivered to the player after certain conditions are met, we create a pacing. The pacing will determine how patient, skillful, lucky, or a combination of all; a player has to be in order to get to the next step.

Naturally, our players will get better, accumulate more power and have more options the more of the game they already unlocked, so to keep the challenge interesting we also gradually increase the difficulty or cost of these conditions, thus pacing is usually incremental.

When you set what content is given based on the challenge level a player confronts, you are creating a Game Economy. In essence, this is at the heart of what Economy Designers do!

Level completed	Estimated Gold accumulated	Estimated characters unlocked
1	10	Character A
2	20 (+10)	Character A
3	35 (+15)	Character A
4	55 (+20)	Character A, Character B

Designing a Game Economy is not necessarily related to monetization. Any game where a player unlocks stuff as part of its Game Loops, will have to deal with Game Economy problems. Some games rely on them so much that they require Economy designers dedicated full-time to the multiple and subtle aspects of this.

Creating a progression isn’t easy. How do you know the progression is the right one for each player? After all, each player is different, has a different amount of skill, time to play, interests, and several other factors. What if the reward is awesome for a certain player but not appealing for another? How do you balance a certain piece of content so it is acceptable for a newcomer but not boring for a veteran? This is the bread and butter of Progression design.

Models

Progression systems are typically associated to spreadsheets. This is just one tool the designer has when designing a Progression system, and it might not be the best one at all times. We tend to use spreadsheets because it allows us to model a certain part of the game, but it is not the only tool we use!

In essence, a model is a tool for making predictions or testing hypotheses. Think of it like a “simulation toy” of a certain part of the game we are interested in tweaking.

So in the model we put an input and a configuration, and then we get an output. The model then tells us a lot of valuable information:

– It can indicate if our output is what we expected. Will a player in X situation do Y?

– It can indicate if our configuration will behave as we want. If the player does X how will react the game rules?

– It can validate behaviors or suggest tweaks to our rules. If I want outcome Y, what situation should the player be in?

Models are not always spreadsheets (though they are definitely helpful). A model can be a piece of scripting, an ingame tool, even the game itself (usually in some kind of “debug mode” for ease of usage). Each project is different, but conceptually, the idea is that the model will help us tweak the game immensely.

For a Game Designer creating a Progression system, being able to create and use Models is a very valuable skill.

Designing Combat Systems

Combat in video games is everywhere. It’s a recurring, essential element that fuels excitement and drives gameplay.

From sword fights to gun battles, combat is a pervasive theme. Sometimes it is the core of the game. Sometimes, it is just a facilitator or a simple resolution mechanism that is just a piece in the game loop.

However, one way or another, combat is in videogames almost since their conception.

I want to write some thoughts about combat in Action Games, which is a broad “meta” category. Fighting games, Action RPGs or FPS can be Action Games, and they all have their own particularities, but there are some core, underlying principles that we can reflect about.

What is combat (in an action game)

While there are wildly different implementations of combat systems out there, one that is clearly popular is the hitbox-based combat. And there are good reasons for it, even if a particular game tweaks or alters this system a lot.

Hitboxes

A hitbox is a region of an entity (usually a character) that is recognized by the combat system. Under the hood, it is the animation and/or physics system that moves the hitbox, but what is important for us is that hitboxes are regions of our space that are meant to hit or be hit.

They are purely an abstraction of real life physics: a projectile or the edge of a sword, while hitting, is bounded by a hitbox which represents the “region that inflicts damage” whereas the body of the character that is vulnerable to hits is also bounded by a hitbox that represents “the region that can receive damage”.

It will get more convoluted but these are the basics you can find in most action combat systems. Hitboxes that can inflict damage, and hitboxes that can receive damage (hurtboxes).

The fundamentals of combat are deceptively simple: to put your damage hitbox in the hurtbox of the opponent.

Then we build from there.

Shape, range, delivery and effect

There are four major aspects you can tweak when you are designing the hitboxes of your combat system. By combining these properties in creative ways you can create a wide range of hitboxes that your character can use.

Shape

Shape is the geometry of the space region of the hitbox. Round hitboxes, single dots, long hitboxes or conic ones.
A blade weapon can have a huge edge, whereas a shotgun-type attack may shoot multiple tiny hitboxes in a chaotic dispersion.

Range

Range is closely related to Shape as both define what space is affected by the hitbox. Range is how far the hitbox travels (if it does), but also how many enemy affects (think Area of Effect attacks), etc. It can also include aids like autoaim and many other tweaks.

Delivery

Delivery refers to how the hitbox appears and extinguishes. For example, many hitboxes have a casting time (which has to be telegraphed for good player feedback), they can also have a cooldown, etc.
Delivery will make a hitbox fast to use, slow, make it sloppy or very precise, etc.

Effects

This term encompasses the system properties the hitbox has when hitting entities. The most basic of all is the damage inflicted, but you can have different effects: ailment statuses, special hitbox properties like ignore obstacles, or hitstun the opponent.

Rules define the experience

System Designers love this saying. The point is, the goal of rules is to incentivize certain thinking and actions in the player, so in turn it creates an experience.

For example, a very lenient combat system where hitboxes can be hit easily and the player has a lot of margin for error will create a more leisure pacing and thus you can, if so you wish, expand on other aspects of the experience like very long, spectacular animations (Kingdom Hearts, Devil May Cry).

On the opposite, if you focus on very punishing and strict rules for your usage of hitboxes, your are emphasizing focus, attention to detail and a huge importance in the environment or your own resources (Elder Ring, Ninja Gaiden).

There are no universal rules for this, because this aspect is tied to the vision of the game. However, for the same reasons, it is paramount that this vision is clear and the team understands it well in all departments.

For example, a fighting game must have very finetuned hitboxes and character animations as this is a genre where the animations define in no small part the shape, range and delivery of the hitboxes. Thus, the Animation and Technology departments must work together with the Game Designers to ensure the tools allow for this and art direction fits the gameplay. Producers must be very aware of this to ensure they don’t work independently and then collide on goals later.

This is in part what a clear vision ensures.

Maai and combat balance

I love practicing martial arts. It was surprising to find some of its concepts where useful later on when designing Combat systems.

In particular, I want to talk about Maai. Maai is a concept, in martial arts, which vaguely means “distance between opponents”, but it is much more. It also includes the time required to cover that distance and the angles and rhythm of attack. Collectively, these elements determine the exact position from which one opponent can effectively strike the other.

A character with a long range weapon has a longer Maai than a character with a shorter weapon… unless the shorter weapon is somehow faster, which can restore both combatants’ Maai to a tie. You get the idea.

The core idea here is, that balancing a combat system is a very dynamic and creative process, which is awesome but also makes it very feel-dependent. So you need both tools and testing to help your design, no matter how cool it is on paper.

On the opposite side, you need the “paper” vision, this is, you need to know what you are trying to achieve when balancing any game system, or you won’t be able to define clear success criteria of how your game is supposed to feel like (it seems obvious, but I have seen it forgotten more than a couple times!). It’s counterproductive to spend hundreds of hours balancing a game until it feels good without having a prior establishment on what this “feels good” is like. And defining that isn’t easy either!

A robust process

Game Design is a very iterative process, but this is sometimes used as an excuse to skip on a clear, solid plan that could solve production issues and reduce uncertainties. Think twice before simply jumping to parameter-tweaking!

Vision

What is the experience you want to arrive to.

A rogue character who feels cunning, weak but fast and lethal, and makes you feel like you must take advantage and exploit the enemy's weak points, but if succesful, can win the fight fast.

Pillars

Success criteria that the final design has to comply with.
Weak to attacks.Fast attacks.Can't sustain face-to-face combat for long.
Very lethal when surprising the enemy or attacking it vulnerable.

Proposal

A particular idea which complies with the pillars.

A set of fast but weak attacks. Low HP, High Attack stats.
A unique mechanic to make enemies fumble, and another which inflicts critical strikes on foes in the ground.

Validation

Ensure the proposal fits.

Prototype, playtest and ensure the rest of the game is in order when this proposal is accepted. No obvious exploits or superior strategies disrupt the core loop nor the overall experience. It feels good to play. Nothing breaks.