Posts

Proun cloning controversy: why indies should complain less about clones

Image
My game Proun was recently 'cloned' by an iOS game called Unpossible . Unpossible isn't the first 'clone' of Proun: games like Synesthetic and Polyrider also copy the core gameplay and many obstacle shapes. Polyrider even goes so far as to copy-paste my main marketing text (DOH!). However, the timing of Unpossible is much more painful as Proun itself is also finally coming to iOS (and Android and 3DS): together with Engine Software I am working on a bigger and better Proun+. Proun+ coming to iOS means that it will be a direct competitor of its alleged clone Unpossible. I saw quite a bit of controversy online about whether Unpossible is a clone or not and whether that would be bad or not, so here is my own take on the matter. I think most people are worrying way too much about most clones. The only clones that should be considered a big problem are direct rips that add nothing and are clearly only intended as a moneygrab. Most infamous clones are not of this typ...

Why free to play games are inherently less fun

Image
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. So...

How we solved the infamous sliding bug

Image
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 mi...

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

Image
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 t...

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

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

Revealing Swords & Soldiers II

Image
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+...