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?

You know I worked a lot with pathfinding. In academia, the MovingAI benchmark created by the MovingAI Lab of the University of Denver is a must for benchmarking pathfinding algorithms. It includes synthetic maps and maps from commercial videogames.

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.

I would like to expand the answer I gave on /r/gamedesign some days ago. The main point of the question was: how can I decide if it “better” to implement the decision-making layer of our game AI with Behavior Trees (BTs) or with more advanced plan-based techniques such as Goal Oriented Action Planning (GOAP) or Simple Hierarchical Ordered Planner (SHOP).

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.

Level-based progression is an extremely popular way of providing the player with the feeling of “getting stronger.” The system is born with Role-Playing Games (RPG), but it is nowadays embedded in practically every game; some more, some less. Even if it is entirely possible to provide progression feeling without levels and experience points, level-based progression is natural, direct, and linear, and it fits well in many (too many?) game genres.

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.

A lot of startups are using “blockchain” as a replacement hyped word for “distributed database”. Well, a blockchain is the most inefficient and slow “distributed database” ever created. Blockchain strength is not in being a database! Stop doing that!

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!

If there is something that can be assumed as a fact in the AI and Machine Learning domain is that the last years had been dominated by Deep Learning and other Neural Network based techniques. When I say dominated, I mean that it looks like the only way to achieve something in Machine Learning and it is absorbing the great part of AI enthusiasts’ energy and attention.

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.