viernes, 27 de noviembre de 2015

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!

lunes, 16 de noviembre de 2015

To full-time indie...

Hi all!

A couple of weeks ago, I achieved a milestone that I though it would never arrived: I got my Ph.D. degree in Computer Science. So yes, now I'm a doctor, but not one of those who can prescribe drugs!

This means that a part of my professional life has finished, and now, new opportunities emerge. In particular, this means that I intend to go full-time into indie games development. Of course, this decision entails quite a lot of risks, which are pretty well materialized in a good deal of failure cases and in the so-called indipocalypse. However, I find myself now in a stage in my life in which I'm willing (and capable) of taking up these risks and the new challenges that are to come.

This also means that I expect to be more active in this blog and in social networks in order to promote our projects, the first of which is the already mentioned Breaking Fast. Also, I intend to upload some videos to Youtube in which I will be implementing some new features of this game.

I have set myself a "reflective" deadline of one year, which means that after that year, I will perform a cost-benefit analysis of  my decision and I'll take a course of action depending on the outcome of such balance.



So yes, there is no time to lose! I will bring you news about Breaking Fast as soon as I have them. Also you can check our webpage, which is in a very early stage of development and lack lots of contents yet.

See you!
FM