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

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

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!

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 eatFruit(); eatFruit("kiwi");

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, globalRumbleManager, 0, RG_MENU);

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 { private: string colour; const float softness; const float tastiness; public: Kiwi(const string& colour_): colour(colour_), softness(1), tastiness(1) {} Kiwi(float softness_): colour("green"), softness(softness_), tastiness(1) {} };

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.

Conclusion

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.

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?

So much awesome news in the week Ronimo turns 7!

Today Ronimo Games turns 7. Seven years old already, it definitely doesn't feel like we have been around for so long already! This week was also marked by the biggest amount of awesome news in a single week so far, so let's have a look.

Most importantly, we announced our new game: Swords & Soldiers II for WiiU. This game has been in the works since November 2011, so it is good to finally reveal it. Right now we are not discussing any specifics yet: more information will come at GDC in a couple of weeks, where press will be able to play it. What I can say right now is that I think the game looks incredible and I am really stunned at the quality of the graphics and animations that our art team has been creating.



It is pretty incredible to read online that the original Swords & Soldiers has so many people who remember it fondly. These are just some of the heart-warming quotes I saw in the comments beneath news articles about the sequel:

-"Hp hip hooray. One of my all time favorite games finally getting a sequel. Can't wait."
-"Ooh, nice! The original was great!"
-"Love it. LOVE IT."
-"Got up, read this = instantly made my day :D Awesome, The original is one of my all time favourite WiiWare titles."
-"Swords and Soldiers was the most underrated wii ware game. This is great news."
-"the original title was one of the WiiWare's hidden gems"

We thought the Kickstarter backers of Awesomenauts Starstorm might have some questions about how this relates to Starstorm, so we put up a public statement explaining how long Swords & Soldiers II has been in development and how we have been growing the team to 21 people to make both projects happen simultaneously. In fact, two new programmers will be starting next Monday! This is also a new challenge for me personally: the Ronimo coding team will now be 7 people and I have never been lead programmer to so many people at once. I am looking forward to this new experience!



Another big announcement is that we finally have a release date for Awesomenauts Assemble on PS4! It took a while to get all the bugs ironed out, but Abstraction Games made a great port and we are really looking forward to playing next-gen Awesomenauts.



This week we also released patch 2.2 for Awesomenauts on Steam. This is a smaller in-between patch that mostly fixes a lot of bugs and improves the balance. It contains one bug-fix that we have been looking for for ages: the infamous sliding bug should be gone now. This was a complex synchronisation bug that is interesting enough that I will be writing a separate blogpost about it soon to discuss the cause and the solutions we tried.

Patch 2.2 also added collecting of anonymous gameplay metrics, so we now have a much better view of how people play the game and how characters and individual items are balanced. For example, we can now actually see how many people play splitscreen, or Custom Games or Baby Kuri Mammoth.



Together with patch 2.2 we also revealed Voltar's Vault. Voltar's Vault is a device that we use to overheat and cook player's brains with anticipation for the awesome new things coming to Awesomenauts. Deliciously cooked brains, they taste so good!



The final bit of news is that the Clunk figurines finally arrived in our office. They turned out much slicker and bigger than I had expected when we started work on this. Very cool! European pre-orderers should mostly have received them by now, while Kickstarter backers and American pre-orderers will have to wait a while longer until they have been shipped to them. This whole process of shipping and physical production is new to us and we are trying to have them delivered to everyone as soon as we can. You can order one these brutal robots over here.

A wise man once said that the final goal of any game developer is to have action figures of his games. Seems like I am ready for retirement now!