Anxiety is a human mind bug. This may seem a strange claim, but I cannot find a better explanation for anxiety disorders. In fact, we can see pathological anxiety as the undesired consequence of our ability to think about the future. Being scared about a life-threatening event in the near future is a valuable ability: it helps us to survive, avoid danger and, in short, make our species survive. That is one of the reason our species has been so successful in nature\[1\].

Now that I finally completed my PhD studies, I started rethinking about my path up here. This is a path I started a long time ago. For some reason, this was the path I traced for myself since my childhood. When I was 10 (or earlier, I don’t really know for sure) I answered for the first time the question: “what do you want to do as a grown up?”. And the answer was “I’ll make games” (“I’ll make Mario’s game”, to be very precise).

Yesterday I wrote a cellular automaton based procedural caves generator algorithm that fits in a business card. The algorithm itself is not new. I already did it in C++, Rust, Javascript and many more languages. It is my personal approach to “Hello World”: when I want to try a new language, write a PCG algorithm in it.

This article has been originally published on Gamasutra.

In the last article we introduced a basic approach for Inventory-Aware Pathfinding (IAP), a pathfinding algorithm capable of interacting with obstacles and not just avoiding them. If you have not read it, I encourage you to go back and read it to understand the basic challenges and the main ideas behind the proposed solution.

For instance, we can have a pathfinding algorithm that can solve small plans and “puzzles” involving reasoning like “before passing this door, I need to get that key”. This is definitely planning territory. However, if we focus on a small subset of the problem, we may squeeze the algorithm into the pathfinding search itself.

You know, I quite enjoy TypeScript. It is not my favorite language ever, I am more a functional type of guy, but it is the best way to bring order into the JavaScript mess without too many hassles. Moreover, it is the language in which I prototyped my Astronomical Calendar Generator. Now that I’m working on extending it, I want to keep using TypeScript and stop falling in my usual decision paralysis. Anyway… First thing I needed to do is how to unit test a TypeScript source base. It is easy, but not intuitive. So let’s see how to do it.

In this year top-5 promising languages list, I put Kotlin in fifth place among the languages that you should definitely check in 2017. This week Google I\O announced that Kotlin is now an officially supported language for Android Development. I like to be right in my forecast. However, I need to be honest. Back then, I didn’t know well why I put it there. I just had some kind of ethereal intuition.

In the article I wrote:

Yesterday I spent way more time than needed for compiling this dependency on Windows. The problem is that the error was not informative enough and hard to google, and, mostly, that there is no standardized way to look for installed libraries in Windows. Just to be clear, there is no reliable way to use pkg-config on Windows as in Unix-like systems.

I am removing comments from this blog. There are several reasons for this decision. First, it is hard to find value in comments anymore. In 3 years I think I have collected something like 10 comments. Most of my interaction with readers and other people happens on Twitter, in the Facebook comments or in the Reddit threads. Second, the existing main solutions for comments are unappealing.

The default WordPress comment system is very spam prone and hard to manage. On the other hand, Disqus looks like a more technologically advanced solution. Unfortunately, in practice, it is a resource hog, it forces you to have your experience shared among different domains, and, in other words, a giant tracking system. I do not want to force my readers to load a third-party potentially tracking system every time. Even because it make hard to me to enforce a serious privacy policy for this place.

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

In this article I want to show you a small proof of concept where we generate from scratch an alien calendar. The difference from other random calendar generators that just put random days and random month is that, in this tool, we can specify as input the orbital parameters of the planet and satellite and generate a calendar that makes sense. How could be the calendar for that planet orbiting a super-massive star? How could be the calendar for Mars or Venus? Every time I try to sketch a Sci-Fi world, I want to try thinking to a calendar that make sense for that particular planet. Because the calculations are long and boring, I built for myself this little tool. However, before going to the tool, I want to provide a small introduction to the problem.