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

Elixir and Clojure are two uprising and fun functional languages. As you know, I talked about both of them in the article on the most promising languages of 2016, and, in fact, they are the only real functional languages I mentioned in there.

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.

Yesterday I converted a Binary Heap data structure in TypeScript. The original code is here, in the Eloquent JavaScript online book by Marijn Haverbeke.

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.

This JS implementation the Eloquent Javascript book is pretty common, so I decided “to typify it”.  The result is in the following Gist:

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 (16x16 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.

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.

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.

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.

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.

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?