Introduction to Löve

Binary Cocoa has been doing game development for a while, and quite often we are asked what engine we use and why we use it.  This post will answer that question as well as give you, the reader, a starting point in doing your own game development.

Löve (www.love2d.org)  is “an *awesome* framework you can use to make 2D games in Lua.” It is fully cross-platform with it running perfectly under Windows, Linux, and Mac.  Support is also available for Android and iOS.  The engine is also licensed permissively, meaning you have full access to the source, and you can use the engine commercially. This makes it very well suited for learning and for production work.  Additionally, the engine is free.  That being said, if you find it useful, you should consider going to their website, scrolling down to the bottom, and following one of their donation links.  It’s a good cause, and it helps make the engine better for everyone.  Seriously, go do that.

Programs in Löve consist of three primary callback functions:

  • love.load() – Fired off when the game starts.  Useful for setting various parameters to be used later in the game.
  • love.update(dt) – Fired off before each frame is drawn.  Useful for updating player positions, calculating when things happen, etc.
  • love.draw() – Fired off to draw each frame. It’s use should be pretty obvious to you.

The following diagram should help you visualize how it works:

cycle

You probably noticed that all three functions were prefixed with love.  Everything made available via the framework is prefixed by love.  You can see a full listing of what’s available in the wiki. During this introduction, we’re going to make a simple program that lets the human control a circle that moves about the screen.  If you aren’t familiar with Lua, don’t worry, and feel free to ask questions in the comments.  We’ll try to keep things simple and straight forward.

function love.load()
   player = {}
   player.y = 0
   player.x = 0
end

What the above code does is quite simple.  It is making an empty table called “player,” and then it is initializing y and x inside of that table to both be 0.  We will be working with those later.  If we wanted the player to start out in the center of our window, we could simply change the x and y value.  We’ll be clever and use some of the love functions to make the program smart about where the center is.  Consider the following code.

function love.load()
   player = {}
   player.y = love.window.getHeight()/2
   player.x = love.window.getWidth()/2
end

That code will dynamically set the player’s x and y coordinates to the center of the window.  Because that is in our love.load function, it will only happen at the very beginning of when the program runs, unless we manually call it later, but I seriously doubt we’ll be doing that.  Now let’s move onto the next function.

function love.update(dt)
   if love.keyboard.isDown('down') then
      player.y = player.y + 100*dt
   elseif love.keyboard.isdown('up') then
      player.y = player.y - 100*dt
   end
end

This function gets called before drawing anything.  It also receives an argument called “dt”, but more about that later.  What’s important to keep in mind right now is that this function is called every frame and should be used for logic and control of the game.  If you take a look at the above code, you’ll see that we’re checking if some keys are down on the keyboard.  Specifically, we are looking for down or up.  If down is being pressed, then we are increasing the player’s Y coordinate by 100 pixels per second.  We are doing the opposite if the player is pushing up.  The only thing you might not understand right now is what ‘dt’ is doing there.  Delta time (dt) can be considered the great normalizer.  It is what we use to make sure the game is consistent regardless of how fast the player’s computer is.  By multiplying the speed of the player (in this case, 100) by dt, we are in effect ensuring that it moves that speed per second. Pretty cool huh?  Now let’s move on to actually drawing our player.

function love.draw()
   love.graphics.circle('fill', player.x, player.y, 30)
end

The only thing new there is the love.graphics.circle function.  It should be pretty obvious what it does though.  Notice that we’re not dealing with player motion in love.draw(), we are only dealing with drawing the player.  Now, if you take all 3 of those functions, put them into main.lua, and run the folder with Löve, you should have a circle that you can move up and down.  Once you have that working, I encourage you to add left and right, and maybe even start working on placing some constraints.  (Hint, you would need to start checking if p.y < something).  Either way, have fun, ask question, and remember – it takes time to learn this, but it’s very rewarding.

Hexapod Defense Force Kills Cell Phones

The headline is just a little misleading.

What we’re trying to say is that Hexapod Defense Force is KILLER on android phones!

That still doesn’t work.

The truth of it all is that after laboring hard for many months Hexapod Defense Force is out on beta for android cell phones! Those that have purchased the game will be able to download it to their android devices and we’re still working towards getting it out on IOS. We’re also still working out all the minor kinks but it is very much playable and looks amazing. Here’s a video of the gameplay just in case you think I’m just crazy talking:

https://www.youtube.com/watch?v=8oHWnf0f62A&feature=youtu.be

When we first set out to make Hexapod Defense Force we had only planned to make it for computers. This meant we could make it as big as we wanted and didn’t give a hoot what anybody else thought. Then many people expressed that they would have liked to download it to their phones and we started thinking…”that might not stink.”

The problem is that the game wasn’t built to be crammed into a cell phone. It was quite large and had tons of moving parts that needed to be optimized for it to not crash and burn. We also had to adapt the game to a touch based platform, which meant totally reworking the hud and adding ways to move and shoot. Needless to say it’s taken a while, but we’re proud to say it works and that it is loads of fun! For serious. Go try it! Get it here! (along with the Desktop version and soundtrack)

-> hdfgame.com

This game should appeal to those that like 2D games that have that retro style gameplay. Basically it’s Space Invaders with more weapons and fun things that move in the background. Oh, and the enemies are a lot more vicious and chaotic than Space Invaders, not to mention that the ending boss is one of the most formidable foes you could ever face.

sticker3

Snarl is a pretty bad dude. He undulates and moves in unpredictable patterns. He disappears for a couple seconds sometimes, making you wonder where he went until he comes up right from under beneath you. He’s also quite difficult, which makes it incredibly rewarding when you finally end his treachery.

Go enjoy Hexapod Defense Force! The one dollar price tag it has is all we ask for in exchange for hours of alien pummeling, missile shooting fun. If you don’t like it you can tell us that we’re losers and…we’ll probably just continue to make games. It’s all about all fun and learning experience, similar to the purpose of these blog posts which are written to reach out to fellow/prospective game developers. Let us know what you think!

Time for ice cream.

Throwing a Loop Into Game Music

Imagine if Star Wars had opened up with a fanfare of kazoos and slide whistles instead of John William’s powerful and timeless masterpiece. Then try imagining if Nintendo had hired the punk band Screeching Weasel to do the score for Super Mario Bros. It might have worked. More likely than not it wouldn’t have. It just wouldn’t have been as fun, at least. Music can make a game or movie great, but it can also send it to the depths of obscurity if it’s bad enough.

Creating music for games takes time, like all good things do, and it is often done later in the process once the mood of the game has been set. You don’t want to be composing epic orchestral music for a game that turns out to be a comedy.

For our game Hexapod Defense Force, we asked our friend Glen Moyes to compose us some music. He played our game and got the idea for a techno soundtrack that would fit the alien invasion theme. The songs he made started off with a dark tone, which warned the player of an imminent alien attack and would shift again when the boss was about to appear. It really made the environment come to life, giving you this feeling that everything was falling apart but that there was still hope for mankind or alienkind or whateverkind. It also had funky dance beats that brought everyone out to the floor. Seriously. We took the game to a conference down in Salt Lake City and caught more than a few people grooving along to the vibes. Glen’s Doom vibes.

Who gets down to doom vibes anyway?

Crazy people.

Or awesome people. Maybe I’m just missing out on something.

By the way, you can check out Hexapod Defense Force at hdfgame.com.

Making Loops

One unique aspect of making music for games is making music that is able to loop for ever and ever. I tried doing this in Garageband at first, and it turned out to be a disaster because it exported all of my tracks at uneven lengths, and everything would just get out of sync when they were played in the game. I then turned to Audacity, which allowed me to specify how long I wanted each track to be, and I exported all of my tracks from there. It’s actually super easy once you figure out how to do it. Just reference the below picture:

trackLength

For a game that we are working on, we decided to use loops, making it so whenever a player went further in the game he or she would unlock more tracks to the loop. So you start the game and all you hear is a drum, and then as you progress, you get chimes, a piano, strings and so on. I had never seen anything like that done in a game before (please excuse my ignorance) and was super excited to see that it actually worked! You can check it out in our game BOCO (it’s current and hopefully last title, but that’s another post), which should be released soon.

Here you can listen to the menu music track that I created for BOCO, if you wish!

Loops are fun to make, especially after you learn how to make them work. They can be pretty frustrating up until that point. And like I mentioned before, Audacity is awesome when it comes to editing tracks. Try it out! It’s free on the internets:

http://audacity.sourceforge.net/download/ 

As for creating music, just go out and collect as many sounds as you can. For one of our songs, I tapped on a desk, put some reverb on it and made it into a loop. Then I played my acoustic guitar over it. Glen went out and bought an electric guitar and learned how to play it for the songs he made for us. One of my favorite bands sampled themselves hitting a baseball bat with drum sticks for one of their songs. It sounded awesome.

So go sample some egg sounds!

Crunch down on some peanuts!

Throw a bath sponge at the stove!

Just don’t break anything that’s not yours. And don’t throw anything at the TV. I’ve seen those destroyed before in the process and it’s just a little awkward when people come home and they can’t watch Cupcake Wars.

Make your music sound balanced and professional as well. Take time to master it so it doesn’t overpower everything else in the game. Making sure game sound effects don’t get lost in the soundtrack is also good. It takes a lot of trial and error work, but it makes a difference in the end.

Happy music making!

Catch the Coding Wave

When we first came up with the concept for Viking Escape, we drew up a sketch that included a little boat, some rocks, and water. The boat and the rocks would be simple enough to program, but the water was going to be tricky because it had to be interesting visually and had to use little memory, you know, to keep cell phones from exploding. That last part was an exaggeration. Anyway, what we drew looked something like this:

sketch1

The grand scheme we concocted included a rising water level to simulate a flooding cave that was supposed to look like it was going back and forth. I drew a water asset that took up the whole screen, thinking that Joseph could program it so that it would start below the screen, slowly rise and eventually consume the screen as the player reached the top. This worked, but it proved to take up too much memory which is bad when you want a game to run smoothly on a smaller device such as a cell phone or tablet. Having learned from experience on a previous game, we learned that it was easier to optimize everything as we went along instead of doing it after the fact.

To save memory we decided to crop all art assets as tightly as possible, because every pixel counts. So for the water asset, I chopped it down to this:

waterWaves

Joseph then programmed the game to take the color from the bottom of the water asset (the blue), and use it to fill the rest of the bottom of the screen. This proved to take up much less memory and made no difference visually. He then programmed the asset to move back and forth, and thus we had moving water. We celebrated by doing the Binary Cocoa victory yell and dance, which no one will ever see or should have to.

To make it look less stale, we decided to code the game so that it would duplicate the water asset three times, stacking them all one level above each other, and staggering the rates at which they moved back and forth. This created a neat sense of depth in the game that really brought the environment to life. You can see it in action here in this short video:

https://www.youtube.com/watch?v=tzBlaSYaubI&feature=youtu.be

(or you could just see what it looks like here in this screen shot)

Screen Shot 2014-07-22 at 12.45.14 AM

The water is just one of the many moving parts within the game, but it just comes to show how putting in a lot of small details can really enhance the game play experience. A couple months ago, Joseph and I watched a video game conference video where two programmers showed everyone how to spice up their games. They took a simplified version of Breakout (that looked painfully boring at first) and put flashing lights in, several bright colors, a techno soundtrack and fun sound effects that all of the sudden made the game look like something anybody would buy. I would post the video here, but it has copious amounts of toilet humor and I think I would just be doing everyone a disservice.

What I’m trying to say is that even the lamest game can catch people’s attention if it is flashy enough. At least for a while anyway. We do all of our stuff in Lua, which has been great because they have libraries upon libraries of game code that they just give to you for free. It’s so much easier to borrow a physics engine instead of banging your head against the wall trying to build one from the ground up. Check out some of the cool things they have to offer here:

https://love2d.org/wiki/love.physics

I suppose it’s time to conclude.

Our goal with Viking Escape is to give players a game that is fun to play as well as aesthetically pleasing. It can be somewhat challenging to accomplish for phones that have little memory, but we’re finding new methods to accommodate better graphics all the time. It’s all really exciting actually. Every time we make a new discovery, it’s like finding your favorite bucket of Oregon black cherry ice cream in the back of the icebox that isn’t freezer burned, or having a load of socks go through the wash and having all the pairs come back intact.

Compare it to what you will. I’m going to eat ice cream.