How to Become a Video Game Artist

When I tell people I’m an artist, the reaction is usually an awkward pause followed by a joke about working at McDonald’s. When I tell people that I help make video games, they can suddenly believe I’m actually employed. Being an artist is fantastic. Art is what I love, and while there are artists who do manage to make it in the field’s purer forms, most of us will have to get a little creative if we’re to channel our passion and ability into something the masses can appreciate. There is no one way to become a video game artist, but I’ve compiled a list that marks my journey from a college student with an art minor to Art Director and primary artist of the new and rising Binary Cocoa.

1. Get a good portfolio together I’m sure most artists are aware that this is a necessary step to success, but it can’t be stressed enough. Have a complete portfolio that highlights your strengths. Be aware that having a cohesive portfolio can be more effective than showing off your versatility.

2. Learn about the process of making games You don’t have to be an expert to get started, but you do want to be knowledgeable about what will be required of you and have a general idea about what your teammate/teammates will be doing. Some basic concepts to study up on are sprite sheets, collaborative building programs like github, and animation options like After Effects.

3. Network Talk to everyone about what you do or even about what you want to do! Get on IRC and go to channels that have to do with video game development and share your portfolio. Be aware that there is some foul language and other interesting things on IRC that you may want to avoid. Talk to people in person as well. Try to talk to people who are interested in computers because they’ll probably be more interested in making a game than anyone else. You could try the Pet the Cutest Kitten club, but I think you’ll have better luck talking to people who work with computers. They usually (almost always) know someone who is building a game but lacking art. Don’t be afraid to team up with someone who hasn’t produced anything substantial yet, but don’t waste your time with someone who isn’t willing to put in the hours to create something worthwhile.

4. Be diligent Once you’ve found a team or programmer to work with, you should show them that you’re dedicated by actually making the art! It’s incredible how many times a project will get started and abandoned a week or two after it’s started. The gaming and programming world can be surprisingly tight-knit. Word spreads quickly, and you don’t want to jeopardize your future by giving up on a project when it loses its novelty.

5. Go beyond your duties Artwork can take a lot of time to produce, and programmers usually know this. There are also a lot of art assets that can be created quickly, which can result in the artist getting ahead of the programmer. Instead of demanding that something gets done over night, try to come up with ways to help. Even if you can’t program, there are almost always things you can do to move the project along. For example, you could look into creating sound effects, designing flyers, creating a website or social media page for your game, or finding ways to advertise your game.

6. Shop the finished product around There are many different platforms for selling a completed game. Sometimes the game itself won’t be what brings you money. In our case, Binary Cocoa put out a game that received only moderate attention from sellers, but caught the eye of a key investor. Be prepared to keep your day job until you’ve repeatedly proved that you can produce great games.

Any artistic venture can be risky and require immense effort. Creating game art is both exhausting and satisfying. There’s nothing better than seeing people enjoying your art, but you’ll need some elbow grease. Good luck and get going!

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.

Throwing a Loop Into Game Music

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

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

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

Who gets down to doom vibes anyway?

Crazy people.

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

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

Making Loops

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


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

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

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

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

So go sample some egg sounds!

Crunch down on some peanuts!

Throw a bath sponge at the stove!

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

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

Happy music making!

Catch the Coding Wave

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


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

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


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

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

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

Screen Shot 2014-07-22 at 12.45.14 AM

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

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

I suppose it’s time to conclude.

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

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