Pause

I would really like to actually finish Proun soon, so I am going to put this blog on hold for a month or two. Writing for this blog is a lot of fun, but takes several hours every week, so it slows down Proun too much for my own good. Especially since this blog, playing in a baroque orchestra, furnishing my new appartment and working on Proun all need to be cramped into that same bit of spare time I have!

When this blog returns, I will have a lot of stuff to talk about, like my 2.5D area light shadowing technique, real-time camera mapping, the awesome in-game tools we developed for Ronimo's Secret New Game, Tha Prototypinat0r, and a lot more!

To give a teaser and pause this blog in style, let me show you an image of another topic that will be discussed at some point after the break. This is a model I generated with my SolidMotion script:



I'll be back! See you later! ^-^

Meta-shapes emerging from perspective

Perspective is a beautiful thing. Look at an object from a different side, and you get something new. Move your head a little bit and sides disappear and appear, lines align or dis-align. All kinds of things are happening to the world in front of you, just by moving around.

I have been fascinated by this for years now. My mother sometimes asked me why I was staring at something and slightly moving my head to the left and right. Well, to change the composition, of course!

I am aware that this is probably a quite strange hobby of mine, but let me give an example to show what I mean. The photograph below was in De Volkskrant (a Dutch newspaper) a while ago.

(Photo by Joost van den Broek)

I think this is a powerful composition. The big boat, which is balanced in the view by the small boat to the right edge. The strong perspective in the containers, which leads the eyes towards the distance, where the ship is heading. Almost all important lines here are either exactly vertical or horizontal, or they lead to the same point at the horizon. Simply a strong composition.

However, something else in this photograph caught my eye. There is a meta-shape here. The edge of the ship and the horizon exactly coincide, creating a new line. This line does not actually exist, but the perspective creates it. It only exists when this scene is looked at from this angle. It is a meta-shape emerging from perspective.



In Proun, I have partial control over the camera. The player can rotate it around the cable, but cannot look left or right. So I can create meta-shapes like this, and unconsciously, the player will sometimes see them. In the screenshot below, two balls form a new meta-circle that only exists from this perspective.



(The purple ring of the bigger ball could also be called a meta-donut, although I don't know whether it would be a meta-donut-with-chocolate or just a normal meta-donut-with-sugar.)

By the way, last week, when I watched the incredibly beautiful Tron: Legacy in 3D at the cinema, I realised that this effect is actually destroyed by 3D. Tron features a lot of incredibly strong compositions, but I feel that the 3D tears them apart. I think the lines and shapes form a stronger image when flattened. So to my surprise, this was actually the first time that I wished I had watched a movie in 2D instead of 3D.

Finally, there is something else hidden in the photo of the boats. By just taking the main lines, I can create an abstract composition. This is a very simple thing, but since the original image has such a strong composition, these lines could form the basis of a new composition in Proun. I could place coloured objects to create a 3D scene that features these lines when looked at from a certain angle.



I won't deny being a crazy idiot, staring at random things while moving my head around. But at least I can pretend it has a purpose! ^-^

10 Tips for the lonely programmer

On the original version of Swords & Soldiers for the Wii, I was the only full-time programmer in a team of 7 developers. On average, there was also 1 programming intern around, but still, this means that the number of programmers was really low. Especially if you consider that this was our first console game!

When working in such a situation, you really need to think smartly about what you make and what you don't make, and plan your entire programming routine around this.

I think about these kinds of problems a lot, so for a presentation at the Festival of Games in April 2010, I boiled my ideas down to these 10 tips for the lonely programmer. Obviously, this is no rocket science, but I think these guidelines may help young gamedev companies and student projects.


It's better to get it working quickly and then add stuff, than to get stuck with more than you can chew. Especially since everyone overestimates his own coding speed.


For example, do not try to tweak the walking speed yourself. Make sure a designer can do this.


Emphasis on the word minimal. Make sure to create something so that levels can be designed and such, but also make sure to not waste half your project making more fancy tools than necessary. Notepad is a perfectly fine level editor.


Keep your code clean at all time, even close to deadlines. Once code becomes a mess, everything you add will also be a mess.


The more bugs and crashes your game already contains, the more difficult it is to see whether what you just added is broken. You will need to fix those bugs at some point anyway, so just do it righ away and keep your game stable.


No need to compete with Uncharted 3. Don't spend your time optimising for the ultimate performance. Instead, focus on making the game good and accept that maybe some computers won't be able to run it.


There are a lot of rules about good programming on the internet. Many of them are a lot of work and not necessary for a small project. For example, it is totally okay to not build your own memory manager and it is no problem to do lots of dynamic allocations in run-time. Just do what works for you.


This is not for student projects, but for start-ups. Interns love to work for real games. Don't feel ashamed if you let an intern create some awesome tools for your project.


Say "No" to almost every idea you hear, especially closer to deadlines. To keep the game concept simple, you will have to protect it from getting bloated. If there is time left, you can always add stuff later.


Game designers and artists depend on your work, so be sure to involve them in why you choose to build some things instead of others. Ask them simple questions, like this one: "I don't have time for option A, but either B or C can be done. Which do you want?" Involving them makes them less frustrated at hearing "no" so often. Otherwise you may end up like this:



Feel free to print these 10 tegeltjeswijsheden and hang them on your wall, and refer to them at all times.

Also, feel free to tell me these are all incredibly obvious. ^-^

PS. For those who expected dating tips after reading the title: that is not part of my field of expertise, so you will have to look elsewhere for that... ;)

Resetting versus re-creating

One weird aspect of my career as a programmer is that I never worked under someone with more experience. I started Ronimo Games right out of school and was the only programmer, and thus directly the lead. Since I did my internship as a 3D artist, this means I never saw how other companies handle their programming. The result is that all of the coding style decisions at Ronimo are just based on my own opinion, and I may be missing some important things that I simply never thought about.

Interestingly, we have been hiring some programmers in the past year, growing the team from just me to five full-time programmers next March. Although the two programmers who have already been working with us for the past year (Ted and Maarten) are former interns of mine, it turned out that as soon as we hired them as real employees, they actually had Opinions. Which is great, because not just blindly doing what I come up with greatly helps against tunnel visions!

One important thing I learned that way recently, is that resetting and reusing objects is error prone, and that a structural change can avoid this.

Let me explain this through an example. In Ronimo's Secret New Game (tm), the player can control a character that when killed, will respawn after a while. My method for doing this, was to hide the character on death, and then reset him when he is respawned, and make him visible again so that the player can continue playing with him.



The problem with this is, that it is easy for the programmer to forget some elements when hiding and resetting. The character consists of many graphical elements, and since they are in very different categories (like healthbar, shadow, character, special effects, etc.), it is not feasible to put all of them in a single list. So when programming the hiding, I need to think of all these elements. The same kind of issue occurs when resetting: many aspects need to be reset (like combo counters, cooldowns on actions, poison time remaining, etc.), and again I need to think of all of them when resetting.

Adding new features is even worse: I always need to remember to add them to the hiding function and to the resetting function. Forgetting one of them results in a bug. Not hiding something is an easy bug to spot, but not resetting something is a lot more difficult to notice, since many effects may usually time out before the respawn timer is over. So it is easy to overlook that sometimes a cooldown may not have expired yet when the player respawns.

This may seem like a subtle and irrelevant issue, but it is very easy to accidentally introduce bugs here when developing a game with more then one programmer, since not everyone may know about these details. So I had been struggling with this for a while, without being able to think of a good solution.

Recenlty, my colleague Maarten came up with a really simple fix: why not completely delete the character on death, and re-create him on respawn? Now we don't need to hide or reset anything. Win!



It turns out that this simple principle actually applies to a lot of things. For example, in Swords & Soldiers, we create all the menus when the game starts, and then just hide them all, except for the one that is currently in view. But why not simply delete them entirely?

Kind of strange that I hadn't thought of this myself, really!

Experienced C++ programmers may counter this argument by saying that dynamic memory allocation costs performance, so resetting is more efficient. This is probably true in most cases. However, I consider design that prohibits bugs to be a lot more important than performance. Current console hardware is very fast and we are not trying to make the next Killzone or Uncharted here.

Anyway, this could also be implemented using placement new (which constructs objects on a piece of memory that you allocated before, instead of requesting new memory). Finally, we have a really fast custom memory manager at Ronimo, so small allocations (up to 256 bytes) are very fast anyway.

Although I didn't think of this re-creation trick myself, it very much fits the coding style at Ronimo: we always try to find structures that make it as difficult as possible to accidentally introduce bugs. Destroying and re-creating objects instead of resetting and reusing them is a great example of this philosophy! Although this example is no super-complex science, I think that one of the most important skills for any programmer is to constantly look at your own code for these kinds of small improvements.

The role of the game designer

(Due to moving to a new city (Utrecht), I didn't have the time to gather balancing data for Swords & Soldiers for the post I promised last week. So that topic will be for another time!)

A little while ago I was asked to judge a couple of student game projects from the Utrecht School of the Arts. Seeing a glimpse of the group dynamics that happen within these projects is mightily interesting!

The main thing I saw in that group, was that they had no idea what the game designer's role should be. I think the things that went wrong in their team, are nice examples of how I think a game designer should function. Of course, there are many ways in which a game development team can function, but this is how I personally see it.

"I tried pitching my concepts to the rest of the team, but they didn't want to build them. Could you teach me how to communicate my ideas better?" - the game designer

No. This is entirely the wrong way of thinking. In a team of creative people, the game designer does not have to be the one to come up with the basic concepts. This should be a group process. Through brainstorming and things like that, ideas should come up that the entire team likes. Anyone can have good ideas, not just the game designer.

Many game design students seem to think that coming up with ideas is the main job of the game designer. It is not. The idea is just 1% of the development process and the game designer is not better at this than the other people in the team.

"For the control scheme I researched how other games did this, implemented it, and tweaked the settings to make it feel good. I worked so hard, are you not impressed?" - the programmer

No. This programmer worked hard, but on the wrong things. To do their job, game designers need tools from the programmer. So the programmer should implement the control scheme, but he should not be the one to tweak and experiment with it. The main role of the programmer is to empower the rest of the team to do their job. Keep that in mind at all times! Make settings files, or something like that, and let the game designer do his job!

"We divided such tasks, so I was in charge of the playtesting sessions." - the 3D artist

Why split these tasks? In small teams, it is often difficult enough anyway to constantly keep the game designer busy, since he is probably often waiting for new features from the programmer. Creating questionnaires and analysing playtests is definitely something the game designer should be doing!

"The level was finished way too late, because no one was in charge of level design." - the team

Euhm, what? You have a game designer in your team, why is he not automatically in charge of the level design? I know that in large teams, game designers and level designers have separate roles, but in smaller team, I think they should usually be one and the same person. It is quite rare for a small game concept to require enough game design work to keep a game designer occupied full-time during the entire project. Since level design is all about gameplay anyway, the game designer is a natural fit to also be a level designer.

Also, I can think of dozens of games where there is hardly any role for the game designer at all if he would not do level design as well. Just think of the old Mario games. Almost all design hours there would be in the level design, hardly anything in the game design!

"I'm a game designer, I cannot create things myself." - the game designer

Learn some tools, RIGHT NOW! It sucks to always have to wait for a programmer who also needs to do other things. There are tons of tools that are fit for a game designer to create small prototypes. Create mods in the Starcraft II or the Unreal III editor, or create little playable thingies in Gamemaker or Virtools. Also, take scissors, paper and dice and create paper prototypes. Learn to make stuff!

"Then what does a game designer do?" - the game designer's mother

Let me give some examples:

• tweak values (like walking speed, jumping height, health, etc.)
• design levels and puzzles
• design tutorials
• organise and analyse playtests
• balancing
• research existing (similar) games

Finally, I'm going to end this blogpost with a nice little blunt remark of my own:

”Game designers who lack the skills to actually create things are useless fools.” - Joost van Dongen

The many faces of balance in an RTS

We are growing our team a bit further and are looking for yet another programmer at Ronimo, to write platform-specific code for the Xbox 360 and Playstation 3! This time someone with good knowledge of C++ and a couple of years of programming experience (though not necessarily in the games industry). Click here for more info! ^-^


I guess anyone who has ever played a strategy game, has an idea of how complex balancing the powers of three very different factions is. However, while we were developing Swords & Soldiers, I learned that there are several other forms of balance, and an RTS needs to achieve them all at once.

The balancing was done by my colleagues Olivier, Jasper, Fabian and Tom and I learned a lot of this from them. Especially Olivier is a hardcore Starcraft player and he brought in a lot of knowledge of what he had learned by following Blizzard's patches and articles on the topic over the years.

So, let's have a look at some of the many forms of balance in an RTS!

1. Faction balance

This is the standard balance that most people mean when they talk about balancing an RTS. Swords & Soldiers has three very different factions: the Vikings, Aztecs and Chinese each have different units and spells and even collect mana for their magic in different ways. The factions may be very different, but if you are a good player, then you should be able to win with each of them. So who wins is decided by your skill, not by which faction you play.



2. Beginner balance

While standard balancing looks at the situation for good players, it is also interesting to look at beginners. How difficult is it to play with a faction at all? In Swords & Soldiers, we deliberately chose to not make the game balanced for beginners. The Vikings are our easiest faction to understand the basic strategies, while the Chinese are a lot more difficult to play with. We wanted to add variation and spice to the game by making the factions different in complexity of the core strategies.

Interestingly, becoming really good is most difficult with the Vikings. Although their basic strategies are easy to understand, their pro strategies are probably the most complex, requiring more skills and units to be combined.

3. Balance between tactics

Each faction should have many different useful tactics, and most of the time, several viable options should be there for the user to choose from. If a faction is only strong with one specific tactic, then you always play that and the game gets boring. Also, the opponent will know exactly what to expect. So there is not just the balance between factions, but also the balance inside a single faction, where all units and many tactics should be of use.

4. Balance on different maps

When the game is balanced on one map, the balance might be broken on another. For example, in Swords & Soldiers, the Chinese need towers to get mana, so a large map with lots of room to build and defend towers makes them stronger. To reduce the complexity of balancing, we balanced for one particular map (the first medium map) and added the other maps for flavour and variation. In online multiplayer, we only allow for 4 of the 9 skirmish maps, because we think the balance is best on those 4 maps.

5. Early game balance versus late game balance

At the start of a match, you don't have a lot of upgrades yet and your choices are limited. The balance at this point is totally different from late in the game, when both players have upgraded all their spells and units. A balance where one faction is stronger early and the other late is not good: if the early rushes are over, you will already know who is probably going to win. That's pretty boring. On the other hand: having some variation in how fast you can rush does add variation between the factions, so making this completely equal might make the game boring as well!

6. The amount of fun in the balance

This type of balancing is really difficult to measure, but quite easy to feel: some tactics are just lame. Spamming a single unit all the time is really boring, so that better not be a good tactic! The following Viking tactic is an example of how things should be: a very strong combo the Vikings can do is to build Frosthammer units (who do area of effect damage and stun), then freeze a large group of enemies with Snowstorm, and then ram the Frosthammers into the frozen enemies with Rage. Doing this requires skill, speed and knowledge, and is pretty strong, so the player will probably feel great doing this!

7. The amount of luck in the balance

A Chinese player can start out with melee units or ranged units. At one point we had a balance in which, depending on the opponent's opening move, this would mean a certain win or a certain loose. This is balanced: you have a 50% chance that the enemy happens to choose the opening move that lets you win. However, this is based purely on luck and thus requires no skill at all. So even though the faction balance was good at this point, this balance was broken!

A little bit of luck is a good thing to have in a game, though. Players who loose a match tend to feel a lot worse if they know it is entirely their fault. If there is also a little bit of luck involved, then they can blame their bad luck and feel less bad about their skills. Taken to its extreme, luck is why a game like Mario Kart (which features tons of luck through the upgrades) is so enjoyable for beginners: it still lets them win once in a while against better players.

Complexinat0ring!

As you can see, balance has many faces. The biggest problem with it, is that even the smallest change might affect all of the types of balance at the same time, plus it probably affects several match-ups of factions as well. Even for a small change, it is practically impossible to predict what effects it will have on the whole. Therefore, it is incredibly difficult to get the balance right for all of these aspects at the same time.

In terms of balancing, Ronimo's Secret New Game is a lot more complex than Swords & Soldiers, so I am really curious to see how well we can pull it off there!

Since balance is such an interesting and complex topic, next week I am going to talk about some of the pitfals of analysing it, both for developers, and for players and reviewers.

AI in Swords & Soldiers (part 2)

Last week I explained how we ended up with Halo 2-style behaviour trees in Swords & Soldiers, but I didn't really dive into how they actually work. So now let's have a closer look at how we worked with them.



The small AI above gives a nice example of how our AIs work. The first thing to note here, is that behaviour trees are based on priorities. It is assumed that the AI will always want to perform the top-most action and will not look any further if that action can be executed. In this case, the action at the top is shooting lightning at a Necromancer (useAbility). Necromancers create lots of skeletons, so killing them first is usually a good idea.

To make this priority system work, the action at the top must have strong requirements, for otherwise the actions below it will never be executed. In this example, this is indeed the case: lightning is only used if an enemy Necromancer is actually near, and if you have enough mana to shoot lightning.

Since the AI must also mine gold, the action below that is building workers (createUnit). In Swords & Soldiers, players cannot have more than 10 workers, so as long as the AI has less then 10 workers (unitCount), and it has enough gold (goldAmount), it will build one worker every ten seconds (timeSinceLastUnit).

Finally, whenever not shooting lightning or building workers, this AI will just pump out as many Berserkers as possible (createUnit, at the bottom).

Now the fun of this system is that these behaviour trees are quite simple to work with, so you don't need a programmer to make them. You do need a designer who is good a logical thinking, but that is something I think every designer worth his salt should be good at in the first place.

The key to make keep these trees manageable, is to have enough blocks to work with, and to hide all complexities inside these blocks. A simple example is the unitNear block. The C++ code for this block looks for all the enemy Necromancers in the level and calculates the distance to each of them, to see whether there is a Necromancer near. The complexities of finding the Necromancers and such are hidden in a C++ class, and the designer doesn't have to know anything about that.

In Swords & Soldiers, I think we did not do this very well, though: our skirmish AI is incredibly large and complex. By having more and smarter conditions and actions to work with, I think our designers could have made some trees in half the size.



An interesting side-effect of these trees, is that they are also excellent for story scripting. Swords & Soldiers often triggers little cut-scenes with dialogues and such in the middle of a level. Deciding when the trigger those, can easily be done inside the behaviour tree, since the behaviour tree already has all these actions and conditions.

Initially, I was strongly against this idea, because I wanted to keep the AI clean and not mix it with cut-scenes. I thought this would get too messy and unclear. However, our designers convinced me to do it that way anyway. In retrospect they were completely right: it is very simple to trigger and play cutscenes with this system.



Finally, let's have a short look at a big change we made to the behaviour tree system for Ronimo's Secret New Game. While working on Swords & Soldiers, we struggled with how to make an AI do several things at once. It makes sense for an AI to build units while also casting spells at the same time. Because of the priority system, doing this kind of thing gets very messy. The priority system really only works if you always want to do exactly one thing at a time.

Working around this made the AIs pretty unreadable at some points, so for Ronimo's Secret New Game, we removed the priority system altogether. Instead, we now simply have a big if-else tree. It still has conditions and actions and looks very similar, but the AI does not stop when it has found an action it can execute. This is a lot more readable and also made it easier to add else-structures. In Swords & Soldiers, we essentially only had if-then structures, while we now also have if-then-else structures.

Let me conclude by saying that we are incredibly happy with our behaviour tree system and our own editor for it, and we will keep using this for several games to come.

In the end, this also means that the actual behaviour of our AIs is scripted by our game designers. For Swords & Soldiers this was mainly Jasper, but also a lot of it by Fabian and Tom. For me as a programmer, it is great to see how designers can make all kinds of awesome things with the tools we provide. Our designers constantly surprise me with how much more they can do with those tools than I myself considered even possible! So the real credit for the great AIs in Swords & Soldiers of course goes to our designers! ^-^