Sunday, 13 April 2014

Why free to play games are inherently less fun

Designing a free to play game with microtransactions is a huge challenge. It is incredibly difficult to find the perfect balance between giving players a strong incentive to pay something while still making the free experience good enough that they keep playing. This challenge is crippling to the game itself. It is impossible to make a game as fun as it could be for both paying and non-paying players. At least one of those groups gets a game that is less fun.

Game design is all about making a certain concept as much fun as possible. By tweaking things like difficulty, flow, reward systems, variation and complexity the game designer tries to create the best experience possible. This "best experience" is an invisible target: you can never know whether you have reached it, or whether tweaking some things would make the game slightly better. It is also something that differs depending on the target audience. Some players like a challenge, others like a more relaxed experience. Some players want to drown all their time in a virtual world, others want a short and condensed experience.

The amount of "fun" in a game can be envisioned as a graph. Design the game in a certain way and you are at the very top of the graph, at the most fun experience. During development you try to tweak the game to get closer and closer to that very top, to that ultimate game. This is of course a theoretical graph: you can never know exactly how it runs. Also, there are many peaks, for the many different game concepts possible and for many different target audiences.

When designing a free to play game, the game designer looks for the best experience, just like when designing a 'normal' paid game. However, when designing for free to play the game designer needs to juggle two balls: some players pay money, others do not, and both groups need to get a good game. Especially the progress and reward structures in the game become very different for paying players. Non-paying players usually get very slow progress, while if you pay you immediately jump ahead. For example, in The Simpsons: Tapped Out you can wait many hours for a building to complete, or pay some real money to have it finished immediately.

Designing a good progress and reward structure is very important for most games. A good RPG usually becomes much less fun if you unlock new skills at half the speed, since it becomes too much of a slow grind. Unlocking things twice as fast does not make a good RPG better either: the player will feel less satisfaction when getting something new, will care less about each new item and might not even try a lot of them because they unlock so quickly. More rewards is not automatically better. There is a perfect rate of progress: not too fast, not too slow.

In most free to play games, the paying players get rewards much faster than the non-paying players. It is impossible that they are both at the top of the "fun" curve. So the designer gets a choice: make them both a bit less fun, or make one of them the ultimate experience and the other a lot less fun. In other words: it is impossible for a free to play game to make both paying and non-paying players have the ultimate experience.

This argument is not just valid for reward structures. It also works for all other aspects of the game: whenever gameplay is sold with real money, it is impossible to make that gameplay perfect for both non-paying and paying players.

The second reason why free to play games cannot achieve the best experience possible is that they are constantly nudging the player towards doing something they don't want to do. Players want to play a game, they don't want to spend money. They might be willing to spend money, but most players would rather not.

This means that the average free to play game is full of things that try to push the player away from doing what he wants to do, pushing the player towards paying real money. This can again be seen in an example from The Simpsons: Tapped Out: when you try to build something with in-game currency, the game often first lists all the items that you can only build with real money. You need to scroll through long lists of things you cannot build, until you get to the things that you can. In a 'normal' game, the game designer would design these menus to help you find what you want to build as quickly as possible. Here the game does the very opposite because it needs to tease you with all these items that it wants you to pay real money for.

Of course the player needs to pay for paid games as well, but in a paid game she pays up front, outside the game. After that the game tries to give here the best experience it can, instead of all the time trying to sell her something.

The above arguments do not mean that free to play games cannot be fun. I imagine that some readers might want to counter my arguments by giving examples of free to play games that are fun. However, my point is not that free to play games cannot be fun. My point is that free to play games could be more fun if they were not damaged by the free to play design.

Despite these problems free to play can still sometimes be a good idea. Especially multiplayer games can sometimes benefit greatly from free to play. This is because multiplayer games automatically become more fun when more people play them. The more players there are, the better the game can match players of similar skill to play together. The more players, the better lag can be reduced by matching those who are geographically close to each other and the higher the chance that your friends are also playing so you can play together with friends instead of strangers. With more players the game can also offer more game modes while still making sure everyone immediately finds opponents to play with.

In short: multiplayer games are better when more people play them. Free to play generally draws a larger crowd and thus often improves the game. So despite that the free to play model damages the game itself, the improvement from having more players might mean that the total effect of free to play can be a plus to such games.

Free to play and microtransactions are also sometimes needed purely from a business perspective. In some game genres and on some platforms players are so used to free to play that many simply refuse to pay upfront for a good game, even if it is a better game. In that case free to play might be the only way to make a successful game. Another business reason to include microtransactions might be that support, running servers and developing patches are all expensive to do. The developer might simply need the additional income from microtransactions to be able to keep supporting the game after launch.

Free to play games are inherently less fun because paying and non-paying players cannot both get the best possible experience, and because making money purely through microtransactions requires constantly pushing the player towards doing something she does not want to do. In case of multiplayer games having more players might add more fun than is lost due to free to play, but that doesn't change the fact that designing a game around microtransactions always damages some of the fun.

Saturday, 5 April 2014

How we solved the infamous sliding bug

Last month we fixed one of the most notorious bugs in Awesomenauts, one that had been in the game for very long: the infamous "sliding bug". This bug is a great example of the complexities of spreading game simulation over several computers in a peer-to-peer multiplayer game like Awesomenauts. The solution we finally managed to come up with is also a good example of how very incorrect workarounds can actually be a really good solution to a complex problem. This is often the case in game development: it hardly ever matters whether something is actually correct. What matters is that the gameplay feels good and that the result is convincing to the player. Smoke and mirrors often work much better in games than 'realism' and 'correctness'.

Whenever the sliding bug happened, two characters became locked to each other and started sliding through the level really quickly. With higher lag, they usually kept sliding until they hit a wall. I have recorded a couple of mild examples of this bug, where the sliding stops quite quickly but still clearly happens.

Note the weird way in which the collision between Froggy and the worms happens.

To understand why this bug happened, I first need to explain some basics of our network structure. Awesomenauts is a purely peer-to-peer game. This means that the simulation of the game is spread out over all the players in the game: every computer is responsible for calculating part of the gameplay. Particularly, each player manages his own character. The result is that character control is super fast: your computer can execute button presses immediately and there is no lag involved in your own controls, since there is no server which has final say over your own character. Of course, lag is still an issue in interactions with other characters that are managed on other computers.

Spreading out the simulation like this is simple enough, until you starting looking at collisions. How to handle when two characters bump into each other? Luckily Awesomenauts does not feature real physics, which would have made this even more complex. Our solution is simply that each character solves only his own collisions. So if two players bump into each other, they solve only their own collision (in other words: they move back a bit to make sure they don't collide anymore). They don't interfere with the other character's position at all. This works pretty well and is very easy to build, but it does become difficult to control the exact feel of pushing a character, since lag is part of that equation.

This works because normally both players will try to resolve their collision in the opposite direction: the character to the right will move to the right and the character to the left will move to the left, thus moving them away from each other.

Which brings us back to the sliding bug. This bug happens when the computers disagree on who is standing to the right and who is standing to the left. If both computers think their player is standing to the right, then they will both try to resolve the collision by moving to the right. However, since they both move in the same direction the collision is not actually solved, so they keep sliding together until they hit a wall.

It is clear how this would cause sliding, but why would the computers disagree on who is standing to the right? This requires both lag and a relatively rare combination of timing and positioning. This is a difficult one to explain, so I'll first explain it in words and then in a scheme. I hope the combination makes it clear what is happening.

Let's look at the situation when two players are both moving to the right. Lonestar is in front and Froggy is behind. Froggy is moving faster, so Froggy is catching up with Lonestar. Now Froggy jumps and lands on top of Lonestar. Because of lag, the jumping Froggy sees a version of Lonestar that is slightly in the past. Since Lonestar is moving to the right, his past version is still a bit more to the left. The resulting positioning is such that Froggy thinks he is further to the right than Lonestar, so Froggy starts resolving his own collision to the right. Lonestar on the other hand sees a past version of Froggy (again because of lag) and thinks he himself is to the right. The lag makes both Froggy and Lonestar think they are on the right side.

We originally thought this would be a very rare bug, but in practice it turns out that it happened often enough that most Awesomenauts players encountered it occasionally. In fact, there was one top player who was able to aim Froggy's Dash so well that he could trigger this bug almost every time. He used it to attach his opponents to him to do maximum damage with the Tornado after the Dash. Impressive skills! Gameplay mechanics that are so difficult to time are cool because they raise the skill ceiling in a game, but it was a bug so we did want to squash it.

Since we thought it was rare and since we couldn't think of an obvious solution, we first ignored the bug for quite a while, until a couple of months ago I managed to finally come up with an elegant solution. Or at least, so I thought...

The solution I came up with was to turn off collision handling for one of the players whenever the sliding bug occurs. This way they stop sliding together, and the character who still handles collisions will resolve the collision for both of them by moving himself a bit further than he normally would. The collision is only turned off between these two characters and only for a short amount of time.

This requires knowing when the bug is happening, which is not obvious because the bug is happening on two different computers over the internet. To detect occurrences of the bug we added a new network message that is sent whenever two players collide. The player with the lowest objectID sends a message to indicate which side he believes he is on. This is a very simple message, simply saying "I am Froggy, I am colliding with Lonestar and I think I am to his right". Lonestar receives this message and if it turns out to be inconsistent with what he thinks is happening, then Lonestar turns off his own collision handling and lets Froggy resolve the collision on his own.

This is simple enough to build and indeed solves the basic version of the sliding bug, but it turned out to feel pretty broken. There are two reasons for this. The first is that in the above situation, if often happens that a character starts resolving his collision in one direction, and then in the other direction. This felt very glitchy, as the character moved in one direction for a bunch of frames and then suddenly moves in the other direction.

The second and bigger problem is that our collision resolving is done at a relatively low speed. We do this deliberately, because this way when you jump on top of a character, it feels like you slide off of him, instead of instantly being pushed aside. This is a gameplay choice that makes the controls feel good. However, this means that collision resolving is not faster than normal walking, so it is possible for Lonestar to keep walking in the same direction as in which Froggy is resolving the collision. This way the collision is never resolved and Froggy keeps sliding without having control. This may sound like a rare situation, but in practice player behaviour turned out to cause this quite often, making this solution not good enough.

Seeing that this didn't work, I came up with a new solution, which is even simpler: whenever the sliding bug happens, both characters turn off their collision, and it is not turned on again until they don't collide any more. In other words: we don't resolve the collision at all!

This sounds really broken, but it turns out that this works wonders in the game: players rarely stand still when that close to an enemy, so they pretty much instantly jump or walk away anyway. In theory they could keep standing in the same spot and notice that the collision is not resolved, but this hardly every happens. Moreover, even if it does happen, it is not that much of a problem: teammates can also stand in the same spot, so two enemies standing in the same spot does not look all that broken.

This solution has been live on Steam for over a month now and as far as we know, it is working really well.

As you might have noticed, this has been a pretty long and complex blogpost. The sliding bug is just one tiny part of network programming, so I hope this makes it clear how complex multiplayer programming really is. There are hundreds upon hundreds of topics at least as difficult as this one that all need to be solved to make a fast-paced action MOBA like Awesomenauts. Also, this solution is a very nice example of something that seems really wrong and way too simple from a programming standpoint, but turns out to work excellently when actually playing the game.

Saturday, 29 March 2014

Guys With Guns: concept art for a cancelled Ronimo project, or: Being asked to pitch for a publisher's project

I have previously discussed pitching your games to publishers, but that was from a very specific perspective: if you already have plans for a game and are trying to make a publisher interested in that. Once a studio has gained some credibility the opposite can also happen: sometimes a publisher is looking for a developer for a game they want made, and they ask a bunch of game studios to pitch for that project.

Around four years ago (early in development of Awesomenauts) this happened to us twice, in both cases with well-known publishers looking for a fresh and different take on a famous franchise they owned. Today I would like to show the concept art our artists made for one of those, and explain how these kinds of pitches work.

Note that things like this are almost always under NDA, so I cannot mention the name of the publisher or the franchise involved. An NDA ("Non-Disclosure Agreement") is a common type of contract used in the games industry in which two parties agree to keep something secret.

When a publisher has a project for which they are looking for a developer, they often ask several developers to pitch for that, usually three to five. This way they can choose the plan that best fits what they are looking for, and can give each developer a chance to show what spin they would give to the game.

We knew that we were not the only developer in the race, so we tried to come up with something special. Most of us had played and loved the franchise when we were younger, so we were really excited to try our hands at bringing a new and modern spin to a classic.

We created a budget overview and wrote a design document in which we explained how we would evolve and change the gameplay. Our artists created concept art for several possible visual styles the new game could have. Since we wanted to give the publisher some choice, we decided to create art for more than one visual style, so that they could pick what best fitted their vision of the game. I think these all look great, so this blogpost is really just one long excuse to show you these awesome drawings by the Ronimo art team!

Style G, by Olivier and Gijs

Style A, by Tim

Style B, by Gijs

Style H, by Martijn

We sent the art, budget overview and design document to the publisher and then waited for their answer...


Nope! Unfortunately, they didn't choose us and went ahead with another developer.

(On second thought: knowing now how great Awesomenauts turned out, I am actually very happy that our pitch wasn't chosen!)

Not winning a bid like this is all part of the game, of course, but we were very disappointed at the reason given: they told us that both our game concept and our art were the best they had received, but they didn't believe we could technically pull off a multi-platform 3D game. This felt very lame, since they could have figured that out before they even asked us to pitch. Not that I think they were wrong: we had never worked on those platforms before and had never released a commercial 3D game, so this would have been a big challenge and I doubt we could have finished it on time and on budget with the experience we had back then. Nevertheless it felt lame that they didn't figure this out before asking us.

Still, I can imagine why they asked us anyway. My theory is that they were probably curious to see whether a young and innovative team like us would come up with something very special and insanely awesome. Instead, we 'only' came up with something that was better than the competition, but probably not enough to make them willing to take the risk of working with such a technically inexperienced team. So if our pitch had been even better, we might have gotten the job despite the technical risks. Of course, this is only my own theory, since we never complained to them about the procedure and thus never got a further explanation.

Despite that we didn't get the gig, it was an interesting experience to go through this process and we still have this awesome concept art! ^_^

Below are some more sketches made by our artists. These didn't make it into the actual pitch, so we never sent these to the publisher. Which makes me curious: which of the styles in this blogpost do you like best?

Concept art F1, by Gijs

Concept art F2, by Gijs

Concept art F3, by Gijs

Concept art D, by Olivier

Sunday, 23 March 2014

Why Scrum is fundamentally broken (but we still use it)

Scrum is one of the most used project management methodologies in the games industry. I know many companies that use it, including we ourselves at Ronimo. Most companies don't use pure Scrum: they change parts to fit their needs. This is so common that there is even an official name for it: ScrumBut (as in: "We use Scrum, but ..."). Any Scrum purists I have met are strongly opposed to ScrumBut, but when talking to them I learned that their views are so rigid and stubborn that they don't understand that one of the core concepts of Scrum is fundamentally broken when used for game development. The purists I met simply deny the problem and come up with fancy crap like this:

"ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum. ... A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team." (source)

Purists want you to believe that only pure Scrum works, but Scrum is fundamentally flawed and therefore not a full solution to project management. I think Scrum is still the best methodology around, but it is crucial to understand its problems and to not overestimate what it can do.

Scrum is mostly know for the stand-up meetings and the blackboards full of post-its, which are both great concepts. The big problem is in how Scrum relates to the overall process. Project management methodologies have many goals, like internal communication, empowering developers, facilitating innovation, communicating with stakeholders and the happiness of the team. Scrum is really good at each of these, but it falls flat on the face in the area that people most often associate with project management: meeting deadlines.

Scrum works with Sprints. A Sprint is a period of typically 1 to 4 weeks in which a certain feature or set of features is built. At the start of every Sprint it is decided which things to work on, and at the end of the Sprint the product is reviewed. Scrum deliberately asks the team not to look too far ahead: the core question when deciding what to work on during a Sprint is what the biggest improvement to the product is at that moment. During the Sprint this is then build and completely finished: Scrum emphasises that whatever is build during a Sprint should be finished and potentially shippable by the end of the Sprint.

This idea of having a fixed period of development and then evaluating what is most useful to work on next is a very good concept for game development: it is often impossible to really know what works until you are playing it in game, and once you are playing it you will learn all kinds of things about what the game actually is and where to bring it next. Regularly evaluating what works and what does not is really important for making good games and Scrum facilitates this really well.

The fixed period of a Sprint also manages to fix the big downside of constantly evaluating: it can be pretty frustrating if the plan changes from day to day and you cannot finish what you are working on because the plan changed again. Scrum forces that the plan cannot change during the Sprint, so it gives a certain amount of stability to the developers. This way they know where they stand during the Sprint.

The emphasis on re-evaluating what is needed next at the beginning of every Sprint brings up an important question: how do we know when the product will be finished? How to meet deadlines? Scrum has a short and simple answer to this: since every Sprint requires the things made in that Sprint to be finished, and since the most important things are always made first, the product is potentially shippable after every Sprint. The product gets better during every next Sprint and at the end of every Sprint it is again potentially shippable. Shipping dates are therefore always met according to Scrum: just stop developing at the deadline and release the product in whatever state it was in at the end of the last Sprint.

This is where Scrum fails utterly and brutally for game development, as this only works in theory.

Let's have a look at a couple of examples of why this does not work:

-To be able to ship a game on console it needs to abide by the console certification rules. These rules are things like showing an error if the harddisk is full when the game wants to save, and pausing the game if the controller is unplugged. Console manufacturers provide long lists of certification requirements. If the game fails to pass their tests, it cannot release. Since the number of requirements is so large, implementing all of them is a very big task. For a game to be "potentially shippable" after every Sprint (as Scrum requires) the certification requirements should be implemented first. Which is a horrible idea. One could in theory indeed start there, but in practice one really should not. Early in the project the most important thing is to get the core gameplay playable as quickly as possible and to set up the tools needed for the artists and designers, so that they can do their work. If the programmers start by focusing on certification requirements, then the artists and designers will waste several months with no game to work on. To enable the artists and designers as much as possible, gameplay programming should have priority and certification requirements should not be implemented until relatively late in the development period. In other words: the game cannot be 'potentially shippable' until very late in development.

-Many larger features also don't work with the concept of being 'potentially shippable' after every Sprint. Some things you either do entirely or not at all, like telling a story through cutscenes. Doing this the Scrum way probably means first very roughly animating all the cutscenes and putting them in-game. This is indeed a good idea for prototyping story flow early on. However, after that the next practical step is to just make each of those animations in turn. This means that halfway through that process, half of the animations are finished and the other half are still rough. Theoretically that might be a 'shippable product', but in practice you really cannot ship until all the rough animations have been replaced.

-Finally, the goal of game development is not "to finish a game" but "to finish a good game". Meeting the release deadline by just releasing whatever you have at that point is a pretty worthless strategy because it does not say anything about the quality of what you release. I can imagine that if the project has completely derailed and failed then you might want to release whatever you have and forget about it, but in all somewhat normal cases I am not interested in just "meeting deadlines": what I am interested in is "making quality games on time". Scrum helps a lot in making quality games, but it hardly helps in making them on time.

Absolutely baffling is that when I discussed this topic with a couple of official Scrum trainers, they simply denied that the problem existed. They claimed that if the game is not in a shippable state after every Sprint, then you are simply doing Scrum wrong. The above examples clearly show their error, but they just kept repeating that if Scrum is done right, the problem does not exist. This is why despite that we use Scrum and I like many aspects of it, I strongly dislike Scrum purists. Good thing not all Scrum trainers are like that!

Most project management methodologies are bloated with too many rules and too many claims of being able to solve almost any problem. Scrum is no exception, and Scrum's concept of ending every Sprint with a 'potentially shippable' product just doesn't provide a solid solution to the problem of meeting release deadlines. However, none of the other methodologies I have seen does this much better, so I think that despite this major flaw, Scrum remains the best project management methodology for games. Just be sure to keep in mind its flaws (and to always distrust Scrum purists).

Thursday, 20 March 2014

Revealing Swords & Soldiers II

We recently announced that we our new game is Swords & Soldiers II. We didn't actually show any real gameplay yet, so today brings an exciting moment: here's what it looks like! It’s beards, mead, sheep, demons, axes, wenches and barbecues! Hope you like it!

Sunday, 16 March 2014

Coding structures that cause bugs

Bugs are usually caused by simple things like typos and oversights. As a programmer, this might make you think you need to become smarter and concentrate better, or maybe you conclude that bugs are simply part of any programmer's life. Both are of course partially true, but there is more to it than that. There are methods that can be used to reduce the chance of creating bugs (even though such methods won't fix all of them).

One of those is better coding structure. Ideally code is structured in such a way that mistakes and oversights are not possible, and that the code is easy to understand. In practice these goals are often not fully achievable, for example because they contradict with the amount of time you have to build it, or the performance requirements, or maybe the problem you are solving is just too complex for easy code. Nevertheless, striving for good structure does make a big difference. Today I would like to give a couple of examples of common coding practices in C++ that can easily cause bugs. Even if you want to keep using them, knowing the pitfalls can help avoid issues.

You might disagree with the examples given here, but I hope they at least help you think about how you structure your code and why. In the end there is no absolute answer to what good code is, but I do believe that to be a good programmer, one needs to think about what good code structure is, and which features of a language to use and which to avoid.

Initialise() functions

Some classes have a separate initialise() function. This means that after having constructed the class, you need to first call the initialise() function before you use it for anything. This is often done because constructors don't have return values (and can thus not return errors in the normal way), or because classes cross-reference each other and they both have to exist before either can be fully initialised.

However, using initialise() functions introduces a new situation that is prone to bugs: it is now possible to have an instance of a class that is not initialised and thus not ready for usage. All kinds of bugs might happen if you forget to call initialise() and then start using the class. This can be fixed by keeping a bool isInitialised in the class and checking for that before usage, but that of course introduces another thing that needs to be remembered and is thus ready to be overlooked by a future programmer working on that class, causing even more bugs.

For this reason it is generally wise to avoid separate initialise() functions altogether. Just create everything in the constructor. This principle is called RAII ("Resource Acquisition Is Initialisation"). If you want to do error checking in the constructor, you can solve the problem of not having a return value by using try/catch.

Default parameters

Default parameters are parameters in functions that have a default value, so that you can skip them if you don't need something special. Like for example:

void eatFruit(string fruitType = "banana");

//Can leave out the fruitType when calling this function

Default parameters are a useful tool: some functions are often called with the same parameters so it is nice to be able to just skip them in those cases. However, default parameters can also be dangerous because it is easy to forget about them, especially when refactoring. In the development version of Awesomenauts I recently created a crash bug while refactoring a piece of code. Here is what I changed:

//Old code
TemporaryAnimation(ParticleFadeManager* particleFadeManager,
                   RumbleManager* rumbleManager,
                   unsigned int textLocalizationIndex,
                   RenderGroup renderGroup = RG_STANDARD);

//New code after refactoring, with one new parameter
TemporaryAnimation(ParticleFadeManager* particleFadeManager,
                   RumbleManager* rumbleManager,
                   ReplayFrameStorer* replayFrameStorer,
                   unsigned int textLocalizationIndex,
                   RenderGroup renderGroup = RG_STANDARD);

I use the compiler a lot while refactoring, so when I change something like adding a function parameter I often just hit compile to see where it is used. In this case however this was a bad choice because the default parameter caused the compiler to interpret my code in a different but still compilable way. Here is the line that caused the crash:

animation = new TemporaryAnimation(particleFadeManager,

Originally the '0' was the textLocalizationIndex, but after refactoring it was interpreted as a NULL pointer for the replayFrameStorer. The compiler didn't complain because RenderGroup is an enum and can thus be interpreted as an unsigned int. So RG_MENU was now interpreted as the textLocalizationIndex and the renderGroup now used the default parameter RG_STANDARD. Really broken code, no compiler error.

Had I not used default parameters here, the compiler would have given an error because I was passing in one parameter too few.

This is just one example of a situation where default parameters have given me such headaches: I have encountered several other situations where I overlooked things because of default parameters.

Also, I prefer if someone who calls a function actually thinks about what he is passing to it, and default parameters don't encourage thinking: they encourage ignoring. So despite their usefulness, I generally try to avoid default parameters.

Constructor overloading

When a class has several constructors, this is called constructor overloading. In university I was taught this is a useful tool for all kinds of things, but in practice it turns out it is often a headache. It creates situations where it is easy to overlook something and introduce new bugs. Let's have a look at an example of this:

class Kiwi
    string colour;
    const float softness;
    const float tastiness;

    Kiwi(const string& colour_):

    Kiwi(float softness_):

The problem here is that I need to initialise everything in every constructor. The tastiness variable is always set to 1, but I have to set it in each function. This means code duplication. Code duplication can be avoided by using a common function that all constructors call, but this is not always possible. In this specific case for example the tastiness variable is const and can thus only be initialised in the initialiser list, not in a separate function.

Even worse worse than code duplication is that if I add a new variable to the class, I need to remember to initialise it in every constructor. Forgetting about one of the constructors has caused bugs in our code in several situations, so we now try to avoid constructor overloading altogether.


These three examples show how certain structures cause bugs. None of these structures are bad per se and they each have their use, despite the risks. In fact, I use these occasionally myself, simply because sometimes the alternatives are worse. However, knowing the risks of certain structures helps make good decisions on when to use them and when not to use them, and to first consider alternatives whenever you think you need them. It is important as a programmer to think about the pros and cons of anything you do, and to always look for better structure.

Sunday, 9 March 2014

The final series of Proun+ music sketches

For the extended soundtrack of Proun+ I am composing a series of short sketches for grooves for the new songs. I already posted seven of them a couple of weeks ago and today I present the final six. From here on I will select the best ones and start turning them into real songs. I would love to hear your opinions on these, since that will help us choose which to expand on.

Keep in mind that these are quick digital sketches. The final soundtrack will be played entirely by live instruments and produced by professional musician Arno Landsbergen, so they will sound much better just because of the real instruments and good production.

The one below is pretty different from the rest. Arno and I wrote "Groove Sketch L" together and Arno recorded it live. This means that the sound is much better right away, making a comparison to the rest difficult. It also shows that everything is better on a real Hammond organ: what an awesome sound these things have! The Mellotron halfway (starting at 0:25) was added later by Arno and I love it, because it is impossible to not love Mellotrons.

The final piece below is in a much further state already and created entirely by Arno. "Chaingang Rag Dressed Up For Warp Speed" is a song Arno started writing a couple of years ago around the time of the launch of the original Proun, but he never finished it for the actual game. I absolutely love it so we have already decided that Arno will expand this one into a complete song for Proun+.

Working at these sketches is a very interesting process and a personal breakthrough for me. I am a completionist: whenever I start working on something, I want to actually finish it. For some things this is good: Proun would never have existed if I didn't feel like I had to finish it for six years. However, being a completionist also has a big downside: instead of making dozens of prototypes and little ideas, I mostly just create bigger stuff. For example, in the past 1.5 years I worked in my spare time on just this one project called Cello Fortress, ignoring all other ideas I have. I love Cello Fortress, but it would also be nice to try some of the dozens of other concepts that linger in my head.

Being a completionist also influences my gaming habits: I have to finish almost any game I start and thus play few games. As a game developer it would be much better if I played and experienced a lot of different things a bit, instead of only selecting those games I will actually finish.

Knowing that I am such a completionist makes me scared to start working on something new, regardless of whether it is a game or a piece of music or 3D artwork. I won't be able to happily drop it until it is finished, and I will feel bad if I don't finish it. In fact, I still plan on finishing my 3D design for a baroque villa, despite that it has been on hold since 2004. Twothousandandfour! That is a ten years old project that still lingers in the back of my mind because I feel bad for not completing it.

Not being able to sketch or prototype stifles creativity, so I am glad that for the music for Proun+ I managed to find a compromise that fixes most of my completionist problem. The 'project' I defined here is to make a long series of simple ideas. Each is an incomplete thing, but to me as whole they form a completed group of sketches.

Turning a group of unfinished things into a project that can be finished as a whole satisfies my urge for completing things, so that I won't feel bad for the unfinished pieces.

Back to these groove sketches for Proun+: which do you like most? Any you really dislike?