As you probably know, I am working (slowly) on an astronomically accurate calendar generator. All the orbital calculations involved are quite challenging, and I am discovering a lot. It is a lot of fun (except for the all the times I need to do some trigonometric magic to make some formula work). Anyway, during this process, I am reshaping and producing many many formulas. I am sure that in six months I will forget all the motivations behind them. For this reason, I want to try to save some of them here. In this way, I will have a good place where to look back at my notes and, moreover, I can be useful to other people trying to do some low-accuracy orbital calculations. I want to start from the beginning: orbital period and orbital trajectory.

Use of machine learning is becoming ubiquitous and, even with a fancy name, it remains a tool in the statistical modeler belt. Every day, we leak billions of data from ourselves to companies ready to use it for their affair. Modeling through data get more common every day and mathematical model are the rulers of our life: they decide where we can work, if we can get a loan, how many years of jails we deserve, and more.

This small article is born from a discussion I had with a friend of mine this week. He was writing a review on Playersunknown’s Battlegrounds (from now on, PUBG) and he ended up talking about the evolution of the genre and its triumph over every other competitor. The article was good but it did not enter in detail about, what I think, it is a greatly important and interesting question: Why PUBG? Why not any of the other dozens of battle royal games we were plagued in the last years?

PUBG is clearly a winner in this competition. It sold more than 8 million copies on Steam only, and I can see the trend going with the future release on consoles. The problem, in my opinion, is that, on paper, there is nothing in PUBG implementation that seems “right”. Nevertheless, it won.

Machiavelli once said that success is 50% luck. That’s definitely true for PUBG. But the other 50% must be researched in the PUBG qualities. Analyzing them, despite the massive “errors”, it is very important for any game designer.

I want to take the cue from a last week massive Reddit thread on micro-transaction in Free2Play (F2P) games to give my opinion of the topic. I think it is important. We need to increase awareness that predatory practices in F2P games are incredibly close to gambling and share with it the same self-destructive and harmful addictive behavior. This is wrong in so many way: it is dangerous for the victims, it is dangerous for the game itself, and it is dangerous for the entire F2P model.

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: