Binary Cocoa Flexes Its Muscles

For the past few months the team at Binary Cocoa has been skiing across the alps and riding eagles down the mountains like real men with copious amounts of chest hair. Sometimes they look like this :


Fus ro dah.

Now let’s get to what Binary Cocoa has really been up to. BOCO has seen its first trailer come to light and it has been slowly spreading through the internet receiving claps of approval. We hope to release it sometime within the next week or two but it is always hard to tell how those things go. The game is complete, however, and we are anxious to share it with all those who would lend an ear.

Now that BOCO has been completed everyone is focusing efforts on the following game Collider, which is starting to shape up nicely. More details of what the game will entail will come later but we can already tell everyone that it involves spaceship shooting, alien enemies, and a groovy techno soundtrack. Fans of minimalist line art will be most satisfied with the aesthetics of the game as well. We’re hoping to have it done by the end of the year to release at the beginning of 2015.

Vikings has been a work in progress that needed more time to develop. Stepping away from it for a moment gave us a new set of eyes for it and gave us time to think about how to approach it correctly. One of the latest steps in the development has been to implement maps using Tiled Map Editor, a fantastic program for creating levels for games more quickly and with fewer assets. Our friend Landon Manning created a quick implementation code for Lua that has made the map implementation process much less stressful as well. Stephen just started to mess around with Tiled Map Editor to explore its possible use for Binary Cocoa games and created a quick level for practice. This is what he came up with:

Screen Shot 2014-11-19 at 8.05.17 PM

(Click for larger view)

2D side scroller games or top down strategy games seem like they are the games that would benefit the most from Tiled. It also allows you to work with orthogonal, isometric and staggered maps if you wish for something a little more complicated. It’s worth playing around with for whatever type of 2D game you wish to make, so give it a try! Feel free to leave questions about it or any other Lua/Love 2D related inquiries and we’ll help you as much as we can.

Sourcetree for the Uninitiated

Joseph and I became a team back in the fall of 2013. I was a partially employed undergrad with an art minor, and Joseph was an IT consultant who’d created a game prototype that needed artwork. Luck (or our mutual friend named Braxton) brought us together, and we made Binary Cocoa’s first game, Hexapod Defense Force.

When I first started doing the art for Hexapod Defense Force, I realized I needed more than art skills to help make a computer game. Two computer tools became absolutely essential to our creative process: SourceTree and Bitbucket.

Bitbucket is a type of cloud storage designed for code projects that can be accessed and updated by multiple users (up to five users for free). SourceTree is the file management program you can download to your computer that simplifies accessing and updating your files and projects stored to Bitbucket. This beautiful relationship makes it so Joseph and I can seamlessly collaborate on games from either side of the country.

While there are plenty of programs that help you share files remotely, the real benefit of using SourceTree and Bitbucket is that you can push and pull modifications and additions to a game with relative ease and with protection against overwriting each other’s work. SourceTree keeps track of every version of a project, so if something blows up, you can always go back to before the explosion. SourceTree manages the files so that you receive any updates prior to sending out your changes to a project.

Here’s an illustration of the basic process:


As an artist, these programs mean I can send Joseph new artwork as I create it. He can then turn around and show me the latest version of the game, and I can test how it plays. Lately, I’ve been learning enough of the basics of programming that I’ve been able to add in art and sound files as I make them. This frees up more of Joseph’s time for the hardcore coding and keeps us on the same page without having to constantly bug one another for updates (not that we don’t love each other).

Programs like SourceTree make it possible to truly collaborate even though we have different talents and schedules and zip codes. Binary Cocoa couldn’t be successful without all the incredible resources available to us. Perhaps this blog is meant to be a dedication more than a how-to or a chronicle.

For more information about SourceTree and Bitbucket, try their official websites.


The Wonders of Winged Edge

Have you ever looked at a problem and thought to yourself, “This will be easy, I just need to do this and that and it’ll be done”? I often look at the broader problem without giving the details much thought until I’m already waist deep in code, and working on BOCO was no different.

I was recently approached by Binary Cocoa to work on their newest game, BOCO. BOCO is a simple strategy board game where you try to fill a game board with coloured pieces to encircle your opponent’s pieces. You can encircle just one, or several pieces to win. The board is a simple grid of triangles, squares, and rectangles. Conceptually, this sounds like a pretty simple game to implement. The catch is that a player can only play their piece adjacent to other played pieces. This complicates things.

My first attempt at mocking up BOCO ended up being very fragile. I quickly threw together a demo and while it worked, it wasn’t extendable in any way. Instead of hardcoding the grid and which shapes were neighbouring others, I needed a more elegant solution that wouldn’t fall apart if we want to expand the game. After some extensive research, I found the perfect solution: the Winged Edge Data Structure.


Winged Edge is a data structure that gives each vertex, edge, and face of an object descriptive information about the the other vertices, edges, and faces neighbouring them. What this means in layman terms is that each piece of an object knows which other pieces are connected to it.


As you can imagine, this is an incredibly useful data structure and fits perfectly with my needs. Using Winged Edge, I could determine both where a player can put their piece, and if a player wins or loses. There was one problem, though. No one had bothered to implement Winged Edge using Lua, the language I was using to write BOCO. Before I could begin working on BOCO, I needed to write a Winged Edge library.

My Winged Edge library, aptly named “Lua Winged Edge”, is a pure Lua implementation of the Winged Edge Data Structure. Any program or game engine that uses Lua can use this library. I’ve also licensed it under the MIT license which allows anyone to use, modify, and distribute both personally and commercially without royalties. The only stipulation is that the original license file remains in tact.

The first step in creating my library was to determine the simplest way to get the original data that needed describing. I opted for two methods:

  1. Allow the user to create a table filled with data that is formatted in a particular way
  2. Import the data from a Wavefront Object file

I wrote a quick and dirty Wavefront Object Loader in Lua that would parse an object file and spit out a formatted table. This loader is again written in pure Lua and all of the above licensing information applies. I am a huge fan of open source software, and try to do my part to provide useful tools where there are none. By using this loader, I was able to quickly mock up BOCO’s game board using Blender, a free, open source 3D modeling suite.


With the board data sitting inside an object file, I was able to quickly load it into a Lua table and then use that table to create the Winged Edge structure. The Winged Edge structure is as follows:

WEobject = {
    vertices = {},
    edges = {},
    faces = {}

The vertices, edges, and faces tables each hold a long list of their respective data. Each data point has information about all other data points that are connected to it. For example, if face 1 is a square, it has four edges and four vertices:

local face = {
    vertices = { 1, 2, 3, 4 },
    edges = { 1, 2, 3, 4 }

Each edge and vertex also has similar data. Each vertex has positional data to indicate where on the grid it stands, and each edge has data so that it knows which edge came before it, and which edge is after it in an edge traversal:

local vertex = {
    edges = { 1, 2, 3, 4 },
    position = { x, y, z }

local edge = {
    vertices = { 1, 2 },
    faces = {
        1 = {
            prev = 4,
            next = 1,
        5 = {
            prev = 7,
            next = 5,

Now that we have our Winged Edge structure set up, what can we do with it? Well, let’s say a player clicks on a tile in a grid to play their piece on the board. We need to know if the play was valid or not. How do we do that? First, we must triangulate each tile to break it down from any shape into a bunch of triangles. Next we cast a ray where the player clicked on the screen and check each tile to see if the ray intersects a triangle. Once we get our intersection, we know which tile was clicked. We can then run our validation check against that tile to ensure the play is valid. The validation check is very simple, we must ensure that the tile is adjacent to a tile that has already been played. What we do here is traverse through the clicked tile’s edges and check each edge to see which other tile it is connected to. If that tile is has already been played at some point, the move is valid.

-- get the click point and the ray cast direction
-- in this case, straight through the z-axis
local point, direction = Vec3(mouse.x, mouse.y, 0.0), Vec3(0, 0, 1)
local intersect = false

-- loop through all the faces in the board
for i, face in ipairs(game_board.faces) do
    local hit = false

    -- cut the face into triangles
    local triangles = WE.triangulate(i, game_board)

    for _, triangle in ipairs(triangles) do
        local tri = {}

        -- get each vertex from each triangle
        for _, vertex in ipairs(triangle) do
            local x = game_board.vertices[vertex].position.x
            local y = game_board.vertices[vertex].position.y
            local z = 0.1

            table.insert(tri, Vec3(x, y, z))

        -- cast the ray through the triangle
        hit = WE.intersect(point, direction, tri)

        if hit then
            local valid = false

            -- if the clicked tile has not been clicked before
            if game_data[i] == 0 then
                -- get all the adjacent faces
                local adjacent = WE.traverse(i, self.board)

                -- loop through them
                for _, f in ipairs(adjacent) do
                    -- if tile has already been played, 
                    -- the move is valid
                    if game_data[f] > 0 then
                        Signal.emit("send_play", i)

The above code has been cut down to get the main point across

Now that we have our valid move, we must check to see if the player has won (or lost!). The win/lose checks use recursion to propagate outward from the clicked tile to check if it has encircled the enemy, or is encircled by the enemy.

-- for this example, we will use tile #5 as the clicked tile
local intersect = 5

-- if we haven’t checked this face yet, check it
if not checked[face] then
    checked[face] = true
    -- if the tile has been played and checked,
    -- return true, else false
    if game_data[face] > 0 then return true end
    return false

if game_data[face] == enemy then
    local f = game_board.faces[face]
    -- number of adjacent blocks
    local perimeter = 0

    -- grab the edges from each tile
    for _, edge in ipairs(f.edges) do
        local e = game_board.edges[edge]

        -- grab the faces from each edge
        for _, eface in ipairs(e.faces) do
            -- if the face is the other face on the edge,
            -- run the recursion
            if eface.face ~= face then
                local recursion = check_encircled(eface.face, grid)

                if recursion then
                    perimeter = perimeter + 1
                    return false

    -- if all of the faces in the current recursive branch are true
    -- start unraveling the recursion
    if perimeter == #f.edges then return true end

    -- if they aren't all true, no win/lose and
    -- the recursion is done
    return false
elseif game_data[face] == player then
    -- We are checking a piece right next to the intersect,
    -- so this is not a win, no enemy piece between
    if intersect then return false end

    -- we've hit the outer wall of our encircle check,
    -- start unraveling
    return true

The above code has been cut down to get the main point across

This code might be a bit difficult to understand if you are not familiar with recursive functions, but the gist of it is that you start with the clicked tile, you check each adjacent tile to see if it pas been played and by whom. If the tile has been played by your enemy, you call the function on itself with the new tile and keep branching outward. Once a recursive branch hits one of your own tiles, you know that you’ve reached a point where you might have encircled the enemy’s tiles so you start unraveling the recursion and send that data back. If at any point you find a tile that has not been played yet, you know that it is impossible that encirclement could have happened and we just kill the whole process.


In the end, loading the game board from an object file and using Winged Edge to manage the whole game was absolutely the right choice. BOCO’s code is in a state where we could potentially add new game boards with different tile shapes without needing to adjust a single line of code. Creating new game boards in Blender takes minutes instead of hours allowing for quick and simple testing of new board designs and new strategies. Developing BOCO was a surprising yet fun challenge and working with the Binary Cocoa team has been a privilege.

Introduction to Löve – Part Two

In my previous post (Introduction to Löve), I showed you how to start using the Löve framework to produce a game. While what we made wasn’t really a game exactly, it did have some of the foundational things you would need.  In this post, we’re going to add a bit more.  Specifically, we’re going to give the player more freedom of motion and add a second player.

First, let’s do a quick review of the code we should have from before.

function love.load()
   player = {}
   player.y = love.window.getHeight()/2
   player.x = love.window.getWidth()/2
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
function love.draw()'fill', player.x, player.y, 30)

That code initializes a player table, stores some coordinates inside of it, and lets us use the up and down arrows on the keyboard to move the player up or down at a rate of 100 pixels per second.  It then goes on to draw the player as a circle.  So let’s dive right in.

The first thing we need to do is let people distinguish the player.  We’ll do this by storing a color in the player entity. There are more elegant ways of doing this, but we’ll simply make another player, and give the player a color entry.

function love.load()
   playerOne = {}
   playerOne.y = love.window.getHeight()/2 - 20
   playerOne.x = love.window.getWidth()/2
   playerOne.color = {255,0,0,255}

   playerTwo = {}
   playerTwo.y = love.window.getHeight()/2 + 20
   playerTwo.x = love.window.getWidth()/2
   playerTwo.color = {0,255,0,255}

Nothing really new there except a bit of additional Lua syntax. We’re storing each player’s color as a table inside of the “color” entry in their own table. Tables in a table, it happens all the time, and it’s very useful. Colors in Löve are defined as RGBA (Red, Green, Blue, Alpha). We’ll be using that color variable a bit later, but for now, let’s improve our player movement.

function love.update(dt)
   if love.keyboard.isDown('down') then
      playerOne.y = playerOne.y + 100*dt
   elseif love.keyboard.isdown('up') then
      playerOne.y = playerOne.y - 100*dt
   if love.keyboard.isDown('left') then
      playerOne.x = playerOne.x - 100*dt
   elseif love.keyboard.isDown('right') then
      playerOne.x = playerOne.x + 100*dt

We didn’t do anything new. really.  We’re using the same functions that we used previously, but this time we’re checking for some different keys.  One thing worth pointing out is that we’re using if and elseif statements. It’s important to think about the order that things happen in the game. In our example, the code fire checks if the down key is pressed.  If it is, then we aren’t even checking if the up key is pressed. This means that if both up and down are pressed, the player would move down.  Same thing for left and right.  If both left and right are pressed, then the player would move to the left. If we had merged everything into the same if and elseif statements, then we would only be able to accept one key at a time.  As it stands, we are able to process up to two keys being concurrently pressed. If we were to break everything into their own if statements, then we could handle all keys being pressed at once.

Our next step is to make sure that we can distinguish between our players.  Color is a great way of doing this.  If you remember, we earlier made the players have a color.  Let’s use it in our draw function now.

function love.draw()'fill', playerOne.x, playerOne.y, 30)'fill', playerTwo.x, playerTwo.y, 30)

Here we are using the setColor function, which accepts four arguments (R,G,B,A).  It will then use that as a modifier for each draw operation performed after it.  We could pass four independent arguments into the function, but we can use a handy function that’s built into Lua called unpack. This takes our table in a table and returns them all independently. That means we now have a nice way of dealing with player color. As has been pointed out by a commenter, the function is also intelligent enough to accept the table directly.  That means that we could simply pass in playerOne.color and it would deal with it appropriately.  That would also be better performing too (though only marginally at best.)

If you run the code now, you can move our circle around and give them color. Using what you’ve learned thus far, you should be able to produce another player with different controls and have them both be controlled independent of each other. Try it out! If you hit any snags or have any questions, feel free to post a comment. We’re here to help! My next post will build on this knowledge by showing you how to do some basic collision management along with tracking even more information about the players. Until then, happy coding!

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 (  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:


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

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

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

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()'fill', player.x, player.y, 30)

The only thing new there is the 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:

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)


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.


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.