Breaking Fast: From Ad-Hoc to Scalable Local Multiplayer System

Hi!

This week we have been working on the local multiplayer of Breaking Fast. The first version of Breaking Fast, which was playtested several months ago, had an ad-hoc art design for only two players, and therefore neither the art nor the code were scalable for moving easily from 1 to 4 players. Therefore, the main work carried out during this week has consisted of refactoring the code so that it accepts a unique set of assets, and that it scales this set according to the number of players. Also, different viewports are created according to the number of players, as shown later.

As every programmer that is reading this post can figure, even for a medium-sized codebase the aformentioned task entails lots of work, but going step by step is the only way to go. In the following sections, I briefly explain the most important code changes that were performed:

1) Substituting scalar values by arrays of values: in the first version of the post, we had something like:

 local Camera = require "Camera"  
 local camera1 = Camera()  
 local camera2 = Camera()  
 local Player = require "Player"  
 local player1 = Player.new(...)   
 local player2 = Player.new(...)   

Of course, if we want to achieve scalability, this is not the way to go. Therefore, we changed the aforementioned scalar variables into arrays, as follows:

 local Camera = require "Camera"  
 for i = 1, numPlayers do  
   cameras[i] = Camera()  
 end  
 local Player = require "Player"  
 for i = 1, numPlayers do  
   players[i] = Player.new(...)  
 end  

This applies of course to every element that needs to be replicated according to the number of players.

2) Re-designing assets for one player scenario: in the single player mode, there are no viewports (there are no any other player), and therefore the assets need to be as large as they can be. Under any other circumstances (more than one player), the assets need to be scaled down proportionally according to the resolution and aspect ratio for which the game is being developed, 1920x1080 and 16:9, respectively.

In the first prototype of the game, the assets were designed ad-hoc for two players. For example, the background was designed with a resolution of 1920 x 540, and I would place two different backgrounds in different positions:

 background1 = love.graphics.newImage("background.png")  
 love.graphics.draw(background1, 0, 0)  
 background2 = love.graphics.newImage("background.png")  
 love.graphics.draw(background2, 0, 540)  

(This is an oversimplification for several reasons; first, we actually add the background to a layer of a camera, because we want it to scroll a little bit. Read this series of posts to get more information on parallax scrolling. Also, what we actually draw is not the background itself, but a batch of backgrounds that we paste once after another in order minimize draw calls and provide an illusion of infinite scenario).

After the changes, we have only one background with a resolution of 1920 x 1080*, and therefore we don't need to place background for different players in different positions; the viewports will take care of this according to the number of players.

*(Again, although this would be technically possible, we use a larger resolution to support scrolling in the vertical axis and for fixing some problems with different aspect ratios, as discussed later).

3) Designing viewports: if we want that more than one player can play on the same machine, we need to provide each player with a fragment of the screen. Each fragment is called a viewport. In the first prototype, we didn't need to worry about viewports, because everything was drawn ad-hoc for two players. However, now we have a unique set of assets, and depending on the number of players, these assets must be replicated for the different players and must be scaled down appropriately.

For example, for two players, we want that the first player is allocated the upper half of the screen, whereas the second player should be provided with the lower half. In the case of four players, each player should have a quarter of the screen.

In order to implement viewports in Löve, I saw two alternatives: using scissors or canvases. I didn't get to really grasp how to use scissors for this purpose in my first attempts (see video below), so I switched my attention quickly to the second option, which turned out to work great.

Fail with using scissor. The second player viewport was rendered onto the first player one.

Canvases represent an off-screen rendering target. Internally, it creates an OpenGL framebuffer object to which the contents are drawn, instead of drawing the contents to the screen. The process from a high-level perspective is as follows:

1. Create as many canvases as the number of players (one canvas per camera).
2. Depending on the number of players, scale the assets that will be drawn to the canvases.
3. Place each canvas in its correct position according to the number of players.
4. Draw all the stuff that we used to draw on the screen on the canvases instead, and then, draw the the canvases.

Some simplified code for the three players case is shown next:

 if numPlayers == 3 then   
   cameras[1]:setScale(2, 2)  
   cameras[1]:createCanvas(0.5 * intendedWidth, 0.5 * intentedHeight, 0, 0)  
   cameras[2]:setScale(2, 2)  
   cameras[2]:createCanvas(0.5 * intendedWidth, 0.5 * intentedHeight, 0.5 * intendedWidth, 0)  
   cameras[3]:setScale(2, 2)  
   cameras[3]:createCanvas(0.5 * intendedWidth, 0.5 * intentedHeight, 0.25 * intendedWidth, 0.5 * intentedHeight)  
 ...  

The createCanvas() function, which is added to my camera module, takes the width and height of the canvas, and its top left position. This would yield the following layout for the screen:

As part of this viewport design, we also needed to change the camera code for drawing. However, modifying this code to support drawing on canvases was surprisingly easy.

camera.lua

 function camera:draw()  
  love.graphics.setCanvas(self.canvas)  
  love.graphics.clear()  
  local bx, by = self.x, self.y  
  for _, v in ipairs(self.layers) do  
   self.x = bx * v.scale  
   self.y = by * v.scale  
   self:set()  
   v.draw()  
   self:unset()  
  end  
  self.x, self.y = bx, by  
  love.graphics.setCanvas()  
  love.graphics.draw(self.canvas, self.canvasLeft, self.canvasTop)  
 end  

The lines in bold text are the only additions we needed to add in order to make the function work with canvases.

You can watch the result of our work in the following video. Challenge 1: By the way, do you recognize the musical masterpiece that goes with the video? :P

4) Managing aspect ratios: ensuring that Breaking Fast can be played on most aspect ratios is vital, but it is also tricky. The solution requires twofold work from the artistic and code perspectives.

First, let's see what happens when we execute the code for two players for a 16:9 aspect ratio (the aspect ratio for which the game is being developed):

Now, consider the same code but for a resolution of 1280 x 800, which is a 16:10 aspect ratio and very common for a Macbook Pro, for example:

As you can see, the assets within the canvases are not properly scaled. Well, actually, they are properly adjusted to the width (note that the countdown on the top right corner is properly placed), but not to the height, because some part of the scenario is lost, like the legs of the characteres.

In order to solve this, the trick is to scale all the assets down to adjust them to the height of the screen, and given that the assets (e.g. the background) are bigger than the screen, the player will have the impression that the adjustement has been perfectly done in both dimensions, as shown next:

There is only one inconvenience. As we are losing the perfect adjustment to the width, the HUD elements like the energy bar or the countdown are not perfectly in the middle or at the end of the screen, respectively, but they have a small offset to the left.

Assuming that we have a perfect adjustment to the width, the middle of the screen is calculated as:

screenMiddleX = 0.5 * intendedWidth

, where intendedWidth is the width of the design resolution (1920). If we want to correct the position, we need to multiply this value by the following proportion:

screenMiddleX = 0.5 * intendedWidth * (scaleForAdjustToHeight / scaleForAdjustToWidth)

The result would be as follows:

Note that now the HUD elements are now properly placed.  The result for many different aspect ratios is shown in the next video. Challenge 2: again, do you recognize the composition that accompanies the video?

And that's all for now. We'll keep you  posted on the advances of Breaking Fast, so stay tuned!

See you!
FM

Parallax Scrolling in Love2d. Part 3: Different Camera Spaces

Hi!

This is the last installment of the series on parallax scrolling in Love2d. In the previous posts, we first discussed how we could implement this technique by defining a camera component and the concept of layers, and how we could reason about the two different coordinate systems that we had: the world and the camera coordinate systems. Consider reading these previous posts before going on, because this installment builds upon them.

We will see now how we can represent an object that is in a given camera space in another camera space, which can be useful for multiplayer games. The problem statement is depicted in Figure 1. We see that we have two cameras, each one representing a fragment of the same world. One of the cameras (camera 1) is in the position (x1, y1), whereas camera 2 is in (x2, y2). Again, for the sake of simplicity, we will focus on the X dimension, but the same reasoning applies to the Y dimension. Each camera follows a different player, namely player 1 and player 2, which have their positions in their camera spaces posPlayer1_cam1 and posPlayer2_cam2, respectively. Now, assume that we want to represent a ghost version of  player 2 in the camera space of player 1, so that player 1 can see the position of player 2. Which is the position of player 2 in the reference system of camera 1, that is, which is the value of posPlayer2_cam1?

 Figure 1. Problem statement

At first sight, the problem seems trivial, and for most cases, it actually is. We simply need to represent the (world) position of player 2 in relation to the camera. Therefore, if the position of player 2 is posPlayer2, and as usual we assume that players belong to layers with scale = 1, we know that:

posPlayer2_cam1 = posPlayer2 - posCamera1 (1) 

Likewise, the position where the player will be drawn would be:

posPlayer2_draw = posCamera1 + posPlayer2 - posCamera1 = posPlayer2 (2)

And that's it. This is what works in most of the cases.

However, there is a situation that we need to consider. Assume that there are obstacles with which the players can collide. If these obstacles belong to a layer with scale = 1, then everything works as we've just described. However, if obstacles belong to layers with a different scale, weird things happen. Suppose that obstacles belong to a layer with scale = 2. Then, as we saw in the previous post, advancing the camera u units result in the object being moved 2u units to the left. Therefore, if we used simply (1) or (2), player 1 would have the impression that player 2 collides (stops) before reaching the obstacle, as depicted in Figure 2. 

 Figure 2. Player 2 reaches the obstacle before it is perceived by player 1

This is happening because whereas the obstacles are moving with a rate of 2u units to the left, player 2 is being moved in camera 1 at a rate of 1u unit to the right. Therefore, player 2 reaches the obstacle in camera 2 before it reaches it in camera 1. The solution is moving player 2 in camera 1 at the same rate as the obstacles move but in opposite direction, that is, 2u units to the right. 

If obstacles belong to layers with scale = n, 0<n<1, then player 2 would reach the obstacle in camera 1 before it reaches it in camera 2, and player 1 would therefore perceive as if player 2 had run through the obstacle, as depicted in Figure 3.

Figure 3. Player 1 perceives that player 2 run through the obstacle

Therefore, the solution consists of correcting this displacement: player 2 has to move in camera 1 at the same rate than obstacles. If camera 1 remains still and camera 2 advance u units, player 2 has to be moved 2u units to the right in camera 1. If camera 2 remains still and camera 1 advance u units, player 2 has to be moved 2u units to the left in camera 1. So the general pattern is: for every unit u of difference between the positions of camera 2 and camera 1, the position of player 2 has to advance 2u units. 

posPlayer2_cam1 = posPlayer2_cam2 + 2*(x2 - x1) = posPlayer2 - x2 + 2*(x2 - x1)  (3)

posPlayer2_draw = x1 + posPlayer2_cam1 = x1 + posPlayer2 - x2 + 2*(x2-x1) (4)

We can simplify (3) and (4) as follows:

posPlayer2_cam1 = posPlayer2 + x2 - 2 * x1

posPlayer2_draw = posPlayer2 + x2 - x1

Finally, we can generalize the formulas for a player in a layer with scale = n, and obstacles in a layer with scale = m:

posPlayer2_cam1 = posPlayer2 + (m - n)*x2 - m*x1

posPlayer2_draw = posPlayer2 + (m - n)*x2 + (1 - m)*x1

And this is all! Hope you enjoyed this series of posts as much as I enjoyed writing it. As I mentioned in the first post, these are the considerations that I took into account while developing the parallax scrolling system for our game to come, Breaking Fast, the result of which you can watch in the following video:

See you!

Parallax Scrolling in Love2d. Part 2: Testing Collisions in different Layers

Hi all!

This is the second installment of the series on parallax scrolling for Love2d. In the previous post, we discussed how we could implement parallax scrolling in Love2d, by defining a camera component that was in charge of managing the different layers. In this post, we are going to provide further insight on this implementation and we are going to discuss how we can detect collisions happening between objects that belong to different layers. The gist here is noticing that we have two different, interrelated coordinate systems, and that in order to detect collisions, we must compare the positions of the objects in the same reference frame. 

Let's start by defining the two coordinate systems that we have, namely the camera coordinate system, and the world coordinate system. An object will have different values of its position in each system, although it is possible to move from one system to the other by simple mathematical operations. Let's assume that we follow up the example of the last post, in which we wanted the camera to track the player in the center of the screen. Figure 1 shows a diagram that relates the world coordinates with the camera coordinates of the player. We will focus only on the X dimension, but the same reasoning would apply to the Y dimension. Note that we define a world of 10000 x 10000 pixels, where the origin of such world is at the top left corner of the screen. The camera has a dimension of 1920 x 1080 pixels, which corresponds with the standard resolution of most screens today. Every object contained in the camera (the red rectangle) will be visible. As you can see, assuming that the position of the camera in the world is (x, y), the player will have different coordinates in camera space (960) and in world space (x + 960).

Figure 1. The player position in camera and world spaces 

In our example, we assume that the camera is updated as a consequence of the movement of the player (which is logical if we want the camera to track the player). Therefore, this is what happens in each frame:

1. The player presses the right key, which increases the world position of the player by a rate depending on the speed we want the character to have. 
2. As a consequence of the update on the character position, we have to update the world position of the camera, which is advanced the same units as the player has moved. That is, if the player has moved 50 units, the camera will move 50 units. The fact that the camera moves at the same rate as the player is due to the fact that the player belongs to a layer with scale = 1, as we will analyse further in the following.

Given that we update the camera when we update the player, we can consider that the world position* of the camera is a function of the world position of the player, and this function is as follows:

posCamera = posPlayer - 960 (1)

* From now on, we will simply say position when we refer to world position.

In general, if we have an object that belongs to a layer with a scale = n, the relationship between the position of the object in world and camera space is given by:

posObject_cam = posObject - posCamera * n (2)

In particular, think of the player, who belongs to a layer of scale = 1. From (1), we have that:

  

posPlayer = posCamera + 960

Substituting this in (2), we have:

posPlayer_cam = posCamera + 960 - posCamera * 1 = 960

As we can see, the position of the player in camera space does not depend on the position of the camera, because it is always the same: the center of the screen. Any other object that belongs to a layer with scale = 1 will meet (from (2)):

posObject_cam = posObject - posCamera (2a)

This means that the position in camera space of the object will change at the same rate that the camera moves. Consider for example a stationary object at position 50. If the camera initially is at position 0, then the object position in camera space will be 50. Now if the camera moves 10 units to the right, the position of the object in camera space would be 50 - 10 = 40. Moving the camera forward u units is equivalent to moving the object backward u units. In the case of the player, it is not a stationary object, but it moves at the same rate as the camera moves, and in particular, the position of the player in camera space is 960 because the difference between the position of the player and the position of the camera is always 960.

Consider now the case of stationary objects that belong to a layer with scale = 0. Then, we would have:

posObject_cam = posObject - posCamera * 0 = posObject (3)

This means that positions of objects that belong to these layers are not affected by changes in the position of the camera: their positions in camera space correspond always to their positions in world space. Or said another way: if a stationary object has the position 10 in camera space, it will keep that same position forever, being the net effect that the object moves at the same rate and same direction as the camera. 

Think now of stationary objects that belong to a layer with scale = 2. Then, we have:

posObject_cam = posObject - posCamera * 2 (4)

Let us suppose that the camera moves 10 units to the right. This means that the object in camera space moves -20 units (or 20 units to the left). In general, moving u units the camera to the right is equivalent to moving the object 2u units to the left.

Once we know how the position of any object in camera space is calculated, let's see something different. Now, we are going to calculate where the objects are actually drawn on the screen. The diagram in Figure 2 helps explaining this:

Figure 2. Object positions in different spaces

Let posObject_draw be the position where an object is drawn on the screen. Clearly, from the diagram above, we have the following:

posObject_draw = posCamera + posObject_cam 

, where posCamera in the X dimension is x.

And if we substitute posObject_cam from (2), we get:

posObject_draw = posCamera + posObject - posCamera * n (5)

, where n is the scale to which the object belongs.

Let us instantiate (5) for the player:

posPlayer_draw = posCamera + posPlayer - posCamera * 1 = posPlayer

This means that the player is drawn exactly in its world coordinates. If the player advances u units to the right, the player will be drawn these same u units to the right. In the case of stationary objects, this means that they will be drawn always in the same position. Therefore, if the camera advances u units to the right, in order for the object to be in the same position, the object will be drawn u units to the left. Note that this is consistent with the analysis performed on (2a).

If we instantiate (5) for a stationary object that belongs to a layer with scale = 0, then we have:

posObject_draw = posCamera + posObject - posCamera * 0 = posCamera + posObject

This means that the position where this object is drawn moves at the same rate as the camera and in the same direction. The net effect is that the position of the object is not affected by the position of the camera and the object seems to be still. This is consistent with what (3) expressed.

If we now instantiate an object that belongs to a layer with scale = 2, we would have:

posObject_draw = posCamera + posObject - posCamera * 2 = posObject - posCamera

This is expressing that moving u units the camera to the right causes the object to be moved u units to the left, being the net effect that the object is moved 2u units to the left, as the analysis in (4) concluded.

Once we understand how everything works, it is time to detect collisions among objects in different layers. The key idea here is that we must compare positions of the same type. Let us suppose that we want to check whether two objects A and B, belonging to layers with scales n and m, respectively, are colliding. We have two options:

1. Compare positions in camera space.
2. Compare positions where the objects are actually drawn.

In option 1, the steps would be as follows:

posA_cam = posA - posCamera * n
posB_cam = posB - posCamera * m
if (colliding(posA_cam, posB_cam)) then ...

In option 2, we would perform the following steps:

posA_draw = posA + posCamera * (1 - n)
posB_draw = posB + posCamera * (1 - m)
if (colliding(posA_draw, posB_draw)) then ...

Note that given that world coordinates of the objects do not account for the displacement that occurs each frame because of the parallax effect, we cannot use these world coordinates directly for the collision detection. For example, consider two stationary objects A and B that are initially placed in the same (world) position: 500, but A belongs to a layer with scale = 1 whereas B belongs to a layer with scale = 2. If we used the world positions to detect collisions between these objects and any other object C that moves toward them, we would detect that C collides with them at the same time, but this is a mistake. Actually, C will reach B in half the time that it will reach A, because B moves twice as faster than A in relation to the camera. In summary: we are using the world position only as an intermediate value to compute the actual position where the objects are drawn (or their position in camera space).

And this is all for now. In the last installment of the series, we will discuss how we can represent the same object in different camera spaces. This is useful for multiplayer games, where each player has a different view of the world.

Hope you found this interesting and see you soon!

Parallax Scrolling in Love2d. Part 1: Data Structures and Programming

Hi all!

This is the first post of a series in which I'll explain how we can implement parallax scrolling in Love2d. The code that I'll share is similar to the one I'm using for Breaking Fast, our next game to come.

The implementation builds on the tutorial that you can find here. Actually, I advise you to take a look at this tutorial first, because it covers the fundamental principles behind the implementation. Then, we will perform some extensions, so come back here. 

The implementation starts with the idea of creating a data structure that represents the camera. So now, we will focus on a camera.lua file that implements the camera data and functionalities.

camera.lua

 local camera = {}  
 camera.__index = camera  
 return camera  

What data must a camera have? Well, the first and most important one is the (x,y) coordinates that represent its position. It could also hold data regarding scaling in both directions, and its orientation. If we want the camera to support parallax (and we certainly do), it must also contain a list of layers, where each layer will contain its own objects to be drawn. With this in mind, we can create the camera constructor, as follows:

camera.lua

 local function construct()  
  local self = setmetatable({x = 0, y = 0, scaleX = 1, scaleY = 1, rotation = 0, layers={}}, camera)  
  return self  
 end  
   
 setmetatable(camera, {__call = construct})  

As you can see, we are creating a camera with an empty list of layers. Also, with the setmetatable function, we are instructing that if, from some client code, we use the table camera as a function, the method to which __call points is to be invoked. This means that if we want to create two different cameras from client code, we only need to do the following:

some client code.lua

 local Camera = require "camera"  
 myCamera1 = Camera()  
 myCamera2 = Camera()  

Love2d uses three functions to transform the current coordinate system:

love.graphics.rotate( rotation )
love.graphics.scale( x_scale, y_scale )
love.graphics.translate ( dx, dy )

Let's focus on the last one. According to the documentation: When this function is called with two numbers, dx, and dy, all the following drawing operations take effect as if their x and y coordinates were x+dx and y+dy.

So, assume we have a square in the coordinate (1, 0), as shown on the left part of Figure 1. After performing love.graphics.translate( -1, 0 ), we would have the square in the coordinate (1 + (-1), 0 + 0) = (0, 0), because even when we are actually moving the coordinate system, this is equivalent to moving the square in the opposite direction, as depicted on the right side of Figure 1.

 Figure 1

This is the fundamental mechanism that we can use in order to implement traditional scrolling, where the dx and dy values correspond to the position of the camera with negative sign. The same applies for the scaling and the rotation. We can encapsulate all this in two functions as follows:

camera.lua

 function camera:set()  
  love.graphics.push()  
  love.graphics.rotate(-self.rotation)  
  love.graphics.scale(1 / self.scaleX, 1 / self.scaleY)  
  love.graphics.translate(-self.x, -self.y)  
 end  
   
 function camera:unset()  
  love.graphics.pop()  
 end  

The push() function saves the current transformation on top of a stack, whereas pop() sets the current transformation to the one on top of the stack. The strategy to draw is therefore something similar to this:

camera.lua

 function camera:draw()  
   self:set()
   -- draw stuff  
   self:unset()  
 end  

Obviously, prior to calling self:set(), we could modify properties of the camera, in such a way that each draw call behaves different in terms of scaling, rotation or movement/position.

Let's focus now on the parallax effect. For such effect, we have to turn our attention to the layers. What data must a layer have? First, the layer must be able to draw itself, so it must have a reference to a function that will draw the objects in such a layer. Given that we want that each layer can move at different rates (in order to achieve the parallax effect), each layer must hold a rate or scale value. Finally, it would be interesting that we could decide a relative order among layers, in such a way that we can specify the order in which different layers are drawn. The function that builds a new layer is shown next:

camera.lua

 function camera:newLayer(order, scale, func)  
  local newLayer = {draw = func, scale = scale, order = order}  
  table.insert(self.layers, newLayer)  
  table.sort(self.layers, function(a,b) return a.order < b.order end)  
  return newLayer  
 end  

Note that after inserting the new layer into the table of layers, we order them according to the order value. Now, we can complete the draw function as follows:

camera.lua 

 function camera:draw()  
  local bx, by = self.x, self.y  
  for _, v in ipairs(self.layers) do  
   self.x = bx * v.scale  
   self.y = by * v.scale  
   self:set()  
   v.draw()  
   self:unset()  
  end  
  self.x, self.y = bx, by  
 end  

The draw function iterates over all the layers defined for the camera, it then applies a layer scale to the current position of the camera, which makes each layer to be drawn in a possibly different position, depending on the value of this scale. Finally, the draw function of the layer is called. In order to preserve the original position of the camera, we use the temporary variables bx and by.

Note that given that we are using the product of the layer scale and the current position, stationary objects in layers with scale = 0 will have no movement. Therefore, any static background of the game will belong to a layer with such a scale. A layer with scale = 1 will contain objects that move at the same rate as the camera (but in the opposite direction). If we want to track a character controlled by the player, a good strategy is including it in a layer with scale = 1 and moving it at the same rate as the camera, as we will see later. Anything that moves at a faster or slower rates than the camera will belong to layers with scales greater or lower than 1, respectively. The following post in the series will provide further insight on these statements, but for now, let's see now how some client code can use all of this. Let's assume that we have four layers, that we want to draw in the following order:

1. Static background layer.
2. Background layer that moves slowly.
3. Player layer.
4. Foreground layer with objects moving much faster than the rate at which the player moves.

The order is important because elements in the layer n+1 will occlude elements in the layer j, 1<=j<n+1 (basically, in all previous layers).

some client code.lua

 myCamera1 = Camera()  
 myCamera1:newLayer(-10, 0, function()    
                love.graphics.setColor(255, 255, 255)   
                love.graphics.draw(staticBackground)  
              end)  
 myCamera1:newLayer(-5, 0.3, function()   
                 love.graphics.setColor(255, 255, 255)  
                 love.graphics.draw(slowBackground)   
                end)  
 myCamera1:newLayer(0, 1.0, function()   
                 love.graphics.setColor(255, 255, 255)  
                 love.graphics.draw(player)   
                end)  
 myCamera1:newLayer(10, 1.5, function()   
                 love.graphics.setColor(255, 255, 255)  
                 love.graphics.draw(foreground)   
                end)  

Of course this is not the end of the story. Client code is responsible for updating and drawing the contents of the camera. Fortunately, this is easy, as it is shown next:

some client code.lua

 function love.draw()  
   myCamera1:draw()  
 end  
   
 function love.update(dt)  
  myCamera1:update(dt, player1.posX)  
 end  

love.draw and love.update(dt) are two framework callbacks provided by Love2d and which developers can override in order to customize their behaviours. The former will essentially call the draw function that we implemented in the camera.lua module, whereas the update function will in turn call an update function in the camera module, which we haven't discussed yet. In this example, we assume that we want the camera to follow the player when it is in the center of the screen. Achieving this requires adding the following lines to the camera.lua file:

camera.lua

 local intendedWidth = 1920  
   
 function camera:setPosition(x, y)  
  self.x = x or self.x  
  self.y = y or self.y  
 end  
   
 function camera:update(dt, posX)  
  if posX > intendedWidth / 2 then  
   self:setPosition(posX - intendedWidth / 2)  
  else  
   self:setPosition(0)  
  end  
 end  

Assuming a resolution (intendedWidth) of 1920 pixels in the horizontal dimension, we want to reposition the camera as soon as the player moves past half of this resolution (center of the screen). From that moment onwards, the camera is repositioned each frame to center the player on the screen. As the player belongs to a layer with scale = 1, the player will remain always in the same position in relation to the camera. This again will be further discussed and mathematically proved in the following post of the series.

And this is for now! I hope you found this tutorial useful. In the next installments of the tutorial, I intend to discuss and provide further insight on three aspects: reasoning about layers scales and their relation with the positions of objects, detecting collisions among objects in different layers and representing objects in different cameras, for example, for local multiplayer games.

See you!

Angry milk and cookies... This is Breaking Fast!

Hi all!

It's my pleasure to announce our new game: Breaking Fast (those who think the name is a pun are completely wrong...).

The game can be described as a competitive runner, or even better, as a Mario Kart-like game, where players have to run as fast as they can, avoiding obstacles as well as the attacks received from other players. As usual in our games, the mood of the game revolves around drinks and food, with a casual and friendly artistic style conceived by Manuela, and music and sounds by Oliver.

Breaking Fast is in an early development state as we are still adding new elements and mechanics to make it even more fun and challenging. Recently, we had the chance to showcase the game in an event for game makers and the feedback was fantastic. People were really hooked on the game and enjoyed playing dirty tricks on their rivals. We also received a good amount of tips to improve the game, and we are currently integrating them. 

The video below presents a coarse-grained view of the development process, starting from the conception on pen and paper. We started to think about the game during the last week of July in order to gain some knowledge about the Löve2d framework, which we intended to use for the August edition of Ludum Dare. However, we didn't advance much and ended up leaving it aside. Once Ludum Dare finished, we retook it because we were really hopeful about the potential of the game.

The development of Breaking Fast along three different phases

 

From its conception, our goal with the game has been targeting the core of fun and competitiveness, providing tight controls that pose a good trade-off between reward and frustration. Once the game is in a more polished state, we intend to submit it to Steam Greenlight, where we expect to receive even more feedback to finish off the last details.

Currently, the game only supports two players but it is our intent to include support for up to four players. Whether the game will have an online mode will largely depend on the feedback that we receive once in Steam Greenlight, due to the overhead in effort and infrastructure that adding online multiplayer may entail.

 

 

People from all ages and genres enjoying the game

 

This time Cookie beat Milk

Hope that we aroused your curiosity. We just created a twitter account through which you can follow us to stay tuned on the latest updates of Breaking Fast.

See you.
FM

Drunkula: Yet Another Post-Mortem (with nice pictures :))

This is an after-the-fact analysis of our experience during our first Ludum Dare, which is divided into three different testimonies coming from three different members/roles in our team.

Welcome to the 33rd edition of Ludum Dare!

Music & Sound by Oliver

I've been participating in game jams during this year for the first time, and LD is the third one. Drunkula is the eighth soundtrack that I've made for a videogame. And although everything can be improved, I'm really satisfied with the outcome.

My intention with Drunkula's music was clear: I didn't want a mere background music, but an interesting composition that conveyed the dark atmosphere bound to a vampiric night together with the drunkennes feeling of the main character.

Setting up our workplace

The composition was the first thing that I did, since it is the most difficult and which takes the longest time. The original instruments are those used for the first two levels. Then, I changed the orchestration to evoke the inners of the chapel (third level) without the need to compose any more pieces. 

For the menu, I cut out a fragment from the theme, changed the instrument of the main theme and I added some audio effects to make it sound like being at the door of a disco. For the credits screen I used a long note in order to simulate that annoying ringing after a night party. 

The serious side of the composition is given by:

• The choice of D minor because it conveys the feeling of dead and solemnity, like in the Mozart's Réquiem. 
• The 3/4 beat because it evokes the feeling of an aristocracy hall, like in any J. Strauss' waltz. 
• The higher dense than usual counterpoint in a jam game in order to convey the overloaded aesthetics usually associated to the vampire's castle, like in the well-known Bach's Toccata and Fugue. 

The comical and grotesque side comes from:

• The instrumentation, specially with the first two levels trying to represent the outside with wind instruments, and synthesizers and beatbox drums.
• The continuous apparent lack of rhythmical beat aims to evoke the drunkennes feeling. For some players, I understand that they felt the music kind of grating, but that was actually the pursued effect. 
• The slightly funky style of some accompaniments suggests the party mood where the guy that was bitten by the protagonist was. 

Some curiosities: 

• Just before closing the loop you can hear the famous "Mmmmm" by Morshu, a character from CDI's Zelda and one of the most parodied characters ever in a videogame. 
• Hidden among the counterpoint you can here the main theme from Japanese horror movie Hausu (1977), a psychedelic masterpiece that we watched a couple of times during the jam. 
• The central part has a sequence of chords taken from the beautiful Valse Triste by the Finnish composer Jean Sibelius. 

Regarding the sound effects and as I did in the two previous game jams in which I participated, I put off the sound effects till the last day. I used a micro to record elements in the house where we were working and then I edited the sounds in my computer. In this regard, I must thank the level designer because the voices are hers and she assisted me with the foley. To make the voices sound more masculine, I simply lowered the tone by software. Given that the sound effects are the last feature to be implemented, their volume are not so well tuned. The forest environment hardly is perceivable and it's a pity, because that day was very windy and I could record that sound in a natural way with the micro. 

Level Design by Esther

The first level was just a tutorial to settle the most basic mechanic of the game: point and click. The second level was about combining two objects to solve the level. In the third screen I introduced another object to solve the level. In this last level I tried to make the game more interesting by increasing a bit the difficulty; hopefully I made it!

I set up the levels with Tiled map editor, although I designed them previously with diagrams using pixels as units of measurement.

I also aimed to take care of the coherence of spaces between screens; that's why the first screen is on a path, the second one is at the entrance of the fortress and the third one is inside the fortress, not the castle yet but the chapel. I would have liked to have more time to introduce more levels, in a cemetery for example and other screens inside the castle itself: things that I keep in mind if we decide to go on with this game ^_^. I also would have liked to have made some sketches of the environment of the screens, not only the diagram of the level, in order to match the background and the platforms completely in a logical way.

The best thing of the jam for me is that we have learned so much in such a short period of time and have earned lots of experience. I have learned how important is to establish a clear and constant communication with all the members of the team (especially with the artists and the programmers).

Programming by Manuela and Francisco

We used the Löve2d framework (https://love2d.org) because we were interested in grasping a better understanding of Lua, a programming language that has been gaining traction among the game development communities during the last years. The main advantage of this choice is that we actually learned a lot about Lua, but the setback (and we were aware of it) is that we needed to build almost everything up from scratch. Given that we had no previous experience with a game jam, and that we had no pre-existing modules or data structures, we were a bit scared that we couldn’t make it to the deadline. Fortunately, this same deadline gave us the productivity boost that we needed to finish everything off. That’s definitely a good thing about jams!

The workflow that we used was the following. The artists handed their assets to the level designer, who used the Tiled Map Editor to set up the level. Then, the level, together with collision information, was exported to a lua format that we could read and show on screen. 

Having a strong breakfast was important!

As for the programming tasks, we started off by loading a simplified version of a level and showing a placeholder sprite for the main character (in particular, an 8-bit Mario sprite…). Then, we made sure that we could read an actual level from the Tiled Map Editor application and that we could show it on screen. Later, we added the main character and the basic collision systems to keep it from falling. In parallel, we tested the anim8 library for loading and showing some animations packed in grids (i.e. spritesheets). Also in parallel, we created the transition system for the different screens and for the introduction, and we integrated the music and sound effects in the last hours. Finally, we had to face some bugs with the change of direction of gravity, but we mostly fixed them all.

Stuff that we liked:

- The workflow was well established from the beginning, and all the members of the team took up their roles perfectly.

- We learned a lot about the Lua language, and the Löve2d framework, which has proven to be very useful not only for game prototyping, but also for the creation of full-fledged games. 

Improvable stuff:

- We didn’t take advantage of all the features of Tiled Map Editor, since we only used it to set up the map and the polylines for simple collisions.

- More play testing would have been beneficial, as some silly bugs could have been identified easily before release.

In the end, this was our results: we were in Q1, which is pretty cool being the first time

Starting Engines for Ludum Dare

Hi!

These days I've been getting ready for the Ludum Dare game jam, the theme of which will be announced next Saturday at 3 a.m. (Spanish local time). As part of my training, I've been learning a little bit about Love2d, a Lua-based game framework that is proving to be a powerful tool not only for mechanics prototyping but also for full-fledged game development. 

As part of this training, I'm developing (again together with Manuela) a local multiplayer game, which I'll show you more about after the jam, because I'll likely not have time to finish it off before this weekend. However, I can share with you some early art created by Manuela. Yes yes yes... more food... again :)

See you!

FM