Bindstone Title Theme

Hey guys! Composer for Bindstone here. So happy to finally meet all of you through the digital space we call the internet!

My name is Monish Corona, and I’ve been composing music for about 10 years, and have been composing game music for 5 years now. I met Michael and Jai about a year ago, and we’ve become pretty good friends since! I actually just recently joined on to do music for Bindstone, and I’m having a blast. I feel incredibly honored to be a part of it!

Anyways, enough about myself, let’s talk about the main theme. Give it a listen!

In this blog post, I’m going to discuss the creative process that drove the making of Bindstone’s Title Theme step by step. Everyone’s creative process is different, and this is especially true when it comes to making music due to the many different genres. Each genre comes with different instrumental requirements and methods of working with and thinking about sound.

I really tried going for a fantasy type vibe with this. I tried to stay away from more modern instrument such as synths and guitars. Before starting a composition I like to try to take some time to look at the art or designs and concepts for what I’m working on (if it’s available of course.) When I saw Jai’s art I thought the best word to describe it was: beautiful.

The style resonated with me and something about it inspired me to make something with a kind of waltz feel.

So, I’m kind of weird in the sense that I usually like to actually create piano sketches of my compositions before orchestrating it. Of course, you can’t do this all the time as it depends on the kind of music; but this piano sketch really helped convey the main ideas I had for this piece. Most composers like to actually create piano versions of their songs after making an orchestral version of the songs.

Here’s the actual piano sketch I did for the main theme:

The reason why I like to create piano versions of compositions before hand (again if I can) is because I find it is an effective way to write out memorable melodies. By playing the piano version I have enough expressiveness to construct a strong melody and it is easy to modify before adding additional instruments while it is in early concept phases.

After this I worked on creating the strings around the melodies, and first draft went a little something like this:

During this first draft, I decided to keep the waltz feel that was described earlier. I also decided to keep the keyboard as a primary instrument because there were lots of little nice touches I thought could be added. A great example of this would be the arpeggios that play at the 45 second mark of the song.

I found that having it replay the melody with double octaves just helped the piece have more of that fantastical feel that I really enjoyed. Though this draft turned out really great, I felt there were some elements missing. For example, one of the things that Michael and I thought could use some work were the first few notes. It felt a bit too dark and dreary.

Michael described his vision for the title music in this way:

“When the player opens Bindstone, they are getting ready to queue up and win some games.

It should be bright and exciting, we want players to think: 

Alright, I can’t wait to play this game, let’s kick some ass!

With that in mind I set out to make this vision reality!

I added a very fantastical intro on the piano. At first I was going to use a lute or violin, but I listened to each instrument individually, and something about it just felt odd, and it felt like there were too many strings.

Piano seemed to be a nice fit for the intro since a piano was going to appear later on in the piece as well. It kind of gave the listener a sneak peak of what was to come later on instead of just having a piano come out of nowhere later on. I also made some strings a little more apparent in the version as well, but for some reason, the strings didn’t feel complete towards the end.

At first I was trying to add a few other elements, but a lot of what I did sounded forced. At some point, I was going to add tubas towards the end. It was a weird choice, and I was using stock Logic Pro X Tubas as well, so it didn’t blend well with the other instruments I had in the piece. I decided to actually change the ending strings almost entirely. The strings I did change were the Bass and Cellos, and the end was result was the finished piece!

Of course, there was a mixing process involved, and other various small touches in terms of exporting what not, but after all is said and done, the main theme that you heard in the beginning of this post isn’t too different from the second last iteration of the song!

I’m glad I was able to take you through this process. I tried not to delve too deep into technical musical terms such as key signatures (though this theme is in D Minor, hint hint), scale degrees, and so on. My hope was that anyone interested in Bindstone can appreciate a bit of the process.

With that said, I didn’t do anything too crazy in terms of musical ideas and I believe the not every piece of music has to be extremely complex. Sometimes, a simple approach is the best thing for a piece. Especially when it’s a piece that is supposed to just be enjoyed and inspire awaiting players to have a great time in their new favorite game!

The next piece I’m working actually does have a some more subtle and complex elements however; and it’s a piece that benefits from those complexities. I look forward to talking to you guys about the next piece in a future blog post! As for now, I’m going to sign off, and continue working on this next piece. I can’t wait to share it with you!


Musically yours,

Monish Corona

Stylish Waterfalls: The Journey [1/2]

In our last art update I outlined the creative steps that went into the production of the Bindstone map.  I finished off with the next steps, and in that list as a final bullet point I boldly and confidently stated, “animating the waterfalls will likely be the last step in this process and should finalize the map!”

Well, the map isn’t final. The waterfalls are though! Let’s talk about it.

First let’s break down what’s in our waterfall. Rocks, moss, water (river/stream/pool/whirlpool), and lily pads are a pretty good summary of the basic parts. You can see a screenshot of the final look for this stuff below. (Note: the buildings, tile, light trees, and stone outside the waterfall path are all works in progress and not complete.)

My 3D pipeline was already complete and the general look for the waterfall stones had already been defined structurally based on reference. I’ve described this in detail in the previous article, but essentially there are two primary styles of stones in the waterfall area. There are organic rounded shelves of the waterfall, and more blocky and chiseled stones. I’m going to pick up where the previous article left off and discuss the process of working off those 3D renders and taking the asset to completion in Photoshop.

By the time I got to the waterfall area, I had already gone through and smoothed the rest of the map. The process for smoothing was largely a mechanical one where I paint over the original rough 3D render and preserve the lighting information. This is to provide a uniform paint layer to work from, but I have not introduced many details or textures at this point. I was saving the waterfall and rock section for last, but by the time I got to it I decided it would be good to just paint the final details of that section all in one pass.

So let’s rock out and look at what goes into a stone!

The rocks are the very first area of the map that I was beginning the final detailing of. There was something kind of high pressure about moving forward on this task knowing I was aiming for a final asset. There would be no further buffer of process between the result of this and what would be seen in the game. This was essentially the beginning of the end!

I actually stressed myself out because I really wanted it to look great, but didn’t know exactly how to get there. I rallied and I spent a while researching and studying rocks in other games. My favorite and most influential resource, however, was a tutorial by SephirothArt available on youtube and in an extended format for sale on his gumroad.

Seph’s tutorials were immensely helpful in getting me started. I decided to try painting 5 stones completely separate from the 3D renders to get a good feel for the overall process. I ended up with 6.

I feel like I did a good job with these practice stones. Naturally, there were days where I was unhappy with the results of my practice, some came out better than others. I also took tentative steps to try to apply these results to the 3D render but was really unhappy with the early attempts and kept coming back to my practice. You can see these practice stones in order of completion below.

You can see a lot of golds and reds painted on the stones to make them stand out from the grass. I mixed opposing colors and added the reflected green tones to finish the look. I was inspired by Seph’s tutorial, but used my own colors. You can see some variations on the texture with some rougher areas and different types of shading. I was experimenting to see what worked.

While this let me play without constraint and get a feel for how to achieve a painterly stone texture, there was still some learning to do. The tutorial stones all had a strong light-source which made shadows and contrast pop out a lot. They also had no constraint over the original shape of the rocks as they were all invented fully in 2D. I still had to figure out how to apply this as a paint-over technique in the context of my existing map with existing rock formations.

On the actual map the lighting is much more subtle and the rock shapes are larger. Color selection had to be more subtle and was difficult to pull off without losing the style. Some of my practice applying this style to the existing render is below, but honestly my first attempts were complete disappointments.

I’m not happy with either of the examples of paint-over attempts below. They looked too much like the 3D render and the 2D tutorial method didn’t really translate as well as I had hoped. I kept re-visiting my independent practice stones from the tutorial and kept painting more until I decided I had spent enough time practicing and needed to move on. My confidence was not very high, but I felt a time pressure and was worried about losing steam on the task.

This practice period lasted a couple weeks and I decided it was time to move forward. I was feeling hesitant, but also did not want to use excessive practice as a procrastination tool. I felt like I had enough experience to do a good job so I just buckled down and started.

I began in the middle near the lower area that had really strong light on it to ease into the task. I was able to finish about one cluster each day. You can see a representation of 4 clusters below representing 4 days of work.

To achieve the final look I start by smoothing the stone texture in the 3D render. This is an extra step not present in the original tutorials because the tutorial stones were built from scratch. My base layer was a lot messier and more detailed and simplifying the colors was a necessary first step. This is done by sampling color from the 3D render and painting over that render with a smooth brush. Sample, paint, repeat.

After the initial smoothing step I increase the saturation by 60% in Photoshop. It expands the color palette and gives a more dynamic color range.

The brushes I used were the same ones used in Seph’s tutorials (available as part of the isometric stones tutorial pack). I would smooth the faces with a round brush, then switch to chalk type brush to add a rougher texture. I carved out grooves in the stone to break up the faces and edges to obscure the original 3D geometry a bit and make the stones appear more natural in shape.

The final detailing was the scratches, marks, and highlights to the stones which dramatically made them look more authentic and weather worn.

Finally, I adjusted brightness and contrast and increased both by 12. It gives the stones a small visual kick that helps a lot. This is what the stones look like before and after I finish with each section. I am trying to get the 3D render to look as much like a 2D painting as possible, that’s the whole point of painting over the render in the first place.

It took constant focus to get the simplified natural look I was trying to achieve. Some days I was better at this than others. If my mind was wandering I could easily slip into making the same repetitive brush patterns that went against the shape of the stone. My hand would tend to create circular hook shaped patterns if I lost focus. I paid a lot of attention to the curves, faces, edges, and lighting. Working from light to dark, bottom to top helped keep the whole piece consistent.

The closeups above show details and brush strokes coming out well with various lighting conditions.

The reason I took this part of the map to completion first is because it is at the edge of the map and is not where the player will be usually looking. By working on this less critical area before finalizing the rest of the painting I could gain valuable practice painting in the final style with less pressure on the results. I’m proud of how it came out.

With the rocks finished I decided to just dive right into painting the pools.

It actually went really smoothly and took very little practice to get right, I feel like the effort I put into painting the rocks translated really well and it felt good to breeze through this task!

I started by smoothing out the blue as it was already there from the 3D render (we had a partially transparent blue waterline placed in each pool.) I used the same chalk brush on the stone walls and floor and brought in darker blues depending on the depth of the pool. I made all the edges softer to give the appearance of being submerged. I added small clusters of stones resting under water and carved out larger cracks on the bottom of the pool. I am actually really happy with how they turned out. I think they look great!

At this point all the stones and pools took roughly 3 weeks of work not counting my practice time. With all the pools complete I had one remaining pool larger than the rest. The bottom of the waterfall where the streams all join to become a river flowing directly into the well. This was the last water-submerged area that I needed to paint over.

I knocked it out on a single Sunday evening. I smoothed the whole area and painted the larger stones, then I slowly added little stones that were clustered together and made the river bed. I was so happy it just took a single really productive evening to complete since I was planning on spending few days on that area! Below are some before/after pictures of the final river pool texture.

You can see the panels of the inside of the river actually are extensions of the tile from the 3D model which just happens to intersect with the river. Because I designed the tile in 2D and Michael did the 3D sculpting of them I didn’t realize this visual artifact was unintentional but I really liked the look of it. So I kept the panels and painted them as intentional walls inside of the river using a similar technique to the stones.

Because the 3D render of those walls was unintentional some of the tiles were different heights and dropped down awkward distances. There was also an early decision to have a large broken piece of the well in the stream, but in an effort to visually simplify the area I decided to eliminate it. These changes required some freehand painting to erase them.

You can see the progress below:

Everything came together really clean. At this point I have the stones and pools complete!

It’s time to go with the flow and draw some waterfall streams.

The technical work involved in stream animations will be described in part 2 by Michael. He was working on the technology required to bring this to life alongside my own work. At this point he had a working concept and idea of how to integrate my streams in the game engine. What he needed at this point was a painted guideline of the streams he could use as a tracing guide in our engine and animate.

With this in mind I spent a couple days figuring out how and where precisely I wanted those waterfall streams to flow. I paid special attention to the shapes of the rocks and how water would flow over them naturally. You can see it took an intermediate step where I had highlights to help visualize the final look before revising and flattening the water to provide a simple outline for animation in the game engine.

With those waterfalls painted and bundled up for Michael to integrate in the game it was time to start the next task. Moss. I have said it before, but…

I seriously hate moss. There’s no pun here. Moss just sucks ass.

Part of the reason I hate moss, is that it is hard to paint simply without making the texture distressingly busy. It is also the final layer of color on the waterfall which means there’s no hiding any mistakes here. It needs to look good. I have studied how other artists do moss and it is usually just the silhouette of it with hints of detail. There’s a beauty to abstract detail, but it is hard to get right. I felt very hesitant to cover up all the beautiful stonework I had painted with something that didn’t stand up to the same bar of quality.

I had a hard time finding a brush to do it in. Then because I wasn’t fully invested in covering up the stones I kept making the patches of moss too small even though Michael had suggested it should grow larger and cover more and I agreed with him. It was hard to bring myself to do it. I was starting to feel a bit of a mounting time pressure to solve this visual issue as well. This is entirely internal, of course, but I was already pretty happy with how the waterfalls were coming out and I didn’t want to over-invest time in the outside edges of the map.

So, as I often do when in doubt, I spent some time studying reference material. I looked at a bunch of art and nature photos of waterfalls and moss. If you look at it up close, it actually looks like really tiny pine needles. There are different variants, but it grows in thick patches and underneath it is actually a deep red in most cases. So it has these really contrasting colors to it naturally which make it more yellow, although it can be vibrant red or deep green.

Realizing it wasn’t just flat greens that made up moss really helped, but even knowing this and trying a few methods I wasn’t satisfied with the results. I tried several methods, Michael liked the second and third images below, all of them are incomplete attempts to try different styles. Ultimately I needed to think it over a bit.

I wanted to add more details and growth to the waterfall area beyond moss, and had specifically considered adding lily pads.

So I padded the time between finishing the moss!

Serendipitously during our walk to work Michael noticed some lily pads growing in the fountain in front of the Santa Monica City Hall. We ran over and snapped a ton of pictures to use as reference and it gave me new energy and space to mull over the moss.

Over the next couple days I painted about 9 different lily pads in total. The reference photos were fantastically helpful as I realized lily pads are not all green. The smaller ones seem to sometimes start out brown/red and it is only as they grow larger that they turn green. The flowers bud from underneath the water and rise out to bloom on the surface.

This was a really refreshing bit of painting and after painting a few re-usable pads and lily’s I was able to mix and match them and arrange several clusters to position around the river and in the pools. I adjusted lighting where necessary and am really happy with the results!

Michael took these and added them to the engine complete with a subtle bobbing animation and we’ll be covering that in part 2 of this article when he digs into the technical details of animating and integrating assets into the Bindstone engine.

After I completed the lily pads, I returned to the moss and was comfortable enough to do what needed doing. I decided to lay down larger clumps of moss and focus more on the piece as a whole instead of agonizing about the stones I was covering so much. I laid them out very similarly to how I laid down the water streams. The moss should follow the stone’s natural shape and contours that I had originally painted.

This more confident approach worked out really well. When I turned on the water path layer, it interacted with the moss layer really well. I spent time painting down a dark crimson base color and painted a lighter green over the top. Tackling this in a multi-layered approach with different colors helped bring a depth and detail to the final result that I think reads really well.

I did the base color with a flat brush and I ended up using a leaf brush scaled down and modified to create a fluffy moss texture for the highlight green color. After laying down highlights I also soften the edges of the base layer with an eraser to finish the paint layer.

Final color correction to the moss layers finished the look. I increased the brightness and contrast of the moss layers in Photoshop and did some slight color balance changes to push the colors and shadows. I also applied a gradient over the moss layer which bumped the color closer to lights and added a fade as the light tapers off to a more blue/violet at the top of the waterfall.

This whole process took a couple weeks.

To give a little sense of perspective of where the 3D render started and the painting ended it helps to see them side by side. Here we have the 3D render on the left, the rocks/pools in the middle, and the moss on the far right.

Finally with effects you can see the full thing together!

This whole adventure leaves us with one final asset before I turn the mic over to Michael for some real talk about technical effects and shaders.

Try not to get dizzy as we take the plunge into the final section of this article!

That final asset is at the heart of our map’s focus and is actually the center of the Bindstone well! The well is the goal that creatures leap into in order to score points for your team. We wanted an interesting effect for the water flowing in a spiral and this called for a whirlpool texture!

This was the whirlpool image that I heavily referenced for our whirlpool texture. Thanks google image search!

This was a heavily referenced hand painted asset that took a couple days to paint. The little dots above the swirl on the left are particle effects which Michael will describe as well, but the actual swirl is a faded/spun version of the image on the right. I free hand painted this from the reference above (no tracing). I made artistic changes in certain areas to make it a bit more dramatic. Also, some areas have been shifted around to fit better into a smaller circle. I haven’t completed it just yet, only because it looks just fine in the engine as is. I will be completing this at a later time if I reuse this same texture for other assets in the game.

With that said, I’ll go ahead and leave you with a video showing all of this in motion. Join us in a couple weeks for part 2 and an in-depth discussion about how all of this stuff got animated and integrated in our game engine! There will be code for those interested!

Don’t forget to subscribe to our mailing list for major updates and beta keys when we have them! Like and subscribe on Youtube as we post video updates on our channel from time to time!

Now lean back and enjoy!

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.