Developing Skirmish Line: A Tale of Two Indie Developers

March 14, 2018
protect

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.

JikGuard.com, a high-tech security service provider focusing on game protection and anti-cheat, is committed to helping game companies solve the problem of cheats and hacks, and providing deeply integrated encryption protection solutions for games.

Read More>>