Some years ago I was playing one of those big AAA games, an epic RPG saga, a staple of single player games. While I was leading my army against the forces of evil, in one of the first outposts I meet a guy with a quest. What an epic quest it will ever be? What dangerous task requires the intervention of an epic hero?

“Collect 10 herbs.”

This month I am a bit late; I have good reasons! A lot of things happened in between the end of February and the begin of March. So, it is better not to lose more time.

It was the summer of 2018. I was a bit burnt out by a mix of anxiety, work and a bloody hot week. So, I decided to go to my parent’s mountain house. The plan was straightforward: go there, disconnect from the world, write fiction, read books, do long walks in nature. I wanted to do the things I used to do a long time ago when life was breezy :D.

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.

Here we are again on this monthly update in which I talk about everything and nothing — a small summary of what I am doing, arranging and brewing, both on tech than in life.

Random Walking is a handy technique to have in your gamdev toolbelt and - despite the name - it is most useful for everything but actual walking. With random walking, we define the output of a process that can be described sequence of random steps. The main difference with a random sequence is that each new value will be statistically near the previous one. Imagine a gold price chart and assume that the current cost is 10€ for 1g of gold. We cannot guess what will be the price in one hour but we can be sure that it will be around 10€ per gram, maybe 9.5€, maybe 10.5€. What is certain, is that a sudden drop to 1€ per gram would be deeply unlikely.

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.

I am a functional-oriented developer. I have a bit of expertise in game development, especially in Unity 3D. It comes naturally that I am interested in the obvious link between the two: F#.

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.

In these days I am reviewing CIG papers. At the moment, I am not active in academia, but I enjoy being around in the community. Even if only with this “simple” tasks.

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.

My opinion is that talking about languages is usually a very unproductive use of time. If these discussions are just cat fights, then it is even worse. Unless you are a language designer, you are writing a language or study a language, you should just use a language and nobody should care.

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.

Fishing is probably the most common mini-game in gaming history. Before I started working on this article,  I never realized how many games include a fishing as mini-game. The list is huge. Fishing is everywhere. It seems that it is not possible to have a game without the possibility for character to have a relaxing time fishing in a pond.

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.

Game Development is one of the fields in which Rust can gain a lot of traction. As a modern compiled language with performances comparable to C++, Rust can finally free us from the tyranny of C++ bloated feature set, hard-to-link dependencies, and header/implementation file double-madness (I am obviously exaggerating, btw).

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?