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!

Sunday, 19 July 2015

Building your mental toolbox for solving coding problems

Solving complex coding problems is hard. What to do when the solution isn't immediately clear? Sometimes you might just get stuck on something, or you might have a solution but are wondering whether there is a better structure or algorithm. No matter how good you are as a programmer, there are always things that are just too complex to easily figure out. How to handle those? The simplistic answer is that you should simply get smarter and more experienced. This is also a lazy answer, as it means you can just keep doing what you do and hope you get better over time. What you can do right now is work on your mental toolbox, your own personal set of approaches and techniques to help your mind tackle topics that are too complex to otherwise solve.

By "mental toolbox" I basically just mean a bunch of tricks to help you think. Such tricks are very personal: what works for one person might not work for someone else. The important thing is to try different approaches and find out what works for you. In today's post I would like to share my own tricks, hoping some of these can help others as well.

Make schemes

Don't try to create an overview in your head, do it on paper! Draw flowcharts, timelines, mindmaps, UML diagrams, lists, relationship graphs or whatever else that might help you see the entire problem, or see the problem in a different light.

Write down all your thoughts

This is my most personal trick, as I have never heard of anyone else who does this, but it is also my best one. Whenever I am truly stuck I fall back to writing down all my thoughts.

To me the biggest problem when trying to solve something is that at some point my mind grinds to a halt as it tries to hold too many thoughts at once, leaving no room for new ones. This is a common thing in humans: in psychology it is called "The Magical Number Seven, Plus or Minus Two", stating that the average human can hold 7 ± 2 objects in working memory. The problem is that as soon as I have a bunch of thoughts that I think are interesting, I try to remember them and lose the capacity to come up with new ones.

My solution is to just write down all my thoughts, including the bad ones. For a complex problem I might scribble an entire A4 full of miniscule notes. For half of those I realise they are irrelevant before I even finish writing them down, but this doesn't matter. The only point is to clear my mind: whatever is on the paper doesn't have to be remembered, so there is room for new thoughts. Letting my mind ramble on and writing it all down often leads me to a solution. This is by far the strongest tool in my box.

Split the problem into smaller pieces

If a problem is really big it might help to just ignore half of it and only solve the other half. Often the parts of a problem depend on each other and trying to figure out the dependencies might be what makes the problem too complex to solve. Try solving only one part while ignoring everything else. Only once the part is solved, try to figure out how to make it work with the rest of the problem.

(More info in this blogpost on AI movement in Awesomenauts)

Try different angles

It can help to force yourself to try a completely different angle, sometimes to even try angles that might seem ridiculous at first. A good example is randomness: if you can't find an exact solution, you might try to generate random solutions and choose the best one. This is rarely the best approach, but looking at it from an angle like that might generate new ideas. For example, this particular approach makes you think about how to compare random results to figure out which is best. The algorithm for comparing results might be the starting point of a real solution. The goal is to force yourself to let go of your current line of thought and try completely different angles.

Just start coding

Sometimes you already have some ideas on how to tackle parts of a problem, but not the rest of it. In this case it might help to just start coding. The code you write will probably end up being thrown away once you figure out the real solution. This is fine: the goal is to turn general ideas into concrete code so that you understand it better. When using this approach be sure to throw away the garbage code afterwards!

Leave markers to avoid being sidetracked

Often while programming something complex I come up with additional problems that I will also need to solve, or edge cases that need to be handled. Doing those all at once makes me lose focus, but I don't want to ignore them either, because I might not remember them later on. So whenever I think of something, I leave a small comment in my code as a reminder and leave it at that, allowing me to keep my focus on one thing at a time. To be able to find those comments quickly once the core code is finished, I add the letters "QQQ" to them.

The internet

Caption Obvious would like to mention that you can search online for solutions.

Ask for help

Surprisingly, quit a lot of programmers would rather be stuck on something for days than ask for help. I have supervised a ton of interns and quite often they keep chewing on a problem without real progress for way too long before asking for help. Asking a question online seems to have a similar barrier. There is no shame in looking for help or discussing a problem with someone else, and often just explaining the problem to someone else clears up the mind enough that you figure out a solution yourself.

Ignore performance and requirements

Often it is easier to solve a problem in an inefficient way than in an efficient way. Letting go of performance requirements is a great way to open your mind to solutions. Often an efficient solution is just a clever variation on an inefficient one.

The same goes for requirements. If you are stuck, let go of all the additional requirements and first try to solve only the core problem. Then try to adapt your solution to those requirements.

Know lots of programming patterns

I often struggle with finding a really good class structure to make my code as clear and maintainable as possible. For such situations it helps to know a lot of design patterns. Design patterns are common structures that can be applied to specific problems. There is an enormous amount of design patterns and the more you know, the better. Wikipedia has a nice overview, including well-known ones like Observer, Factory, Singleton and Strategy.

Know lots of algorithmic techniques

Many problems are completely different, but can be solved in similar ways. Often you can find a solution by trying approaches you have seen in other algorithms. The more approaches you have seen, the larger the chance you know something suitable. Here are a bunch of categories of solutions of which it is good to have seen a couple of examples of algorithms that use each approach:

  • Recursive algorithms
  • Heuristics (or: approximate solutions versus exact solutions)
  • Greedy algorithms
  • Dynamic programming algorithms
  • Iterative improvement (running the same algorithm over and over again to improve the result with each run)
  • Smaller steps (splitting a simulation into smaller steps instead of once with a big step, like in this collision trick I used in Proun)
  • Monte Carlo versus Las Vegas algorithms

Take your mind off the problem

If all else fails you can choose to simply leave the problem be for a day or two and work on something else. A solution might pop up when least expected. Under the shower, while cycling or taking a walk. I personally get lots of good ideas on the toilet... Key to this approach is to allow your mind to wander. Don't fill every waking minute of your day with entertainment/work as your mind would be too occupied for new thoughts.

Your mental toolbox is something you can improve and work on. You can experiment with new approaches and ask others what theirs are. Give all kinds of things a try, and see what works for you.

What are your tricks for solving complex problems?

Thursday, 14 May 2015

Swords & Soldiers II introduction trailer

Our awesome introduction trailer for Swords & Soldiers II just went live! Koen made a really nice trailer for our new game, with help from Ralph and Gijs. Swords & Soldiers II is launching on Wii U next week (on Thursday 21 May), exciting times! :D

Saturday, 2 May 2015

Making gameplay stand out against rich backgrounds

Good game graphics are not just about being pretty. Equally important is that they communicate well. The richer and more detailed a visual style becomes, the more difficult it is to communicate gameplay clearly. With the amount of detail and variation we wanted in Swords & Soldiers II it was a challenge to make the units, spells and other gameplay objects pop out against the colourful backgrounds. Today I would like to show the tricks our artists used to make this work.

The reason this is important is that otherwise it would not be clear which objects are interactive and which are not. For example, is a tree a wall that I cannot pass through, or just a backdrop that has no effect on the gameplay? Ideally these kinds of things are immediately and intuitively clear to the player, without requiring any explanation.

Our new game Swords & Soldiers II launches on Wii U on May 21st.

The easiest way to achieve visual clarity is to not have any backgrounds or effects. Just a flat-coloured background with the gameplay objects. This looks horrible of course, so we want to add more art to the game. In general, the more you add to the world, the more difficult it becomes to distinguish gameplay objects from graphical fluff. In truly rich visual styles achieving clarity is a challenging balancing act. Objects should look like they belong in the world but at the same time pop out. The creators of a game can even choose to let go of visual clarity if they value visual beauty more.

At Ronimo gameplay always come first, especially when creating highly tactical games like Swords & Soldiers II and Awesomenauts. This means our artists had to employ a lot of clever tricks to combine the lush visual style with gameplay readability.

Our art director Gijs Hermans is responsible for maintaining a consistent style throughout the game. For this blogpost I interviewed Gijs about the tricks used in Swords & Soldiers II. Our level artist Ralph Rademakers showed me some additional tricks. Below I will be showing the clever techniques they used to make the gameplay stand out.

To make characters, spells and towers stand out against background objects they are drawn in a different style: with outlines and cell shading. The backgrounds are more painterly, lacking outlines and with more brushy and subtle lighting.

In many Disney classics, like Jungle Book (top), animated objects are in a different style than non-animated objects. Our artists love this combination so they even combined the animated and non-animated styles within the Viking base for its different parts. Note the difference in outlines and shading between the animated caterpillar and the ship itself.

(Click for high resolution)
The first version of the Viking base was more in the style of the backgrounds. To make it stand out more the final design was pulled more towards the gameplay style.

Early in development characters had hardly any shading (top), making their shapes less readable. Their final designs (bottom) have deeper shading and more saturated colours.

(Click for high resolution)
Our artists tried a lot of different shading and outline styles for gameplay objects. This image shows a series of early experiments with the goldmine. All the way to the right is the final design. Be sure to click this image for full resolution, since this scale does not show the differences well.

Background graphics are less saturated. Our level artist Ralph even used such atmospheric perspective on objects very close: the house here is directly behind the playground and thus too close for 'real' atmospheric perspective. Ralph desaturated it anyway to make gameplay stand out more.

Sheep are sometimes gameplay objects and sometimes background objects. To make this clearer they are blended a bit towards a single colour when they are in the background or foreground.

Background brightness is often changed to make gameplay stand out more. In both of these images the background is brighter near the gameplay layer, adding contrast. Higher up in the screen no gameplay happens, so there 'normal' colours are used in the background.

Gradients are not the only way to make the playground stand out: here the bushes directly behind the playground don't have snow, turning them into a green border between the snowy playground and the snowy trees. It would be weird if only these objects lacked snow, so snow is also removed from other objects like the rooftop in the background on the left.

Corpses have gameplay functionality but having lots of them really clutters the view. We therefore desaturate corpses to make soldiers walking in front of them stand out more.

Depth of field blur on the background not only adds depth but also makes the foreground pop. We use this trick in both Swords & Soldiers II and Awesomenauts to make gameplay more readable.