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?

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.

You can follow the links to read the first part and the second part of this series.

In the previous part we have seen how to pass not trivial data to Rust functions such as a Python list. It is still not enough, though. In many cases we need to pass complex data structure back and forth from a Rust library. We may need to pass quaternions, 3D points, trees, a list of “books”… In short: anything.

Learning how to pass custom aggregated data types to Rust libraries (and back to Python) will be the focus of this part!