lunes, 17 de octubre de 2016

Gamepolis Indie Zone: A Summary

Hi folks!

It's been too long since the last post, so first things first: sorry about the delay. As you may know, we're working hard to meet several deadlines with our game Breaking Fast, about which I'll write something more technically-oriented soon.

By the end of July we attended Gamepolis. But unlike in the previous years in which we participated as general audience, this year we were presenting our own game: Breaking Fast.

Our stand at Gamepolis. From right to left, Óliver, Manuela and myself

The Indie Zone, which was located close to the entry doors, consisted of a circular area in which 16 indie studios were showcasing their games, most of them, if not all, still in development. As usual, the two main benefits of attending an event like Gamepolis, which is targeted at a broad audience, are obtaining feedback and raising awareness of your game, and getting to know other professionals who have the same dreams and aspirations as us. As for the last point, we're very happy that we could meet the developers of great games like Cubotrox, Hive, Noahmund, Crimson Breath or Charlie Beard, among others. We even went out for a dinner one night after the show!

Pictures with some of the other studios that participated in Gamepolis

The other advantage of participating in this event, that is, exposing your game to a big audience, turned out a fantastic experience. People of all ages (although especially kids and teenagers) would play for a really long time, and they'd come back later bringing more friends to show that 'crazy game with breakfast food'.

People enjoying the Breaking Fast experience. Locomalito and Gryzor also enjoyed it!

We even organized a tournament in which the best three players would win an official Breaking Fast tee. The initiative was really welcome, and hundreds of participants signed up for it. Knowing potential fans of your game is very rewarding, and we took a good deal of pictures with them. Some of them covered Breaking Fast on their Youtube channels, which is something that we, as indie developers, always appreciate a lot.

Some of our more loyal fans. Thanks so much!

Finally, as part of the participation, we were eligible for different awards, and good news are... we won the Public Choice Award! Even when the economic value of the award cannot be dismissed for a low-budget studio, the real value comes in the form of motivation and inspiration to continue improving the game. It's a certainty right now that people enjoy Breaking Fast, and enjoy it a lot. It's just a matter of polishing it well. The other awards went to Noahmund (best sound), Hive (best game as chosen by the jurors), Crimson Breath (best visuals) and Cubotrox (most innovative game).

If you want to read something very cool (and deep) about Gamepolis and about the indie scene in general, check this out (in Spanish, sorry).

See you!

miércoles, 17 de agosto de 2016

Mallorca Game and Gamelab 2016

I want to discuss today our experience during two videogames events that we had by the end of June: Mallorca Game and Gamelab. These two events are very different from each other, with the former being targeted at a broader audience, and the latter oriented towards professional game developers.

Mallorca Game

The fourth edition of this event brought a big deal of attention from gamers and cosplayers.  It was a two-days event where people could buy almost anything you can imagine from the videogames and manga worlds, and where we, the indie game developers, could showcase our game. We had a long table with enough space to set up everything we needed to present our game Breaking Fast. We hung some posters, prepared our monitor and four controllers, and laid some promotional material on the table, such as flyers and business cards.

We didn't expect such a big audience, and again like in Boston and Cartagena, the feedback was really valuable and positive. People from all ages played our game and especially some kids wouldn't let go the controller for a (too) long period of time.

As part of the event, there were three awards to the three best indie games that were presented at the so-called Mallorca Game Awards. In the gala ceremony, which was held during the last day, we were awarded with the second prize to the best indie game.

We were 'snatched' the first prize by Cubotrox, an amazing and innovative puzzle game created by two twin brothers from Valencia that we got to meet, coincidentally, at Gamelab.

As usual in our trips, we took some time off in order to visit Mallorca and enjoy really nice food.


As I mentioned before, whereas Mallorca Game was targeted at a broad audience, Gamelab was very focused on professional game developers. Actually, the number of attendants seemed to be lower than at Mallorca Game, and the quality of the conferences was amazing (e.g. John Romero...).

The feedback that we gained was more polished and concrete, although not so many people played Breaking Fast. David Mariscal, who is collaborating with us, came to help us out.

While in Mallorca we had a long table for us (actually more space than we actually needed), at Gamelab the space was too narrow. Being a multiplayer game, it was kind of annoying when four players wanted to play together, as they'd have to stand too close to each other and still they would take part of the space from the indie games to our right and left.

One of the main benefits of attending an event of recognized prestige like Gamelab (in addition to the feedback) is the possibility of networking with other important indie teams and professionals of different videogames-related areas. And this networking does not boil down to talking during the event, but also after the official time. In particular, a party was organized in a cottage with a big swimming-pool and free beer.

Two guys from Machinima SBOC, with whom we had the chance to talk, wanted to record the event live (but they finally couldn't because there was no Wi-Fi available). Yet they made a couple of videos about their experiencie at Gamepolis and they played our game, Breaking Fast! :D

As I said before, we met Cubotrox makers, and although we didn't know them by that time, we would meet them later at Gamepolis (more on this in the following post). You can take a look at other great indie games presented at Gamelab here.

viernes, 8 de julio de 2016

Game Loops with Fixed Simulation Steps


Today I want to talk about game loops. If you're a game developer, you surely know what a game loop is. However, let me summarize it with the following image:

Figure 1. Traditional Game Loop (from

A game loop is basically a sequence of instructions that is repeated continously from the beginning to the end of the game and which is in charge of interpreting input, simulating the world and rendering the world on screen. Very often, there is a 1:1 mapping between the concept of frame, and one execution of the loop, because a frame of the game is rendered each execution of the loop. However, this doesn't need to be the case and you can have different frame rates for the rendering function and for the simulation function. In fact, a common approach in sophisticated, simulation-intensive games is to fix the timestep of the simulation function in order to achieve predictable and deterministic behaviour of the simulation. Meanwhile, the render function is executed as fast as it can run, leading to a higher, variable display rate. You can read more about this decoupling in the following eye-opener posts:

I actually encourage you to read the previous posts (especially the first one) before continuing reading. Otherwise, this post may be difficult to follow.

I had the idea of writing this article because I tried to use the technique suggested in [1] with no success. After failing, I skimmed through the comments of the post and I found two comments (by Nick and Voy) which basically stated that although the technique was really valuable, the implementation suffered an off by one error, which resulted in no simulation step taken at all. This was in fact the problem I was having (entities of the game weren't moving), and therefore I set out to fix it for educational purposes.

Before showing the actual code, let me illustrate with figures how we want the simulation to happen:

 Figure 2
 Figure 3
Figure 4

Figure 2 shows that we divide the time of the game in discrete chunks of the same size. Don't let the concrete numbers fool you: you'll typically want the simulation to take small steps (say 0.01 seconds) in order to reduce numerical errors. The point is that there are concrete, fixed moments over the life of the game at which we want to simulate the world, and we DON'T want to simulate at any other moments between those.

For instance, let's assume that the time is somewhere between the beginning of the game (0) and the first moment at which we want to simulate (1). This corresponds to what Figure 3 shows. The green arrows show different game times at which we can be, whereas the red arrow shows the point that we actually want to simulate for these times. Notice that while we're between point 0 and 1, we simulate at time 1. Similarly, as illustrated in Figure 4, while we are between moments 1 and 2, we want the simulation of time 2. And so on.

At this point, you might be thinking that this is somewhat incorrect, right? Because this wouldn't produce a smooth movement, as we're treating many different times the same way. That is, the position (and velocities) of objects shouldn't be the same for every time value between 0 and 1. If we're on time 0.2 and then the game advances to time 0.5, you want the objects of the game to move a little bit. However, with what I've just told you up to now, objects wouldn't move until the time of the game advances past 1, at which point we would make another simulation.

This is when interpolation comes into play. The key of the approach is the following: we simulate the future and we interpolate proportionally to the distance to this future. Therefore, if we're on time 0.2, we're further away from the future than if we're on time 0.8. The closer to the future, the closer to the simulation. We can achieve this with a linear interpolation in which an alpha value determines how close we're to the future:

position = position * (1 - alpha) + futurePosition * alpha,    0 <= alpha <= 1

Without further ado, here's the C++/SFML code for the simulation:

 //Initialization (out of the loop)
 const auto dt = sf::seconds(0.01f);
 auto accumulator = sf::Time::Zero;
 auto lastTimeUpdated = 1;
 MotionSystem::SimulateFuture(dt.asSeconds(), futurePos, futureVel);

 //In game loop
 accumulator += elapsedTime;  
 double timesDt;  
 const auto fractionToNextFrame = modf(accumulator / dt, &timesDt);  
 if ((timesDt + 1) > lastTimeUpdated)  
    for (uint16_t i = lastTimeUpdated; i < timesDt + 1; ++i)  
       MotionSystem::SimulateFuture(dt.asSeconds(), futurePos, futureVel);  
    lastTimeUpdated = timesDt + 1;  
 MotionSystem::Interpolate(fractionToNextFrame, futurePos, futureVel);  

The accumulator variable holds the time that has passed since the game started. Then, by using the C++ function modf, we can extract how many times dt has passed and how close we are to the next frame.

Note that before entering the loop, we have made the first simulation, the one corresponding to the first point in time at which we want to simulate. That is, we have simulated the first point in the future and lastTimeUpdated is assigned this information.

Let's lay out an example: consider that the first time the loop executes, accumulator = 0.004. Being dt = 0.01, we're almost halfway between the present and the simulated future. Given that accumulator / dt = 0.4, after the execution of modf, the variable timesDt = 0, and fractionToNextFrame = 0.4. The if condition is not met, and therefore no simulation is performed. We interpolate the current position with the future position according to fractionToNextFrame when we call MotionSystem::Interpolate. Internally, this function does something like the following:

position = position * 0.6 + futurePosition * 0.4

Let's assume that in the following execution of the loop, accumulator = 0.018. Now, timesDt =  1 and fractionToNextFrame = 0.8. The if condition is now met (2 > 1) and in the for loop, we make one simulation of the future, reaching the second simulation point, and updating lastTimeUpdated = 2. Finally, we interpolate as follows:

position = position * 0.2 + futurePosition * 0.8

In case there's a frame drop or the rendering function (which would be executed after this simulation) takes too long, the simulation can catch up in a controlled way because it will be executed all the times it is required in a fixed timestep. You can work out the numbers yourself considering a sudden accumulator = 0.12.

Hope you liked this post. If you notice that something is missing or that I made any mistake, let me know so that I can fix it.

See you!