Designing a game for two players is easy. Designing a game for 10 players is harder. But designing a game for 200 or 500 players is extremely hard. Here you will see my opinion on why.
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?
Note that MMO are just a cheap trick. They tackle the challenge of having thousands of players in the same world full of activities; but each activity is limited and designed for a much smaller group of users. For instance, World of Warcraft’s raids are designed for a fixed number of player (usually 25 or 40 in some cases).
But what if we want more? What if we want a game that can be meaningfully played by 100, 1000 or 10000 players?
As you probably know, last week I was at the DiGRA-FDG conference in Dundee, Scotland. The conference ended last week, but I have the urge to add something to a really interesting presentation I’ve attended during the first day at the workshop on Procedural Contents Generation.
Before FDG, I was reading a small book on how the Chinese language has evolved during the centuries. It is extremely interesting. Especially if we look at the clear and wonderful evolution from pictures on paleolithic wood artifacts to the modern Mandarin Language. This triggered in me the idea to explore the literature on teleological algorithms for the procedural generation of languages (if you don’t know, the teleological algorithms in PCG are the ones that try to generate a “thing” by simulating the physical and evolutionary processes through which the “thing” is generated in the Real World™).
I was thinking about that just two days before the conference. Therefore, you can maybe understand my surprise when the first presentation I attended was titled: “Diegetically Grounded Evolution of Gameworld Languages”.
This small paper describes very effectively the simulation of some aspects of how languages evolve in the real world. It is inspiring and worth read it! However, I feel that the thing I was interested into was not really covered. So, I’ll try to dump my brain in this article.
I just came back from the Nucl.ai conference. I want to share some fresh feelings on what I’ve got from this beautiful experience!
I’m back! During the last week, I had a beautiful experience as a volunteer at the Nucl.ai 2016 conference, one of the nicest Game AI related conferences in Europe.
I like this conference. It has a very informal atmosphere and both speakers and attendees are incredibly friendly and very willing in giving advice. You can go there like a complete no-one (for instance, like me) and you can speak and have a beer with Lead AI programmer in Triple-A games, in top notch industries like Google, Blizzard or Epic as if they are your friends.
This is possible because I can guarantee that the people involved in organizing this conference are very passionate about the topic and, most important, they do it while having fun!
But that’s enough with advertising! Let’s talk about what I got from attending this conference!
At the time, I didn’t really explore these two languages in deep, and in fact, I think I was a bit too hard on Clojure. During this half year, I had the opportunity to go deeper in Clojure and my opinion on the languages increased accordingly. Moreover, Clojure 1.8 came out just a month later with some nice improvements and the upcoming Clojure 1.9 (with the introduction of the clojure.spec) seems to push the bar even further. So, yeah, I was wrong on a big point: Clojure is advancing quite fast.
However, even if Clojure is a more established language, I preferred Elixir in the list as the most promising language. Well, after everything I said and after this half year of experience, I have to say that I will still put Elixir on top of Clojure again. And now, I will explain why.
In short, a Binary Heap is a common data structure for a priority queue. We want to put inside the queue many values (or an object) and you want to extract the smallest value (or the object with the smallest score) in the most efficient way.
A quick note from my developing life. How to perform a pixel-perfect scaling of a Phaser.io game?
As you may know, I am in the middle of developing a demo for some Smart Pathfinding, and I’m using Phaser and TypeScript for it. Unfortunately, as soon as I started coding a couple of days ago, I quickly found a problem. How can I do pixel-perfect scaling of the game?
The tileset I’m using is very small (16×16 pixels tiles) and I needed to scale them at least 3 times to make them visible on a big screen. However, searching for “phaser.io” and “scaling” returns a lot of not useful results.
Results are often about the wrong thing (for instance, scaling a single sprite or a tilemap) or old (that is, something that is not true on Phaser 2.5.0). But a solution exists! And I’m here for this!
This 4 lines of code solved my problems. I put them in the Phaser’s preload function as a first thing. Let’s see how this work line-by-line:
Line 1. We set the scaleMode variable of our Phaser.Game instance to Phaser.ScaleManager.USE_SCALE. This means that the ScaleManager subsystem (the one that is in charge of scaling the game) will accept a manual scale specification.
Line 2. And this is the manual scale specification. We say that we want to scale the full windows by 3 in all directions.
Line 3. This is a bit mysterious at first. This line says to the renderer system that we want to round the sprite position to the integer value. This is to avoid to render sprite pixels in sub-pixels positions. To better understand, consider that by scaling by 3 the game, each pixel in our images corresponds to a square of 3×3 pixels in the game windows. This will ensure that moving the image by 1 pixel in the “not scaled world” correspond to a 3px movement in the actual game windows.
Line 4. This is the last step. We want a crisp rendering. In a pixel perfect game, we want to see our beautiful square pixels. So we say to the rendering system that we don’t want antialiasing or other things like that.
This guide is updated to Phaser 2.5.0. I hope you can find this useful and do not waste a full 30 minutes on this trivial task! :)
In the last period, I’m really enjoying TypeScript. It is typed, can be used in a functional way without effort, it like a C# for the Web, in short, I love it. For this reason, I started converting some old Phaser.io demo in TypeScript, for fun.
So, why I’m writing here? To solve two main problems. First, the TypeScript guide in the Phaser.io web page is really outdated. Second, there are a lot of “template” project fo Phaser.io you can download. These templates are really state-of-the-art level: they use Gulp, Grunt, NPM and another million of tools.
However, when I’m approaching a new development environment, I’m usually overwhelmed by “too much tooling”. They are all additional levels between me and my understanding of how things work! I wanted something easy, something with only a web page, the Phaser.io library and the TypeScript compiler.
So, I present to you the very basic bootstrap guide for TypeScript development for Phaser.io. This includes the minimal amount of steps between an empty folder and a running Phaser.io + TypeScript environment! Enjoy!
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.
I was looking at my RPG dice set thinking: can I use you to generate a passphrase? So I generated a contorted but funny algorithm for this.
Times ago, I was reading something on numerical systems and password generators and I find myself discovering Diceware, a system for generating a passphrase using several 6-side dice. I think it was funny, so I looked for some dice in my house to try the system. Unfortunately, I have just one d6. Diceware requires five throws just for a single word and a good passphrase requires 3 or 4 words, plus some modifiers here and there. In total, I should throw that single die 20 times to get a good passphrase.
However, just on top of my desk, I have a full d20 RPG dice set (where that d6 belongs). I thought: it is possible to use an RPG dice set to do something similar to Diceware? After all, an RPG set spans over 4,608,000 possible outcomes per word while six d6 can obtain “just” 7,776 different results. There is more than enough room to make the system work. So, that is the system I propose.
Every day, you only have a limited amount of “good” decisions. So, it is better to learn how to avoid wasting them.
If there is something that I learned from my daily struggle with procrastination, is that every day you just have a limited amount of decisions. Every day, you can only do 5, 8, maybe 10 meaningfully decisions. After that you will start doing mistakes, get tired and, in general, doing wrong.
What can be surprising of this, is that doesn’t matter how important the decision is. Look at a traditional day: you wake up and you need to decide what to eat for breakfast, what clothes to wear, if it is better to go to work using the car or public transportation. You have literally just waked up and you have already depleted the big part of you decision pool for the day. And none of that decision is meaningful for your work, your career, your family, your affections.