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: http://xkcd.com/974/

A perfect represenation of overgeneralization: http://xkcd.com/974/

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:

JUST DO IT

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!

References

Back from AIIDE 2014

Everything looks better in long-exposure.

Hi everyone! Sorry for the long absence but my days are really full of commitments and terrible news. It is still not over, but but I really need write about something before is too late. :)

During the last 3th-7th October, the tenth conference on Artificial Intelligence for Interactive Digital Entertainment (AIIDE) was held in Raleigh (North Carolina, USA). It was a very interesting conference on AI and games stuff and I am really happy to have joined such amazing things. I mean, this is something that I could proudly say to the 10 years old me and make him happy and unbelieving. I could look the younger me in the eyes and say “In the future you’ll participate in a conference about artificial intelligence and videogames with some of the most beautiful mind in that field!”. Wow. However, unfortunately I received too many commitments and bad news from Italy to be able to freely enjoy this conference and to be fully concentrated. I’m really sorry of this.

In any case, in that conference I was presenting my works on Belief-Driven Pathfinding (an extended version of the arguments I was presenting in the ECAI conference). I am pleased that I found many people interested in this work and that share my belief that this is an open and interesting problem to solve in AI for games. It was very hard to push this idea and work into some academic conference and I’m really really happy that I finally succeeded after a lot of failures! I also collected a lot of idea for some later works on the same subject so, thank you all for everything.

I also found very interesting the keynote by Squirrel Eiserloh on how to make the academic research on games more appealing to the gaming industry. It was very inspirational and I’d like to follow some of his advice writing a “simplified version” of my paper for developers and non academic people (I’ll publish it here and on Gamasutra if I can). :)

An there is more! You can find the full proceedings for this conference HERE. If you are interested in artificial intelligence and videogames the AIIDE proceedings are a wonderful place where you can find a lot of inspiring ideas! So, take a look!

Have a nice day!

PS: Just 20 days at the ProcJam 2014!!

Original photo by UsaPics

Speccy Jam 2014 Postmortem

BlackSmith SpeccyJam

As I said in a previous post, in these days me and my colleague at Noctua were working in the SpeccyJam 2014. The goal of the jam/competition is to make a game with the same look and feel of an original ZX Spectrum game. This introduces a lot of interesting limitations. First, it constrains our resolution to  256 × 192 (that is, however, a really big improvement respect to the LowRezJam :D), second it forces us to use only 15 colors. But most important of all, the non-strict limitation, is to simulate the color clash effect of the original Spectrum on modern engines. This was the most hard constraint that forced us to explore 2D shaders and a lot of simulated low-level algorithms on top of a modern engine like Unity 3D.

So, now that the jam is ended, is time, as usual, to back over our steps to see what we have done, what we have learned and what we can improve.

First Step: The Concept

The traditional HD disappointing game cover!

The traditional HD disappointing game cover!

The first step for each jam is to think of a concept for the game. We decided to use a game concept that was in the air for a long time but that we never found time to implement. The idea is an economy management game inspired by the daily life of a blacksmith. The original idea was a bit complex, but we thought we could easily strip a lot of feature in order to fit the game into a jam-size project.

The player is a blacksmith in a fantasy world. At the beginning of the game he has nothing but a forge and a bunch of money. The first step is to hire some goblin minions (characterized by two parameters, combat skill and geology skill) and send them in some remote land to mine metals and resources. When the goblins come back with the resources the blacksmith can start forging weapons through a mini-game based on rhythm and coordination.  When the weapon is successfully forged, its time to sell it in order to get gold and fame. Obviously it is important to hire minions wisely to avoid starvation and to go out of business.

Simple but effective. It is time to start working.

Second Step: The Low Level Framework

For our work we chose to use Unity 3D. Also if we have switched to the Unreal Engine 4, the 2D framework for UE4 is still rough and we preferred to use something on which we are more experienced. It is not cool to find out some engine problem in the middle of a jam, so it is better to be safe.

An example of color clash in action. Note the knight sprite assuming the color of the background objects.

An example of color clash in action. Note the knight sprite assuming the color of the background objects.

Before to start implementing the a actual game, we needed to implement a good low-level framework for ZX Spectrum graphic emulation and, in particular, an effective and simple way to emulate the color clash behavior. Let’s explain better what it is. You have to know that the ZX Spectrum, by design, stored pixel bitmap and color information in separate areas of memory. While the bitmap specified the state of individual pixels (either on or off), the color information (or “attributes”) are specified in a 24×32 matrix. This means that there are just one byte per 8×8 pixel character cell. Because each byte can specify two colors (namely INK for the foreground and PAPER for the background, plus two bits for modifiers such as BRIGHT and FLASH), each 8×8 “tile” of the Spectrum screen can have only two colors at the same time. When a sprite with a third color enter in a 8×8 tile with two other different colors, the whole tile get the color of the entering sprite according some nor-really-deterministic behavior.

Now, to simulate this in Unity is really not straightforward. My friend Maurilio did an amazing job into handling this problem. Obviously him can explain this better, but I’ll try to express the key points behind this simulation. The main tools used are sprites and shaders. The idea is to directly simulate the Spectrum graphic system separating the bitmap memory from the color memory (exactly like in the original spectrum). So, we built a fake “video memory” using two textures that store the 24×32 color information matrix for INK and PAPER and used the Unity sprite only for the bitmap.

Hammer Speccy Blacksmith Example

As you can see in the picture above, each sprite is composed only by two colors (plus the alpha channel). The red parts of the image are the INK pixels, the green one are the PAPER pixels. Combining this to a complex system that can write color information in the fake video memory and a 2d shader to render these sprites, we was able to recreate a really amazing and realistic clashing effect (also too real, for instance there are some glitches when switching from one scene to another because of the fake video memory not being updated fast enough :D).

The shader work in this way: it get two textures, one for the INK color memory and one for the PAPERS color memory and then replaces red/green from the sprite with the INK/PAPER value in the position of that particular fragment in screen coordinate (the INK/PAPERS textures, in fact, map each pixel to a particular screen pixel).

This system is a bit complex and fascinating and really need a more in deep details explanation from its main author, so I ask him to write something and I’ll share that here as soon as possible. :)

Step Three: The Game Logic

Now it is time to start writing the real game logic. To improve our ability to parallelize the effort, we worked in the following way: while Maurilio worked on the low-level stuff, I wrote the full game logic in a low-level-independent. Then, we had merged all together in the last days. I don’t know if I can recommend this workflow, usually is better to work more close and less in a “MCV” way, however it worked well enough.

The whole game logic is fully accessible from a  BlackSmithGame class. This class is not a MonoBehavior and it contains the method and the data needed by the game interface in order to access the game mechanics and allow the player to play. Then there are some “object” classes that are used to store information about several game entity: these classes are Metal, Weapon, Location and Minion. The first three classes store also the “data-driven” part of the game. Because metals, weapons and locations are fixed at design time, they also include the only instances available (in fact their constructor is private). As an example, look at the metal code

As you can see the class only stores its data (namely Name, Description and Level). At the end of the class there is a static dictionary that I use to store the only existing instances. So, in every class, when I need a metal, I can directly access this dictionary to get the needed instances. The same is for Weapons and Location.

Minions, instead, are a bit different. In fact, we need to create random minions at runtime. So, we have a standard constructor plus a static function that is used to generate a random minion according some input parameters (for instance, we usually create minions whose skill is proportional to the blacksmith’s fame level).

Step four: The minigames

The forge minigame.

The forge minigame.

After the main game logic, we need to implement the forging minigame. As I said before, the forge minigame is a slightly modified rhythm game. The player has to warm up the forge pressing by quickly pressing a key with the left hand and match the signed spot (the yellow square in the image) with Return and the right hand. The game is then divided in two sub-games: the press-the-key-as-quick-as-possible game and a press-at-the-right-time game.

The code for the first one is very simple:

The game is just an exponential decay equation plus a key to increase the value. More the value grows, more it decrease quickly in the decay step. The final result is a “game” where it is progressively more difficult to keep an high value for a long time. This is perfect to simulate the blacksmith that has to keep an high temperature to forge the weapon.

The second code is more complex from the code point of view, mostly because it is really bonded with the GUI. However the key idea is very simple: keep a counter and, when the player press the Return button, check if the counter is on a valid spot. No more, no less.

Step Five: Put all together

The last day of the jam me an Maurilio met together in order to assemble all the part of the project. I was very glad that the integration phase was very easy. No problem emerged during this phase. THis is amazing because, you know, it is always difficult to produce two part of a software in a separate way without performing some integration test in between. :)

However there are still a lot of balancing problems. In fact we had no time to balance the game (respect to weapon sell value or minion salaries). Unfortunately we ended a bit late.

Step Six: Take away

At the end we completed the game and published it on the SpeccyJam forum (the game should be soon available in the main page). At the end there are several lessons I learned during this jam. Here there are a summary:

  • First, we always get better, faster and nicer. More we get faster, more we try more complex projects. More the project get more complex, more I have fun developing the game logic. This is really a nice motivation to continue.
  • This is a jam we performed without an “artist” for a long time.  This is nice in some sense because we are having problem dealing with our “graphic department” so I feel better knowing that we can still do something relying only on the two of us.
  • We learned a lot about shader in 2D game. And we learned again how bad can Unity be.
  • There are also some negative stuff. The next time I really like to end the project first in order to concentrate more on the final polishing of the project. This includes: balancing the gameplay, refine graphic and UI, write a tutorial or something to make easier for the new player to play the game. These are really thing that can make a difference between an average product and a great product.
  • I really need had to improve my artistic skills.

At the end, we have another jam on the shoulder and we get more experienced. That’s why I love joining jam. Have a nice day!