Binary Cocoa Has an Identity Crisis

A little more than a year ago Binary Cocoa embarked on a mission to build solid 2D video games that would be intuitive and visually excellent. As the art director, I was happy and comfortable drawing assets in Photoshop in the corner of my lair. I would spend hours stroking a green eyed cat on my lap, cackling while drawing characters and backgrounds for 2D games we were working on. Then one day the mad scientist, or Joseph, howled down from the top of the lighting filled tower and asked if I would try out something new.

This new thing was Blender, a free and open source 3D animation suite. Blender was completely new to me, but the prospect of building assets in 3D was intriguing even if the notion did seem farfetched at first. To get some help I started watching tutorial videos, and within an hour I was starting to build my own simple models. Here is the first one that I built:

Screen Shot 2014-12-24 at 4.01.54 PM

Is it a space station of sorts? Or is it a door knocker? I don’t have a clue myself, but I do know that it was fun to build.

I fooled around with the program a little more, trying to make a spaceship, and came out with what looked like a hot dog with extra appendages:

space hot dog

Progress was made by learning how to make things smooth by using the tools given to me, and then rendering an image of it using the camera built into the program. It also lets you adjust the lighting on your model by giving you a lamp that can be moved around.

I set out to build a third model and came up with something more angular. I was still trying to build a ship, and created a goofy looking duck that looks like something straight out of Star Fox:


I know it’s not extraordinary, but I’m making progress! And I’ve only been playing with Blender for a day. I have yet to learn how to color or do other crazy things, but when I do I will be sure to post my progress and tips here for anyone who is interested.

Blender also allows you to render sprite sheets of your work which you could use in 2D games. You can save a lot of animating time by drawing one character and animating it, instead of redrawing it eight or ten times. It also means that Binary Cocoa is changing the way it is looking at implementing art in its games.

I guess you can say we’re having an identity crisis. I suppose that because we are mad scientists, this should be expected. So what happens now? Does Binary Cocoa just have to settle down and make changes or be shipped off to the psych ward?

Binary Cocoa Bakes a Pie

Binary Cocoa has been furiously working away at our new game, Collider, over the past couple of months. The game involves shooting bullets that develop their own AI and try to destroy you. It’s so evil and cute I can hardly stand it. Check out this nifty trailer:

The game allows players to use up to eight game pads and multiple game modes. For the extra-creative players, Collider lets you build your own game modes that can be shared with an online community.

In the past, Binary Cocoa has built games and sold them through providers such as the Humble Widget and Desura. This time we are using Steam Greenlight to get the word out about the game. Help us by voting through this link. Your votes determine whether or not Collider becomes the next big thing.

Also, our programmer Joseph has agreed to take a pie to the face as soon as Collider gets into Greenlight’s top one hundred. We will, of course, document his reaction for our records.

Let us know in the comments what type of pie you believe should be used.

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.

Binary Cocoa Releases Trailer for Boco

Watch the first trailer for Binary Cocoa’s newest game BOCO!

Check out for more exciting tips and information on how to play the game. Check here for further updates on a release dates and more posts on how to make your own games using the love 2D framework!

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.