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.
Sometimes, solving planning and pathfinding at the same time can save you a lot of time. It is the case of Inventory-Aware Pathfinding in which we want to solve pathfinding in a map constrained by the items brought by the agent (e.g., keys to open locked doors).
Everybody know what pathfinding is. I don’t think I have to explain to a game developers audience why pathfinding is so important in games. If something in your game is moving not in a straight line, then you are using some kind of pathfinding.
What is less evident is that pathfinding is the only place in which “searching” is generally accepted. Except for GOAP and other planning-based techniques, the big part of the NPC’s decision-making techniques are reactive-based.
This is not a bad thing. Reactive techniques are an amazing design tool. However, this raises a question. Why is this? Mainly because of computational limits – full-fledged planning still requires an impractical amount of time – but also because of design unpredictability. The output of planning decision-making techniques is hard to control and the final behavior of the agent could be counterintuitive for the designers and, at the end, for the players.
Why can pathfinding play a role in this? Because it is possible to embed in it a minimal, specialized, subset of planning, especially if these planning instances require spatial reasoning. A common example is solving a pathfinding problem in which areas of the map are blocked by doors that can be open by switches or keys sparse around on the map. How can we solve this kind of problems?
A beautiful mathematical object I played with in some boring afternoons. Just for the love of math.
This will be just a small theoretical article on the Primes Ancestor Tree. We will explore the possibility to label a generic tree in such way that it will be possible to verify if a node is an ancestor of another node (or to find the common ancestor of two nodes) just by applying integer arithmetic.
In fact, sometimes ago I was trying to implement some fancy algorithm that, given two nodes from the open list of a search algorithm, finds their common ancestor. While I was doing this I asked myself if it was possible to use prime numbers in order to provide a labeling system that encodes the “descendant” relation of the nodes.
I think that I have found a theoretical system. Even if it can not be used in real-world applications, I had fun playing with it looking for the properties of the resulting labeled tree. So, I thought it could be interesting to share.