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.

Binary Cocoa Soars to the Future On the Wings of a Grouse

The team at Binary Cocoa has been busier than a nest of hornets chasing the kid who threw rocks at them this year. We’ve put our sweat and caffeine into making new blog posts for readers who share an affinity for game development, and we’ve had fun along the way. We’re on the tipping point of something great and are bracing ourselves for maximum warp on the highway of success.

Hexapod Defense Force has seen its release for computers across several platforms, and we are currently evicting the bugs from the code that are keeping it in beta mode. Improving its performance has been a priority, and we are picking up new tricks along the way. Someday we’ll share some of those here.

Here’s what Stephen and Joseph have been up to outside of the gaming world:

Stephen packed up all of his stuff, crammed it into his tiny Honda Civic and drove it across the country to Virginia, where he’ll be staying for a while. The trip took four days, two boxes of fruit snacks. His back was very sore. Then he drove back and forth between Baltimore and Williamsburg on a weekly basis to do job interviews at different school districts. After much searching he finally acquired one in Queens Lake, VA. This allowed him to move into an apartment and continue to do art in the evenings and every other day.

Joseph continued to function at his day job, as well as taking on Binary Cocoa projects at night. His dedication and hard work kept things going while Stephen lived in a car and smelled bad. His efforts brought much advancement to a game the team is developing that is called BOCO. The game is nearing completion, and we expect to do a release sometime in the near future.

The work on Viking Escape has slowed for the time being, but after preceding projects see completion it will see its day. We’re all very excited about this one. We were much more efficient on coding this game having experienced much with the previous one. Every game has pushed us a step further in quality development, and we hope to continue the trend as long as we’re creating games.

Additionally, Binary Cocoa has brought on an intern. Braden will be working with us to keep our games moving forward, and we’ve been able to work with him on bringing some of his ideas to life. Collider is another game being worked on that should be released before the New Year. Expect to see postings about it.

So, in summary, here are our plans before the New Year. Release the final versions of HDF and BOCO for Win/Lin/Mac/Android and have it submitted to Google Play store as well as the Apple App Store. Collider should be ready for people to enjoy and Vikings should be close to its final release. The blog will have more posts, specifically more in depth tutorials for those learning development.

So tag along with us as we puff out our chests and grouse our way into the future! Or just check in for our weekly posts and try our games if you don’t wish to be so showy. Leave us comments and we’ll be happy to answer them during breaks from squashing bugs in code.

Moving Art From the Paper Pad to the Computer Screen

There is something magical about creating a huge mess when it comes to making art. There are few things more therapeutic than throwing a clay pot on a wheel and walking away with dust all over you. Or being able to smear charcoal across paper with your fingers and getting to feel the texture. Some famous artists have complained that a lot of today’s art has lost its integrity by being altered electronically. Others say that computers are best thing to ever happen to the world of art. I’m not here to argue either side because after all…what is art?

I dislike that question.

Throwing paint everywhere has its merits, but let’s focus on how to switch to electronic art for those that want to know how to blend it with the tech industry.

1. Learn how to use a drawing tablet

Tablets are awesome. They allow you to draw directly from your tablet to the drawing program on your computer in whatever medium you’d like (although I still haven’t found a decent watercolor emulator) without leaving a mess. They can save you a ton of time, which is essential if you have limited time to work on a project. They also allow you to correct your mistakes, thus producing more professional work in abundance. They can be pricey if you go for the top models, but Wacom has a selection of reasonably priced models that you can start out on. Sometimes it’s not about having the best tool, but about knowing how to push what you have to its limits and beyond.

2. Become acquainted with an image manipulation program on the computer

A lot of people use Photoshop these days. Illustrator as well. Those that want to be completely open source might go for something like Gimp. It’s a great tool for people that want to make assets for 2D video games. Those that are looking for a real challenge might be interested in Blender which allows you to make 3D models. Those take forever, by the way. Learning these tools can make you so much more marketable to developers that might be hiring artists, especially when you learn the harder programs and can code a little. It might seem a little intimidating at first, and does take some time to learn, but it’s worth the time it requires. You might even figure out if the career path you’ve been exploring is right for you throughout the process. offers great tutorial videos for almost any program if you’re struggling.

3. Learn to take criticism

Your success largely depends on you being able to provide what developers want to use in their projects. This means that whatever they tell you to improve on or change, have the humility to understand that what you think might be perfect doesn’t always fit what everyone else wants. Sometimes people just won’t like your stuff, and that’s ok! Going through the refiner’s fire will help you put out your best work, which is much better than putting out mediocre work more frequently.

I guess the last thing I should tell you in this post is to not believe everything you learn on the internet. Some people pave their own paths in such unique and awesome ways and there aren’t enough blogs in the world to catalogue them all. That being said, we might be able to assume that they all had to work hard to get to where they are, so don’t give up! You’ll find that if you put the time in, eventually you and people around you will start to appreciate the work you’re doing.

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!