Sunlight

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 alter...

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 ...

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 curre...

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. Mo...

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 m...

An important goal in the game design of Swords & Soldiers , Awesomenauts and Swords & Soldiers II is gameplay variety. We try to make all the classes, units and factions play and feel as differently is possible. This makes it more fun to try them all and allows for much more interesting and varied tactics than if everything feels the same. It seems quite obvious that a game gets better if more diversity is added, as long as you have the budget to do so and it does not take away from the core vision. However, there are some serious downsides that are not as obvious. Adding more diversity can hurt many different aspects of a game, as I will explain in this blogpost. When striving for variety it is important to be aware of the trade-offs. It does not mean that you should avoid diverse mechanics, far from it: it is a key element of the games we make at Ronimo ! But consider the consequences before blindly adding variety. A great example of such trade-offs can be found in the move...

When we started developent of the bots for Awesomenauts , we started with the most complex part: how to do path finding and movement? When people think of path finding, they usually think of A*. This well-known standard algorithm indeed solves the finding of the path, and in games like an RTS that is all there is to it, since the path can easily be traversed. In a platformer however the step after the finding of the path is much more complex: doing actual movement over the path. Awesomenauts features a ton of different platforming mechanics, like jumps, double jumps, flying, hovering, hopping and air control. We also have moving platforms and the player can upgrade his jump height. How should an AI know which jumps it can make, how to time the jump, how much air control is needed? This turned out to be big challenge! Since there are so many potential subtleties in platforming movement, my first thought was that handling it in our behaviour trees might not be doable at all. Behaviour tr...

With the next Awesomenauts patch (patch 2.5) we will release our AI editor and enable players to load modded AIs in Custom Games. The editor is in beta right now and a surprisingly large amount of new AIs have already popped up. Other game developers can also use our AI editor for non-commercial purposes, or contact us to discuss the possibility of using our tool in a commercial product. This all makes for a great occasion to discuss how we made the AIs and what kinds of tools we have developed for this. Anyone who wants to give making AIs for Awesomenauts a try can check this little starting guide that explains the basics. I have previously discussed in two blogposts how we made the AI for Swords & Soldiers ( part 1 and part 2 ). Since then we have changed some of the fundamentals and those blogposts are well over three years old now, so I will write this blogpost assuming you didn't read them. When people think about "AI" they usually think about advanced self-l...

Designing a free to play game with microtransactions is a huge challenge. It is incredibly difficult to find the perfect balance between giving players a strong incentive to pay something while still making the free experience good enough that they keep playing. This challenge is crippling to the game itself. It is impossible to make a game as fun as it could be for both paying and non-paying players. At least one of those groups gets a game that is less fun. Game design is all about making a certain concept as much fun as possible. By tweaking things like difficulty, flow, reward systems, variation and complexity the game designer tries to create the best experience possible. This "best experience" is an invisible target: you can never know whether you have reached it, or whether tweaking some things would make the game slightly better. It is also something that differs depending on the target audience. Some players like a challenge, others like a more relaxed experience. So...

Games contain many forms of chance. From simply selecting a random character or level to play, to random pick-ups and even completely procedural worlds: chance, luck and randomisation play a huge role. While developing Awesomenauts we have experienced this first hand, especially in the various versions of Leon's crits, which has been changed several times in patches during the past 1.5 years. Last week I mostly talked about the psychology of crits , and today I am going to look at chance in games in general. When a programmer is told to implement a random for something, he will often simply use std::rand() or something similar and that's it. However, in practice it turns out that both players and designers rarely really want a truly random chance. A good example of this can be found in level selection in Awesomenauts: in a practice match there are four levels to chose from, and there is a 'random' button to select random levels. With a true random, the random button m...