Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Developing Skirmish Line: A Tale of Two Indie Developers

For the past 2 years, I have been working on a game called Skirmish Line, inspired by the classic flash game: Mud and Blood 2. This is not a post-mortem about for the game, but rather a cautionary tale about developing games.

Tony Hua, Blogger

March 14, 2018

19 Min Read

For the past 2 years, I have been working on a little game called Skirmish Line, inspired by the classic flash game: Mud and Blood 2. This is my first commercial title and my first foray into the indie games scene as a mostly solo developer. I wanted to take the time to write down my thoughts while they are still fresh, and I hope these notes will help other aspiring developers.

Before I begin, I should say that I'm not very keen on the idea that you will be successful by simply avoiding mistakes. Very often, I find making mistakes is what lets us grow. So rather than labeling failures in the project as mistakes, I will call them observations. They are things you should look out for and think about but are sometimes unavoidable. Live and learn. Don't be afraid to dive into something and experience it yourself.

I graduated from college in 2015 with twin degrees in Economics and Applied Mathematics. For most of my college career, I was preparing myself for graduate school in Economics, having developed an interest in the field. But during my final year of college, I changed my mind. While my primary focus had been to get into graduate school and conduct research, I was also a modder on the side, working on the now defunct persistency mod for Company of Heroes, Operation Market Garden (OMGMod), as a designer and balancer. We had just released a major update for the mod, and one of my fellow modder suggested we try making games for a living. In truth, I felt a much greater sense of accomplishment working on OMGMod than I ever did with any research paper or regression analysis.

So I gave in to the siren song of gamedev and formed a small team with my modding friend, and he brought on a few of his friends. Our first and only project was Rocketman, a mobile Unity game about directing the eponymous hero, Rocketman, into space while evading asteroids and other obstacles. There were 5 of us, and I was responsible for the game's UI while sound effects, art, and programming was handled by the other four. This project did not go well.

There were probably a lot of reasons why Rocketman failed. For starters, we had no version control, which meant it was a huge pain whenever we merged our project builds. Ideas were discussed, agreed upon, but never implemented. But more importantly, the motivation for the project petered out after a couple of months. We talked less and less about the project until it became clear to me that it was going nowhere.

Starting Over Again

I was determined and very stubborn, so I wanted to give game development another shot. So after ranting about the project to a friend, who was a freelancer programmer, and he suggested to me that we tried working on a game together. I had the idea of making a mobile version of the popular flash game, Mud and Blood 2, and this would later become Skirmish Line. My friend built a working prototype, and we contracted Clark, the artist who worked on Rocketman.

I would love to say that the project went off without a hitch. But even at the start, there were problems. My friend was an experienced programmer, having worked on e-commerce websites and other projects for a living, and I had a semester of Java programming, along with some high level programming for various software suites like Matlab or Stata. We had a sort of verbal agreement that I would serve primarily as the designer and handle the UI while he focused on the programming. As with most projects, the initial stages are very heavy on the programming, and my friend felt that I wasn't doing my fair share of the work and pushed me to try some of the programming. So I wrote a few classes and methods, at a painfully slow rate, encountering basic errors such as null reference errors, which I simply did not understand at the time.

Observation #1

When partnering up in small teams, try to have either similar skill levels when working in the same field, e.g. be about as competent a programmer as the other programmers, or have a demonstrable skill the other partner does not have, such as programming vs art. In this particular case, my strength was in designing and balancing a game, which isn't something that is really demonstrable until a project matures. Dedicated designers are really a luxury of big studios, where multiple projects can be run, allowing designers to be busy while the core programming is done on a newer project.

After a few weeks, I began modifying existing code, which triggered a second conflict with my partner. Most programmers have their own idea of organization and ideas for the codebase. So when you have multiple programmers, ideas will start clashing. My partner was not happy about the modification of his code but kept quiet about it until I brought the subject up.

Observation #2

Establish common ground for how to handle the code base. Style is important, and coders can be very protective of their work. Spend some time before you begin coding in earnest to establish procedures.

After our disputes over modifying code, I avoided touching code written by my partner. Rather, I would either ask my partner to do the modifications or reference written notes. Compounding this inefficiency was the implementation of features or mechanics that were not agreed on or discussed. The truth is, the programmer dictates what actually goes into a project. And my partner had begun implementing things we didn't discuss. Eventually this sparkled another disagreement, as the project's design began diverging.

Observation #3

Programming is an integral part of a game's design. In theory, you can separate the ideas, but in practice, the way code is structured is a hard constraint on design. It is my personal belief that you cannot realistically have a programmer not be a designer. 

After a little less than 2 months of development, my partner stopping working on the project to continue work on his personal project, unrelated to game development. Taking a brief aside, it's worth discussing that game development involves people, and people have eccentricities. For instance, my partner on the project insists on using an encryption program whenever we pass potentially sensitive information. This meant every time we wanted to share certain info, such as our address or bank account numbers over Steam, we would need to write the information down, encrypt it, send the key over, then decrypt it, a process I felt was unnecessary but I had nonetheless agreed to do. But by far, the biggest issue was my partner's habit of avoiding confrontation. In every disagreement we have had up to this point, my partner's response to a disagreement had been to be quiet about it or to ostensibly agree, only to disagree later. This was a reoccurring issue over the course of the project. The sudden break was my partner's response to the culmination of disagreements we have had, although he would not confirm it until 3 months later.

Over these 3 months, I would continue development on my own, implementing features while learning C# and Unity. During this period, I developed my core understanding for syntax and how to navigate through Unity.

Observation #4

Do not be afraid of learning how to program. It takes time and a lot of effort, but it is a skill like any other. There are plenty of resources online that can help.

My partner returned mid-April. During this period we discussed the issues we had before: the differences in programming skill, the disagreements on designing the game, and his sudden and extended absence. At this point, my partner was heavily invested on his personal project and wanted to concentrate on that. He agreed to work on the project nonetheless, asking me to reserve certain tasks for him. After about a week of work, he disappeared again then returned for another week of work at the onset of June, before leaving the project for another 4 months until October. We kept limited communication during this period, as we researched and prepared the paperwork for a company.

We officially formed a LLC in late August of 2016. Up to this point, I had been financing the project out of my own pockets, with the promise that my partner would provide his share of the capital, something I overlooked as we had been operating on a shoestring budget for the game. After the formation of the company, my partner contributed about 75% of his share of the capital (to match my contributions to date), again with the promise that he would pay the remaining 25% later. He also insisted that I no longer add any more money onto the project, as that would require him to contribute more to maintain our equal capital contributions later on, and he had no desires to put anymore money into the company.

We had a couple of major disagreements over where to take the project. My partner wanted to release the game on mobile devices while I felt it was more prudent to attempt a release on PC/Mac/Linux first. My partner also wanted to release the game as soon as possible, while releasing subsequent versions later after assessing marketability and gauging feedback. Again, I disagreed, as I felt that it would be poor business practice and that a string of poor releases would damage the potential marketability of the game in the future. I felt that we could lead up to proper full release by getting feedback through smaller distribution platforms such as gamejolt or itch.io.

In both of our initial discussions on these subject matters, my partner had ostensibly agreed to my positions. After months without touching the project itself, I asked my partner to contribute to the codebase once more, as the project was being bottlenecked by tasks assigned to him. At this point, my partner unveiled his true opinion on the project, his frustrations over the business plan and our earlier disagreements over the design of the game. I offered a buyout for his share of the company, offering to cover his capital contribution, along with a premium for his work. My partner refused the offer, instead we attempted once again to talk through our issues.

It is the start of October 2016 by this point. My partner worked again for a few days, before returning to his personal project. He would not return to working on the project until late December. At this point, there was a clear pattern. Roughly a week of work followed by months of absence. My partner did not care for the project, but he did not want to part with the idea of the company either. I was getting burned out on the project myself, partly from having worked on the project for nearly a year and from the disagreements with my partner.

Between December 2016 and January 2017, my partner paid the remaining 25% of the capital contribution and worked again for a little less than 2 weeks. At this point, I wanted to share a working alpha of the game with the Mud and Blood community. This was a very anxious period for me, as I was afraid that the community would respond negatively to our game. We discussed possibly avoiding the community altogether, but ultimately I felt that it was better to approach the community itself than to let them approach us. In truth, I don't know what my partner's opinion on the matter was at this point. While he seemed to agree, I could no longer trust his opinion, as it seemed so inconsistent.

Sharing the game was the single best decision we ever made. The community was very responsive and provided us with a very motivated group of playtesters. For the next few months, from mid-January until July, I was the most productive I had ever been with the project. By this point, I had a decent understanding of how to program, and the constant feedback was integral to the game's development. During these 7 months, I also made the decision to do my partner's share of the work, as he was absent for its development during this entire period, and I felt that I could no longer wait on his behalf.

Observation #5

Player feedback is absolutely vital. This is what truly dictates the path of development. Design documents can only get you so far. In addition, there is a huge motivational factor when you watch people play your games.

By February, I ran into another problem: the bank account was nearing empty. Development had expended nearly the entire $5000 in capital we had set aside. As my partner had stated that he would no longer contribute any money back in August of 2016, I was unable to raise another round of funding. At this point, I made the decision to finance the rest of the project on my own. The plan was to put in additional contributions but to continue to treat royalty payments as a 50/50 split later on.

At some point during March, I was confiding to a friend about the situation in the company. About a week later, my partner found out through our mutual friend. The secret was out, and my partner was not happy. Yet, he could not be mad either, as he was going to get his split of the revenue regardless, only that he felt it was a betrayal of trust. He stipulated that I no longer add funds to the company account, and that future development would depend on incoming revenue.

By July, I had become very unhappy with the way the company was proceeding. With dwindling funds and an inability to add more, I made the choice to offer another buyout offer. My partner was very resistant to the idea, demanding a premium of $5000 plus a reimbursement of his capital contribution, amounting to $7300, of which I was willing to pay at the time. Nonetheless, my partner asked me to reconsider, and I reluctantly agreed. In return, he would match the contributions I had put in since, another $1100, which helped funded us through the rest of the summer.

For the first time in 2017 since January, my partner worked on the project again, for about 3 weeks, from late July to mid-August. Our plan was to release the game in Steam Early Access during the summer, before the rush of triple A game releases in the fall. Here, we disagreed again where to release the game. My partner was afraid of pirating and did not want to release on DRM-free platforms such as itch.io, where the executable can simply be repackaged and downloaded. I took the stance that pirating was impossible to stop, and that we were limiting our potential market. But I nonetheless agreed to release on Steam only.

Content development slowed during the summer, as we had very limited funds to add new content. We concentrated our efforts to getting the game ready for Steam, adding key bindings, Steam achievements, and fixing bugs. We also made the decision to stop releasing public alphas to the Mud and Blood community, as there was a fear that people would simply download the free alpha available instead of buying the game.

I eventually found out that Unity games did not abid by Steam DRM. Yet my partner was insistent on releasing on Steam only, citing a custom built DRM system that would at least require Steam to be online before the game would launch, and that he would implement this system himself. To this date, this custom DRM has not been implemented.

Preparing the Steam store page took longer than expected. Our greatest setback was the lack of a trailer. After checking with various trailer makers, none were within our budget. We ultimately settled on having a friend of mine, a former shoutcaster for OMGMod, produce a trailer for us. Unfortunately, this delayed our release until late October.

Observation #6

Your trailer on the Steam store page is the single most important element when it comes to marketability by a massive margin. For the vast, vast majority of customers, this is what determines if they will buy your game or not.

We spent about a month sitting on the Coming Soon list on Steam. During this time, we accumulated a little over 1000 wishlist additions. We understood that the initial release window is typically the single most important date for a game. We wanted to get as many sales and reviews as possible, in order to boost us up on the Top Sellers list. While the timing was unfortunate, given that fall through winter are some of the worst months for releasing an indie game, we simply did not have the money to continue development.

Observation #7

Having a proper Steam store page up, including a very good trailer and clear descriptions of everything, can build up a decent following. It is essentially free exposure. On the other hand, you can lose potential customers if your store page is bad, as certain users may simply tag your game as "Not Interested."

Skirmish Line released on October 17 on Steam Early Access to a spectacularly underwhelming reception. We never made it to Top Sellers list, although I had already expected this to be the case. The game was not ready in my opinion. We needed more time, more money, and more exposure.

Of our 5 user reviews during October, 3 were positive and 2 were negative. While this wasn't shovelware reviews type bad, it wasn't good either, not for something I've spent so much time and energy on. Particularly demanding was this review, which has since amounted to 176 thumbs up and remains the most helpful review on Steam:

12/24/2020 Update: That negative review has been taken down by the original poster, and the game has been hovering around 87-89% on overall Steam ratings.

I spent the next few weeks working to address the problems with the game. In particular, the game became too easy after a recent round of untested changes. As we had no playtesting since the summer, various bugs and issues came up. In retrospect, we should have continued to work with the Mud and Blood community. The decision to simply tease what little content we could afford to entice community members to purchase the game ultimately had no noticeable effects on getting Skirmish Line on the Top Sellers list.

Observation #8

Playtest every change. Games are complex systems, where a few variables can completely change the gameplay and feel of the experience. Accumulated changes without playtesting can result in dramatically different playing experiences than intended.

By the end of November, I was able to convince my partner to use the revenue from sales from October to finance further development. In particular, we had reserved $800 for an annual LLC fee, and I was able to convince him that the revenue over the next few months would cover the fee when it became due. Although my partner had initially wanted to recoup the capital contribution first before any further development, we agreed on a system where I would estimate the price of the next content patch before ordering them from our artist, Clark. We were able to keep costs low through clever re-use of existing assets, which allowed my artists to produce new content by remixing old sprites with new ones. Thanks to our working relationship, Clark was also willing to accept payments later than would be accepted by many other contractors.

Observation #9

Working closely with the same contractor can be beneficial. In addition to building up trust, you can develop a very efficient pipeline for getting assets out.

It has been roughly 5 months since Skirmish Line's Early Access release. In that time, the reviews have improved from 3 positive and 2 negative reviews to 21 positive and 3 negative reviews, sitting at a comfortable 87%.

I don't quite know how Steam's algorithms work, but I speculate that if a game gets below a certain amount of user reviews, it gets buried with the so called "fake games." In this metric, I think Skirmish Line has passed, which was the bare minimum bar I had hoped to achieve.

My partner has not worked on the game since August 2017 and has agreed to a new buyout offer of $9200. Taking into account all the revenue earned, this would have me at a net loss of roughly $3400, which combined with the required annual LLC fee of 2017, would amount to a net loss of $4200. I am hoping the revenue over the next few months will pay off this loss while funding development.

Observation #10

Choose your team members and partners very carefully when it comes to developing a game. This is a decision can stick for months and years.

I seldom talk to my partner anymore, and our friendship has suffered for it. The total development cost of the game has reached about $8000, a relatively low cost of production, given that $1600 were paid for California LLC alone. My partner has made a profit of $5700 from the buyout offer.

I'd like to leave some positive notes.

Working on a shoe string budget gives you a real constraint to work against. While I felt that a hard budget constraint hurt Skirmish Line's Early Access release overall, it nonetheless encouraged finding ways to cut down on expenses.

You will learn so many skills as a solo or mostly solo indie developer. In addition to programming, I directed the voice acting for the game, made countless image edits to get things just right, acted as a community manager, wrote articles on the wiki, and just improved my ability to learn new things overall.

While admittedly I have become reluctant to work on collaborations since, I am very fortunate to have worked with other very awesome people. Clark is a fantastic artist and conducts his work in a very professional manner. The voice actors I worked were super enthusiastic. And for all the loyal fans of Skirmish Line, I thank each and everyone for their bug reports, wiki contributions, localization efforts, and encouraging words.

Originally, I had intended to provide more details about Skirmish Line, but the merits and faults of the game deserves its own post, which I shall leave for a proper post-mortem.

Read more about:

Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like