Bindstone: From 2D to 3D and Back Again!


Bindstone’s art has been in development for the past three years. 2016 was a particularly productive year, and as we approach 2017 I wanted to take a moment in retrospect to present the many iterations we have been through to get here. In this post I’ll be reviewing how much the artwork for the game has improved and how our production pipeline has evolved from an art perspective. This will be a focus on the map assets specifically, building and character assets will be another post later.

If you are unfamiliar with the game, we have an introduction to the game posted here. If you would like updates when major milestones are reached please subscribe so we can contact you!

The first iterations of Bindstone were purely illustrated in 2D, that’s what I studied when I was attending school. Michael had spent years creating a custom 2D engine that we would use, so approaching this in 3D never crossed my mind. The game would be viewed from a single orthographic top-down perspective similar to isometric (but 55° instead of 45°.)

The first pieces of art created for the game were stand-alone buildings, but after several months of working on one-off pieces it became increasingly clear I would need to build a cohesive map for them to sit in. It was difficult to keep a consistent style and imagine a world for buildings and characters to interact with otherwise. When I began painting the map my style evolved. I found myself spending more time drafting things in our peculiar perspective so I decided to learn Blender as an intermediate step to draft architecture. The rest of this post will dive into the multiple iterations in 2D, transition to 3D, and then the currently in-progress effort involved in painting back over the 3D render.

When I first started Bindstone I was mostly a traditional artist who knew Illustrator, Flash, and Corel Painter. I had not learned the three primary programs I’d use making our game, Photoshop, Blender, and Spine. Just some resume bullet points I hope to never need.

Before getting into the art itself, I’d like to explain the scale of the map. It’s easy to see zoomed out pictures of the whole thing and not really have a good grasp of how big it really is. The player needs to be able to zoom in and interact with it closely. This necessitates an awfully large image.

The Bindstone map is 28,500 x 10,000 pixels in size. If printed at a standard print resolution of 300 DPI it would fill an 8′ x 2.7′ page. Put on its side, it would be as tall as a room. The map compressed to the minimum number of working layers is 4.5 GB and growing, or about as large as an HD Movie.

The scale of this is greater than any single piece of artwork I’ve ever done, and while it is this large while I work on it, we will be shipping multiple sizes of the map depending on the capabilities of each device. PC is likely the only platform that will load the full resolution assets as it takes up 1.14 GB of memory to load the background image alone. This isn’t an unreasonable amount of space for modern desktops. For different phones it will likely be halved or quartered in size and will still look great.

I’d like to mud wrestle you through designing one of the main buildings on the Bindstone map. This building is the reason we moved to start working in 3D.

Well Concepts 0

These are the very first images of the well. The well is the end goal on either side of the map which the enemy is trying to infiltrate.

Through the first three iterations I was deciding the overall style of the game. The original style of the map was suggested Aztec or Mayan themed by Michael and red was a dominant color, but I drifted further away from this and we are both much happier with the more lush blue and green theme in the later images.

You can see influences of Bastion and League of Legends as the map progresses. The seventh iteration of the well seen above was actually the longest standing version and is still in the MutedVision engine as of this post. The last version seen above is when I started to really focus on making more of a structure rather than just a hole. From the beginning we called it a well, the name still stands unofficially. We may officially rename it later.

Fun fact: The Bindstone sits inside of the well and emanates light, it is the power source for each base but it is not directly visible in the map. Our game was originally unofficially called “wargame” and then later “Moon Dog” before we settled on “Bindstone” as the release title.


I wanted to portray a more substantial structure for the well but having the structure visually obscure characters was unsatisfying. We wanna see that juicy de-spawn animation when points are scored. Making the buildings ancient and ruined would let us hint at something more substantial while fulfilling the game-play visuals we were after! The sketches on the left show a rough concept of what I was trying to achieve.

This was the most complicated building I had planned for the game’s map (not counting unit spawning buildings), and it is the center of each player’s base. Getting it right was a good investment of time. At this point, I decided to pursue the design to completion. I did not want a particularly sketchy rough version of the structure, so a sketch with nicer paint would not suffice. Bindstone has a much more crisp look I was trying to achieve which required drafting since I had not yet adopted Blender. You can see my hand-drawn lines above and on the right.

Even if most of the building was ruined I still needed to draft the whole building before I applied damage to it to ensure accuracy. I needed to draft the inside and outside lines of the well so that I could see how thick the walls were at every point when I was going to do the damage pass. Trying to draft this by hand was a nightmare, drawing an orthographic dome on top of a 3D structure with multiple facets took me a month to complete. I could tell that I hadn’t quite got the angles right in some places, but it was very close. I couldn’t spend this much time drafting architecture, something needed to change.


I realized I was trying to be AutoCAD. Frustrated, I turned to Michael seeing if there was a program that would help me with the drafting phase that was taking so much time and effort. He originally suggested we could build up 3D objects from simple primitives in Unity and showed me screenshots of a primitive cylinder and sphere on top of it to represent the well. I wasn’t satisfied with that solution, it didn’t get me the full inside and outside walls of the wireframe I was after at the time, so he investigated Blender and we had our solution.

Neither of us knew how to use it, and we both learned the program together, much of what I describe about our process with 3D tools needs to be understood from the perspective of someone learning the tool for the first time. Some of what I describe has very real technical solutions which we may not have been aware of at the time.

Since I was looking for a detailed wireframe to draw over and apply damage to in Photoshop the biggest issue with a wireframe render was that the lines were all the same color. I wanted different components to come out different colors, and the inner walls to be differentiated as well. So I spent another few weeks carefully color coding those lines in Photoshop as seen in the middle image. This involved painstakingly tracing and decoding which lines were which.

The final image above and on the right is simply the well we modeled without wireframes.


After some unsatisfying legwork tracing lines for an uncomfortable amount of time, and having also moved on to other parts of the map in 3D we both got more familiar with Blender.

With familiarity I got comfortable with the idea of simply modelling the final look of the building with the damage I was after rather than just relying on wireframes and drawing it all by hand. The Blender BoolTool was a really neat discovery and allowed me to take a completed model and pull out chunks of it based on some other shape. Since we don’t care a lot about mesh topography as we are only relying on the final render and not using these assets directly in animations, this was a fantastic tool to get a specific look.

The images above show a few stages of our well being rendered differently after having this applied to them and becoming more familiar with lighting in the scene. I finally saw Blenders ability to provide really dynamic lighting reference and this excited me quite a bit. I officially decided to integrate blender renders with lighting and materials into the map and would use those as a base to paint on top of directly rather than making use of wireframes for further sketching and painting passes.

This saved a ton of time by cutting past intermediate sketch and value study mock-ups!


To render with textures we actually invested in an external GPU setup which took a full weekend and multiple operating system re-installs to figure out. Let’s just pause for a moment to appreciate this jank bundle of wires that made the images above. We eventually got the Power Supply, Akitio Thunder 2, and GTX 970 plugged in and working on a 2013 Macbook Pro. It looks like half a computer splayed out across the table, kind of gruesome, but also awesome!

As I continued working in Blender it seemed like each new feature discovered was just another step I wouldn’t need to do in Photoshop by hand. I would of course do a lot of painting in Photoshop to get a really nice feel, but now I could avoid a bunch of guesswork, drafting, and made-up lighting.

We decided to add textures and color to the buildings on the map to try and approximate the original colors from the full 2D version (you can see it roughly here in this video, or here at 6 seconds if you pause). These wells are both textured with heavily modified free-to-use materials found online. The image on the right is from after I discovered the vine tool (the one on the left is a smaller render without vines pasted over one with vines to give an idea of before and after even though it is technically a later image). The vines you see will not be directly used, but are more for reference when I am doing the final detail pass.


This is the most up to date image of the well, though it is still in-progress. The well has been completely repainted by hand in Photoshop over the render to achieve a smooth base coat. I plan on going over the stonework one last time to get the final detail pass, smooth out the edges to make them appear a little less CG, bring in more color variation, and bring in some softer tones and additional cracks. After applying one last coat of paint to the stonework I will be applying moss, dirt, and vines.

While the well is not complete this is the progress that’s happened over the past year. Next I’m going to talk about another portion of the map that has changed dramatically since the start of the project, the waterfall. It’s a major background element to the map that didn’t originally exist. It used to be an Aztec temple.


The first image is the very first concept of the temple. It was to function as an end cap on the map (the last element on either side before the game locks further scrolling). Next you can see my attempt at drafting a cleaner version based on the original concept. Originally we were thinking about having interchangeable faces that users could purchase to customize their base. Maybe it could have worked, but the strictly forward facing angle made it hard to design interesting and unique assets worth buying. The third and final step down this path was an attempt to tighten up the horizontal length of the structure and re-color it to our new blue and green palette.

I was growing pretty dissatisfied with the temple concept and didn’t get too far with it. The whole structure wasn’t really going to be seen much anyway during game play since it’s so off to the side. On top of that having such a busy and intricate object on the border of the map was distracting from where I really needed to direct player’s attention.

I felt frustrated with the old design and one afternoon I quickly painted a waterfall and fell in love with the simplicity of it. From there I began making the final design. The fourth image is actually what I painted in frustration and the last image is a more polished version of that.

It was really liberating just leaving the old concept behind and starting fresh and it really changed the feel of the map for the better.


So, you saw that sweet painted waterfall, right? Well, there were a couple design issues with it that bugged me enough that I decided to approach it differently.

  • The first was that I felt the waterfall appeared to pour too heavily to accommodate the small pool it flowed into, I wanted to design it to splash more against rocks on the way down rather than appear like Niagara Falls.
  • The other issue was not immediately obvious and was actually with the dimensions. The top of the waterfall in the original painting was about 25% wider than the base. It was subtle in 2D but obvious when confronted with a 3D model.

With that said, my initial attempts were not ideal. The images above represent my step into the 90s of CG. I had no idea what I was doing. This is bleeding edge 3D technology surround sound for your eyeballs. Learning what mesh topography was? Nope! I had no idea, just kept subdividing the whole mesh. It actually pushed my computer to the point of where I couldn’t edit the model because of how many vertices there were. I vaguely remember encountering ngons and tears in the mesh and just abandoned editing certain rocks which were rendered static in sculpt mode.

I’ve had the end result described in various colorful ways: popcorn, termite mounds, and poop.

This took me two months, let’s move on


So yeah, those sweet popcorn cliffs were placed into my old painted map. I had to actually remove them from the blender scene for performance reasons, they sat alone in their own file. These were dark times, and not just because we had no proper lighting at the time. We even thought that maybe that same idea would work on the cliff wall surrounding the rest of the map. The results speak for themselves, a jumbled mess of blob rocks that don’t really read well or serve the map as a whole.

Yeah, anyways, we came to our senses and in the final image we learned the Bisect Tool and actually made rocks that looked like rocks. (Note To Artists: The Bisect Tool is great, though has some caveats with mesh topography in animations which don’t really matter a lot to our game.) You’ll notice our light towers, bridge lights, and tile work all got some love well before we figured the cliffs out. This was not a straight line of progress, but we’ll talk about those portions later.

I was actually heavily influenced by the cliffs in The Witness. I appreciate the simplicity and elegance of them.

Simplicity and noise reduction in the environment for Bindstone will allow players to focus more on the action on the map.


With our slick new rock sculpting style figured out, I still needed to plan out the ledges water would flow from pool to pool down. The first image on the left was a rough painted concept to reason about how I wanted to actually model the rocks in the middle. This is a more gentle waterfall than the original and actually makes sense with the amount of water flowing into the well.

The second image from the left represents the actual modelling of that drawing, and also our first attempt at applying materials in blender to the map. The third and fourth images are different applications of the vine tool to get some simulated moss. The moss is placeholder and simply gives me a rough idea of how shadows might play over the moss. The final painting of that moss will look very different.


The 3D version of the moss on the waterfall is something that I spent more time on than I’d like to admit. Since the map is ancient and has two large water sources nearby, I really wanted lush greenery to spread inward and swallow the map from either side. Moss near the waterfall was pretty important in getting that look and would bring some much needed color to the waterfall stones.

I discovered the vine tool in blender and thought about how I might be able to use it for the moss. By default the blender vine tool makes ivy style foliage with as much vine as it has leaves. By playing with the parameters quite a bit, however, I could turn up the number of leaves, and adjust their placement so that they would layer more like moss than vines. After getting the leaves right I’d simply delete the vine stem out from under the leaves and with the right texture and a little luck, I might have a quick way of creating moss!

I ended up investing around 4 weeks into this task. I seriously hate moss. There must have been a better way to approach this.

The vine generator tool is controlled indirectly by a series of parameters which feed in to a python script to generate randomly branching vines with randomly placed leaves. This meant you could quickly get something interesting on the screen, but if you wanted something specific on the screen that was a different story.

Moss is usually very compact and very close to surfaces it grows on and I wanted to imitate that. I spent quite a bit of time creating additional vertices on the rock faces to anchor the random vine generator to, generating a vine, not liking it, changing the random seed and regenerating, manually deleting the extra leaves that were too high or too dense, manually deleting the vine stem then moving on to the next one until it was thick and lush. This would sometimes be 50 to 200 unique vines per stone.

The final result is a very useful lighting reference, though the color and the texture is obviously not final. It still needs to be painted over.

Really, each area of this map has been given so much love and attention. I’ve only covered the well and the waterfall/cliffs. Buckle up, because I’m going to explain the evolution of the light towers.


The light source of our map was not decided from the beginning. It was really more of an answer to an implicit decision made with some of the first assets drawn before the map was even concepted. I made the first building assets with a very strong shadow on one side. I put my heart and soul into them, but had not thought about how they would look when flipped. When I first found out they needed to work facing either direction depending on which base they were in I was pretty upset.

So we were faced with a dilemma. Either paint each asset twice with different lighting, remove strong lighting from the existing assets, or make the setting near nighttime and place powerful light sources on each side of the map. Ultimately I really liked the stronger lighting because it added a lot of color variation, so we decided to make our map set at dusk and placed large torches near the waterfall and smaller ones on the bridge. Thus began our journey.

Addressing the iterations above you can see we started with those torches but it didn’t really feel unique enough for Bindstone. We tried moving from basic torches to overgrown watchtowers with bonfires surrounded by branches. It looked a little goofy and we figured it would probably just burn down, so I decided to have more fun with the design.

I found inspiration in The Heart of the Forest by Tuomas Korpi and loved the idea of an organic light source. It was easy to imagine a fantasy world where trees could grow lights, and then imagine those being deliberately planted for more industrial use. I decided to do my own take of that in Bindstone. It makes the map feel more fantasy themed and I could already imagine how the branches might sway in an animation. It was a really exciting portion of the map to play with and it was really fun to design.


Since we’re talking about the light sources on the map, it’s a good time to also discuss the torches on the bridge. The basic torch and fire design as our light source is present in three of the first four images. Looking carefully at the second image you can see two little buckets hastily doodled in. It was clearly a huge priority at the time.

In the third and fourth images I played around with the idea of having the torches look like dragon claws with huge pillars extending down below the bridge for support. It made the map look really busy and structurally it didn’t make sense for a bridge hundreds of meters in the air to have large stone pillars.

In the remaining images you can see the transition to the new organic lights. Originally I played with the idea of overgrown vines with the light orbs growing on them wrapping along the bridge. The concept was these pots used to be torches, but got overgrown and ruined by nature over the years while retaining their original light source purpose. It was a cool concept, but those vines unfortunately looked pretty busy.

The final rendition is also pretty cool, instead of vines overgrowing existing structures we have pots deliberately used for planting light sources, a mix of nature and industry that is pretty fun to think about. In the final image I have the tower tree concept sketches slapped in there temporarily, I used these as reference for the bridge trees to keep them consistent.

A technique I used to sketch the tree concepts was the coil technique that helped me feel out the branches in 3D space before I moved to actually modelling them.


Going back to the light towers, this is a sequence from the original hand painted 2D tower to it’s final 3D design. I heavily referenced the original painting, but sculpted the tree in Blender so that I could accurately break the tower around the branches. This had the added benefit of getting the correct lighting information on the tree as well. I learned a lot by sculpting the trees, the first one was made in a week, the last tree took only 2 days.


Above and on the left we have the final render of the light tower with basic materials and vines. You can see it’s pretty grainy and looks kind of like an old-school RPG.

The painted over version is on the right and despite some unfinished areas of the tree gives a much better picture of the goal for Bindstone’s final paint over. The wavey texture on the stonework will be toned back quite a bit and probably done differently, and the tree bark is incomplete. A lot of the final style is still being sorted out, but it’s exciting to see some of the life from the original 2D painted map breathed back in to the 3D render!


Returning to the torches one last time we can check out the steps involved in making each one. We have a total of 8 on the map, each one is individually sculpted to be unique. After sculpting the 4 main light towers these were actually a breeze and I was able to move very quickly. It’s been important to me from the beginning to keep the whole map feeling like a painting. This means no tiled textures, and no copy pasted assets. There is only one map and I want the whole thing to to read like a traditional painting.

Let’s move on to the next section! The pillars have been on the map since the very beginning, they frame the bases and provide a visual boundary for the game board. Thematically I wanted to close off the area surrounding the well and also make it look more like a sacred place. The pillars act as a wall on our map defining the area the players can operate in.


These are the very first iterations of the pillars all the way up to the final concept. You can see in earlier versions I was actually having quite a bit of fun with the designs. The first designs were vertebrae inspired in their shape, but I wanted to simplify the shapes and remove visual noise. I ended up with a smaller number of simple pillars which worked really well.

These buildings were actually pretty tricky for me because I needed to draft each one individually at each angle. I definitely feel like my perspective was off and later it was confirmed in Blender. This is a perfect example of how working in 3D saves me a lot of time. Instead of having to draft each one, I can build one pillar in 3D and simply rotate it. Before moving to the pillars in 3D, though, let’s take a moment to look at the final 2D version…


I was able to get the pillars to look damaged, but only the first two got attention when it came to detailing. I got to this point and then moved on to other places on the map to try and get the whole painting up to the same level of detail. When working with such a large image as our map it’s hard to know how far to take one particular asset to completion before addressing another part. It feels like many smaller paintings all begging for time, and keeping the whole thing cohesive is an ongoing effort.

Speaking of moving on, it’s that time! Let’s look at the 3D assets for these bad boys.


This pillar on the left was actually the very first thing we sculpted. It feels nostalgic looking at it, but it’s also very familiar because the design of the pillars is deeply integrated with the other buildings on the map. Look at the corners of the light towers and the detailing on the well and you’ll see similar shapes. This was really a huge step in making a consistent visual style and was something sorely lacking in the original 2D assets.

That consistency in our 2D map was lacking and the complexity of the architecture was limited because drafting any intricate architecture was a lot more work. While I could re-use elements of design across structures, the more complex the element, the more the multiplicative cost of using it! With 3D there is a higher degree of re-use possible with less effort.

Looking at the third image above you can see that I red-lined the damage in 2D to get a good sense for composition before actually doing the damage in 3D with the Bool Tool in the fourth image.


Above you can see a more detailed render of the pillars before and after getting their colored materials. The second picture above is actually more busy and less appealing compared to the simplicity of the uncolored render. There is a charm to the monochrome render that makes it look like a toy which gets lost when the gritty textures are applied.

The final look we are after requires colors and textures and the second image is easier to paint over, and so it is a necessary temporary step backwards. It’s always important to understand that each step in the artistic process may not necessarily look better than the one before it in isolation; keeping the final goal in mind is absolutely integral in coming up with a solid piece.

Dallas once said that often it’s only the last 5% of a painting where it really comes together. This is part of what makes art in progress hard to share. This is why concept art looks awesome, but intermediate work in progress of production assets rarely makes it into the art books and instead you simply see the polished final renders.


Above you can see the most up to date version of the pillars. I have painted over the textures to smooth them out. There are a few steps left where I will choose the final color, soften edges, add vines, dust, and more details. I am in the last 5-10% on these pillars, but it is still not quite finished. With that said, I’ll share an often quoted joke Michael shared with me about code which could just as easily apply to any creative process.

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

— Tom Cargill

The last area of the map I’m going to to show and discuss is the tile work. I spent quite a bit of time considering what would look good and a few things really spoke to me about the newest Summoner’s Rift map which can be read about League of Legends developer blog. They had some fantastic observations about visual heirarchy, but one of the most obvious points I will quote here:

“Another concept we keep in mind when pursuing clarity is ‘flow’ – essentially, the art should be a soft visual indicator that subtlety suggests the path. It should clarify game space, not clutter it.”



So, with some really invaluable observations graciously shared from Riot I had a much better understanding of what a map should do. A map should guide the player’s eye, but not dominate the foreground. I started to design arrows in the tile work that clearly communicate, “Your characters march this way!”

The arrow tiles, like the map as a whole, will be darker and less saturated than characters and effects. The edges will be played down and softened with grass and dirt so they do not distract from the action. I want to keep a hierarchy of visuals. The map is the subtle backdrop behind the characters and spells playing across it rather than a dominating force distracting from the action.

The original concept did not include actual tiles, I hadn’t considered the ground carefully until the later variations shown above. For most of the map’s lifespan I knew the rough direction I wanted to go with tiles blended into the dirt and grass for an overgrown aesthetic. The two images to the right are the actually the final designs of the tile.

Fun Fact: The tiles contain a visual Easter Egg. The tile work on one side will have a dragon head and on the other a wolf head. They are symbolic characters which Michael and I relate to.

These are the two tile designs side by side. Between the ears is where the well rests. The nose and eyes act as arrows guiding the player’s eyes during the game. The original final tile designs in 2D are drawn above.


Here we show the 2D designs adopted directly in Blender and meticulously sculpted in 3D. This took a full two weeks to finish, each tile is manually sculpted over the original work, and then tilted or broken in 3D space to create a unique look. Individual vertices were manipulated to ensure repeating shapes were minimized and the tile work really springs to life because of that attention to detail. This was laborious and most of it will be covered with grass and dirt, but the final result is a fantastic base to work from. The final painting will be much smoother and less noisy.


In the middle of the bridge you can also see the wolf and dragon tiles together marking the middle point of the bridge. This is where the arrows of the tiles clash and the clear confrontation between the two sides begins. The characters are meant to be subtle but fun design elements which an average player may not notice immediately.

Details like this have been sprinkled in throughout the map without much expectation to be noticed individually, the hope is that the whole piece reads clearly and facilitates game play while being pleasing to the eye.


There it is! This is the latest version of the Bindstone map! You may notice vines are missing from the right side of the map, this is because that is where the painting is currently in progress. I will be painting them back in by hand later.

I still have a ways to go to paint over this and add back in the painterly feel it originally had, but I now have a solid base to work from!

So, what’s next?

  • I’m currently focused on painting one half of the map. The final map will not be mirrored, and the assets are different in the picture above on either side, but for fast prototyping it will be quick to mirror it in the game engine.
  • Next I will create a parallax backdrop so the map has a proper background in engine.
  • Animations for some of the major assets will be created to give the map more life! Adding particle effects will help a lot too!
  • From there I will complete the other side of the painting.
  • Animating the waterfalls will likely be the last step in this process and should finalize the map!

I’m so excited! In 2017 we will see the completion and animation of Bindstone’s map. This is the only map in the game and since it will be played on Mobile and PC I want it to be as beautiful and unique as possible at various resolutions. When I complete major milestones I’ll post updates on the art pipeline and process, as I said at the beginning, subscribe to the newsletter if you’re interested in updates!

Game Engine Development


It has never been a better time to be an indie game developer.

There are numerous intractably difficult aspects of making any kind of software. Books have been written on the subject, and continue to be. It is an open problem where no formula exists. I am not saying it is easy to be an indie game developer, but certainly this is the best time in history to be one. There are objective reasons for this:

  • Production: High quality, low-cost game engines with fantastic tools for content creation exist. A few of these engines have really only been readily available to individuals in the last few years. A few of these engines have really improved in the last few years to be usable and competitive. Commercial game engines used to be a thing exclusively for big companies.
  • Distribution: Multiple market places exist to launch a game with built in payment platforms and audiences. You can instantly reach an audience of millions if you are featured on any of these stores. As with commercial game engines, market places used to be locked down to publishers who could afford to produce physical media. Now with digital market places any dedicated individual can be competitive in the same space.
  • Promotion: With a mix of incredibly connected social platforms and well attended gaming events, there are more avenues to promotion than ever before. Long gone are the days of TV, Magazine, Radio, and Billboard advertising as the primary methods of getting a message out. You just need a strong message, good presentation, and some luck.
  • Funding: Kickstarter and Indiegogo. If you have an idea that resonates with people, and have put in a lot of effort to spread the word, the infrastructure exists to give supporters the ability to throw money at the screen and have it reach you. This means that you need to essentially self-fund the development process to the point of a demo or at least a really solid presentation, nothing in life is free.

With all of these available tools, it makes sense to leverage them. The truth is that even with this much support available, successful game projects are rare. Only 33% of game projects on Kickstarter get funded. Observing successfully funded Kickstarter video games reveals that only 37% of them deliver. The total number of started indie games vs delivered is impossible to know, many never make it to Kickstarter before being abandoned. It is safe to say that the vast majority of games started never see the light of day.

With this inherent difficulty and low success rate, it makes a lot of sense to make use of an existing game engine. If you are someone interested in starting game development, I highly recommend taking this common-sense advice. I am going to share this advice which haunts me and which has inspired this article. “Make a game, not an engine”.

This is sound advice I’ve heard directed at me before, but which I do not listen to because I am happy with my current direction. It is equal in value to the following advice which I do subscribe to. Keep your project small and well defined.

This would be a boring article if I were to just leave it at that. I’m not here to tell you what to do with your time, though I believe in sharing knowledge and making informed decisions. I have a lot of experience using Unity with C# and believe it is a fantastic tool, but Bindstone has its own C++ engine which is where I have the most fun.

Bindstone has been in development for nearly 3 years. That engine is a work in progress for the last 7 years. The oldest project I made with this engine was in October 4, 2009, you can see it here: Dark Sky Fire. The code base would be difficult to compare in size and quality, and much has been rewritten, but it goes to show how long it takes to make a commercial quality engine. I also have a strong desire to understand everything about game development even when I lean on external libraries for certain features. This is more of a personal quirk than inherent complexity.


A lot of the effort required to develop a custom engine is actually in writing tools. It isn’t enough to make a wicked scene graph with a solid rendering pipeline. Having well integrated collision detection and physics is great. Having good font rendering support and UI is fantastic. Making a solid network layer is key. But none of these individual systems will flesh out a game.

It’s simple when you have a single stage game with limited assets like Tetris or Missile Commander, or if you can create a simple text format to load. Making a level, animation, and UI editor is definitely a project in and of itself. When using Unity or Unreal you immediately have an integrated editor where you can spend most of your time. For indie projects in C++ you have no such luxury, but can make use of things like Spine2D, Cocos CreatorTiled, Overlap2D. Choosing one or a combination of external pre-built editing tools will dramatically increase productivity.

Creating the Bindstone editor was a 10 month project for me with ongoing effort to this day. I leave animations up to Spine2D since skeletal rigging and animations could easily double that time. Unless you are dedicating regular full time hours you can expect a similar experience in tackling your own editor on evenings and weekends. There are only three benefits, so consider that drawback up front.

  1. You have native serialization of your types so are not beholden to maintaining a transformation layer from a general editor’s file format to your own engine.
  2. You have infinite flexibility in the features your editor supports, though the cost is that you have to develop it yourself.
  3. You really exercise your game engine by using it in more projects. Writing an editor in your engine qualifies. For me it really increased the sophistication of my UI earlier than I would have otherwise investigated it.

Tool support is an evolving landscape, when I first looked into it, I feel like the projects I linked above were not as mature. Cocos Creator and Overlap 2D both seem exciting and if I were to start again today I think I’d seriously investigate those options in addition to my existing Spine2D support.


Serialization is another integral and often overlooked aspect of game engine development. Before Bindstone I had not considered this aspect seriously, but now that I have, there is no question that it needs ubiquitous bulletproof support throughout your code. Serialization is at the heart of save game formats, UI/level/game assets, configuration details, and network interaction.

Often JSON is chosen as the go-to standard for intermediate formats, there is good reason for this. It’s human readable/editable and ubiquitous. The only drawback is deserialization speed which can add up. The alternatives for save formats are often less convenient, which is a good reason not to start with something like google’s protobuf, or msgpack. But it’s a great idea to design with this in mind by selecting something other than a raw json library.

Bindstone uses cereal which has an interchangeable input/output formats. This is good because we make use of a portable binary format for real time network message parsing and for save game format JSON is fine and less fragile.

It took 2 months of evening and weekend effort to robustly integrate and debug serialization on the scene graph and component system that drives Bindstone. This was non-trivial effort which informed several bug fixes and improvements in cereal itself.


Supporting multiple platforms requires a concentrated effort all the way from the beginning. Before you integrate a third party library you need to know how it will behave on all target platforms, and how to build and include it in your project. This easily bleeds into build system considerations which are abysmally boring to think about, but equally important. C++ is incredibly primitive in the area of build system and package management, Visual Studio supposedly supports native iOS and Android development now, but nobody fucking knows how with SDL.

This leaves you with either CMake, Conan, or just setting it up separate project files for each platform and maintaining them by hand. This is something I have yet to tackle that could easy be a couple hard weeks of full time effort.

All of this is pretty painless if you go with something like Unity, it has excellent one-button multi-platform build options.

This is just a taste of what people are talking about when they give you the advice to build games rather than engines. There is deep wisdom in those words. There is deep wisdom and also, deep intentional, blissful ignorance. It comes from a place of not needing to be knowledgeable about those nitty gritty details to launch a game in today’s age of game development.


Ignorance is bliss, but knowledge is power.

This stuff has made me a more competent developer. There is great pride in being able to draw from full-stack engine building experience when tackling problems in game code. Plus, it’s just fun working on certain things from different perspectives.

This is a non-comprehensive list of things that I would never have been exposed to in depth without building and maintaining Bindstone’s engine. Many of these things I would have only brushed against casually if not for this exercise, any one of these I could write an article on:

  • Multithreaded particle system
  • Scene graph design and component architecture
  • Network programming from the socket layer up
  • Box2D and Spine2D integration
  • GUI implementation
  • Maintaining a 7 year old code base and keeping it modern
  • Pathfinding algorithms in detail
  • Genuine understanding of game and engine code boundaries
  • Thread pool
  • Signal/Slot implementation
  • Script integration
  • Serialization in depth

By understanding multiple aspects of engine development in depth and breadth you gain a rich appreciation for systems and interface design in code. Not just solving individual problems as they come up, but for their integration with the system as a whole. Learning to develop robust and beautiful code is an art only achieved through practice.

A game engine can be a fantastic project with which to learn and practice, there is intrinsic value for this reason alone. If you have read this far and are in the process of developing your own game engine, or are planning on it despite the time commitment trade-offs I will impart a few humble suggestions. These are not usually things you will hear, because usually people are too busy trying to dissuade and don’t get much past that.

  • Develop your game engine alongside an actual game, actually use it. Working in a vacuum for too long leads to blind-spots which are inefficient to patch up later and may result in poor decisions revealed months late.Bindstone’s engine emerged from the process of writing three small games (Dark Sky Fire, Star Collector, and an unlisted Snake clone) several years ago and refining the code base significantly. I’ve written some platformer code and gotten it to work with Box2D in an unreleased game in pretty early stages. Bindstone, of course, would make for 5 total projects, 3 which have been finished.
  • Limit the development of “speculative features”. If you don’t plan on immediately using a new feature you are developing for your engine, do not do it. I would go so far as to say, implement it in a game-specific way if you must, and then refactor and develop a clean game-agnostic interface before allowing it to propagate to too many places. You can easily find yourself well off the beaten path with no game release in sight if you don’t prioritize game-required features over wishlist items that sound fun.
  • Avoid prolific global state from the start. Singletons are not your friend (an answer/article I wrote some time ago). They are hard to remove later, and if you are developing your own engine, you really have full stack control over your architecture.

I hope this helps you in your travels. If you want to get future updates about Bindstone please subscribe!

Philosophy of Bindstone


Bindstone is a real time competitive game that you can play on your phone or on your computer. It is a game you can play casually if that is your inclination, but which encourages learning and mastery. It has been in development for over 2 years.

It can most succinctly be described as a member of the genre “Tug of War” defined by Castle Fight and later refined by Nexus Wars. These games pit two teams (either one or two players each) against each other on opposing sides of a map. Each team has a base, which, if destroyed, signals the end of the match and a loss for the team overrun. Each player can build structures which regularly spawn non-controllable allied units of different kinds (depending on the building). The units walk down the lane towards the opponent’s base and attack enemy units or use special abilities according to their individual AI.

Tug of war games have a sort of back and forth nature by which you choose units to counter your opponent and attempt to over-run their defenses. When you are doing well, the lane pushes towards their base, when you are being countered it can swing back towards you. It is pure strategy of the build order, reaction to the enemy strategy, and management of resources balancing late and early game goals which defines a good player.

Bindstone is similar to other games in its genre in many respects, and different in as many others. We are not making a clone.

League of Legends draws heavy influence from the original Warcraft 3 map DOTA, with an emphasis on streamlined gameplay and additional objective depth. It is with this spirit that Bindstone seeks to streamline and improve upon its genre, while also migrating to mobile.

A typical match may play out in this fashion:

  1. Before the game even begins, you customize your strategy by selecting 8 buildings in the same way you select your champion in a MOBA.
  2. Each building will start inactive on your side of the map around your goal “well”. Your buildings will not be attacked by enemy units.
  3. You and your opponent start with 100 mana (in game currency), as time passes that mana passively increases based on your income. Building upgrades can increase this passive income.
  4. You can spend mana to activate buildings. Activated buildings typically spawn units on a set interval, but each building has a unique function. Some may affect economy, or provide buffs, or cast spells instead.
  5. Once active, two additional upgrades for that building become available; you can only choose to invest in one. Upgrading a second time will spawn additional, or more powerful units.
  6. As buildings spawn units, and units fight against each-other, inevitably they will reach their goal. When a unit reaches an enemy well it will descend (leaving the playing field) and deal damage to the well’s owner.
  7. When enough of your units enter the enemy well you win! The round ends, the two players go their separate ways. Your account gets credited with experience, and you can tune your strategy and play again!


I want to end with a ramble about monetization because I think mobile gaming is unfortunately synonymous with some frankly shitty business practices.

We’re a humble two person indie team.

Bindstone is a game without pay to win mechanics. You cannot buy stats or power-ups. Your Void building will be identical to every other person’s Void building. Like chess pieces, a pawn is a pawn, a knight is a knight. They do not level up or gain experience, they do not fuse. There are still collection elements, but the game itself is meant to be balanced such that you can play the weekly available buildings on rotation and still succeed at the highest level. You will not be handicapped or enhanced by paying money.

You can pay for visual upgrades to your buildings (skins). You can pay to permanently add a building to your collection, but you can also permanently unlock every building through regular play in a reasonable amount of time.

All too often when playing mobile games players are squeezed for money at the most frustrating points during gameplay. In decoration games this is often in the form of paying to advance a timer, or skip it entirely. Sometimes you are forced to purchase lives or wait for them to refill. Sometimes it’s nearly mandatory spamming of Facebook friends to progress.

These kinds of dissatisfying payment points are called “friction” and are ruthlessly balanced behind the scenes to be just annoying enough to make you consider paying, but hopefully not annoying enough to drive you to quit. There are entire network infrastructures and data scientists employed to ensure the level of player dissatisfaction is more helpful than harmful to the bottom line.

Bindstone represents our desire to present a game without artificially annoying friction. We hope to strike a good balance between funding our efforts, keeping servers up and running, and entertaining our players! Bindstone should be a game that people feel like sharing on their own rather than because you can’t play until you “message 10 friends about us”.

I want players to feel delight when they buy a building, or a skin. It should feel like buying a toy.

So that is the ambition of Bindstone. We have months of work to go before a demo. In the interim you can expect updates and game development articles on this site. If you’re excited about this game, please join our mailing list for exclusive beta access, skins, and details about our upcoming Kickstarter.