The definitive guide to start with ClojureScript

Yesterday, while my working machine was crunching tons of numbers, graphs and maps to produce some (hopefully) meaningful data for a research work, I was looking for a simple guide to build a simple web page with ClojureScript. Unfortunately, I was not able to find something that was at the same time straightforward, simple, minimal and explained! So, I decided to write something by myself to avoid my pain to some future young clojurist.

The main problem with the guides I’ve found online were:

  1. They didn’t use Leiningen or any other build system. Now, this can also be good, but Leiningen is, in practice, a standard for Clojure developer, so I’d like to learn how to setup a project as soon as possible.
  2. They are outdated.
  3. They are not well explained. For sake of simplicity, they assume a lot of things. But I want to know what I’m writing!
  4. They are not simple. I don’t want to write a full featured web application with a lot of dependencies and plugins! I want an hello world!

So, I hope to cover all this points. Let’s start!

Continue Reading…

My peek on Atom

Atom Editor

People who know me already know: I’m a tool maniac. I can spend hours searching for the perfect configuration of keys, plugins, colors, themes, debugging tools and so on, and unfortunately this is how I waste a lot of time every now and then. Text editors and IDE are one of these big tools that I cannot stop searching for the perfect one. The real problem, though, is that I cannot find satisfaction for more than a month on a particular editor, so, during my life as a coder I used with a certain degree of experience tons of editors such as Vim, Emacs, Sublime Text, GEdit and much more. Honestly! Look at this! If  I had spent less time on tweaking my editors and more on coding, now I would have more side projects completed for sure. Anyway…

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.

Continue Reading…

Global Game Jam 2015 Postmortem

Exoplanet, Header

First of all, some time ago I stated that I would like to start writing more. Unfortunately, a combination of personal issues, flu and other psychological breaks did not allow me to respect this promise. But I’ll be back soon. I swear.

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.

Continue Reading…

The most promising languages of 2015 – Part 2

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.

Continue Reading…

The most promising languages of 2015 – Part 1

Rusty Crown

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.

Continue Reading…

One Game A Month – December 2014

Well, good job myself-artist.

The new year is come, full of good resolutions and appealing feelings of renovation. For my part I have two main target. The first one is to write a bit more. I always feel that I have a lot to say but, for some reason, I usually get stuck in a kind of writer’s block every time I finally found time for writing. So, because the only way to beat a writer’s block is to write, and write and write, I decided to spend at least January into a more strict scheduling. Maybe there will be a good impact in the blog post frequency too.

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.

Continue Reading…

On developer anxiety

Black Matrix

You are finally back home. During your work day your mind was totally a volcano of creativity. You have so many cool ideas to implement (or at least to sketch). You go to your machine and you start to thing to the technical details. Many questions reach your mind. Maybe too many. Is it better to use Python or Haskell, or maybe C++? I have to start implementing my game prototype with Unity or with some other engine? What if in the future I want to add “feature X” after “feature Y”? So you start crawling the web for resources, opinions and more information on your problem. And this will generate more questions. You spend two hours in this way and you are still full of doubts. Then it becomes late. You are tired. You will check out this problems tomorrow. But tomorrow you will find others problem and not even a solution. And so on. Until every project loses its momentum.

This scene happens to me and other people too many times. This is a classical example of developer anxiety. It is one of the most frustrating experience in this field: you have an idea but you can not even start to implement it because of the many technical choices you have to make but you are not brave enough to do. Because developer anxiety can be very common, I’d like to share some of my experience on this.

The Causes

It is interesting to look at the reasons behind developer anxiety. Let’s go in order.

1. Overgeneralization

A perfect represenation of overgeneralization:

A perfect represenation of overgeneralization:

This is one of the most common obstacle on the way of a successful project. Because developers are genetically trained to think about generalization and abstraction, our natural way to tackle a problem is to solve the general problem. Always. If we have to make a function to draw a triangle, we think on how to do a function capable to draw any regular polygon. If we have to represent a matrix of char, we design data structures that can store every grid of objects.

This tendency to overgeneralize over any problem can really slow down a project. Even if the generalized problem can solve many problems in the future, if it requires more than 15 minutes to be solved it is really recommended to take it apart and start with the particular one. Proceed in the development is fundamental for keeping the momentum of a newborn projects. If you lose two hours in solving the general problem, probably you get frustrated in not seeing a global advancement and the project can probably suffer of this.

In general the direction you want to take is from the specific to the general and not viceversa. It is better to have something specific working than a perfect general machine not working.

2. The Oracle

Another big anxiety generator is the “oracle syndrome”. The anxiety arises from the attempt to predict in advance every possible flaw in the architecture, in the feasibility of some design choice and so on. Obviously this is not possible. Experience and knowledge can help into avoiding obvious errors, thinking about that is a wise choice, however it is not possible to solve every error in advance. This problem usually pairs with the overgeneralization one: for instance, trying to check if a particular data structure will be scalable to the general problem.

You have to resign yourself to the fact that you can not solve all the problem in advance. Moreover, often can happen that the “perfect solution” will be completely broken after the first practical problem you find during the actual implementation. As a result, all the time you have spent in thinking is completely wasted. So, please, stop overthinking on possible problems and start exploring the real world implementation.

3. The Perfect Shot

Another way in which anxiety is manifested is into the desire to deliver a software from scratch directly into its final form. A long beautiful elegant parabolic shot from “nothing” to a state-of-the-art product. It is evident that this problem is quite similar to the oracle problem but has a tiny huge difference. In this case the developer is not trying to anticipate every problem, is trying to develop every possible feature all at once. So, instead of a working prototype with limited features, he has a not working mass of code that partially implements 100 features.

In the best case. Because in reality, the anxious developer, thinking on how to implement all this features, will be overwhelmed and it will never write a single line of code. So, don’t try to be a perfect archer, rather try to be a golf player: try to reach the goal through manageable and reasoned intermediate steps.

4. Information BlackHole

The anxious developer will search for information. Is it better Python or Lua for this problem? Will it be this language scalable to ten billion users? Will this framework be supported in fifty years? More the developer searches, more it sees different opinions, pro and con that will have the only effect to increase the developer’s overthinking. At some point, the amount of information will reach a critical mass and the developer world will collapse on itself.

In general, too information is even worse than no information at all. This desire of information is obviously driven by the “Perfect Shot” and “Oracle” flaws, but it is so important that it deserves a point by itself. Search for information is good, try to use information to know everything before start coding is BAD. There are two main reasons why the time used to explore the available domain knowledge should be limited and well allocated. First, you can always find opinions that are opposite each other, second, every second you spend searching for information you increase the risk of falling into (3) or (2).

This is a problem that I feel very near because (unfortunately?) I know too many programming languages and I spend too much time into selecting the right one for the current task. Oh well…

The Solution

Now that we know the causes behind developer anxiety it is time to see The Solution:


Really. Trust me. It is so simple. I know it is hard. Often, even I can not follow this simple advice. But it is the solution. When you see your code “alive”, also if it is not perfect, you completely forgot about any of the previous stuff.

So my advice is to allocate a fixed amount of time for thinking: 2 hours, 6 hours, a full day, whatever. But when the time ends, you start working. It will not be the perfect software, but it is something. And in the coding workflow it is incredibly important to see something works.

Random Maps with Cellular Automata

Real cells are a bit more complex than that... anyway...

In the spirit of the ProcJam2014 (that unfortunately I have to skip because of a ton of academic duties :<) I’m presenting to you a simple algorithm to generate maps: the cellular automata generator. In particular, cellular automata are very well suited for cave-like environment and, in general, natural maps. It works both in 2D than in 3D and can be easily implemented in no more than 20 minutes.

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.

There are a huge amount of theoretical work on cellular automata. The good news is that you have to know nothing about that to use them! Let’s see an example.

In the small applet above you can see the algorithm at work. First we start with a completely random map in which each cell is initialized randomly.

In the applet above, I have set the amount of initially “wall” cells to 40%. There is no reason for this number, it is just an empirical number. If you look better the map, you can see an empty column at the center of the map. Also in this case, there is no technical reason: I’ve just seen that with an empty line in the center of the map I usually get better results.

Then, you can press the “Evolve” button. The evolve button starts the cellular automata evolution algorithm. This is really simple. For each cell I check the following rules.

  • If the cell is a wall: if the number of walls around that cell is greater than 3, the cell remains a wall. Otherwise it becomes empty.
  • If the cell is empty: if the number of walls around that cell is greater than 5 or the number of walls in a range of two step from that cell is less than 2, the cell becomes a wall. Otherwise it remains empty.

As usual, the code is better than thousand words.

Because these rules leave some single-wall in the empty spaces, there is another rule that can be used to “clean” the map. You can see the effect of this second rule with the “Clean” button.

As you can see, the result of this algorithm is amazing1 and it is so easy to implement! There must be a flaw! Well, there is. Cellular automata algorithm are powerfull but are really difficult to control. There is really low control on the shape and features of the map. Moreover, this algorithm is extremely sensible to rule and parameter variations. Changing the initial randomness, or a single element of the evolution rule can have an huge impact on the final result. For this reason, this algorithm is suitable only in that situations in which the completely randomness of the level is a desired features. In other cases (or if you want an “artificial” environment or dungeon) there are other algorithms that are recommended.

The full javascript code can be found here. There is also a C++ implementation on my GitHub account here.

I hope you enjoy this!

Towards the ProcJam 2014

Next year we want a procedurally generated header!

Procedural Contents Generation (PCG) is a family of techniques, algorithms and procedures used for generating contents in an automatic way rather than manually. In other words, using PCG, game contents can be created by the host computer instead of pre-design everything at development time.

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.

A bit of history

Even if PCG are discussed a lot in recent years, its application in games (even commercial games) is quite old. One of the first complete example of PCG-based game is for sure Rogue, a game that was so influential to represent a new genre by its own (known as roguelike) and to be inspirational for an huge amount of games (up to Diablo). The games was developed back in the 1980 and it was characterized by a randomly generated dungeon in which the player have to explore, fight monsters and get treasures. The PCG generation of the dungeon is the main strength of the game and, not least, the main feature of a genre that goes from near successors (like Angband (1990)) to modern contemporary games such as Crypt of the Necrodancer (2014) or Binding of Isaac (2011).

Minecraft is the most popular example of procedural 3D world generation.

Minecraft is the most popular example of procedural 3D world generation.

Other than roguelike games, PCG has been used in many other games generes. One great example is Elite (1984), a space trading and simulation game in which literally everything (planet positions, names, politics and descriptions) is generated procedurally. The code for the PCG algorithm used in Elite can be found here with the name Text Elite.

In recent years, there are several notable examples of PCG in commercial (and non) games: Minecraft, with its fully infinite procedurally generated 3D world full of items and different biomes, Dwarf Fortress, maybe the most impressive use of PCG in an actual game with a full world with history, erosion, events and populations randomly generated, the Borderland and Diablo series, and so on.

I’m definitely leaving out important titles. Please game-god, forgive me.

The present of PCG

Weapons in Borderland are completely made in PCG-land.

Weapons in Borderland are completely made in PCG-land. A nice example of “Instancing Of In-Game Entities”.

In modern games there are several application of PCG (an interesting article on that can be found in [2])

  • Runtime Random Level Generation. This is the generation of game levels while the game is being played, using PCG techniques. In this category fall all the map generation techniques. It is probably the most famous type of PCG techniques in games.
  • Design Of Level Content. This family represent the use of PCG techniques at design or build time. In other world, the goal of PCG is to help the designer into creating contents. This type of PCG application is usually hidden to the final player. A common example of these techniques is the use of fractal height map to create landscapes and terrains which will than populated with other objects by hand.
  • Instancing Of In-Game Entities. These techniques are, in some sense, orthogonal to the previous category. Instead of generating the world, they instantiate the game objects (such as, trees, monsters, characters, item, treasures and so on). In Left for Dead, for instance, this techniques is used to instantiate dynamically the enemies into a static environment in order to provide variety and some adaptation capability to the game.
  • User Mediated Content. This is a borderline technique. In fact, it uses the users themselves as a source of new and “PCG” contents. This can be also be mixed with other PCG techniques (hence the word “mediated” in the name).
  • Dynamic Systems. This is PCG applied to agent behaviors. For instance, dynamic systems such as weather, and group and crowd behaviour, can be modelled using PCG techniques.
  • Procedural Puzzles And Plot Generation. PCG can be also applied to plot, story, quests and puzzle generation. This is a more difficult field because it often requires some Natural Language Processing ability. However, many games are starting to integrate automated quests into their code and gameplay.

The future of PCG

The tgame NERO. You cannot see that... but soldiers ARE EVOLVING WITH NEUROEVOLUTION.

The tgame NERO. You cannot see that… but soldiers ARE EVOLVING WITH NEUROEVOLUTION.

As it is possible to see before, PCG applications are only limited by the human imagination. But if the past look great, the future is totally amazing for PCG. The main evolution in PCG will be represented by the introduction of AI in it with the emerging field of the Experience-Driven Procedural Content Generation [3]. In fact, all the “old” approaches have something in common: the randomness. However, what if the game use the actual player experience in order to create new contents? What if a a random level generator can avoid to create some type of obstacle if it “perceives” that the player get frustrated with them?

All this question are currently open and there are a large number of techniques that can be explored (and are still not explored in any commercial game!). Search-based procedural content generation [1] and the neuroevolution [4] are just a couple of promising techniques and experiment that I found very exciting for the future. Obviously, it is possible that the amount of expertise required by these approaches will be a hard obstacle for their commercial application (as often happens to many AI techniques born in the academia), but, well… they are exciting though!

The Jam

So, what all this boring talk is for? To announce to you the ProcJam 2014, what else! This is an interesting jam (which is held from 8th to 11th November) to experiment with all the techniques I briefly introduced to you and with other I don’t even know! Moreover, on November 8th there will be on Twitch a kickoff day of talks about Procedural Generation! There are a lot of interesting people talking (way more skilled than me on the topic) so I really encourage you to participate the talks (and, if it possible, the jam).

By myself I really think to join the “competition”. I have a lot of ideas (although many are probably too difficult for the jam). Let’s see what I can do. In the worst case I’ll expand my dungeon generator. :P

Have a nice day!