Monday, 28 September 2015

The future of indie is amateur

The number of indie games being released on Steam and consoles has sky-rocketed this last year. At the same time, the amount of money being spent on indie games doesn't really seem to increase. In other words: the average indie game is making much less money! SteamSpy recently released some graphs that show that while total sales for all games together are pretty stable, median sales per game have dropped enormously. You only need to open Steam's list of new releases to see why: so many new games launching every day! Five years ago only a couple of games launched on Steam per week. Now there are dozens launching daily, and they're all competing for the same players. The average income of a new indie game has dropped so far that some even call this current trend the 'indiepocalypse'.

There are several reasons we're seeing this now. The most obvious reason is that marketplaces like Steam have made worldwide distribution easy. They have become more and more open to release games, and not just the cream of the crop. Five years ago, if a hobbyist made a game he put it on Newgrounds and didn't expect to make any money. In contrast, professionally made indie games released as paid products on other platforms and thus competed with hobby developers in a less direct manner, and often in different genres. Today many smaller games can also release on Steam. If Steam keeps going in its current direction, then soon everyone will release their games there. The same goes for other platforms: ID@Xbox isn't anywhere near the speed of Steam yet, but with 21 indie games released in August alone they too are stepping up the pace enormously.

Another important factor is that tools like Unity, GameMaker and Unreal make game development much easier and cheaper than it ever was. Previously many developers were confined to 2D browser games because 3D was technically too complex, as were mobile and console. Licensing a decent game engine that handled this was very expensive. Five years ago only teams with significant technical skill could make such games, yet now these engines don't require much more than the click of a button to reach most platforms.

The final drop is that game dev courses are abundant now. For example, here in the Netherlands we used to have only a few schools teaching game development. Today there are dozens. I'm seeing this same kind of educational expansion everywhere in Europe. More graduates means more people to make games and many of those are starting indie companies straight out of school.

Together these three factors have caused an enormous influx of people all trying to make a living making indie games. Their number is growing much faster than the market, so the average sales of indie games are dwindling. Many indie games that release today won't make much more than a few thousand dollars, far from enough to make a living as a full-time game developer.

What does this mean for indie studios? I recently met a young dev who had started a company with friends and spent a lot of time making their first game. When it launched it literally sold only a few hundred copies. His conclusion? He was going to look for a job and continue making his own indie games – in his spare time, as a hobby.

I think we are going to see this pattern for a lot of start-ups. There are so many games that only a few actually make a decent buck. The rest won't make enough money to sustain the company, causing those indies to bail out of trying to make a living as an indie developer. Many will become amateur indie developers instead.

I don't think this dire financial situation will stop people from making games. Development is just too much fun and that small chance at success just too awesome. What if your game becomes the next Braid or Minecraft? If you can't do it professionally, I'm sure many people will just build those games as a hobbyist instead.

Talented amateurs won't be able to make AAA games like the next Grand Theft Auto, but they will be able to make games similar to what indie teams of only a few people can make. A bunch of highly talented hobbyists working on a game in their spare time for a few years might be able to make the next Banished or Nuclear Throne. This is great of course, but they will be competing for the exact same audience as those trying to make a living as an indie.

Full-time indies competing directly with hobbyist developers will cause the chances of indie games being a financial success to plummet even further than they already have. As the chances decrease, it will become highly infeasible to start a company and 'go pro'. Heck, it probably already has! In the long term people will realise this beforehand and most won't even try to make a living making indie games anymore. I expect they'll just get a job somewhere (hopefully still as game devs!) and keep doing their own projects on the side.

Of course, some will become a hit and be able to make a living. Some others already have an audience and are really good at what they do, so those too will stick around. But in general, the vast majority of future smaller indie games will be amateur games.

Is this bad? No: 'amateur' and 'hobbyist' aren't negative words. They just indicate someone who does something without making money from it. This doesn't mean they can't be good at what they do: just like there are tons of hobby musicians who are actually amazingly good, we will be seeing more and more fantastic games by talented hobby game developers. As well as a lot of bad ones of course, which is fine as long as they too are having fun making games. I expect there will also be a lot of indie games from people who have a regular job as a game developer or freelancer and make their indie games as hobby projects on the side.

I've heard the current trend described as the 'indiepocalypse'. I don't think that word makes sense: this isn't an apocalypse as it isn't the end of indie. Instead it's a shift from professional indie to hobbyist indie. We'll keep seeing awesome indie games and some of those will break through to huge success.

There is a big downside though: this is very sad news for those who release their first game now. Many will have started their company when the indie scene was still small enough that all decent games sold at least okay, not just the amazing ones. Many will be disappointed when their game launches and doesn't reach an audience. I can only hope they'll realise how awesome it is to have made their own full game and feel proud of having released it. But it's a bittersweet second prize, when you dreamt of making a living as an indie dev.

What does this all mean for the bigger indie studios, the ones with more than ten people working on a single game? I don't know. They're capable of creating bigger, more polished productions than hobbyist developers, making those bigger games stand out from the crowd. Will this be enough for a good chance to earn back the much bigger investment? Time will tell. One thing I expect is that they will make more business deals with publishers, investors and other partners to decrease their risks and gather the required budgets. This will move those bigger indie studios further away from what is traditionally considered 'indie'.

If an indie studio is successful and grows its team, it is often not considered 'indie' any more. I regularly get the question whether our own studio Ronimo is still indie: “Aren't you too big for that now?” If that's true, then 'success' often means 'not indie anymore', as using that success to grow the studio apparently isn't indie. By that definition the only successful indies are those who not only have a hit but also stay small.

From a gamer's perspective I don't think any of this matters much. My favourite game this year so far is Ori And The Blind Forest. For me as a gamer it offers exactly what I look for in an indie game: it tackles a genre that AAA doesn't do (2D platformer), has a beautifully crafted atmosphere and brings a focussed experience that dares to take risks. Yet I haven't seen this game mentioned as being 'indie' at all. Apparently a type of game that I perceive as typically high-end indie isn't called 'indie' anyway.

An odd part in all of this is the new breed of 'indie publishers'. Now that the overflow of indie games has made reaching a bigger audience so difficult it makes sense to look for a partner to work with: a publisher that specialises in marketing indie games. However, I remember 'indie' was originally mostly defined as 'not working with a publisher or investor'. Doesn't that make the term 'indie publisher' a contradictio in terminis?

The result is that 'indie' is a word with very little meaning today. It's more marketing buzzword than anything real. Even the gigantic company EA has published games that they marketed as 'indie'.

Let's piece all of this together. What do we have? The vast majority of smaller indie games doesn't make money. Hobby devs can use cheap, high quality engines to make bigger games. They can release their games on more open platforms to reach more people. And finally, the bigger games often aren't called indie. Combining this can lead to only one conclusion: in a few years the word 'indie' will mostly be interpreted as 'probably made by hobby developers'. In other words: the future of indie is amateur!

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.

Sunday, 30 August 2015

Opinions needed: which art style for Cello Fortress?

The gameplay of my live performance game Cello Fortress is nearly finished, but the graphics are still basic blocks with some crude textures. Recently I've been working on figuring out what style I want for the game, and I've ended up with two possible styles that I like: one dubbed "Surreal Architecture" and the other "Rough Polygons". Since I have a hard time choosing, I figured I'd just ask here. Which style should I use for Cello Fortress?

I've also added the pros and cons of each style as I see them. Several are just my personal taste so let me know in the comments if you disagree.

"Surreal Architecture" style

The basic idea of this style is that you travel through a world of surreal architecture. The surrealism is of the subtle sort: on first sight it might look like normal classical architecture, but if you stop and think for a second you realise this cannot be: buildings are too big and repetitive, it makes no sense to have a city with nothing but church towers, and why is there an area with giant organ pipes?

This style is inspired by the graphic novel series Les Cit├ęs Obscures (also known as Cities Of The Fantastic or De Duistere Steden) by Schuiten and Peters. To get an idea of their style, have a look at these beautiful images. To a lesser degree it is also inspired by the Rork series by Andreas (picture).

The main reason to do this style is that I love classical architecture. I haven't done a lot of 3D modelling recently and this kind of stuff is one of my favourite things to model so I'd love to get back to that. The biggest problems with this style are that the link with Cello Fortress isn't very clear, and that it might distract from what the game is all about: the live cello. So the main reason to do this style is that I'd enjoy making it so much.

As concept art I've made some basic environments in 3dsmax and even rendered a video as if it were the game:

Click for high resolution

Click for high resolution

Previz video of the Surreal Architecture style.

  • More unique and notable
  • Lots of fun to make
  • Very close to me as a person

  • Lots of work
  • Distracts from game's core (the live cello)
  • Gameplay less readable for players
  • Link between visuals and gameplay less clear
  • Needs serious optimisation for good framerate
  • Doesn't fit style of existing vehicle and turret art very well
  • Not entirely happy with this concept art yet

"Rough Polygons" style

This style is a lot simpler. It is mostly about big, untextured polygons. It has a rough rook and most of the potential beauty of this style comes from the lighting. Using a combination of pre-baked lightmaps and some simple tricks I think I can achieve a global illumination-look as in this image.

A big benefit of this style is that is does not distract from the gameplay. Cello Fortress is such a weird concept that I often need to explain quite a lot to the audience and this style won't distract from the core. It also helps that the gameplay will remain very readable under poor lighting conditions: I often perform with Cello Fortress at festivals and it is not rare to have a beamer projection on a rough wall with too much environment light. Such conditions make the game look a lot less bright and crisp than a normal gaming environment.

Click for high resolution

  • Very readable and understandable for players
  • Looks good with crappy beamers on bumpy walls
  • Faster to make
  • Higher framerate
  • Fits style of existing vehicle and turret art

  • Less original / notable
  • Not as much fun to make
  • Strong shadows on the floor might be too dark but are crucial for this look

Why am I not sure which style to choose? The Surreal Architecture style is much more fun to make and would stand out more, but it just doesn't seem like the best choice for the game. It has little to do with the rest of the concept and would distract from what it's all about: the live cello performance.

Which do you think I should make, and why?

Wednesday, 19 August 2015

Cello Fortress micro vlog #1: Big Chord Attack

I've added a new cello attack to Cello Fortress! Check this little video for a demo and explanation. :)

Sunday, 16 August 2015

3D printing Captain August

To use a 3D model for 3D printing it usually needs to be altered quite a bit, since 3D printing adds a bunch of additional requirements that rendering and games don't care about. I've recently done this for the first time so today I would like to explain the process and show the result.

Let's first have a look at the result:

Click for high resolution

I used a model I made in 2007 of Captain August, a webcomic that ran until 2010. The author of Captain August is a friend of mine, Roderick Leeuwenhart, and I made this 3D print as a birthday gift for him. Awesomenauts players might be familiar with Roderick's work as a writer: he wrote the voice scripts for a bunch of the latest additions to Awesomenauts, including Ksenia, Rocco and the Wildlife Documentary Announcer. Roderick also writes books: he wrote the "Pindakaas en Sushi" series. This title means "Peanut Butter and Sushi", which must be a delicious combination since I personally came up with the name. ^_^

Click for high resolution

To 3D print a model it needs to be one mesh without intersecting polygons, and the mesh needs to be without holes. When modelling for normal rendering geometry is often a lot of interesting objects and this mesh is no exception. The arms stick through the body, the eyes through the head, etc. To fix this I filled all the holes in all the individual objects by hand, and then used the boolean union tool to combine all the objects into one mesh and get rid of all the intersections. This crashed a lot because of the high polycounts (and probably also because I use the ancient 3dsmax 2009), but after a bunch of tries it worked and I got a usable model.

For the 3D printing I used Shapeways, a company specialised in 3D printing on demand with all kinds of different materials. They even do expensive stuff like silver, but that wasn't intended here.

I uploaded my 3D model into their system to see whether it would accept it. Shapeways runs a lot of automatic tests to find problem areas and it found a bunch that I had to fix. The biggest thing to look out for is whether walls and wires are not too thin. 3D printers can print fine details, but those might not be strong enough. The limits depend on the material and I suppose also the manufacturing process. With the Color Sandstone material I wanted to use, details cannot be smaller then 3mm (there are some further details to this, check the Shapeways site for more info).

In this case I had to fix things like the long pointy nose and the fingers. The fix was rather easy: I just made them thicker, and in case of the nose I also cut off the thinnest part at the end. I performed the fixes on the original model and then redid the boolean union step (including the crashes).

A bit more subtle is that the model needs to be balanced and not snap. Shapeways describes this as the "Sandcastle Rule: if this structure was made of wet sand, would it break?" However, exactly what the limits are is unclear, so I had no idea how far I could go. To be on the safe side I just made the legs and arm a lot thicker and asked Shapeways whether it would work. Within two days they had a look and emailed it would be fine. The model indeed worked out well so apparently this was enough.

3D printers cannot interpolate normals, so polygon smoothing does not work for them. This means that if you make something for 3D printing, you need to turn off all surface smoothing. If the model is not smooth enough at that point, you need to add polygons to make it smoother. In this case I was lucky: the Captain August model was made entirely through low-poly modelling with meshsmooth in mind. I could just increase the number of meshsmooth iterations to get more polygons and thus smoother surfaces. The end result is around 200,000 triangles.

To do a colour model Shapeways wants either a texture or vertex colours. Since my 3D model is mostly just flat coloured parts I made a quick texture with those colours and that's it.

This is one aspect where I think I could have done a better job: since notches and details are so tiny on a figurine they don't get the shading and sharp shadows that a full-sized model would and thus are less visible. A Warhammer model painter once told me you need to paint the lighting to compensate for this. I didn't think of that for Captain August and I think he might have looked better had I done this. For example, I could have made the insides of the creases a bit darker.

Shapeways does a lot of different materials, at very different price points. I wanted a full-colour figurine and didn't want to pay too much so I went for the Color Sandstone material. This is an interesting material: as the name suggests it looks like sand, but it is really a hard material.

From up close this material looks really weird. I wonder whether it was the inspiration for the strange material of the character Joy in Pixar's brilliant new movie Inside Out. It looks a bit similar. Looking at this concept art it probably wasn't, but I couldn't resist an excuse to mention how awesome Inside Out is (yes, I know, I'm a Pixar fanboy).

An interesting aspect of most current 3D printing techniques is that they print in layers. If you look closely, you can often still see those layers. In this model this is especially noticeable at the top of the head and in the wood. My wood mesh has a noise applied to it to make it look less flat. In the 3D print this generates unintended layer patterns that actually look pretty cool. However, in some spots it looks a bit too much like a map of terrain heights.

It turned out to be surprisingly difficult to make good sharp pictures of an object this small. I tried several lenses and lighting conditions to be able to make sharp pictures. I also tried a bathtub trick that I heard about somewhere: I put the figurine in an empty bathtub, giving an exciting all-white background. Pity the lighting conditions in my bathroom were pretty bad so these photos aren't as good as hoped. Still, funny idea.

To conclude this blogpost, here are a bunch of pictures of Captain August under several angles:

Click for high resolution

I'd love to do more art for 3D printing at some point, but for the moment the price of the actual 3D printing is just too high to do just for the fun of it. I'll first have to look for a good excuse to try this again. Maybe another birthday or something? ^_^

Sunday, 9 August 2015

Why adding multiplayer makes game coding twice as much work

Most gamers and reviewers these days expect almost any game to have online multiplayer. What they might not realise (or not care about), is that adding online multiplayer makes a game twice as much work to program. Most programmers who build this for the first time hugely underestimate how much work it really is. For those who have never made an online multiplayer game, here are some of the reasons why it doubles the programming effort needed.

Before I start, of course note that the real complexity of building multiplayer depends on the game. Adding a multiplayer match-3 minigame to Mass Effect probably wouldn't be much work compared to the main game, but that isn't realistic: big, complex games usually also have big, complex multiplayer features. Roughly doubling the time it takes to program a game when multiplayer is added is in most cases a good guideline.

The basic cause of all multiplayer complexities, is that it takes time for a message to travel from one computer to another. This might take anywhere between a few milliseconds and a few seconds. Whenever you need to know something about another player, you always have to take into account that you don't know when the answer will come. To make things worse, it's impossible to know exactly how long any specific messages takes and latency might vary wildly between packets.

Gameplay synchronisation
All players need to have the same view of the game world. When things happen on one computer, packets need to be sent to make sure all computers know about it. This adds a lot of complexity to an otherwise simple game, because the game suddenly needs to be able to put all the information about the game in packets and send those over the internet. And what to do if we want smooth animations while some packets take way longer to travel over the internet than other packets?

In a normal game, when you want to start a match, you just do so. In a multiplayer game, computers first need to talk about that to make sure all computers go into the game together. Since sending messages takes time, you need to wait for answers to come back. But what if a message takes longer than expected? Is it indeed coming later and should we just wait, or was the other computer suddenly turned off and is the reply never coming? Basically, any communication you do needs a timer to keep track of how long you are waiting and to cancel communications if the answer takes too long. And, also important: you need to handle if the message unexpectedly comes in after you decided to continue and not wait for it any more!

Gameplay balancing
All the other topics in this list are about tech, but of course game design for a multiplayer game is also really complex, especially in the balancing department. Our game Awesomenauts now features 22 characters and a thousand upgrades, and more are underway. What if some very specific combination of characters and upgrades is way too powerful?

Even with thousands of hours of balance testing you can still be certain further balance issues will be found once your game launches. Even Blizzard, with their extensive beta periods, never manages to get balance completely right at launch. If your game involves any kind of balance, then be prepared to spend ages getting it right, and more ages to improve it after launch.

Modern internet connections can handle lots of data, but not everyone has such fast internet, so any commercial game needs to be able to run on low bandwidth. Most games seem to settle for something around 10 to 20 kilobytes per second as the minimum bandwidth required to play the game. Awesomenauts is no exception. Updating dozens of characters lots of times per second without using way more bandwidth than that requires some really smart optimisation tricks.

If your game uses any kind of servers, then those better be prepared for any number of players. What happens if all of a sudden a thousand players all try to join matchmaking? Writing scalable server code is incredibly difficult. Testing it is a challenge since you can't easily get thousands of people to run your game simultaneously, especially before launch.

With Awesomenauts we once had a free week in which the concurrent player count went from 1,000 to over 12,000 within 24 hours. If your netcode and servers can't handle success, then you won't have it. One workaround for this problem is to not have servers of your own at all: Awesomenauts launched using only the services that Sony/Microsoft/Valve provide. Since those are scalable, so was Awesomenauts. I expect that if it had been 100,000 instead of 12,000 it would still have worked, simply because Valve's system are used to much more. Still, we spent a lot of time before launch analysing and testing our code to make sure it really was as scalable as we thought.

One particular topic that may seem like a detail, but turns out to be horrible, is inviting people. On modern platforms like Xbox, Playstation and Steam players can invite their friends to play with them. The complexity here is that these platforms allow players to accept invites from basically anywhere. Not just while in the menu or while playing another match, but also during a loading screen, during the intro cinematic, from outside the game or even while joining a game based on an earlier invite!

To give a nice example of something that could happen on the Xbox 360: while a player is in the loading screen, another player on the same console might pick up the second controller, log in with another account, and accept an invitation to play with someone online. Now the first player's match should quit as soon as the loading screen ends, the second player should become the Active Player and should join his match. This particular situation is really cumbersome to handle, and it becomes way worse when you realise there is an enormous amount of similarly weird combinations of events and they all need to be handled correctly.

Console requirements
Which leads me to the final topic here. Modern consoles have long lists of requirements that games need to abide by to be allowed to launch, and this list gets a lot longer if your game has online multiplayer. If any of the weird combinations above goes wrong in the game then Sony, Microsoft or Nintendo might refuse to release it until it's fixed. Of course, console manufacturers are right to demand quality for all the games that launch on them, but it does take a lot of extra work to build.

Just starting the game to test your code isn't good enough for an online multiplayer game. Instead, you need to start several instances of the game, make them connect to each other, and then test whatever you just programmed. Also, the number of possible combinations of events explodes in online multiplayer situations, so not only does testing become much more cumbersome, it also requires many more tests.

I could easily have added dozens of other items to this list, but I think you already get a clear picture of how complex creating a multiplayer game really is. Many programmers think they can add online multiplayer to their game in just a month or two, but for a game of significant size it generally takes way longer than that, especially the first time you do it!

Saturday, 25 July 2015

Using key poses to prototype character animations

When creating a new game character it's crucial to get a feel for his in-game poses and movement as quickly as possible. During the visual design of a character you shouldn't just wonder how he looks, but also how he moves. If a character looks cool while standing still but bad while in motion, you have a problem. Not only is this a key part of a character's personality and look, it also helps discover problems early on. Maybe that big weapon is obstructing the dynamic actions your hero needs to do?

This is why our artists first draw key animation poses and throw those into the game as quickly as possible. During early development of a new character for Awesomenauts we playtest with just those key poses, without any animation. Less than 10 frames represent the entire movement set of the character. One frame for a jump, one for a fall, a couple for a walk, one for each attack, for sliding to a halt and for idling, and that's roughly it.

It's surprising how smooth and awesome a character can already feel with just one still frame per action. Doing this also has another benefit: the game design feels much more solid if a character isn't a box and doesn't look like some other character you already have in the game.

Of course, the phase after this is to create the actual animations. A finished character in Awesomenauts consists of hundreds of animation frames. But today I'd like to focus on the prototyping and concepting before the real animations are made.

Most of the characters we added to Awesomenauts during the past two years were animated by Ronimo artist Tim Scheel. Tim is a master at drawing dynamic poses and experiments a lot with the animations.

To show how this works I have dug into our archives and made a video of how Scoop, Nibbs and Rocco moved before they got any real animation. I think it's pretty amazing how powerful these already look!

Early animations of characters in Awesomenauts, using key poses only.

A nice thing to notice in this video is that Tim adds some quick in-engine squash-and-stretch effects to make it look a little bit more dynamic. This is especially noticeable in Nibbs' idle and attack frames.

Before Tim puts anything in the game he first makes animation concept art. This is just a sheet with a lot of sketches of what the various animations might look like. Here are the sketches Tim made for Rocco:

Click for high resolution

In Rocco's first gameplay design he couldn't move while doing special attacks. This allowed Tim to draw some really cool attack poses, as you can see in the sheet above. Later the game design changed and Rocco wasn't forced to stand still during attacks any more. This means Rocco needs to do his normal movement animations while doing a special attack, so the attacks changed from character animation to purely special effects.

A particular challenge when designing a character is the amount of detail. Awesomenauts has a strong cartoony style in which microscopic details don't really fit, especially since characters aren't that big on the screen. This means details that were in the concept art are often removed when the in-game version of a character is created. You can already see this happening in the concept art above: some shots have two little straps in the part around the neck, while others only have one of those, reducing the amount of detail a bit.

Rocco's scars were also a challenge: initially he had a scar on his nose but this turned out too small. The scar around his eyes was kept after making it a lot bigger to be more legible. The headphones had to go for a different reason: they had too little to do with Rocco's backstory and personality.

Another example of removing details can be seen below in Nibbs' animation concept art. Tn the bottom right you can see Nibbs' tongue hanging out while running. This is a little detail that I absolutely love: it makes Nibbs look so much more like an overly enthusiastic puppy dragon. However, it turned out to be too small and illegible in the actual game, so it was removed. How much detail there is, is an important part of any visual style, so this needs to be kept somewhat similar in all characters.

Click for high resolution

Another great example of animation influencing a character's visual design can be found in Ori And The Blind Forest, one of my favourite games of recent years. In a presentation at GDC animator James Benson mentions that Ori has a tale because it helped him show the direction of movement better. It's interesting to hear that a crucial element like a tail is there mostly because of the animation, not because of anything else. Be sure to check out this video of his highly interesting presentation!

Back to Awesomenauts! Because Scoop doesn't have legs, his walk cycle was a challenge. As you can see in the concept art below Tim drew a lot of poses for the walk cycle to try different things and find something that works.

Click for high resolution

When drawing game art one must never forget the goal of the art: to be used in an actual game. The requirements of the gameplay need to be kept in mind. In Awesomenauts this means that melee attacks allow for much more freedom than ranged attacks. Melee attacks are generally just an animation that plays, so Tim go do whatever he wants to make it look awesome. Ranged attacks however need to be aimed at the cursor, which means that the gun-arm needs to be able to rotate freely even during the attack. Not being able to animate the gun-arm is a huge limitation to the animations. Such gameplay limitations are important to keep in mind and this is why Tim enjoys animating melee attacks more than ranged attacks: more freedom!

(For those interested, in 2012 I wrote two blogposts about making 2D characters aim in all directions and about shooting animations in Awesomenauts.)

A couple of years ago I hadn't realised that animations need prototyping and playtesting just as much as any other part of a game. The video at the start of this post gives a great example of this. I hope you enjoyed seeing Tim's animation concepting as much as I did!