This small article is born from a discussion I had with a friend of mine this week. He was writing a review on Playersunknown’s Battlegrounds (from now on, PUBG) and he ended up talking about the evolution of the genre and its triumph over every other competitor. The article was good but it did not enter in detail about, what I think, it is a greatly important and interesting question: Why PUBG? Why not any of the other dozens of battle royal games we were plagued in the last years?

PUBG is clearly a winner in this competition. It sold more than 8 million copies on Steam only, and I can see the trend going with the future release on consoles. The problem, in my opinion, is that, on paper, there is nothing in PUBG implementation that seems “right”. Nevertheless, it won.

Machiavelli once said that success is 50% luck. That’s definitely true for PUBG. But the other 50% must be researched in the PUBG qualities. Analyzing them, despite the massive “errors”, it is very important for any game designer.

I want to take the cue from a last week massive Reddit thread on micro-transaction in Free2Play (F2P) games to give my opinion of the topic. I think it is important. We need to increase awareness that predatory practices in F2P games are incredibly close to gambling and share with it the same self-destructive and harmful addictive behavior. This is wrong in so many way: it is dangerous for the victims, it is dangerous for the game itself, and it is dangerous for the entire F2P model.

I feel the urge of stating the obvious: randomness in Procedural Generation refers to the perceived randomness of the outcome; not the randomness of the input parameters.

In some sense this is “obvious” but, at the same time, is one of the most common mistake I see when developers tackle procedural content generation in their games. It is an understandable mistake, though. There are two assumptions we subconsciously make when we approach randomness: 1) we think that uniformly random parameters produce uniformly random outputs (that’s blatantly false), and 2) we think that uniformly random outputs yield to uniformly random perception in the human (even more false).

I think the time is ready to talk about Procedural Contents Generation (PCG) in the post No Man’s Sky era. I’m talking about “era” for a good reason: No Man’s Sky huge failure will definitely mark an era in the history of PCG, and not for a good reason. Players’ perception on PCG has been severely hurt by how badly NMS delivered its contents. Probably, this will be the end of PCG as a marketing buzz-word.

When you design a game, one of the most important aspect to take into account is the number of players. Games can be designed for a single player, two players, four players or thousands of player (like in MMOs) and this decision has a huge impact in the technical and design requirements.

But it is not just choosing a number. The “number of players” parameter cannot be arbitrarily moved at will. The more we increase the value, the more the designing task becomes harder and harder. Look around you. We have thousands of single-player games, we can find a huge amount of games for 2 to 4 players, we have party games that can go to 10 players or team sport games such as rugby and football that can be played up to 20 or 30 players, but after this amount of players, how many good games there are?

I hope you agree with me: controls are the true essence of every game. Sometimes, controls schemes are enough to define the game itself: once you decide the game controls mechanics, the rest of the game will follow. So I thought to start exploring controls schemes in a more formal way, searching for a way to analyze games from the user interaction point of view only.

We will start from the simplest control scheme possible: a game with a single button. These kind of games are recently more common than ever: they are easy to implement, easy to play and very suitable for smartphones (touch screens can be seen as single giant buttons). In other words, they are the perfect candidate for a funny mobile game.

Hello everybody! It is time to continue with our series on Pokemon-like battle systems. In this chapter I will be more general: now we have our beautiful damage formula and a draft of our characters sheet, it is time to quickly check if the game the formula is balanced. There are a lot of questions that we want to answer as quick as possible. How much HP the enemy must have? What is a good value for the attack power? Is the damage formula fair enough? The critical strike is too much? The randomness is too much? Is it fun?

Except for the last question, we can try to answer them just looking at the damage formula. Obviously we can not answer all the questions now, but if there is some evident mistake, we will be able to catch it as soon as possible. There are several ways to analyse the tuning and balancing problem for a damage formula (and thus for a large part of the combat system): analytically, with Google Sheet/Excel, and with a quick software prototype.

In this article we will start from the first step: the analytical analysis.

A.K.A. why Elite: Dangerous, Star Citizen and No Man’s Sky could be doomed to fail

Since the beginning of the videogame era, developers aim to reach a perfect simulation of the world. “So realistic!” is probably one of the most abused comment to a videogame ever. The videogame industry tried to reach realistic graphic, realistic sounds, realistic landscapes and realistic Non-Player Characters. However, reaching the perfect realism is a never-ending quest. As soon as we reach something, desire drives us to seek more.

Now that we have extraordinary graphic capabilities and stunning landscapes, some developers are going to raise the bar to a much bigger task: simulating the universe (or at least, the galaxy). We are not in the first (game) generation who is trying to achieve that (the original Elite is a very old game indeed), but we are for sure in the first generation who can reach this goal; at least to some extent.

We have the technical capabilities for doing amazing things: we can generate and simulate hundreds of billions of star systems, we can allow the player to travel to every one of them, explore and land on every square unit of the planet surface, every asteroid, every satellite. Software/games such Space Engine can clearly show us what a lonely developer can do in its spare time. Imagine what a game developers team can do on their full time job! It is not a surprise that several studios spotted the niche in the market and tried to use this power for a real game. After all, it is not “simulation of experience” one of the meaning of “game”?

The Combat System is one of the main gameplay element in a game. Of course there are a lot of games without “combat”: puzzles, simulation games, driving games and so on. However (and you know this in the depths of your soul) that your game must have an amazing combat system because we LOVE beating the crap out of our enemies! Other games mechanics are good, but a good fight can be AMAZING.

There are several ways to implement a combat system but, at the end of the day, we can divide the heterogeneous world of combat systems into two big clusters: real time combat systems and turn-based combat systems. The first are exciting but they rapidly becomes hard to implement. We will need to do a lot of animations, tuning collision boxes and tons of graphical stuff. If you are a poor programmer like me, you cannot do that (sad face :<).

With turn-based combat system, instead, you can do the most complex things you can image! You can take into account hundreds of variables and statistics, create complex strategic combinations, evocations, magic, everything. You can use dice, cards, tokens, everything in order to emulate an epic combat between a dragon and drunk dwarf with a wooden leg. Because turn based combat systems are an explicit abstraction of a real combat, the player can absorb without complaining a bigger level abstraction. The same cannot be said for a real-time combat system in which just an ugly animation can be labeled as “ugly designed and sluggish combat” and provide frustration to the player.

So we are going to implement a turn-based combat system! But how? Well, this obviously depends on which type of turn-based combat system you want to do. For now, we will try to do a replica of the first turn-based game I’ve ever played: the Pokemon Combat System!

This is a nice combat system to replicate as a tutorial because is not too complex (especially in Gen. 1 or 2), but contains several tricky points that we need to handle! We will explore the design and the implementation of this combat system in details. We will see how to design the combat system, how to do a first balancing and test on paper, and every implementation step! So let’s start!