Showing posts with label game design. Show all posts
Showing posts with label game design. Show all posts

Sunday, 21 February 2021

Blightbound's approach to individual storytelling in a coop game

An interesting design challenge during development of Blightbound was how to combine personal storytelling with coop gameplay. In Blightbound three players play together, but they might be at different spots in the stories of their respective characters. How to make room for storytelling without spoiling stories for other players who might not be there yet, and without making players wait for each other? Today I’d like to dissect the approach we’ve used to solve this problem.

Before I continue, note that this blogpost will spoil some story moments. However, I’ve made sure to only take examples from early in each character’s story, so the videos in this post will only be a minor spoiler to the game.

Blightbound is a coop dungeon crawler, but unlike games like Diablo it doesn’t have a linear campaign. Instead, the player repeatedly plays a number of dungeons while learning each character’s story and gathering loot and more characters. In that sense it’s structured more like the end-game of Diablo, or like a looter shooter.


Blightbound is a 3 player game, with both online and local coop.

Another important aspect of Blightbound is that it has a lot of heroes. Instead of maxing out one hero for dozens of hours, the player gets to unlock a bunch and is invited to try them all. We would like players to vary what character they play. For this reason we wanted to tell a lot of small stories, interweaved with gameplay, instead of telling one big story. Each character has their own little story they go through.

Each hero in Blightbound has an individual story that’s told through the dungeon runs with that character. When 3 players play together, they each play a different character so they’re supposed to get different stories. This is where the issues that I’m discussing today arise. Players shouldn’t see the stories that the other players are getting, because they might not have progressed to that point with that character yet (spoilers!), or might have seen that bit already. Also, Blightbound is a fast-paced game so we don’t want players waiting for each other’s cutscenes.

The solution we came up with is that the storytelling is entirely private. When one player gets a bit of story for their character, other players don’t notice this at all. They might even simultaneously be getting different stories for different characters!

Now how do we make that work without letting players wait for an invisible cutscene? The simplest solution is used a lot in Blightbound: dialogue while gameplay continues. The player gets served portraits, speech bubbles and voice acting while the gameplay continues. So there’s no need to stand still and watch a cutscene.


Two examples of basic story beats during gameplay.

This does introduce a problem: getting extensive dialogue during combat is going to be very distracting and the player likely won’t be able to follow the text while focussing on the fight. Luckily, we needed some pacing anyway. A dungeon that’s 15 minutes of constant combat is both too intense and boring. So we should introduce some quieter moments anyway, and we make dialogue happen during such moments as much as possible. This way players can keep exploring but also have the mindspace to digest the storytelling.

If the player keeps moving, who is that dialogue with then? Here we’ve tried to vary it as much as possible. The simplest ‘dialogues’ are inner monologues of the hero. In other cases there’s a dialogue with an an NPC who’s standing in the level. Here too the other players can’t see this non-player character. To avoid waiting, the player can just keep walking: the dialogue starts when interacting with the NPC, but after that the player can run away and the dialogue will continue.


Gameplay continues during dialogues, so teammates don't have to wait for you.

To spice things up, we’ve added a fun trick here. The player is playing with two others who are random other heroes. To make the dialogues more dynamic, these other heroes will actually respond to it. But 21 characters all responding to all the story moments of all 21 other characters is way too many combinations. So instead we’ve defined a bunch of standard responses that each character has unique versions of. These are referred to in the dialogue scripts and then inserted dynamically during gameplay.

We have a total of 11 types of such standard responses and each character has their own line for each type. This way the responses can fit their personality. For example, these three lines show how different characters fill in the symphathy response:

  • "I feel your pain."
  • "You have the clan's sympathy."
  • "Would a moisturizing salve help?" (lol wut)


All eleven types of responses for one of the playable heroes.

What we have so far is cool, but still rather basic: all storytelling is done through dialogues and monologues and that’s it. From there we’ve looked into how we could spice things up without adding pauses. We should also not introduce too much work: Blightbound has more than 100 such story moments so efficiency is important.

The first element that adds some variation is how story beats are triggered. In some cases it’s simple: enter an area that’s marked and the storytelling starts. Some story events can trigger in any such area, while others need to take place in specific dungeons since they’re linked to that setting.

The more interesting ones require some form of interaction. For example, the mage Korrus looks for vases to investigate, so you need to spot them and interact with them. Other characters see someone standing in the dungeon and need to interact with the character, or see a hallucination. When there’s a hallucination hanging in the level, it’s only visible to the player who’s story beat this is for. To their teammates, it’s just a regular spot in a dungeon. Again we’ve made sure that we only use short and simple interactions, so that your teammates don’t need to wait for you.

One of the more fun types of story events are elite enemies. Some heroes need to fight specific characters to progress their story. To make this work, we’ve made special elite versions of some enemies that only trigger as part of someone’s story. The party of 3 players fight the elite enemy together. The nice thing here is that to your teammates, it’s just another elite enemy with some special skills (we have plenty of those outside story moments as well), while to you this specific enemy is a story moment and triggers dialogue. So this is a coop battle that is also a single player story moment. Quit neat, I think!


An example of a story beat in which we encounter an elite enemy.

Unlocking new heroes to play is a big part of Blightbound’s progression system. Here too a goal was to add some variation. Many heroes are simply found and rescued from a dungeon, but some others can only be unlocked by paying the merchant, by making your village prosper, or by finishing the story of another character.

For the simplest case, where a hero is rescued from a dungeon, we again ran into the problem of this being a coop game. My teammate might already have saved the hero that I’m rescuing, how does that work? To solve this problem, we’ve introduced the concept of survivors. These are basic characters that you can’t play. When you rescue a survivor, you get a little prosperity bonus to your village and that’s it. Now whenever one player is unlocking a hero by rescuing them in a dungeon, the other players see this as rescuing a generic survivor. This way it never looks like a teammate is reviving thin air: there’s always someone lying on the ground, ready to be saved. It might just happen to be a different character for each player.


Unlocking a hero compared to rescuing an anymous survivor.

One more nice trick that I would like to mention is one that we’ve so far unfortunately not finished implementing (Blightbound is still in Early Access on Steam). Since levels have these areas that are ideal for triggering story beats (no combat, some space for exploration), it would be nice to do something with that even when there’s no story beat for your specific character triggering in that run. So Roderick (the writer on Blightbound) has written a bunch of dialogues and banter that add some world building and personality building, but aren’t tied to any moment in the story. This way we can always trigger something. Since this is really a non-essential bonus feature we haven’t gotten around to actually implementing these lines yet, but I really like this feature so I can only hope that we’ll find the time to add this at some point.

Before concluding this blogpost I’d like to also have a short look at the implementation. With 21 heroes all having story moments and shouts and banter, Blightbound has a LOT of voice lines. There are more than 100 story events and over 6,000 voice files, ranging from short barks to several sentences. Working efficiently with such large volumes requires some proper tools, so Ronimo programmer Jeroen Stout (known for having made Dinner Date before joining Ronimo) implemented a system he calls Voice-A-Tron.

Voice-A-Tron was tailor-made for Blightbound and it’s a very neat tool that provides a bunch of features, including:

  • A spreadsheet that automatically presents all lines in two formats: per character and as it appears in dialogue (so alternating between lines of different characters).
  • Some simple scripting rules that allow defining dialogues, what portrait to use, where to trigger context-sensitive responses, triggering animations and even triggering related achievements and unlocks.
  • A system that automatically executes these scripts in-game, so that our game designers need to do less work to implement story beats.
  • Special objects that can be placed in levels to control where and when story beats are triggered.

Using Jeroen’s Voice-A-Tron system, Roderick Leeuwenhart wrote and defined all the story beats. Roderick is the writer for all Blightbound dialogues, as well as a series of short stories set in the Blightbound universe. The next step was that Ronimo game designer Thomas van der Klis did the actual implementation, for example defining where story events can trigger and creating special items and elite enemies.

The result of all this work is that in Blightbound, each character has their own story beats and these are told without interrupting the flow of gameplay and without spoiling teammates. At the same time the system is simple enough that it was doable to implement for all 21 heroes in Blightbound. While Blightbound isn't a storytelling game at its core, I feel this adds a lot of personality and purpose to the experience.

Monday, 7 September 2020

The games that inspired me most

A few years ago I was asked by a videogame magazine what games inspired me most. I had a lot of fun compiling a short list for them. Today I've updated that list. These aren't necessarily my favourite games (although they're close): Doom II isn't on this list for example. I'm going to focus not on why I had fun with a game, but why it inspired me, how it taught me something new. They all have some unique aspects that changed how I look at games and game development.

Command & Conquer

As a kid I was so much a fan of Command & Conquer that I even rebuilt some of its units with Lego. I started playing around with 3D computer graphics when I was only 13 years old and C&C was my big inspiration. I wanted to make 3D as awesome as in the cut-scenes for this game. Especially the video where a flame tank drives into a town and torches everything is still vividly in my mind. Many of the game designs that I wrote down on paper at this age were for RTS games inspired by C&C. 



Star Control II

This is easily my favourite game of all time. Great music, crazy humour, fun combat and a rich universe with deep backstories and tons of personality. What is most special though is that this is one of the few games I know where information and exploration are intertwined so strongly. Everything is there at the start of the game, but the universe is way too big to find things without knowing the coordinates of interesting planets. Gathering information and even buying it is a key feature here. In combination with the lack of invisible walls this makes exploration extremely rewarding and quite different from most open world games.


An interesting aside is that in the newly released Star Control: Origins (which I really like, by the way) some players complain about the universe being so empty that grinding through planets is boring. The problem here is that modern players have been taught that it's useful to randomly wander around the world, because most open world games these days make sure there are interesting things everywhere. That's fun of course, but that means that in a game like Fallout information isn't very important: by randomly walking around you'll likely find everything (although that does cost a lot of time). Star Control's exploration is totally different because the universe is so much bigger. I think the problem in Star Control: Origins is purely expectations: it isn't clearly communicated to players that this game is different.

Another aspect of Star Control II that has greatly influenced me is the music. Each alien race you encounter has a theme song that captures the personality of that race. Music in many games (as well as movies) mostly serves to set the mood and influence the viewers emotions. But I like music that takes the foreground and really adds to the personality of the game. Inspired by the alien themes from Star Control II, I pushed for having character theme songs in our game Awesomenauts as well. This resulted in Sonic Picnic making an amazingly diverse soundtrack for Awesomenauts, adding tons of personality.

Bioshock

In most games the story and the gameplay are told intertwined but are not truly related. Not in Bioshock: here the gameplay and the story revolve around a common theme. Both add meaningful insights to the concepts of freedom and choice that are explored. Bioshock is not just a marvellously fun game; it also made me ponder the philosophical themes it explores. Especially the twist halfway the game felt incredibly smart and exciting. I felt like I had personally fallen victim to exactly what had happened to the character in-game. One of the few games with true philosophical depth.


World of Goo

World of Goo is the ultimate example of how much creativity is needed to extend a simple and original concept to a full game. It seems to me like many of the participants of gamejams think that coming up with something original is the highest goal in game design. But much more difficult is to develop that original concept from a gimmick into a full game. World of Goo started out as a gimmicky mini-game and ended up as a glorious game. It adds enormous diversity and depth without adding a lot of features or complexity. This is true mastery of game design.


Deus Ex

The original Deus Ex is a great game in general and the combination of RPG + FPS is pure gold for my taste in games. However, the most unique thing in this game to me is the ending. Usually when games have different endings, they are very black-and-white. There are the good ending and the evil ending. Or maybe there were extra challenges and then there are a good ending and a super good ending. Not in Deus Ex: here the three endings all have up- and downsides. It's not clear which would be the best for humanity and the options are clever enough that I spent considerable time pondering each. Deus Ex has similarly deep philosophical thoughts as Bioshock, but while Bioshock is about the game manipulating the player, Deus Ex is about the player manipulating the world.


Dear Esther

A core aspect of game design to me is that a game should be fun without the graphics and the polish. If a game is already fun with just boxes, then it will be even better when visuals and sound are added. Dear Esther is a fantastic example of a game that proves me wrong. In fact, there's hardly any gameplay. But the storytelling, the music and the visuals all add up to an incredible experience. Dear Esther is also interesting in that it suggests a lot and explains very little. I played this game with my wife and we were constantly discussing what it all meant. The game continuously pushed our thoughts into different directions with new snippets of information.


Railroad Tycoon

I am a big fan of trains and always want to see more of them in games. I fondly remember Railroad Tycoon, Transport Tycoon and Sid Meier's Railroads. As a teen I wrote tons of pages of notes on an RTS that resolved around building railroads to transport resources. Trains could be armed to defend them and gather the resources needed to build an army. I doubt that game will ever happen, but anything with trains makes me all giddy with excitement. In fact, most of the game ideas I come up with today still have room for trains somewhere. I hope that in a few years I will finally have made at least one game that actually features trains!


Ori And The Blind Forest & Rayman Origins


I'm grouping these two games together because they have done a similar thing: they have both raised the bar for 2D art in games. 2D art is sometimes seen as lesser than 3D art, but Ori and Rayman have shown that it's possible for a 2D game to have the appeal of a big AAA production. At Ronimo we have studied the animation, special effects and level art in these two games in detail to see what techniques we could apply to our own games.


Braid


Of all the games in this list, Braid has probably influenced me most, and on several levels. For starters, Braid introduced us to the concept of self-publishing and indie development. Xbox Live Arcade had been around for a little while already but Braid, World of Goo and Castle Crashers really showed us the potential of indie and self publishing. When we started Ronimo we thought we needed to make disk based full price games. This was however not a path we were succeeding at so when we realised that we could do what these games were doing, we adjusted our plans and made a smaller game on our own instead. This became our first commercial release: Swords & Soldiers on Nintendo Wii.

Braid also influenced me on a more personal level. My interpretation of Braid's story is that it's not about an actual princess, but about the danger of looking for perfection. The main character has a girlfriend, but he breaks up with her because she isn't perfect. So he looks for the perfect woman, his 'princess'. But he doesn't find her because no one is perfect. The result is that he's alone and doesn't have his actually quite wonderful girlfriend anymore. In the epilogue the game also mentions other examples of the dangers of obsessing over perfection, like a scientist looking for the perfect science but creating the nuclear bomb as part of the Manhattan Project.


I don't know whether the story was truly meant like this, but this interpretation has greatly influenced me in my view on both creativity and life. Perfection is an impossible goal so striving for it only hampers you. Perfectionism causes you to spend too much time looking for an even better game concept to make, or endlessly iterating your game instead of releasing it and making another, or breaking up with your partner instead of making it work. Braid has truly changed my mindset in what to strive for in life and work.

So, that's it: the games that inspired me most! What games changed your view on games or the world?

Sunday, 2 February 2020

Five important realisations about game balance

The games we've so far made at Ronimo have all featured a heavy emphasis on competitive multiplayer. Designing, testing and iterating these games, especially our biggest hit Awesomenauts, has taught us many things about balancing. Today I'd like to share some of the most important lessons we've learned along the way.

1. Overpowered is much worse than underpowered


At first glance one might think that in game balance, underpowered and overpowered are equally bad: they both mean something is badly balanced and needs to be improved. This is true, but in practice overpowered things turn out to have way more impact than underpowered ones.

The reason for this is that players tend to flock to whatever is strongest and use only that. For example, Awesomenauts has 34 characters. If 3 of those would be underpowered, then most players wouldn't play those, leaving 31 valid characters. That's still plenty of choice and variation. On the other hand, if 3 characters were overpowered, then players would play only those 3 and would ignore the rest. That would make the game very repetitive and turn stale quickly.

This knowledge can be used as a crude tool in cases where no better solution is available. For example, if something is overpowered but only under certain circumstances, then you might choose to nerf it until it's okay under those circumstances only and is underpowered in all other situations. This way at least it isn't dominating the game anymore.

2. Variety always adds imbalance


A game with just one weapon on just one symmetrical map will pretty much automatically be balanced. Even if only because all players are in exactly the same situation. Such a game would however probably not just be balanced, but also be boring. So we need to add variety: more weapons, more maps, more items, more builds, more everything. Maybe even asymmetrical maps. The key thing to realise when doing this, is that as the game becomes more complex, 'perfect' balance becomes ever more difficult to achieve. This quickly gets to the point were 'perfect' balance is impossible, and every bit of variation you add makes the game a bit more unbalanced.

Let's look at a really simple example: walking speed. Let's say some characters are fast and others are slow. This gives the slow characters a disadvantage that can be balanced by giving them more health and damage. However, now we also add maps of different sizes. On a bigger map, the disadvantage for the slow characters will be bigger than on a small map. This is because if the arena is small, slow characters can get to the other side fast enough anyway. No amount of health or damage tweaks will fix this, since it differs per map.



One solution to this can be found in our game Swords & Soldiers 2. There in matchmade online matches, we only use certain maps: the ones that we feel are most balanced. On the other hand, when you invite a friend to play, you can choose from all maps, including a bunch of pretty weird ones. Those might be less balanced, but they add a lot of spice and fun. Depending on how much you want to appeal to players with a competitive mindset, you can choose to include those varied but imbalanced maps, or not.

3. Competitive players often dislike randomness and luck


When Awesomenauts launched, the game had random crits, which dealt a lot of extra damage. This added surprise and suspense: every hit might be extra strong! It also means that even if the opponent is better than you, you might occasionally win because you got lucky. This makes a game a lot more friendly for beginners. An extreme example of this can be found in Mario Kart: this game includes a lot of randomness. Combined with a bunch of catch-up mechanics, Mario Kart is a game where occasionally a n00b can beat a pr0.

However, randomess also adds bad luck: sometimes you clearly outplay an opponent and still lose, because the enemy got lucky and landed several crits in a row. In a sense this might feel nice: since the opponent clearly just got lucky, you don't need to blame yourself for losing. Many competitive players however don't want this to factor into the equation. They want a very simple thing: the best player should win. "If I practice more and get better, then I should always win." In the years after release many players in the Awesomenauts community got better and more competitive, to the point where a lot of players really wanted the random crits to be removed from the game. For this reason we ended up changing crits into a predictable system where simply every third hit deals more damage.



4. Balance automatically becomes worse over time


Even if you think the balance in your game is in a good place, by simply leaving it as it is for a while, it will deteriorate. The reason for this is that as time passes, players get better at the game, learn new tricks and talk to each other. This changes how the game is played, thus also changing how the balance is experienced. Usually not for the better: as time progresses and no balance tweaks are made, balance usually becomes worse.

One example we've seen with Awesomenauts was that at some point after a few months of stable balance, one specific team discovered a new tactic that was super strong. This tactic had been possible for months, but somehow no one had found it yet. This tactic was then first used in a tournament, where that team gloriously beat everyone else and won. After the tournament, news spread like wildfire and suddenly this tactic was used in almost every match. We had no choice but to quickly do a balance patch specifically to nerf this one particular tactic. (The fact that our game is deep enough that players can discover new tactics this way is one of the things I'm most proud of in all of my career as a gamedev.)

Another example of balance getting worse over time might not even be caused by something actually being way too strong. Maybe there's something that's just slightly overpowered, so mildly that it really doesn't matter. As time passes, players write guides and talk about the best tactics. They will point each other at this subtle advantage, causing more and more people to use it. Even if the advantage is really small, or, even more extreme, even if the advantage doesn't exist and players are just imagining it, this still ruins the game for the simple reason that everyone starts doing the same thing. This makes the game predictable and boring.

Sometimes you get lucky and players start responding to that imbalance. Maybe an underpowered character happens to be really strong in that particular situation. Since that situation now happens so often, that underpowered character is suddenly super strong in most matches, causing lots of players to choose him. This makes the dominant strategy shift naturally from one thing to another, adding variation and fun. I've been told some games in the Super Smash Brothers series have balanced excellently for this: as soon as one character becomes dominant, its counter becomes extra interesting and lots of players start playing the counter, at which point the counter of the counter becomes useful, etc. This causes the balance to slowly but constantly shift.

5. 'Perfect' balance is impossible


The final point I'd like to share today is both soothing and intensely frustrating: for any game that has significant complexity and variation, perfect balance is impossible. This is a soothing thought in the sense that it makes you realise that even if you were the best game designer in the world, your game would still not have perfect balance. It's also frustrating, because of course the goal of the game designer is to make the balance really good. Knowing that the balance will never be truly fantastic makes balancing a frustrating experience.

So, why is 'perfect' balance not possible? I've already mentioned above that as more variation is added, it becomes impossible to make all options equally strong under all circumstances. But there's more. What about players of different skills? Some characters/weapons/maps are bound to be more difficult to play than others. The result is that for beginners, the balance will be different than for pros. And what about simply different tastes? Some players prefer fun and variation, while other players prefer predictability and skill. The balance can't make both groups perfectly happy. Combined, all of these elements make it impossible to achieve 'perfect' balance.

This post has shared some of the things we've learned through the years about balance. What are your most valuable or most surprising insights regarding balance?

PS. Some of the topics in this blogpost have been discussed in more detail in previous blogposts. If you'd like to read more, have a look at the following posts:

Friday, 16 August 2019

Beginner balance versus pro balance

Game balance is often approached from the angle of the pro-gamer: how strong are things when used by a skilled player? However, the balance as it's experienced by beginners is equally important, since a large portion of the playerbase will never reach pro skill levels but will still want to have a fun experience. Today I'd like to discuss three different approaches we've used in our games Awesomenauts and Swords & Soldiers II to make the gameplay fun for beginners but also balanced for experienced players.

The big challenge here is that in a complex game with varied characters/weapons/factions/etc. it's nearly impossible to achieve perfect balance under all circumstances. Balance is influenced by almost everything and if you want variation, then that variation is undoubtedly going to upset the balance. For example, if some characters are faster than others, then having maps of different sizes can greatly change the balance on one map compared to another. The alternative is to make all maps the same size, but that's boring. For this reason balance is a moving target that you're constantly trying to get closer to but a certain amount of imbalance is (grudgingly) accepted in almost every game.



To make a competitive game fun for players of all skill levels, the ideal situation is to make it balanced for pro players, intermediate players and beginners alike. An example of striving for this goal are the changes we've made to the Awesomenauts character Gnaw. At some point Gnaw was heavily overpowered for beginning players, but mediocre at best for pro players. That meant that if we had nerfed (weakened) Gnaw for the sake of the beginner experience, Gnaw would have become totally useless for pro players. If simple nerfing is not an option, then what to do instead?

When a character is overpowered specifically in matches with beginners, this is often either because the character is too easy to play well, or because the counters are too difficult to figure out and perform. The nice thing is that if we can change the difficulty, it won't matter much for pro players: if the character becomes harder to play, pros will still master it. And if the character becomes easier to counter, that also doesn't matter for pro players: their opponents already mastered the counters anyway. Realising this doesn't make fixing the balance easy, but at least it gives us a starting point for where to look for a fix.



To modify Gnaw's difficulty for beginners, our designers made a number of changes over the years. Most of these revolved around making it more work to be effective with Gnaw. For example, initially Gnaw's Weedlings (little creatures Gnaw can leave behind to attack enemies) would live forever. One of the changes we made was that Weedlings would die after a while, requiring Gnaw to place them again. Weedlings were also changed to start weaker and become stronger over time. The result of these changes is that the player needs to be a lot more active to keep their Weedlings in the right places. Also, if the enemy has destroyed the Weedlings, Gnaw can't just replace them with equally strong ones right away.



Of course these changes also influenced the balance for pro players, but combined with some further tweaks we managed to keep Gnaw about equally strong for pro players while making him harder to play well for beginning players. Hence the pro balance remained similar while the beginner balance was improved.

Another Awesomenauts character with a similar problem was Ayla. Here too we made changes to make her harder to play well and easier to counter. While our designers did manage to improve Ayla's balance for beginning players, she remained problematic to counter for beginners.

Therefore when going free-to-play we employed a different tactic. In the free-to-play version of Awesomenauts, characters need to be unlocked with Awesomepoints, which the player can collect by playing the game. Characters have different prices. For example, some characters are difficult to play so we made them expensive to keep beginners from unlocking them right away. Since we had a problem with Ayla not being so much fun to play against for beginners, we chose to make Ayla expensive as well. This way few beginners will have Ayla and thus few beginners will encounter other beginners who are playing Ayla. This feels like a crude solution, but sometimes crude is the best one can do.



An even cruder solution that might be considered is that if a character is too damaging for the beginner experience, then maybe it's worthwhile to nerf the character to the point where it's okay for beginners, despite that this makes the character not viable for pro play anymore. An important thing to realise here is that with a cast of dozens of characters, a single character not being viable in pro play doesn't make that big of a difference since there are so many other options. However, a single character being overpowered for beginners will mean that lots of beginners play this character and it will ruin many matches.



The third example of fixing beginner balance that I'd like to discuss today comes from our real-time strategy game Swords & Soldiers 2. This game has 3 wildly different factions (Vikings, Persians and Demons), which gives enough headaches in terms of balance already. However, on top of that there is also a tactic that may be balanced, but that's just not fun for beginning players: rushing.

Experienced Swords & Soldiers 2 players can have a lot of fun harassing each other's economy as early as possible, forcing the opponent to spend their gold on defence instead of upgrades, or maybe occasionally even winning the game in under a minute. However, beginning players rarely start a match effectively. They're likely still reading some upgrade descriptions or thinking about what to do next. The result is that if the opponent employs even a very ineffective rush tactic, a beginning player will still be overwhelmed and lose in less than a minute.

For beginners this is highly frustrating, but since rushing is so much fun for pro players we didn't want to remove rush tactics from the game altogether. Instead we came up with something that's just for beginners: Starting Gates. Starting Gates are gates in front of each player's base that need to be destroyed before the base can be reached. This slows down rush tactics a lot and gives the defending player quite a lot of extra time to respond once the enemy soldiers come into view. Starting Gates are truly only for beginners: in matchmade online matches they're not placed if both players have played a bunch of online matches already.



Making the balance as fun for beginners as it is for experienced players is a hard and sometimes nearly impossible challenge. In this post I've given examples of 3 different tricks we've employed to improve beginner balance: Gnaw was made more difficult to play without making him stronger, Ayla was made more expensive so that beginners would encounter her less, and rushing in Swords & Soldiers 2 was changed for beginners by introducing a new mechanic that only applies to beginner matches.

These are all examples of looking at balance as a creative challenge, not just as a topic that's about spreadsheets and tweaking numbers. Have you used any nice tricks to improve balance? Please share in the comments!

Sunday, 2 September 2018

The challenge of finding enough playtesters

I recently watched Jan Willem Nijman's great talk on The Art of Screenshake and noticed an interesting YouTube comment to that video by someone named SquidCaps. SquidCaps mentions that for an unknown developer, it's really hard to find playtesters who actually test regularly. I agree that this gets a lot easier the more well-known you are, but I think it might also help to try a different approach to playtesting. So I figured it would be interesting to discuss how we approach playtesting at Ronimo and how to find playtesters.

Let's start by having a look at SquidCaps' comment. It's quite long so I've selected only the parts that I'm going to reply to:


Heh, "let people play your game and iterate".. quite a bit easier to say when you have plenty of gametesters already in the office.. For solo, unknown developer, having just ONE game tester that suffers 10 minutes per week is too much.. What you need is full game, with menus, high scores save games etc, basically a beta before you get any testers and then you get plenty of them.. When it's still in alpha and the biggest, most revolutionary stuff is happening, then you are alone. Something that developers who are already successful almost always forget; you get plenty of free resources at one point. [...]

The truth is that your mates play for a while but without actual team behind you, you can't support them enough, interest dies down and soon, you see that no one downloaded latest build.. [...] I've been on half a dozen playtesting groups with hundreds of members and they all fail.. The sad truth is that no one cares until you are almost done. big teams have people who they employ that can do playtesting and can even afford to pay for playtesting.. [...]"

Playtesting versus QA

Before actually getting into SquidCaps' comment, I'd like to start with making a clear distinction between playtesting and QA (Quality Assurance, not to be confused with Q&A which means Questions & Answers). QA is all about finding bugs, while playtesting is all about making the game more fun, more understandable and finding the right difficulty curve and balance.

QA is usually an extremely boring and repetitive task. For example, in our game Awesomenauts we've had cases where we hired people to systematically test whether all upgrades in the game function correctly. Awesomenauts has around 1200 different upgrades, so you can imagine that systematically testing them all is not a fun job. Another example of something that's done in QA, is trying to walk into walls to see whether collision is correct everywhere. This usually involves running into all walls in a game and is an incredibly monotonous thing to do. Since QA is so little fun, it's usually not done by volunteers or friends, but instead by professional testers who get paid to do this. Often QA is outsourced to specialised companies in low-wages countries. An alternative is of course that the devs do such testing themselves.

The goal of playtesting on the other hand is to figure out whether the game is fun to play, whether players understand how to play the game and whether the difficulty and balance are right. This is a completely different way of approaching testing. Someone who systematically goes through all 1200 upgrades in Awesomenauts is never going to have fun, so QA's way of testing is not going to tell you anything about how fun individual upgrades are to play with. To find out whether something is fun, you need to let testers play in a more natural, unforced way. You can then just observe how they play and ask them afterwards which things they liked and which they didn't.



Now that we have a clear distinction between QA and playtesting, let's get back to SquidCaps' comment. SquidCaps talks about getting people to play new versions of the game every week. For most purposes of playtesting I think you shouldn't just let the same people play every week. Of course it's helpful, since you can ask them questions like "Is the game more fun now than it was last week?", but you won't get a wide diversity of opinions from a small group. Also, these playtesters play with a preconceived notion of the game based on previous playtests, so their opinions will not represent what fresh players will experience.

For these reasons for Swords & Soldiers 2, spread out during development we invited around 120 people into our office so that we could observe them playing. Every few weeks half a dozen people would come in on a Saturday, play for a few hours and share their opinions. We made sure these were different people every time, so that we would get fresh, unbiased opinions.

For figuring out whether the mechanics and tutorial are clear you also need fresh players every time. Anyone who has already played the game can't truly judge whether the tutorial explains it well, since they already know how it works beforehand. Same for difficulty: after practice you get better, so you can't judge anymore whether it's playable for someone who's new to the game. This is also why the devs themselves are horrible playtesters: they know exactly how the game is intended and are usually really good at it, so they can't judge difficulty and clarity.



When to playtest

This is where I totally agree with SquidCaps: playtesting should start early on: "When it's still in alpha and the biggest, most revolutionary stuff is happening." I regularly encounter developers who think you need complete and bug-free gameplay to do your first playtesting, but there's no reason to wait that long. As soon as you've got something playable, you can let others play it.

Sure, in an early stage you probably need to sit next to the tester to explain a lot of stuff, but you can still learn a ton about which parts of the game are fun and which are not. It might even happen that the playtesters don't enjoy the core but really enjoy some other aspects of the game and this might lead you to change the direction of the game altogether. Or maybe they share some great ideas that you didn't think of yet. If you're wondering "Should I wait for the game to be more complete before testing?", the answer is almost always "Nope, just test anyway and see what you can learn!"

Finding playtesters

This is SquidCaps' main point: it's really difficult to find playtesters if you're not successful. I'd like to add to this that it's even difficult to find playtesters when you are successful: at Ronimo we've sold millions of copies of our games, but finding playtesters is still sometimes hard and takes time.

I think the best playtesting happens in person. That way you can see what the other person is doing and ask questions or help out if needed, especially when testing an early version of a game that doesn't contain a tutorial yet and might be full of bugs. That's why SquidCaps' approach of sharing builds online and joining playtesting groups is not something we'd consider until very late in development. We usually only share builds online for players to test in case of betas, like we do with Awesomenauts updates.

Instead, we mostly search in our local communities. For example, I occasionally talk at game dev schools here in the Netherlands. Whenever I do that, I end my talk with asking people to sign up for playtesting. Usually around 20% of the students in the audience do so, so we now have a significant number of email addresses of potential playtesters we can invite. Unfortunately in practice few of them actually respond, but it's still enough to get dozens of playtesters for a game, usually spread out over a bunch of Saturday afternoons.

When our mailing list runs dry, we look further. We've asked around at local game development schools, where students are often eager to visit a real game dev company and play a secret, unannounced game. We've also asked on social media, hoping enough gamers from the Netherlands follow us to actually get some visitors.

In total these usually get us enough playtesters. However, you can go further than that when needed. Here are some examples:
  • I know a game company where the devs took an iPad version of their game, went to Gamescom and let people who were standing in line for some big triple-A game play their game. Queuing people don't have anything better to do so it's rather easy to get them to play for as much as fifteen minutes or more.
  • Similarly, you can go to a random public space with a laptop and just ask people to play. If you're a student this could be the hall of your own school, or it could be a station, or anywhere really. This requires getting over some awkwardness when approaching strangers, but really, this is very doable.
  • If you've got some budget you can also get a booth at a game event like Gamescom or PAX. Booths are not just nice for marketing but also for playtesting. Lots of different people will play your game and you'll get the most honest feedback in the world: the moment they don't like it anymore, they'll just walk away. Painful, but very useful information.
  • You can organise local playtesting events together with other devs. Here in the Netherlands Adriaan de Jongh organises PlayDev.Club, which is simply a gathering of local devs who play early versions of each other's games and share feedback. If there's nothing like that in your community, you can organise something like that yourself, as long as you're in an area that has enough game devs.



None of these approaches will easily get us people who play our game for a huge number of hours. However, if our game isn't that fun yet then maybe that shouldn't be our focus and the focus should be on making that first hour super awesome. Once the core game is a lot of fun, it becomes easier to find playtesters who are willing to come back and invest more hours to get to the advanced tactics and pro skills.

While all of these ideas are easier if you're a more well-known developer and are better connected, with enough effort an unknown dev can also find playtesters in such ways. Before we released our first game Swords & Soldiers we also managed to find playtesters, despite being an unknown studio at the time. Finding playtesters takes initiative, creativity and effort, but in most cases it's doable even for those of us who aren't well-known.

These were some of the things we do at Ronimo and that I've heard from other developers. How do you find playtesters? What are your challenges and have you got any clever tricks?

Sunday, 28 January 2018

Entertaining players while waiting for matchmaking

In a game where high quality matchmaking is important (like competitive team-based games), waiting times to find suitable opponents are often unavoidable. Today I'd like to discuss the problems we had in Awesomenauts with our initial approach to this and how we made waiting a bit less boring later on.

Until the launch of the Galactron update in 2016, this is how it worked in Awesomenauts: when you started searching you got into a matchroom right away. You selected your character, and then you had to wait in the loading screen until the match was full with 6 players. This could take several minutes and there was no interaction possible whatsoever: just a loading screen that says the match isn't full yet. To show progress we did have six tickboxes that showed how many players had joined and whether they had already selected their characters, but that was it.



A static screen with no interaction possible is probably the most boring type of waiting imaginable. Compare this to current Awesomenauts, where you wait in the menus instead of in a loading screen. Still not ideal, but this means that while waiting you can chat with other players, check out the skills and items of all characters and watch replays and live matches. Awesomenauts has a system where it lists the ten most exciting matches happening right now and also automatically selects a match of the day that you can watch. We hardly advertise watching replays while waiting though, so I think many players don't realise that you can watch a live match or replay while waiting for matchmaking.

An important thing to realise when thinking about waiting times is that on PC, players can simply alt+tab and browse the internet while waiting. This isn't possible on console, but there's always that other option: mobile phones. I don't have any statistics on this, but I wouldn't be surprised if a lot of players ignore menus, replays and chat during waiting times and just randomly browse the internet instead.

While I think current Awesomenauts is a huge improvement in terms of diversions while waiting for matchmaking, I don't think it's ideal. Waiting times for a proper match can be rather long (which is unavoidable if you don't have a giant playerbase and prefer better match-ups over quicker matchmaking) and clicking through menus isn't the best entertainment in the world. I like the solution that PlayerUnknown's Battlegrounds has: players get thrown into a little area where they can walk and jump around, punch each other, voice chat and generally goof around a bit. It's still clearly a waiting area, but it's so much more fun and interactive than a menu or a replay.



Even better is to have some kind of mini-game while waiting. During early development of Awesomenauts we experimented with having a little death match arena where you played until the real match started. It's similar to what PlayerUnknown's Battlegrounds does, but even more game-like since it's real deathmatch. I can't quite remember why we decided not to put this into the game, but I imagine the mean reason was probably a lack of time: we were making a really big game with a small team and needed to cut features in order to finish it before funds ran out.

There might also have been concerns internally that it might be frustrating to be in a deathmatch game and then we thrown out into the main game all of a sudden. Knowing that it can end any moment might potentially make that deathmatch more frustrating than fun. In Swords & Soldiers we solved this frustration by letting the player do single player while waiting and storing the state of that single player as soon as an online match started. This way the player could continue the single player session after having finished the online match. However, this approach doesn't work with an online deathmatch. Still, I think having gameplay instead of menus is probably preferable anyway.



Despite all of this I do think we had some nice touches in the original waiting screen in Awesomenauts. One is that we showed the maximum waiting time left. Waiting for a few minutes is a lot more acceptable if you actually know how long you're going to be waiting than if you don't know whether you need to wait one more minute or ten. If after a few minutes the match was still not full, it would just start with fewer players and add bots to complete the teams. This way the player had a guarantee that when the timer ran out, gameplay would definitely start.

In the new matchmaking system we also want players to know how long they're going to wait, so we still show a number that says how long it takes until the next matchmaking round happens. Only now it's shown in the main menu instead of in the loading screen. This can be frustrating if the time is long (worst case it can be as much as 7 minutes), but at least you know what you're getting into.

In the waiting screen of the old version of Awesomenauts you also heard the theme song of the character you had selected. Every character in Awesomenauts has their own jingle and this adds loads of personality to the game. Since this was basically the only entertainment during this waiting screen we even made these songs longer: jingles for the initial characters were only around 20 seconds, while later on we started aiming for 1:30 minutes to reduce repetition.

In the current system where you don't select a character until the match is full we do miss this great opportunity to let the character jingles shine. Instead you now only hear a short bit of the character jingle after selecting the character. The other way to hear these jingles is in the menus while browsing character stats. Having less focus on these awesome theme songs is a pity.


Ideally your multiplayer game has an infinite number of players and you can find equally skilled opponents right away. However, very few games live in this ideal world, so everyone else needs to think cleverly about how their matchmaking works. Just building basic matchmaking and assuming it'll work out isn't going to cut it. If you're interested in reading more on this topic I recommend reading my previous post on designing matchmaking for non-gigantic communities as well.

In the end I think the main reason we ended up with that waiting screen in Awesomenauts for years is that we underestimated how hardcore our community would be. We had designed Awesomenauts as a casual, fun alternative to the other MOBA games. We thought starting with bots right away and adding players as soon as they came online was way more fun than waiting for a full match. Our players disagreed: joining a match that's already in progress is a disadvantage since the bots might have already lost some ground by the time you replace them. Matchmaking issues quickly became the number one complaint about Awesomenauts in our community, so we increased the waiting time before a match actually starts to 2 minutes (or less if the match is already full). This did increase the chance of everyone being there at the start, but we still got complaints about matches not always being full, so we increased the waiting time even further to 4 minutes.

Since we thought we were making a more casual game we hadn't anticipated that our players would prefer long waiting times to be able to play in a more competitive way. We did adjust the system based on this feedback, but the result was waiting in a loading screen. I'm glad we got to improve that situation when Galactron launched later on.

Sunday, 2 October 2016

The big list of ways to create varied weapons

When designing weapons, there are many ways of differentiating them and spicing them up. To help anyone who is working on that, I would today like to give a big list of weapon parameters that one can play with. Most can be applied to ranged, melee and special attacks, but obviously not all can be used for everything in every genre. I hope this list can be used as an aid, regardless of genre. Note that I only focus on gameplay here: graphics are also an important part of the feel of a weapon, but his post is entirely about gameplay.

I made most of this list a couple of years ago when I was thinking about creating an open world game with randomly generated enemies. As a first step I made a long list of weapon properties and side effects that could be combined to create attacks for those enemies. As with many of my game ideas I doubt I'll ever get around to actually making this game, but I figured this list might also be useful to others, so I've extended it into this blogpost.

Most of this list is inspired by what Ronimo designers Fabian and Jasper made for Awesomenauts. Awesomenauts currently has 27 characters, each with 3 different attacks. Each character also has 18 unique upgrades with several tiers each. In total that's over 1000 upgrades! Many are simple upgrades that modify things like damage, cooldown, stun or range, but some are very unique, like the ones that upgrade the "AI" of Leon's clone. I'm really impressed by the creativity that went into many of those and put many into this list.

This list is by no means complete: you can come up with new ideas and variations forever. If you feel I overlooked some cool things, then please post them below and I will add them.

Basic parameters


  • Melee, ranged or area: for example, is it a sword, a gun, or an area effect around the character?
  • Range: how far does the attack reach? Note that this is not only important for guns, but also for things like the length of a sword
  • Effect timing: how long after you pressed the attack button does the damage actually apply? In case of a large sword movement, it might take a second before the sword actually hits. This gives the opponent time to get away, but also gives the attack itself a more powerful and impactful feel.

How often you can hit


  • Attack speed / cooldown: how fast an attack can be repeated. The term "attack speed" is usually used for weapons that can be used several times per second, while "cooldown" is generally used for things that take several seconds before you can use them again.
  • Ammo: weapons might have a limited amount of bullets. If they run out, you need to pick up more bullets, switch to another weapon or wait for bullets to regenerate.
  • Ammo clips / reloading: even if you still have enough ammo, you might have to pause shooting once in a while to reload. Parameters are how often you can shoot before you need to reload, how long reloading takes and whether you can reload before the ammo clip is empty. A special variation here is the Active Reload made famous by Gears of War: if you press a button with a very specific timing, the reloading is super fast or might give you a small buff.
  • Mana: similar to ammo, but mana usually automatically regenerates over time and is shared between several weapons.
  • Interrupt immunity: can an enemy interrupt this attack through a counter-attack or stun, or will this attack always finish once started?

Controls


  • Charge by holding a button: the weapon doesn't fire until you let go of the button, and it charges as long as you keep it pressed. Charging might make you throw further, or deal more damage or have some other effect. An important choice here is whether you can still move while charging.
  • Other charges: the weapon gains strength in some other way. Maybe every time you hit an enemy with your basic attack your special attack grows stronger, or maybe it becomes stronger over time. Once you use the weapon the charge is usually lost and the weapon needs to be charged again.
  • Holding versus button bashing: when doing consecutive slashes or shots, do you need to hold the button pressed, or bash the button all the time? This will also influence the number of attacks per second: if a new attack doesn't start until you press again, there will usually be a couple of frames in between attacks even when the player presses the button really quickly.
  • Combo's: specific combinations of attacks or button presses create stronger or different attacks. To make this more challenging this usually requires a specific timing for the button presses, but it can also be as simple as every third hit being stronger.
  • Cross-weapon influences: in this case performing one attack adds an effect to the next usage of a different attack. For example, maybe after using your special skill the next gunshot is charged with stunning electricity.
  • Timing: when do you need to press the button? For example, do you do extra damage if you press again just when the last slash has its impact?

Basic impact


  • Damage
  • Heal
  • DoT / HoT: Damage Over Time and Heal Over Time. These are controlled by a couple of parameters: how long it lasts, the total amount, and how often it applies (10 damage once per second isn't the same as 1 damage 10 times per second!). An extra setting is whether DoT stacks or not: if you get hit again while a previous DoT is still happening, do they add up or not? You can also have different DoT types: in Awesomenauts two poison DoTs don't stack, but a fire DoT and a poison DoT can happen simultaneously, so they do stack.
  • Stun: keeps you from doing anything for a time and interrupts whatever you were doing.
  • Microstun: this is a stun that is so short that it breaks your current attack, but doesn't keep you stunned. So you keep control, but if you are for example already charging an attack, then this charge is cancelled. In case of Awesomenauts, a good example of this can be found in Leon, who has microstun on his slash and can use that to turn off a Yuri's jetpack, causing the Yuri to fall to the ground, making him vulnerable for further melee attacks by Leon.
  • Slow: slows down movement and maybe jump height. Doesn't influence cooldowns or attack speed!
  • Silence: keeps you from using weapons and/or skills. Often this only influences special attacks and lets you keep doing your basic slash.
  • Snare: keeps you from moving, but allows you to still use weapons and skills.
  • Blind: for a while you can't see anything, or not far enough, or only right in front of you. In shooters this is often done with a flare grenade.
  • Knockback: an enemy is pushed away, often also a bit upwards into the air.
  • Throw: similar to knockback, but here you pick up an enemy and throw her away.
  • Crit: there is a certain chance that an attack is extra strong. Settings are the chance of the crit, and the amount of extra damage/effect. You can also implement rules that keep consecutive crits from happening, or that make sure that there is always at least one crit every N attacks. Have a look at these two blogposts for an analysis of designing crit chances.
  • Lifesteal: gain life yourself whenever you damage an opponent.

Note that many of these effects limit the player's control. Especially stun is really bad at this, but slow, silence, snare, blind and knockback all have such effects. When designing a single player game, these can be great fun: stunning an enemy is great and allows for mechanics in which you combat large groups of enemies without being overwhelmed. However, in an online multiplayer game like Awesomenauts, anything you do influences another human player. Being stunned for a long time is incredibly frustrating, and the same goes for snares and strong slows. All limitations are frustrating, and limitations on the player's movement even more so. Keep this in mind, and in general avoid designing situations where combos of these keep the player out of control for too long.

Projectile movement and count


For ranged attacks, the projectile you fire (or bullet, or magic fireball, or whatever) also has a number of its own properties:

  • Projectile speed: how fast the projectile moves makes a big difference for how dodgeable it is. If it moves pretty slowly compared to an enemy, you might even have to aim in front of her to be able to hit. The most extreme speed here is the instant hit, where the simulation doesn't consider it a projectile at all. This is the case for guns in most shooters. In the case of Awesomenauts, aiming is quite easy, but so is dodging. Using a sniper in an FPS, aiming for a headshot is pretty difficult, but if you aim correctly then the other player can't dodge at all. This greatly influences game feel.
  • Projectile size and shape: how big is the projectile, and is it square, rectangular, round or some other shape.
  • Homing: whether the projectile automatically changes its path to follow an opponent. You can tweak how quickly the projectile can rotate towards the enemy, but also how long it takes before the projectile starts homing after it was shot. Another setting is whether the projectile chooses its target only when shot or can alter its target during flight.
  • Arcs: some projectiles might not fly in a straight line. Grenades might be thrown in an arc, making aiming more complex but also allowing a projectile to be thrown over a wall.
  • Movement patterns: some weapons might move in strange patterns. For example, a waving sine movement could be applied.
  • Projectile count: you might shoot several projectiles at once. Important choices here are in what direction the different projectiles go (all somewhat forward, 360 degrees all around?) and whether all projectiles fire at the same time, or they come after each other in a series of shots.
  • Mines and bounces: what happens when a projectile hits the ground? Does it disappear, or explode with area of effect, or bounce away in another direction? Or does it stay on the ground like a mine, waiting to explode when an enemy is near? Also, if it does become a mine, is it a spider mine that jumps towards enemies that come near, or does it only attack who steps on it?
  • Detonation: when does the projectile explode? When it hits something, or when the player presses a button? The latter is mostly relevant in combination with area of effect and can be used with both mines and slow moving projectiles. Detonating a projectile by hand is a fun thing to do, but also often tends to somewhat slow down the game as the player watches every projectile fly.
  • Return to player: after a while or after a button press the projectile flies back towards the player. Might be used for a weapon that the player needs to retrieve before being able to use it again, or for a penetrating bullet that can hit enemies again on the way back.
  • Morphs: does the projectile change into something else at some point? Maybe if it hits a wall it bounces but becomes weaker, or if it flies long enough it grows, or if it flies through fire it gets an added damage over time fire effect?
  • Splits: whether the projectile can split into several separate projectiles. This can happen at a specific timing, or when hitting an opponent or wall. The newly spawned projectiles can also be more of the same projectile, or a different one altogether.

Who and where you hit


  • Friendly fire: whether you can hit your own teammates or not makes a big difference for the playstyle of the game.
  • Self-damage: weapons like rockets might damage yourself when they explode too near to you. An extreme example of this is Clunk's explode in Awesomenauts: he does massive damage to anyone near him, but also damages himself and can even kill himself this way. Another example is the famous rocket jump, where the knockback of the explosion of your own rocket allows you to jump higher.
  • Area of effect (AoE): normally an attack hits only one enemy, with AoE it can hit everyone in an area. AoE has several settings to play with: the size and shape of the area, and in some cases also the maximum number of opponents hit. A weapon can also be a combination: maybe the enemy that was hit gets 10 damage directly, and there's also an AoE effect that deals 5 damage to everyone near her. Be warned: area of effect can be very difficult to balance if the player sometimes faces many opponents, and sometimes only a few.
  • Penetrating: if you hit someone, does the bullet fly on and hit another target, or does it just end. Often seen variations to this are that a bullet has a maximum number of targets or deals decreased damage to consecutive targets. It might even change direction on hit, like with chain lightning.
  • Wall piercing: whether a weapon can shoot through walls or not. This makes a big difference to where an opponent will feel safe. In Awesomenauts only a couple of weapons can go through walls, and knowing whether there's an opponent in the field who has such a weapon is extremely important for successfully fleeing when low on health.

Buffing and debuffing


  • Buff: when you hit a teammate, she becomes stronger in some way. This can influence any parameter, like giving her a shield, increasing her health, reducing her cooldowns or increasing her damage output.
  • Debuff: this is an effect that makes an opponent weaker. This is the opposite of a buff and can again affect any aspect of the gameplay.
  • Cleanse: instantly removing the debuffs from a teammate.
  • CC immunity: this is a very specific type of buff that makes a player immune to things like stun, slow and snare, but doesn't make her immune to damage. "CC" stands for "Crowd Control", since such effects don't kill someone, but allow you to have some control over what others do.
  • Shield: another specific type of buff. A shield reduces damage you receive. This can be done in several ways: a percentage of damage can be removed, a fixed amount of damage per attack can be absorbed, or you can temporarily become invincible altogether. This makes a big difference: absorbing a fixed amount is weak against very strong attacks, but it also makes you invulnerable against weak attacks that are below the threshold, making this super effective against rapid fire of small bullets. A shield might also turn off once it has absorbed too much damage, allowing opponents to destroy the shield. Shields can then regenerate, turn on again after a cooldown, or be lost until picked up again.
  • Time bubble: slows down all time in an area, usually only for opponents. Everything takes longer, so movement is slower, bullets slow down and even cooldowns are longer. That makes this quite different from a normal slow, which only affects movement. This can also be inverted to make time go faster for teammates.
  • Invisibility: you can make yourself or a teammate invisible, or really hard to see. This is often frustrating for the enemy so it might be needed to limit how long you can be invisible or to give certain enemies a skill that allows them to see you even when invisible.
  • Phasing out: a weapon might make you disappear from the battlefield temporarily, making it impossible to receive or deal damage. It might also phase you out partially: maybe you can move through enemies temporarily, but you can still attack and receive damage.
  • Self (de)buff: all of these effects can also apply to yourself. They can be the main effect of a weapon, or a side effect. For example, maybe using some super powerful weapon drains your batteries and makes all other attacks have a longer cooldown for a while.

Armor and damage types


Damage and armor can have specific types. Often this means that you deal less damage against opponents who have a procentual resistenance against certain attacks. Some variations on this are:

  • Elemental: a weapon might deal a certain type of damage (fire, ice, poison, etc) and an armor might give extra protection against certain types of damage. An extreme example of this can be found in Titan Quest, where there are many types of damage and all items can give all kinds of resistances. For example, a bow might give a subtle 2% extra fire resistance.
  • Opponent type: some weapons might be extra strong or extra weak against certain types of opponents. Maybe poison has no effect against mechanical enemies, or ice has no effect against the undead. An example in Awesomenauts is that most special skills are very weak against turrets to avoid lame outranging tactics.
  • Piercing: if a weapon is piercing, it ignores the armor of the opponent and does full damage.

These things not only serve to add variation to the weapons and upgrades in a game: they can also help in balancing. Especially armor types are great for this. If it turns out that one specific class is way too strong against one specific other class, but everything else in the game is quite fine, then it can be really difficult to find a way to fix the balance between those two classes without destroying all the rest of the balance. Armor types are a great way to fix this: make one of the two classes undead and make the weapons of the other weak against undead. To the player this might feel like a general rule that makes sense, while in fact it's an extremely specific nerf.

Own movement


A weapon or skill might also include movement of the player herself. This greatly changes the feel of a weapon and has a large tactical impact on when to use a weapon.

  • Dash: attacks that combine with fast movement in a certain direction. A dash can go through enemies or stop as soon as you touch someone. Also important is when the dash does damage: whenever it touches someone (like Froggy G's dash in Awesomenauts) or only at the beginning end/or end of the movement (like Vinnie & Spike's dive).
  • Jump: whenever you perform this attack, you also jump up. Like doing an upward punch or overcharging your jetpack.
  • Groundpound: attacks that can only be done downward to the ground from a point in the air.
  • Pull: pull yourself towards and enemy or pull an enemy towards you. Which it is makes a big difference: the first might put you in the middle of a group of enemies, while the latter might for example pull an enemy in range of your own turret.
  • Teleport: an attack can let you or an enemy teleport towards a position. Maybe you teleport towards the position of the bullet, or towards an object you left behind before, or towards your own position 5 seconds ago.
  • Swap position: swap position with an enemy or teammate.
  • Movement limitations: an attack can also limit movement. Maybe you become really slow while carrying a heavy gun, or maybe you turn into a turret and can't move at all for a while.

Other


  • Chain: keeps an opponent chained to a certain point, but she has complete freedom within the range of the chain. This is a great variation to a snare, because it's much less frustrating to be limited to an area than to not be able to move at all. An opponent can also be chained to an object or another character, allowing you to drag someone along.
  • Weapons that add weaknesses: a great way to add more variation is to add special weaknesses to certain weapons. Maybe the player loses a bit of health whenever she shoots, or moves slower when holding a specific weapon. By adding weaknesses to a weapon you can make its strengths much more extreme without making a weapon instantly overpowered.
  • Summons: a weapon can also spawn a new AI character that can fight for you. If you do this, the summoned character can also have tons of upgrades, like Leon in Awesomenauts who can upgrade the AI of his clones to make them move around or attack. The character can be spawned near the player, or in the spot where a project hit something.
  • Transform: changes an enemy or teammate into something else. A famous example is the Warcraft spell that temporarily turns enemies into sheep that can't attack. The transformation might also be permanent: in Awesomenauts there's an upgrade that lets Genji morph normal droids into flying droids.
  • Vision: some weapons might let you see different things, like a scope on a sniper that let's you look far away, or heatvision, or a weapon that temporarily shows you invisible enemies.
  • Attack visibility: whether the enemy can see your attack coming, and how easily. A nearly invisible bullet is much harder to dodge than a big purple one. Also, if your attack has a clear charge animation then enemies can see it coming and have more time to dodge the attack.

That's it! I hope this list can help other game designers add variation to their weapons. At the very least I had fun making a list and have a nice reference now for my own game designs. ^_^

Sunday, 6 September 2015

Designing matchmaking for non-gigantic communities

Most multiplayer games die within a week. Not because the multiplayer doesn't work, but because there aren't enough people playing online. If you look for opponents and don't find any, then the multiplayer mode might just as well not have been made. This is even more of a waste because online multiplayer is so much work to develop, as I recently explained. The vast majority of online multiplayer games ever made isn't playable any more because of this. Partially this is because not all games can be a success, but there is a much more important reason: often the matchmaking is poorly designed for a smaller playerbase. With clever choices multiplayer can flourish even with a tiny community.

For an average indie game that is doing okay but isn't a big hit it is pretty decent to have 40 simultaneous players a few weeks after launch. Our own game Awesomenauts did really well so our daily peak is usually above 1000 players, but expecting such numbers is unrealistic for most games.

Let's consider a four player multiplayer game that has three game modes. We press the quickmatch button and the game starts looking for opponents. If a match takes on average 30 minutes and there are 40 simultaneous players then a player starts looking for a match once every 45 seconds. Since there are three game modes your mode will have one player searching once every 135 seconds. Waiting for a complete match of four players then takes almost 7 minutes.

Seven minutes! Few players are willing to look at a "Searching" screen for that long, so most will just quit and play something else. If a player concludes your game is dead he probably won't try again later and is lost forever. Whatever playerbase you had will quickly disappear. So many multiplayer games die because there aren't enough players for a good experience.

However, with clever design choices this fate can be averted. 40 simultaneous players would have been plenty for a good experience if matchmaking had been designed in a different way.



Reduce game modes

Game modes split the community. If half of your players wants to play Domination while the other half wants to play Deathmatch, then they all have only half as many opponents to play with. In the example above removing two game modes would have reduced the waiting time to 2:15 minutes, which might already have done the trick. Even the gigantonormous League of Legends has removed less popular game modes because there weren't enough players for a good experience.

For exactly this reason Awesomenauts has only one core game mode. There is a custom game option where users can set up all kinds of weird game modes, but these aren't part of the core matchmaking and thus only playable through friend invites. This way there are extra options for players who want them, but there is only one core mode and it has plenty of players to matchmake with. (For a more detailed analysis of player spread, check my blogpost on why good matchmaking requires enormous player counts.)

If you really want to have more game modes, you can also choose to force players to play whatever is available. Maybe players can select a preferred game mode and the matchmaker looks at all the preferences and tries to find the best match-up. If there aren't enough players in your favourite game mode, then you just play a different game mode. The downside of this approach is that players would probably complain a lot that they aren't put in their favourite game mode. Not having an option at all might in some cases feel better than having an option that you can't actually play...

Allow solo play while waiting

The above approach tries to reduce the waiting times. An alternative is to make waiting more fun so that players are willing to wait longer. In our 2010 game Swords & Soldiers we allow players to play all single player content while waiting for an opponent. If you start the matchmaker a little icon appears in a corner of the screen and you can just play some skirmish against the computer until another human becomes available to play with. This works wonders: players are willing to wait much longer, increasing the chance they actually find an opponent.

This can be improved further by having content that is fun to play repeatedly. A story campaign isn't so much fun to play every time while waiting, but a highscore mode is. In Swords & Soldiers I usually played the endless Survival mode while waiting. Of course it sucks to be thrown out of your highscore run because an opponent is found, so our solution was to auto-save the solo match when starting a multiplayer match. You can continue your single player challenge after the multiplayer has ended.

A while ago a colleague of mine tried playing Swords & Soldiers online. Even though the Steam version of the game is almost five years old now and there are only a few people playing, he got three different opponents in just an hour. There were never more than four people playing Swords & Soldiers simultaneously that evening, so he got a surprisingly good multiplayer experience with such a microscopic community. Amazing!



Playing against bots

For Awesomenauts we chose a different approach. Here we let the match start even if there aren't enough players for a full 3vs3 match. The missing spots are filled with bots until more players are found. The result is that even if there are very few players online, you never have to wait long and can always start playing.

Initially Awesomenauts just started a match right away regardless of how many players were found, removing waiting times altogether. The big downside of this is that it doesn't work well with a competitive mentality: it feels unfair if bots already lost a tower before you even joined. For this reason we later added waiting time, but with a countdown timer that shows the maximum waiting time left. Since Awesomenauts has plenty of players most of the time the match will be full well before the timer runs out, so you rarely start with bots.

This drop-in aspect of the game is a constant source of complaints from our userbase, but players often don't realise that without it, Awesomenauts might not have survived its first months. It took nearly half a year before our playerbase reached a constant good amount on PC and even with those smaller numbers there were never long loading times.



Adding more players

So far I have focussed on making the most out of a your existing players. Another important approach is to maximise the numbers of players. This can be done in various ways. Many multiplayer games are free-to-play, increasing the size of the playerbase (although there are also plenty of free-to-play games that don't actually manage to gather a significant playerbase).

The developers of Verdun chose a hybrid approach: at some point their game had a free browser version and a paid Steam version and they all played together online. The free players didn't bring in a lot of money directly, but they made the game more fun for the Steam players, increasing sales there.

Even when not going free-to-play it is a good idea to not make a game too expensive. The average indie game seems to have recently gone up in price, but I would heavily advice against pricing a multiplayer-only game above $15: this will decrease the size of the playerbase. Selling more copies is more important for the long term income of a multiplayer game than the short term income of a higher price. Awesomenauts is $10 and we often drop its price heavily during sales, by as much as 90%. This boosts the playerbase enormously, more than making up for the low price.

Extreme measures

If you want to make a multiplayer game playable with below 10 simultaneous online players you might have to resort to extreme measures to keep something going. Several devs told me they promoted a specific moment, like one specific evening every week, as multiplayer evening. This way everyone comes online at the same moment, creating a somewhat lively community once per week. One dev even went as far as taking the multiplayer functionality offline altogether during weekdays, only allowing multiplayer during weekends.



I can imagine other, more subtle ways to get players online at the some moment. Like allowing players to send a challenge to other players who are near them in the leaderboards. The game then sets up a time for them to play against each other, giving them a good reason to come online at one particular time. Asynchronous multiplayer is also a good way to do this, but this only works with certain types of games. For highscore based games asynchronous multiplayer can be an excellent way of boosting the competition within the community.





There are many other ways to make the most out of a small community. For example, things like clever lobbies, a rematch option and showing the expected waiting time per game mode. Key is to consider matchmaking a real part of game design, something to brainstorm about and come up with creative solutions. If you just make something then you might end up killing your community much quicker than needed. If you aren't Blizzard or Riot then thinking about how to make the most out of a smaller online community is crucial to the success of your multiplayer game.