If you are not a software developer and you use AI to jam together personal scripts for yourself, do not worry, you can do as you want. If you are using them to learn something, don’t worry either.

For example, I have a note summarizing all the movies I watched each month. For that I use a combination of CSS and a Dataview query to generate a grid of movie posters. Until recently I used a very simple Dataview query, but I had a problem: if I watched a movie twice in a month, I got only one entry in my poster grid. This is not what I wanted, so I had to do something more complicated.

Fortunately, I have some experience with these situations, so I was able to regain control in a week instead of the three months it used to take.

No real damage, I suppose. I guess nobody lost any sleep over it. 😅

This is already a good result for July, per se. Hailstorms and high-speed winds scourged Northern Italy, while forest fires tormented Southern Italy. I, in the middle, only had to endure 45°C. If you look at this in perspective, it is not so bad.

However, surviving was not enough. While the world slowed down, burdened by the sluggish progression of an overheated July, I felt more in tune with myself.

June was also the month in which I was supposed to get the new car I ordered back in January. But no. No luck. I must continue with my old garbage-car for a bit (if she doesn’t fail me first).

Unfortunately, I was right. Over the past 30 days, I have felt myself slowly sliding to the bottom of my emotional pit. Moreover, my “preventive care trip” to Ferrara got canceled due to the extensive and destructive floods in the region, so I had no other option but to accept the sliding.

April has been grossly underwhelming; I had little motivation, energy, and found myself in a persistent state of low-level anxiety.

Unfortunately, this has dramatically impacted my ability to mentally organize my things. For example, I usually follow a seasonal schedule where I reevaluate the previous three months at the end of each quarter to see what worked and what didn’t, and plan for the next quarter. It’s kinda like having a “new year” every 12 weeks.

With a quick statistical exploration of my diary, “kitchen” was the third most used word, followed only by “things” and “do.” I don’t need GPT-4. Even this stupidly simple stat nails the two main issues this month: finding it very hard to do anything and fighting with my damn kitchen.

I wanted to actively come back to fiction writing for a long time, but I never managed to get myself to do anything in that regard. So this month, I followed my own advice and asked myself to write for 30 minutes three days a week. It is really nothing. But it worked, and I wrote the first 2000 words of fiction in a long time. Not much, but still 2000 more words than in the previous 13 months. And even if I continue with this laughable average, I will still have a complete novel in 1 year. Not bad for “getting unstuck.”

Is this a good reason to give up? Absolutely not. But if we want to build a tower, we must prepare the terrain first. This is what January is for: not for tracking down goals but for preparing ourselves to veer the boat in the right direction.

So what this list tells about me?

For one, it says that I am a bit disappointed. I ended the year with only 28 books: three less than 2021, even if there are more short books. So, I should look back and see what didn’t work out. For instance, I started too many books in parallel. Another thing is that this tragically eventful year has deeply distracted me. Finally, I only read 7 fiction books (last year, they were 17). 2 of these 7 were really boring bricks that slowed me down a lot. The lesson is that I should learn how to drop a book that is draining the life out of me.

December is also when winter begins. People see winter as a gloomy season, but I see it as the season of rest. If you look around, winter is when Nature goes to rest. Some animals go into hibernation, plants look dead, and sprouts and seeds lie sleeping under the snow. Winter is when Nature takes it slow.

November is usually a bad month. It is always full of bad memories and events. Even this year, November hit again early in the month: once again, I had to attend a November funeral. So I was ready to accept another black month in which the best I could do was to collect the pieces.

Well, no. The critical part is the other: transitions.

Transitions can make or break your AI independently of how carefully crafted the states are. In other words, intelligence is in change, and the element of change in an FSM is represented by transitions.

This threw me off a bit. At the moment I am writing, it is Halloween, yet I do not really feel it. Well, I didn’t feel the October vibes for the other part of the month, either. So I will probably call this month September 2.0, hope for a more traditional November (or not; I am okay with mild temperatures this year), and move on.

I’ve also finally updated this blog with an extensive article. The funny thing is that it was not any of my “currently in draft” articles. Instead, I tried to intervene in a bit of drama between the artist community, the recent progress of Computational Creativity, and the state of the art in “AI-Generated Images.” So if you don’t know what I am talking about, but if you like AI, are an artist, or simply want a freakout-free guide to “AI Artists,” you are the perfect audience for my article.

But July was not one of those months. In fact, when it started, I was sitting at a beach bar in Attica, Greece, looking at the moon reflecting on the nigh sea after the first day of the company retreat (to be precise, the first retreat after the pandemic pause).

But let’s come back to the chase: June. June started as May ended: in an emotional disaster. Fortunately, though, things got better along the way. If it weren’t for my usual travel-induced anxiety, I’d be in a very good spot.

I constantly have the burning desire to have a place to write something completely free. My blog is mostly about technology, and my Medium publication is about political philosophy, but what about everything else? In the last two years, my interests shifted, and while I am definitively still working in tech fields, and I will still write about it, I missed having a small place where to explore different things that are not big enough to be worth an entire article or, even worse, a separate blog.

However, I am back with an announcement: I have recently published the fifth edition of Unity Artificial Intelligence Programming.

Not only have I updated the book for Unity 2022, but the book is also a massive improvement over the last edition in terms of code quality and consistency (and I really need to thank Kazimieras Mikelis for the extensive and detailed review). Moreover, I added a chapter on Procedural Content Generation because it is my main interest, of course.

Fortunately, time proved me wrong. And I am delighted I was. I am not sure what happened (as I said, I stopped following it), but the language had significant acceleration, and it finally got enough adoption and interest that it finally popped up a lot under my radar.

During the years, my extension page grew bigger and bigger; new extensions get installed, old extensions get removed. You know, the usual stuff. But during all these years, a bunch of extensions has always remained the same. They are my favorite VSCode extensions, and I am going to list them here.

It will be a chance to discuss my readings without the need to write a full-fledged article. I hope it will be interesting as a review of the book or as a discussion starter. So, let’s start.

About Life

September has been fun. I traveled to Padua for the CICAP Fest (a series of conferences organized by the main Italian Skeptical association), I went to a couple of nice restaurants, I completed some personal goal and I ate some Banana Pancake. 🥞

However, sometimes, I fall into watching discussions in the go community, and they are so absurd I cannot shut up. 

To hot to think and words order fine screen in! Let’s just look at this month update before I catch fire!

Yesterday I was reflecting about an interesting fact: in the list of “my favorite games of all times,” the top 10 is packed with games that share all a common element. The games are:

• Dark Souls
• Dark Souls II
• Well… every game of the soulborne genre.
• Hollow Knight
• The Legend of Zelda: Breath of the Wild
• And more.

Can you guess what they all have in common?

Sure, they all have a decadent setting (the world is falling or is recovering after a cataclysm), but there is a way more common design element: narration through discovery.

Sure, they understand better, they speak better, they have learned some new trick; but in the end, they are still a funny but useless experience. After the first fun moments of experimentation when you start talking to them – that is, where you keep asking them silly jokes or dumb questions – they quickly came back to be pretty dumb object. I am pretty sure that the vast majority of user use a VA just for timers, weather and – occasionally – asking for the event on our calendar.

If you know what a Turing machine is (and you should) you will have an intuitive idea of the claim: you know that X can compute any computable function. Sure; but if you stop thinking about that for a bit, it is not so intuitive how we can prove that. If we think long enough, we can start understanding how X can simulate a Turing machine, but how can we be sure that we can encode a Universal Turing Machine and what is the program of a UTM and how we can prove that it is, in fact, universal?

Kotlin is a really sweet language. It is the perfect thing in between a “super-powerful and but difficult language” like Rust or Modern C++, and a “super-easy but that seems to be designed in the 80s” like Go. With the upcoming release on Kotlin Native, then, you can even ditch the JVM!

However, while IntelliJ is a great IDE, often I do not like to rely on big IDEs — especially when VSCode works perfectly well for 90% of my use cases. Therefore, it is time to see if and how I can use Kotlin in VS Code (and see what is missing).

Reading those parts for the n-th times made me realize that Quidditch may be a good way to showcase common rookie mistakes done by people approaching game-design for the first time (and it also provide meaning for my struggle). So, that’s what we will do today!

“Collect 10 herbs.”

However, after just one day, I found myself doing the same things I usually do at home: checking news, looking for interesting, reading opinions, checking Twitter and so on. It was then that: I did not know how to relax anymore. I did not know how to be creative anymore.

In this article, we will talk briefly about random walking and its ability to simulate many real-world processes such as resources prices, temperature, floating objects position over time, and much more.

F# is a functional language of the ML family born in the Microsoft Research and now developed by the F# Software Foundation. Of course, F# run on the .NET framework, the same as C#, the language used by Unity3D. It is clear, then, that we could use F# in Unity. And, in fact, we can with moderate easiness.

Should we? How easy is that? answering these questions is the goal of this article.

This, however, makes me think about the state of scientific work in academia. At least in the computer science field. Something bothered me during my Ph.D. and I am sure it is related to that. (Note: I am talking about what I know, that is, the computer science and AI community) In general, researchers are evaluated on the number of publications. The number of publications is a proxy variable for measuring “quality”. Unfortunately, researchers know that and started to game the system. They try to publish more and to do that they need to lower the “quality” of their work. Because the medium used to communicate your work is a plain PFD file, the obvious way to cut work is to cut the implementation part.

But good articles on language pro and cons are always nice. They may be helpful to choose the right tool for the problem. For this reason I link a good article on Go. And that’s the last time I’ll talk about Go.

Everybody loves fishing! At least in games. We can imagine a deep reason for that. There must be something that attract designers, gamers and human in general to the ancient art of fishing. However, for the time being, we are not interested in this question. Instead, we want to explore the huge design space of “fishing games”.

In fact, the action of fishing has been dissected for decades by game designer. It is fascinating to see how many implementations exist for the same real-life action. So, it is time to see what they produced, what are the possibilities and how we can do something new in this domain.

However, if this freedom arrive, it will be a very slow process. To make it slower, the feature of memory safety in videogames is not a huge priority compared to the ability to quickly prototype. The borrow-checker and the strict compiler are an obstacle in this regard. On the other hand, memory safety also means easier multi-threading. And this is sweet!

Fortunately, the annoyances of borrow-checker will get less in the way while people becomes more confident with the language, and while tooling gets better and better. I am confident we may see Rust carve out its space in this domain.

But this is the future. What about now?

Parsing the benchmark data, the maps, creating the map data structure and more, is one of the most boring thing I needed to do for testing my algorithms. For this reason, I think a common library for working with the maps specifications it is a must.

First consideration: this is not a technical problem

The first thing to know is that writing game AI is not a race for the best technology. Instead, it is just about choosing the right tool for serving the gameplay as well as possible. So, there is no urgency to select the most advanced algorithm. You need to choose the simplest one that is good enough for your game. Remember Pac-Man. The AI of Pac-Man is still utterly challenging, and yet it is exceptionally straightforward.

However, not every experience-level progression is the same, and it is essential to design designing a fun system. Many games do that without much thinking: they just slap experience points and level, and that’s it. The general idea is that the more is your level, the more experience you need to advance to the next one. This is true, but it is just a small part of the design. In fact, you must keep in mind the effect of any gameplay element on the player, and you must be sure that what you do produces the emotion you want to convey.

The blockchain power is in avoiding divergent transactions, and guarantee a not falsifiable and immutable history. That is, no node in the system can alter the past of the chain. That’s it. They are huge and specific problems.

One of the feature I like the most on Rust is automatic documentation. Documentation is a pillar in language ergonomic, and I love that Rust spend so much time into making documentation and documenting code a much pleasant experience.

Rust autogenerated documentation (with cargo doc) looks good, every crate on crates.io get its documentation published on docs.rs, and, most important, every code example in the code is compiled and run as a “unit test” making sure that all the examples are up-to date!

This is indubitably a good thing. Having a strong AI technique that can solve so many hard challenges is a huge step forward for humanity. However, how everything in life, Deep Learning, despite being highly successful in some application, carries with it several limitations to that, in other applications, makes the use of Deep Learning unfeasible or even dangerous.

This year, however, I am not in the mood of doing it. There are several reasons why. The first one is that this year there have not been a lot of movement on the new programming languages. I am sure there are a lot, but no one got enough attention to make into a list. Therefore, I am concerned that I will just starting to repeat myself talking about the same stuff.

The book title is “Crittografia ossia l’arte di cifrare e decifrare le corrispondenze segrete” of Count Luigi Gioppi of Turkheim.

Well, I don’t know if this book is hard to find. In any way, I decided to take a photo of every page to share and preserve this book. The book is very old and some page is ruined, sorry if the quality of the photo is not optimal. I’ve done my best for not destroying the book in the process. :) I will release the photo one chapter at the time. Keep this page in the bookmark.

The Novel

I think it is the proper way to do it: I need to talk about the novel. The novel is, of course, in Italian and it is unfinished. With 52k words I reached barely the beginning of the third act, more or less. Many things need to be rewritten, characters disappeared in thin air as soon as I discovered that I don’t need them… stuff like that. The usual way to do a first draft.

Said that, here we go with the next part: lunar phases.

Why lunar phases

Lunar phases are incredibly important in a calendar. So important, that many of the early humanity calendars are, in fact, lunar calendars or lunisolar calendars. Of course, this is true if and only if the planet is lucky enough to have a big moon like us.

In this part, instead, we will tackle a fascinating consequence of the cosmic dance of our planet around its sun: seasons. Seasons are a strange beast because their behavior depends on a huge amount of factors. We are used to our four seasons with mild springs and autumns, hot summers and cold winters. But these four season are just the consequence of our planet ecosystem, atmosphere, the peculiar axial tilt, if the orbit is particularly eccentric, distance from the sun in different period of the year can be a strong modifier too! In multi-star system, we can have more than 4 seasons, in planets with strange mechanics we can not have seasons at all (or better, the “season” depends on where are you on the planet).

But let’s start from the beginning. Imagine a simple binary classifier. It takes some input \( x \) and return a Boolean value telling use if \( x \) belongs to a certain class \( C \) or not. When we pass through the algorithm a number of elements, we can identify only 4 possible outcomes:

Can a game that can easily beaten in a couple of hours be hard? No. It is challenging", yes. It requires multiple tries, for sure. But it is not hard and definitely not “brutal”. There are several reasons why Cuphead can be considered a very forgiving game.

The Context

You are probably asking yourselves: why? A perfect summary is explained u/A-Grey-World comment on Reddit:

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.

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.

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.

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.

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

So, now that you know what I am talking about, here we go with the top 5 for 2017.

Top 5 Promising Programming Languages for 2017

Rust

In reality, the exploration of the “combinatorial nature of art and human thoughts” is a much older concept. Probably, the most interesting and early writing on “PCG” is the doctoral dissertation of Gottfried Leibniz, De Arte Combinatoria (On the Combinatorial Art) (1666) in which he exposed the main idea that “all truth are nothing but combinations of a relatively small number of simple concepts.”

For some reason, there is no easy out-of-the-box way to do that. On the internet, there is a small library, but it depends on JQuery and I think it is insane to load JQuery on top of THREE.js just to load a couple of files. Therefore, I wrote a function to do that using the THREE.js integrated generic loader function.

Moreover, there is also an article of mine on the Ouvroir de littérature potentielle (Oulipo), a mid ‘900 literary movement that it is really connected with the PCG. If you want to read about people developing PCG stories in the pre-information era, take a look.

Why I’m talking about this? Because, in the last weeks, I’ve found an extremely easy way to spy any Telegram group. It is not a dark market secret (in fact it is perfectly documented in the Telegram Bot API), but works perfectly because nobody cares. While every internet and privacy activist is talking about how Google, Facebook and Yahoo are spying on our email, telegram bots that are actually logging all the messages in all the groups in plain text. They are bot, by unknown programmers, without ToS, without anything, reading all your messages and potentially storing them who knows where.

So, I will explain to you how to build a Telegram SpyBot. Hopefully you can use it to teach some privacy lesson to your friends.

These days were a bit busy. I want to break the silence with an interesting link to a video. This is an interesting and fun to watch talk coming from the last PyCon. It talks about “practical statistics”, that is, how you can try to produce (or validate) a model when you can not compute the analytic model of a phenomenon. Many of the technique he describes can be used to any language, so it is suitable even if you do not program in Python. Anyway, look that, it is worth it. Moreover, this is just an excuse to suggest you to look around all the other videos from PyCon. They are well made and there are some interesting talk that should be watched.

But it is not just choosing a number. The “number of players” parameter cannot be arbitrarily moved at will. The more we increase the value, the more the designing task becomes harder and harder. Look around you. We have thousands of single-player games, we can find a huge amount of games for 2 to 4 players, we have party games that can go to 10 players or team sport games such as rugby and football that can be played up to 20 or 30 players, but after this amount of players, how many good games there are?

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

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.

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:

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.

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.

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.

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.

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?

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!

In the previous part we have seen how to run simple Rust functions with integer arguments. This is not enough, of course. We need to go further by passing Python lists to Rust functions.

The problem is that it is not possible to pass directly a Python list to a C interface. Python lists (we can call them Plists) are complicated beasts, you can easily see that they are objects full of methods, and attributes and… Stuff.

1
2

dir([])
['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']

We need first to convert this in something edible from a Rust library. But first things first.

Rust is an amazing language. It is one of the best potential alternatives to C and has been elected two times in a row as the most promising language of the year (by me, :P). However, because its strict compile-time memory correctness enforcement and because it is a low-level language, it is not the fastest way to build a prototype. But don’t worry! Rust is the perfect language for embedding fast-binary libraries in Python! In this way we can get the best of both worlds!

Writing Rust code that can be executed in Python is stupidly easy. Obviously, you have to well design the interface between the two languages, but this will improve your Python code in two ways: 1) You can execute CPU-intensive algorithms at binary speed and 2) use real threads instead of the Python “simulated” ones (and because Rust is designed to be memory safe, writing thread safe routines is much easier). Let’s see!

The last of these tools is a straightforward Python script to convert images into maps in the MovingAI format. It is useful when you want to quickly develop some test maps.

On the other hand, it is almost impossible that a researcher will learn the basics of software development in some book because 1) nobody cares (and they really should!) and 2) books on this topic are mostly focused on commercial software development. This is a problem because, even if best practices overlap for the 80%, research code and commercial code are driven by completely different priorities.

So, because I am just a lonely man in the middle of this valley, nor a good research code writer nor a good commercial code writer, I can share my neutral opinion. Maybe, I will convince you, fellow researcher, that may be worth to spend some time improving your coding practices.

January 2016 has been a great start for this year! During the last months of last year I started a personal journey to fight my inner demons. I don’t want to bore you with some self-improvement/productivity bullshit -it is not the place for that- so I will not. You just have to know that after 6 months of trying and failing this January is the month in which all the good habits really start to stick.

The “One Game A Month” challenge was the perfect way to test myself and doing one of the activities I love most. As usual, we will start from the beginning.

One of the main problems with the standard average is that it “slows” over time. This can be a serious problem. Suppose that you are designing a game in which your player have to quickly press a button to keep a value (e.g., player speed) above a certain average. If you use the global average, after a certain amount of time, your player can stop pressing the button and still keep the average above the threshold.

The demonstration of this is quite intuitive. If you have an average a(t) at frame t and the player will not press anything in the current frame, the average at frame t+1 will be

This factor depends on the elapsed time and becomes “almost 1” very quickly. You don’t want that. You want to keep your player on the narrow land between “boredom” and “frustration”. You cannot give to your player the possibility to win without doing nothing for 30 seconds.

The solution to this problem is simple. Use a Moving Average. The player will have to push the button faster than the threshold, but the average is computed only using the data from the last 5 second (or any other time window you want).

Thus, I decided to write my personal framework for running experiments in Python: YoshiX. The idea behind YoshiX, inspired by classical Unit Testing libraries, is quite simple. You write your test in a separate file, then you run yoshix and it automatically finds every experiment in a specific folder, runs them, and collects the output in the format of choice.

It is a simple tool; I still have not spent a lot of time in it. But I think it has some interesting developments. Let’s look into some details.

Instead, I am trying to list emerging languages that may become more important at the end of 2016. This list is for you if: 1) you are passionate about programming languages 2) you want to learn something new because you are bored with your current language 3) you want to bet on a language hoping that it will become mainstream (and thus, you will be one of the early experts in that language, and this implies nice job opportunity). Or you can read this list because you are simply interested on where the language research and development is going in the real world (academic research is a totally different story).

Except for the last question, we can try to answer them just looking at the damage formula. Obviously we can not answer all the questions now, but if there is some evident mistake, we will be able to catch it as soon as possible. There are several ways to analyse the tuning and balancing problem for a damage formula (and thus for a large part of the combat system): analytically, with Google Sheet/Excel, and with a quick software prototype.

In this article we will start from the first step: the analytical analysis.

Since the beginning of the videogame era, developers aim to reach a perfect simulation of the world. “So realistic!” is probably one of the most abused comment to a videogame ever. The videogame industry tried to reach realistic graphic, realistic sounds, realistic landscapes and realistic Non-Player Characters. However, reaching the perfect realism is a never-ending quest. As soon as we reach something, desire drives us to seek more.

Now that we have extraordinary graphic capabilities and stunning landscapes, some developers are going to raise the bar to a much bigger task: simulating the universe (or at least, the galaxy). We are not in the first (game) generation who is trying to achieve that (the original Elite is a very old game indeed), but we are for sure in the first generation who can reach this goal; at least to some extent.

We have the technical capabilities for doing amazing things: we can generate and simulate hundreds of billions of star systems, we can allow the player to travel to every one of them, explore and land on every square unit of the planet surface, every asteroid, every satellite. Software/games such Space Engine can clearly show us what a lonely developer can do in its spare time. Imagine what a game developers team can do on their full time job! It is not a surprise that several studios spotted the niche in the market and tried to use this power for a real game. After all, it is not “simulation of experience” one of the meaning of “game”?

There are several ways to implement a combat system but, at the end of the day, we can divide the heterogeneous world of combat systems into two big clusters: real time combat systems and turn-based combat systems. The first are exciting but they rapidly becomes hard to implement. We will need to do a lot of animations, tuning collision boxes and tons of graphical stuff. If you are a poor programmer like me, you cannot do that (sad face :<).

With turn-based combat system, instead, you can do the most complex things you can image! You can take into account hundreds of variables and statistics, create complex strategic combinations, evocations, magic, everything. You can use dice, cards, tokens, everything in order to emulate an epic combat between a dragon and drunk dwarf with a wooden leg. Because turn based combat systems are an explicit abstraction of a real combat, the player can absorb without complaining a bigger level abstraction. The same cannot be said for a real-time combat system in which just an ugly animation can be labeled as “ugly designed and sluggish combat” and provide frustration to the player.

So we are going to implement a turn-based combat system! But how? Well, this obviously depends on which type of turn-based combat system you want to do. For now, we will try to do a replica of the first turn-based game I’ve ever played: the Pokemon Combat System!

This is a nice combat system to replicate as a tutorial because is not too complex (especially in Gen. 1 or 2), but contains several tricky points that we need to handle! We will explore the design and the implementation of this combat system in details. We will see how to design the combat system, how to do a first balancing and test on paper, and every implementation step! So let’s start!

But where I could start? I decided to stress myself on an old obsession of mine: writing. As you know I have stories in mind and I have a deep need to tell these stories. There are many ways to express these stories (music or gamedev are the most important one for me!) but writing it is much less complex: it is just you, the story and a piece of paper. There is no technology involved, no extra abilities such as visual arts, no constraints, no distractions. I did not want to feed p-monkey with a lot of fake-problems to justify myself for not doing anything every day. So, I took a piece of paper and I wrote on it: I’ll write One Million Word of fiction. It is important to have some kind of metric to measure your progress and the number of words written is a perfect metric! Every night, at the end of the day, I can update the counter, see the target approaching and feel good about myself.

A month is passed and I want to share this small step with you.

Returning to the subject, my work is totally focused on pathfinding with cognitive capabilities. This means that I try to embed pathfinding into a more high-level reasoning pattern or, if you prefer, to push high level elements - such as reasoning with keys and equipment - down into the pathfinding level. As a consequence I use hierarchical abstraction of the map space a lot and for “a lot” I mean that in the last year and half I’ve implemented Hierarchical Pathfinding (HPA*) at least 4-5 times in different context and languages.

Anyway, let’s start!

In the last months, I get used a lot to the Javascript ecosystem and community and it becomes a language in which I feel quite happy to work with. Let’s see why (and why still is not a perfect language).

Many of you use Git daily, I’m sure of this. You are using it for managing projects, tracking version of your software, personal documents or to collaborate with other colleagues and open source softwares. But I’m pretty sure that many of you don’t know that you can use Git for debug! Yes, Git can be one of your debugging tools too! Let’s see how!

This positive feedback loop can really increase your productivity. The real problem is, how can we find this magic smooth workflow? I don’t know. I cannot tell you the magic solution to every developer problems. You have to find this by yourselves. The only thing I can do now is telling you my actual workflow. This may be a good starting point for some of you. :)

So the idea was to do this trying to be as much idiomatic as possible so that this code could be used by new haskellers in order to learn something on the language. It is still not really idiomatic, but I’m working on that.

I have a certain envy for those developers that are able to stick on, for instance, Vim for more than 20 years. They are happy and enthusiastic of their editor! Lucky them! But I’m not in this way. Maybe I find the exploration more rewarding. I don’t know.

So, coming back to the topic, when I used Linux I was happy too and my favourite editor was by far Vim. Yes, the learning curve is steep as hell but this thing has never scared me (I try to learn too many newborn and cryptic programming languages to be scared by a text editor, complex or not that may be. Then, a couple of years ago, I moved back to Windows and I started to work on bigger project. For some reason, my pleasure and muscle memory in using Vim began to disappear.

Now, there is a long story made of IDE and text editors but I don’t want to spend too much time talking about my evolution (or devolution, your call) in the world of programming editors. The real goal of this article is to explain why, for now, I’m happily landed on Atom, the text editor mad in GitHub.

Second, it is now time to talk about the game we developed for the Global Game Jam 2015 (and obviously valid as a January entry for my One Game A Month challenge!) I’m very happy with this game also if it is not a real “game” because (little spoiler) it is an online game who require a big amount of users to be interesting. I’ll never have so many users connected at the same time, so it is useless in practice. The good thing is that it was a big technical challenge and to be able to complete everything in less than 30 hours was really exciting. But first things first.

In the the previous post we have seen what are the general trends of the previous year with regard to the fascinating world of programming languages. To summarize, we can say the there are two strong trends: 1) more functional-inspired elements in programming languages 2) more statically strong typed languages that can be compiled in machine code.

Now, in the current article, I want to list all the languages which have attracted interests in the last years and that represent the implementation of these trends. Obviously, as I said in the previous article, these are not languages on which to bet their careers: these are new trendy languages but the real world does not work on “trends”, but on software, oil, commerce, health care and an hundred of categories in which the actual programming languages are doing great with an huge amount of per-existing codebase.

However, it is nice to explore the “future”, so, let’s take a look.

At the very beginning of a new year, it is customary to try to predict what will happen in the future. That is the selling point of each big astrology book which pollute bookstores and newsstands in this part of the year.

Personally I’m not a fortune teller, but I think that can be interesting to try to set the route of the new year on the basis of the one just past. Obviously, I do not pretend to talk on every possible kind of events, but for the one I’m interested in, I think I can say something interesting or, at least, start a discussion.

So, let’s try to spend some words on the trends regarding programming languages and software development.

The second “resolution” is to beat the One Game A Month challenge for 2015. The goal is to complete a game each month. You don’t have to realize the full game in one month, you just have to complete and release it. I think it is a nice opportunity to challenge myself on some specific game development aspect while forcing some deadline (that is always a good thing).

However, taking advantage of the Ludum Dare jam on December, I started this challenge a bit in advance. :) So, now I’m going to do short post-analysis of my game for the previous month.

From the theoretical point of view, a cellular automata is a discrete model that consist in a regular grid of cells. Each cell can have a finite number of states (usually two: on and off). On top of this grid, a system of rules is built to control the evolution of the cells. The rule are usually simple and local: this means that each rule decide on the state of a single cell just on the basis of a limited set of cells (the neighborhood) located around the cell of interest. No rule on the global state of the grid can exist! For instance “the total number of cell in the on state is less than X” is NOT a local rule.

In recent years, PCG is having an increasing popularity among the academic and game development communities. There are two big reasons behind this success: first, it allow the designer to generate an near-infinite amount of contents without the effort of manually design each element by hand (and that’s why the indie scene love PCG), second it increase the game longevity and replayability value of the game (because, for instance, the game it is always different after each run and so it can be replayed more). This two things combined are The Dream for every game designer: huge longevity with low effort at design time.