Anyway, YouTuber and Twitterer (Tweeter?) @xtomass recently uploaded a video of his play-through of version 0.0.6 of Slay the Beast and I would be remiss not to share it.

So, enjoy!

As proof, here’s a (very) early work-in-progress screenshot of my current indie game project, Slay the Beast:

Slay the Beast is a versus fighting game where one player controls a huge boss-level monster. While the other player controls a puny (but respawning) hero. The sprites are from Oryx Design Lab‘s Hifi Gothic Set and animation is done with Spine, from Esoteric Software.

The game is still at an early stage of development. Heck, I just started this project a few weeks ago! However, I plan on making WIP builds available soon. Stay tuned for more news.

EDIT:
Here are some more screenshots for your viewing pleasure:

And one more for people who’d like to see how characters look in-editor:

While this sort of escalation is the kind of situation you want to avoid in real life, it is a powerful tool in game design. As a matter of fact, you can find some element of escalation in almost any game worth playing.

At its most basic level, escalation in games is about raising stakes. This is distinct from a game’s difficulty rising simply from, say increasing numbers of stronger and stronger enemies though that is a part of a game’s escalation. It’s usually as it progresses that a game gives the player the opportunity to use the biggest, most gratifying tools it has to offer while presenting the player with the largest, most impressive challenges it can muster. Thus, the game escalates as everything gets bigger and louder. Similarly, while a player’s ability to avoid damage may improve as they become more skilled, enemy attacks may become more instantly lethal as a game progresses thus rendering each dodge the player executes more significant, escalating the stakes of the game’s risk-reward equation.

Escalation can also work wonders in player versus player scenarios. One of my favorite examples of a clear escalation mechanic is the mana system from Magic: The Gathering. In Magic, each player can lay one Land card per turn. These lands can then be used (called being “tapped”) once a turn to produce a point of mana needed for casting spells. At the beginning of each turn, the player can refresh their previously tapped lands as well as lay another land card. In this way, each players’ available bank of mana increases by a point every turn with every point of mana widening the range of spell combinations the player can execute.

This slow build-up of power is key to how Magic is able to function so well as a game. By starting the power scale low and then slowly building it up, the game creates an ecosystem where low-cost cards are more valuable than higher-cost cards at the beginning of a match but where the relative value of low-cost versus high-cost cards reverses as the match progresses. This ensures that a wider range of cards are relevant to the game than would have been the case if players started each match with a full store of mana.

Mana escalation in Magic is also useful in keeping matches exciting. Higher mana pools allow players to play high-cost combinations of cards that are more likely to be game changers allowing a losing player to turn-the-tables of a match. This makes it less likely for one player to dominate a match from beginning to end, allowing both players to be fully engaged in the game. In essence, moves made at the end of a match matter more than the moves made earlier in a match by the nature of the sheer power level of the abilities available towards the end of a match.

For more escalation in practice, you can read this article on the design of the Penny Arcade collectible ping-pong card game Paint the Line. This game actually has a literal Escalation Deck that the designers used to provide their game with forward momentum.

So, that’s escalation in a nutshell. As a game progresses, player stakes go up, lending greater importance to their actions. This can help players stay engaged with a game by allowing for comebacks at later stages of play. It can also serve as a throttle to allow for a wider range of abilities to be relevant to the way the game as played.

I think one of the definitions offered by the Merriam-Webster dictionary provides a clear picture of how this word applies to game design:

a balance maintained in an artistic work between opposing forces or elements

Civilization and Pirates! creator Sid Meier famously stated that “games are a series of interesting decisions.” To me, “interesting” is a particularly important word in that phrase. Any choice presented to the player can be considered a decision, but unless that decision is actually “interesting”, the decision does nothing to actually make the game more fun. Tension is a useful tool for making sure that the choices in your game are actually interesting.

In the context of games, you can create tension by giving the player multiple opposing goals. Successfully implemented, this will mean that your player will have to continuously choose between two or more actions each in service to a different goal. Pulling an example from Super Mario Bros., consider the interplay between the jumping obstacle-avoidance gameplay versus the time-limit applied to each stage. These systems represent two separate goals that encourage different behavior: moving carefully to avoid obstacles & moving quickly to reach the stage’s end before time runs out.

It’s important to note how the time-limit is balanced so as not to be overwhelmingly severe. At the start of a stage, the player rarely has to pay attention to the time-limit because there’s usually more than enough time to complete a stage if they proceed at a reasonable rate. This is good because the player often needs to concentrate on understanding whatever unique challenges or gimmicks the stage is presenting. That being said, the time-limit is not set so high so as to be irrelevant. It is set to be enough to enforce a certain level of risk-taking by the player and prevent too-slow, overly conservative gameplay (which will probably be dull for the player.) The time-limit later becomes a factor towards the end of a level with a chime and sped-up music informing the player that they need to hustle. At this point, the player has acclimated to the stage’s particular challenges so they are able to make an informed choice regarding how much faster they can go without taking on too much additional risk.

Similarly, I intentionally use this sort of tension in my February #OneGameAMonth entry. While the player must keep their ship out of the line-of-fire of their enemies, the only way to target the enemies is to pass through their firing lines. This way, the player can’t win by simply avoiding fire, they must gauge when it’s safe to expose themselves to enemy attack in order to get their own attacks in. Even Robot Legions uses the tried-and-true system of having defeated enemies drop collectibles. While defeating an enemy and moving on is the safest strategy, the collectibles tempt the player to linger in a spot where other enemies are likely to converge.

Tension is about the energy that results from pulling something in opposite directions. This energy is part of what makes a lot of games fun. If there is only one optimal choice or if all player choices are complimentary this reduces the tension of that decision. Tension is about making sure a player’s choices matter so the resulting game matters to the player.

The basic principle here is that, in games, the level of reward provided by an action should match the level of risk it entails. Low-risk behavior should generally provide low rewards. A highly rewarding action (say a high-damage attack or a high-value treasure) should require a commiserate level of risk otherwise players will never have a reason to choose a lower-reward alternative.

Using Risk-Reward as a lens, you can see this relationship at various levels of game design, from weapon balance to level design. Consider the classic relationship between light attacks and fierce attacks in the Street Fighter series. Fierce attacks do significantly more damage on a hit but, due to their long recovery animations, leave the player vulnerable if they miss. On the other hand, light attacks do little damage on a successful hit but provide a nearly non-existent window for counter-attack should they miss.

You can also see Risk-Reward at work in level design in the Mario series. A particularly clear example of this how red coins are used in Super Mario 64. In every level, there are 8 red coins that the player could collect for an extra star (the reach goal of the game being to collect all 120 stars). Red coins are often placed near the main course of a stage but in locations that are harder to reach than normal, say a small platform that the player would need to jump carefully in order to reach. Here, the player is presented with a choice: risk losing a life to get the red coin or play it safe and give up on collecting all 8 red coins and earning an extra star.

A key in the red coin example is that the reward has to be significant enough to justify the risk while not being absolutely vital to proceeding in the game. Had the red coins been required to finish the game, precariously placed red coins would have gone from being an optional risk to being a difficulty spike that could cause players to quit the game out of frustration. Nowadays, it’s almost a given that players expect to be able to finish any game they play. This doesn’t mean that they expect to clear every possible challenge a game presents, just that they can beat it at a “normal” level of difficulty. What this implies that clearing a game does not present a significant enough of a reward to justify higher-than-normal risk. This isn’t to say that a game has to be easy, it’s that the difficulty of required actions shouldn’t deviate too far from the average difficulty of the game at that point. Applied to Risk-Reward this suggests that risk of a particular action should be calculated relative to the risk of other actions available at the same time.

Risk-Reward is a powerful tool for evaluating game design and can be useful when trying to balance various game features. When considering a new feature for a game, I’ve found it useful analyze it from the perspective of Risk-Reward to determine how best to use the feature (or if I should even use it at all.)

#OneGameAMonth

One Game a Month. That’s twelve games in a year. Considering that I struggled to launch two games last year (Michelangelo and Robot Legions, $1 a piece if you’re interested), this seems like a pretty tall order. And you know what, it is. But, I’m going to try and see how far I get.

One Game A Month is a motivational promotion being run by @McFunkypants. As the name suggests, the goal is to make a game every month. There are over 2000 developers signed-up who are ready to encourage each other to make games. As a nice touch, the One Game A Month site has implemented a suite of typical gamification features: experience points for making games, leveling-up profiles, and achievements.

On one hand, it’s silly. On the other, it’s also hugely motivating. If you’re a game dev looking for a challenge, this may be the one for you. If you need some more convincing, how about listening to @McFunkypant’s One Game A Month keynote speech:

In this article, I’d like to present a few of the game design guidelines that I’ve found useful in my work. Again, they aren’t absolute rules but they are a great way to sanity check game designs to make sure you’re heading in the right direction.

The Rule of Three
This is the big classic of game design. Originally stemming from a guideline in writing, this idea claims that almost anything you create will be most satisfying when presented in threes.

In games, its application is probably most visible in games attributed to Shigeru Miyamoto. Look anywhere in a Mario or a Zelda and you’re likely to see the Rule of Three show up. Numbers of lives or hearts, hits needed to defeat a boss, the strength ratio between the weakest and strongest enemy in a species (think Moblins). The Rule of Three is everywhere.

In writing, the Rule of Three presents a structure for creating tension, building it up, and then releasing it. In games, this pattern maps well to teaching mechanics to the player. The first hit the player scores on the boss teaches them how to damage them, the second hit reinforces the lesson and establishes that the first hit wasn’t an accident, the third hit represents mastery and anything after that becomes rote repetition. This suggests that, after that third hit, you need to either kill the boss, have the boss change behavior or make sure hitting it is so much fun that the player doesn’t mind repeating it over-and-over again.

If the Player Doesn’t See It, It Doesn’t Exist
This may seem obvious at first glance, but you may be surprised at how easy it is to forget about this during the heat of game development. I’ve seen more than a few perfectly good ideas fall flat because not enough through was given as to how to present the information to the player.

Game logic that exists mostly “under-the-hood” or hidden in complicated equations might as well not exist for most players. Unless these elements are presented to the player in some way that makes sense to them, they are not going to be able to use that information to inform their play which renders the system inert. For example, if you were to have damage in a role-playing game vary depending on how an attacker’s element relates to a defender’s element, you would need to clearly indicate the attacker’s and the defender’s element as well as the relationship between them to the player (most likely through on-screen icons or character design and a tutorial.) Without this information being relayed to them, most players would never realize how elements affect the game and their influence on damage might as well be random. Which brings me to the next point…

KISS
Ah yes, “Keep it Simple Stupid”. This is a good guideline for almost any design or technical discipline, not just games. Basically, don’t make your systems more complicated than they absolutely need to be. If a system is so complex that a player can’t easily predict how it will behave given reasonable inputs, it might as well be random.

If your scoring system is too complex, players won’t know what they need to do to increase their score and will be less motivated to even try. Similarly, if you have a scoring system with multiple elements that is dominated by only a few factors, you’re probably better off cutting out the lesser elements since they do nothing but cloud the system and make it harder to debug. For example, it would probably not be worth counting kills in a Capture-the-Flag game where each kill was worth a point, but each flag capture was worth 100 points. Unless, of course, you had the game tuned just so that there were A LOT of kills relative to flag captures.

This isn’t to say that games shouldn’t be complex, but it is a matter of what creates that complexity. Complexity should result from the combination of rules, not from the rules themselves. Consider almost any card in Magic: the Gathering. Individual cards have very simple rules and clear-cut effects. It’s the combination of them creates the complexity of the game. Indeed, the reason the game works so well, in my opinion, stems from how well players are able to predict the effect multiple combinations of cards will have on the game and thus have a reasonable (though not absolute) ability to guess how an opponent may respond.

Game design is a wide-open field without a whole lot of rules one absolutely has to follow. That being said, it can be hard to find your way around without some sort of structure to help you along the way. Tips like the ones above can be helpful when you need that little extra nudge to get your game designs back on track.

Recently, while reading some game dev books, I ran across a bit of advice with sentiments similar to one of my previous blog posts. The text in question is from “Shooting Game Algorithm Maniacs”, a Japanese game dev book focussing on SHMUPS (shoot-em-ups).

For folks who may not be able to read Japanese, here is my translation of the advice from the conclusion of Chapter 2 (called “Stage 2″ in the book.):

If you’ve ever thought “I want to make a SHUMP!” and you don’t mind a good bullet-hell shooter, I recommend starting by programming the bullets. The reason for this is that, no matter how many “awesome effects”, “giant bosses”, or “cool weapons” you have, these things do not make a game.

Even without effects, bosses, and weapons, as long as you have bullets, you have a game. (Well, you need the player’s ship as well, of course.) You don’t have to be able to draw. If all you need are a bullet image and a ship image, you can easily ask an artistically-inclined friend. If you don’t want to ask a friend for help or draw anything yourself, you can still get by with circles for bullets and a triangle for the player’s ship. There are some free games that take this approach. As long as the game is good, it will be fun even if all the graphics are circles and triangles. Of course, having only circles and triangles for graphics probably won’t help your game sell that well…

Anyway, that’s the point of this chapter (Stage 2): “If you want to make a SHMUP, start with the bullets!”

The author emphasizes that the relationship between the player and bullets is the core of the SHMUP experience, especially for those of the bullet-hell variety. If this core relationship is well put-together, it will be be fun in and of itself. Everything else in the game (all the weapons, special abilities, unique bosses, etc.) becomes about emphasizing and complimenting the core.

This is a mindset that I think can be applied to many game genres, not just SHMUPS.

For reference, the original Japanese text follows. If you’re at all interested in creating SHMUPS, I highly recommend picking up a copy of “Shooting Game Algorithm Maniacs” (original edition / new printing). With copious code samples, it’s understandable even without a whole lot of Japanese knowledge.

「シューティングゲームを作ろう！」と思い立って、もし弾幕が嫌いでなかったら、まずは弾のプログラミングから始めることをお勧めします。というのは、いざシューティングゲームを作ろうと思って、「凝った演出」や「巨大ボスキャラ」や「派手でカッコいい武器」を作ったとしても、それだけではゲームとして成立しにくいからです。
演出やボスキャラや武器が何もなくても、弾さえあれば何とかゲームになります（さすがに自機は必要ですが）。絵が描けなくても何も問題はありません。「弾の絵」と「自機の絵」くらいなら、絵を描くのが好きな友達に頼めば描いてくれるでしょう。自分で描くのも友達に頼むのもめんどうならば、弾は●（マル）、自機は▲（サンカク）というのでもかまわないでしょう。実際、フリーソフトウェアはそういったゲームも見かけますし、ゲーム性が練れているものは絵が●や▲でも面白いものです。商用で絵が●や▲だけのゲームが一般受けするかどうかはまた別の話ですが。。。
というわけで、「シューティングを作るときには、まず弾から作れ！」というのがStage 2のまとめです。

In terms of handling multiplayer from a game design perspective, there are several issues that tend to slip through the cracks until they show up during actual implementation. In large teams, the late discovery of these issues can cause disproportionate amounts of time being spent to fix them as they wind their way from the discover’s desk to the people responsible for game design decisions and back to the feature implementor.

So, in an effort to nip that sort of game development waste in the bud, here is a short list of common multiplayer oversights that I’ve seen crop up in the wild.

Whose Save Data is This Anyway?
In the past, most multiplayer modes had very little in the way of persistent data. Let alone data that may be saved per user. Nowadays, with player profiles and the like, it’s quite likely for each player in the game to have their own save data. While it makes sense in terms of having each player save their own play records, things can get messy when we start talking about unlockable characters, options, and levels. Should multiple players be able to select from a union of characters unlocked by all the players? Should players only be able to select characters they themselves have unlocked? The best answers to these questions vary by the kind of game and have significant effects on the core design of menu UI.

In terms of playable levels, one must think about how a player’s progression data is handled. Will a player be able to unlock levels by playing multiplayer? What happens if they unlock levels out-of-order by playing with someone who has progressed further in the game? This is one of the reasons that games with co-op campaigns tend of have player 2 as a sort of guest participant in player 1’s host game (and save data). While player 2 may save some statistical data, the main progress data remains wedded to player 1.

Whose Story is This Anyway?
In games with a significant story element, handling of extra players in cutscenes can be a major issue. Because of the significant costs involved in creating cutscenes that could handle a variable number of stars (or co-stars), it’s common for the cutscenes to simply focus on the main (player 1’s) character while player 2’s character simply shows up in the background (if at all.) Another common approach is to have player 2 take control of a normally AI-controlled character. This allows the “buddy” character to be available story-wise while also providing a vessel for player 2 to participate should they want to play.

Whose Menu is This Anyway?
Castle Crashers is not a good party game. Not if you have a mix of gamers and non-gamers anway. The main reason I say this is because of the map menu. Basically, because everyone could control the map simultaneously, we could never select the stage we wanted because someone was always fiddling with their controller for some reason or another. Someone might be moving the thumbstick idly while someone else is trying to select a stage. In the meantime someone else was always trying to compensate for stray inputs, further complicating the mess. Eventually, one of us had to yell out and tell everyone else to not touch their controllers while they selected a stage. The end result: the non-gamers were too intimidated to touch their controllers while the gamers would occasionally try to override each other’s level decision.

Seemingly in an attempt to be “fair” to all players involved, Castle Crashers allowed them all to control the level select menu simultaneously. Unfortunately, this led to the above result. This is why most fighting games arbitrarily choose one player to pick the arena backgrounds during Versus mode. You want to the players to squabble over who is the better fighter, not over what the next stage should be. In the case of Castle Crashers, some explicit decision as to who would control the level map (essentially, a party leader) would have gone a long way to smooth the multiplayer experience with any disagreements about level choice ultimately being filtered through a human arbiter before being chosen in the game.

Multiplayer gaming is great, especially the local, on-the-couch kind. That being said, it can bring along with it a lot of seemingly minor issues that can deeply affect the core experience of a game. With a little bit of forethought, it’s possible to address these issues before encountering them during implementation. In a project with any sort of significant budget on the line, this sort of forethought is crucial.

The classic SHMUP (shoot-em-up) may be one of the purest video game designs out there. Even for games like Ikaruga that implement systems that dramatically change the gameplay, the core mechanic stays essentially the same: the player must destroy enemies while dodging loads and loads of bullets.

Given the significance of the relationship between the player and enemy bullets, the design of said bullets is crucial to making a SHMUP work. The following is a series of guidelines that I use when implementing enemy projectiles in games.

Enemy projectiles should be… Bright
Because a SHMUP requires a player to be keenly aware of where enemy bullets are located, they must stand-out from the rest of the graphics in the game. As a result, such projectiles are usually brightly colored. Some games go so far as to make them flash different colors in order to make them more easily noticeable. Enemy projectiles are one of the few cases where it may be advisable to ignore the color palette of the rest of the game and purposefully render them with conflicting colors.

In terms of draw order, enemy projectiles should also occupy a rank commiserate with their importance to the player. What this works out to is that enemy projectiles should generally be rendered on top of most other objects in the game. The last thing you would want is to have bullets hiding behind power-ups leading to unfair player deaths.

Enemy projectiles should be… Slow
At first glance, it might make sense to have player and enemy projectiles travel at the same speed. While that symmetry may seem attractive, it ignores the differing purposes served by player projectiles and enemy projectiles. Mainly, player projectiles are meant to hit enemies while enemy projectiles are meant to be dodged. Player projectiles need to be fast so that they hit enemies effectively and enemy projectiles need to be slow so that the player can avoid them.

I learned this lesson the first time I tried making a SHMUP. I started out with both player and enemy projectiles having similar speeds. As a result, enemy projectiles were so fast that I rarely had a chance to avoid them once they fired. The only way to avoid damage was to destroy enemies before they fired. One day, I tried halving the speed of enemy projectiles. The game immediately changed. Instead of try to destroy enemies just as they came on the screen, I was weaving around fields of projectiles to get good shots on enemies. And it was a whole lot more fun that way.

Enemy projectiles should be… Deadly
This may seem like a no-brainer, but I can’t understate how important it is for collisions between players and enemy bullets to be a significant event. In games with one-hit death, this condition is cleared because the loss of a life provides a clear enough sense of consequence.

Games where the player can take multiple hits need to provide a lot of feedback to make collision with enemy projectiles a suitably jarring experience. U.N. Squadron does a great job of this by having alarms go off when the player is hit as well as putting the player in a temporarily vulnerable state where one more hit will instantly finish them off. Sine Mora also does this well by having the player’s accumulated power-ups fly out thereby forcing the player to drop what they were doing and concentrate on recollecting power-ups.

Enemy bullets are key to making a SHMUP fun. If you ever find yourself building one, remember: enemy projectiles should be Bright, Slow, and Deadly.