Category: Coding

Pixel Art Explosions and Collider Collisions

There have been many explosions going off at Binary Cocoa this week! Mostly animated pixel art explosions in Tiled. Stephen has been pixel arting his brains out and is loving every minute of it. Too bad his code skills are still not up to snuff otherwise he would have made six games by now (not that they would have been super great). Here’s a screenshot of a top down dungeon searcher game he was fixing up in Tiled:


It needs some work still but it’s getting somewhere!

In other Binary Cocoa news there has been an update to Collider that people can get through Steam! Joseph and Braxton did a major overhaul to the collisions system in the game and it runs much smoother now.  We’ve found ourselves on a couple torrent sites, and we’re flattered, but we want everyone to have the latest version which can be found on Steam. We’re getting close to releasing a new game mode called Serpentine and it is awesome. It might even be our first multiplayer over the network mode if we’re lucky enough! We know that many of you have been asking for this and we are listening. We just don’t know all the hows and whens yet.

Wet Blanket is also on its way! Stephen sat down today and did a good art chunk today and that’s looking spiffy as well. Should arrive in December! Keep your ears to the ground! Watch out for trains though.

Binary Cocoa Does a Barrel Roll

We’re making some space jets! We’ve been secretly working on a game that’s in the vein of Strike Gunner and other star blasters alike. Here’s a screenshot of the game so far!


Those of you that are following our Twitter account might have already been seeing this, but we’ll divulge more information on this game here in the blog. We have two players made so far and they both do barrel rolls when you lean left or right hard enough. They’re both animated with 15 frames so their movements are pretty smooth and give you a sense of flying though space in a space jet. We’ve been creating enemies and space station environments that the player will be able to fly through and we think it’s going to be pretty fun! We’ll see anyways.

Stephen has been working on Wet Blanket mostly with his time, so that is Binary Cocoa’s top priority right now. We’ve been working on a multiplayer over the network system that we’ll implement in Egypt and Collider aaaaaand….we have way too many projects on our hands right now. But we love them all! We’ll keep spreading the news as it comes! Thanks for keeping up with us!

Binary Cocoa Puts On Their Teacher Pants

I used to teach middle school so I know what teacher pants feel like. Lots of chalk stains, marker stains, puke stains, and a whole lot of sagging from walking around a classroom all day. Not a bad life!

Joseph has been approved to teach a class about game development this year at the OpenWest conference! He will be teaching young and old the basics of Lua and game development, so come on down and see us! We’ll also have the booth there will all sorts of cool stuff. The arcade cabinet will be set up as always which has always been a joy for us to see people try our game and give us feedback. The conference is July 13-16 and we absolutely cannot wait! There will also be a presentation by us about online multiplayer game development on Friday during the conference.


Check out the conference details here.

Binary Cocoa Ups the Ante

Lots of new things have happened this week! Joseph said we couldn’t install firemen’s poles but that we could continue to work on Collider. His reasoning against the poles included something about what other people would think when they saw our office.

Whatevs. He’s probably right.

Braxton has been muscling the development work on Collider and has made some really colorful advancements! Since it would take a lot of paragraphs to explain what they are let me sum them up in a screen shot:

Screen Shot 2015-11-11 at 3.01.48 PM

Basically you defend the core from invaders and you set up a lot of nodes that connect to protect it. The yingyang looking power up is a replicator node that replicates another node type. It replicates for a couple seconds, pauses, and then replicates a different type. It can prove to be a strong ally in the game, but also a setback as it does pause and let enemies in every now and then. One must be wise with these things. Or just get a thousand of them. That seems to work too.

Stephen has also been creating much artwork for a still untitled game that’s in the works! Here’s a little taste of what’s to come:

Screen Shot 2015-11-11 at 3.22.43 PM

Screen Shot 2015-11-11 at 4.07.15 PM

Our good friend Jesse Horne will be coming out for a couple days to help begin the code with this game. This is going extremely helpful since our two main developers both have day jobs and Stephen has no coding skills…yet.


Anyway, we’ll be rolling out the coding sessions soon and doing all sorts of fun things in the months to come. We got a new trash can for the office and that’s pretty cool. I guess we can buy more string cheese now that we can throw the wrappers away.

Well! See you all soon!

Binary Cocoa Tries To Be Social

We have an office! Yes, all those scathing rumors are true. After some contemplation we decided that it would be nice to have a dedicated space for work and to proudly display our arcade cabinet. It was also apparent we needed some human interaction apart from spookily eyeing people from afar. The savages have treated us very well so far.

Joseph and Braxton have been busily cranking out much work on Collider. The latest game mode consists of a core that the player must protect from invading outsiders. It reminds me of the popcorn we have on our mini fridge that we must protect vigorously from mooching heathens.

I really do like our neighbors here in our office complex. It’s not you, it’s me and my deranged writing style.

Stephen has been churning out more artwork and music. Lately he has been working on a mystery project that we’ll reveal a bit down the road, but here’s a screenshot:

Screen Shot 2015-10-27 at 4.31.03 PM


Vikings has been developing as well, but more in speculation than actual work since Collider has been on the forefront. We hope Collider will be done soon! We have all the game modes we want in place with Core Defense being touched up at the moment. Then we will try to give the whole thing some visual flare.

Keep in touch for some more news! We have also been streaming some of our coding sessions which you can follow here:

We should have a widget on our site soon that will let people know when we’re online.

See you then!

Binary Cocoa Goes Live On YouTube

Hey there, fellow gamers!

You might not have noticed, but we haven’t posted in a couple of weeks now. That’s not to say we haven’t been busy on the development side of things…we just haven’t been updating the blog. Shame on us. Most of that shame falls on Stephen because he writes these things.


We’ve decided that a good way to reach out to more people beyond the blog is to do a live steam on YouTube twice a week! One steaming session will take place during a random day of the week and the other stream will always be on Saturdays because that is the day we can guarantee we have off (most of the time). You can even participate by typing in questions as the session goes along! Feel free to hang with us at this link here. We plan on eventually adding an “on-the-air” indicator on the blog so you can easily check if we are streaming or not.

We’ve been using Open Broadcaster Software to link our stream to YouTube and it’s been really great to us so far. Have any suggestions as to how we can implement this or another tool? We’d love to hear from you!

We’re finishing up the last game mode in Collider, after which we’ll be focusing on some visual elements for a bit. Then we shall release! It will be glorious for sure. Lots of explosions everywhere. Hope you all tag along with us as we head that way.

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!