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 or learn how to Submit Your Own Blog Post
Roughly 3 years in the making, Skirmish Line was a first project, indie "success" story. Here's what I've learned making my first game, and how new and old indies can get some pointers for their own projects.
Over 3 years ago, I started work on Skirmish Line. You can and probably should check it out at this link to the Steam store page. In this post-mortem, I will be using what I call "The Good, the Bad, and the Unexpected" format for portions of the postmortem. Game development is complex and filled with uncertainty. There are good and bad aspects from various decisions but also sometimes unexpected outcomes, so I feel this format helps highlight the process more clearly. My goal is to help other indie developers by detailing my own journey, and I sincerely hope this helps others who are starting out.
When I started working on Skirmish Line, I had virtually zero programming training. I understood basic concepts such as loops from taking an introductory course in programming, but little else. I also knew that I am a terrible artist. These were my weakpoints starting out.
As a modder for a competitive Company of Heroes mod and an applied math major, I had a strong numerical background. I am able to study a game and break it down into a basic mathematical model. I had also been playing games for most of my life. These skills gave me a strong understanding of designing games, in particular how mechanics interact on a mathematical level.
I have always been a very frugal person. During my university days, I did not own a car, preferring to ride the bus. I had two part time jobs and frequently shopped for discounted items at the grocery store. Along with some savings from before, I managed to accumulate a small sum of money as a student. From there, I took advantage of the stock market, moving the majority of my savings into indexed stocks but later into more risky options. This last idea came from my background as an Economics major. All of this combined yielded about $25,000, which would form the seed money for developing games. To be clear, I am not advocating that you do what I did, but the general idea should be considered. Save money, and if you think you are able to handle it, invest. The end goal is to have enough money to sustain yourself and with enough leftover for business expenses.
There will be a distinct lack of pictures in this article. Unfortunately, it had slipped my mind to take any screenshots of earlier builds of the game. When you embark on your own projects, be sure to consider taking a few pictures here and there. Game development is a lengthy process with a lot to learn. You'll probably make some silly mistakes like that I did by forgetting to take screenshots. Don't be too hard on yourself. This is all a learning process.
The entire idea behind Skirmish Line was originally to develop from the grounds up, an improved version of the popular Mud and Blood 2 Flash game. This is not a terribly original idea, but it is an idea with other valuable properties.
First off, Mud and Blood 2 is literally my favorite Flash game of all time. This might seem like a redundant point, but you need to be interested in your project if you are going to work on it for a long period of time. If you're an indie developer and you're working on games you don't even care that much about, what are you doing with yourself? I do mean it. Ask yourself that.
There is a potential audience. Mud and Blood 2 was a major hit, with millions of plays across various websites. Released back in 2007, the game has aged enough that players would want something newer. This plays into nostalgia without infringing on the work itself, as Urb, the developer for Mud and Blood 2, had moved on from the project years ago.
Mud and Blood 2 is a mechanically driven game with a lot of math going on in the background. This fits with my strengths. The game doesn't need 3D modeling and the art can be fairly simplistic that at the time, I thought I could even do myself.
The final property that I considered was the flexibility of the idea. Having played Mud and Blood 2 extensively, I knew what I didn't like about the game but also what else I thought could be incorporated into it. Thinking on another game, Rising Storm, a FPS game set in the Pacific Theater during WW2, I considered the idea of implementing Banzai charges into Mud and Blood 2. I recognized that much of Mud and Blood 2 involved ranged combat and wanted to implement systems that would enable more melee focused situations. From there, Skirmish Line, which was tentatively titled: Mud and Blood: Pacific, was chosen as my first project.
Skirmish Line uses single sprite expression for most of the in-game sprites. This means there is a single sprite for each a state an object might be in. In Skirmish Line, the individual soldiers have a separate sprite for the different state they are in, e.g. idle, pinned, aiming/firing, dead.
The Good
Single sprite expression cuts down on the number of sprites needed to be drawn. This can be a huge money saver when you scale up the project.
The Bad
The most obvious outcome is that the game won't look as good when you're inspecting an individual element, as there really isn't much going on when you zoom in. For a low budget product, we found this trade-off acceptable.
The Unexpected
When taken as a whole, it actually looks pretty good. A huge melee with multiple units fighting looks and feels good despite most of the fighting involving only 2-3 sprites on the part of each individual unit.
For Skirmish Line, I went for a fairly bare bones UI. All unit menus are hidden until accessed. One major departure from the original Mud and Blood 2 game is that there are no UI buttons on the screen itself.
The Good
With such a minimal UI, players get a nice view of the game with little obstruction from the UI. This helps a lot when for players taking screenshots. There is a built in function to hide the screenshot (similar to many other games), but players rarely use such a function when playing.
The Bad
Some players may find the UI lacking, especially new players who are expecting more detailed stats. This comes along with one of the game's core design philosophy, being a minimalist game where players are expected to figure out the game through repeated plays.
The Unexpected
Surprisingly, some players prefer having UI buttons on screen. I ended up implementing a couple of buttons for such players, but this highlights how some players are very GUI oriented, at least in this genre of games.
Borrowing Firaxis' 33 Rule, the goal with Skirmish Line was to make a game with the basis of Mud and Blood 2 while changing and adding enough to the game to create a new experience. In essence, a third of the game would remain the same, a third would be changed, and a final third would incorporate new mechanics.
The Good
Being a first project, being able to build the foundations of the game after an existing game was a big help. The original prototype of the game was simply an attempt to copy all of the mechanics of Mud and Blood 2. For a beginner, this cuts out a lot of unknowns and gives a core goal for everyone to work towards.
By working with a game in mind, we can also make conscious decisions to change elements that didn't work well. For Skirmish Line, we abandon the "6 man rule" from Mud and Blood 2, a behind the scene rule (known only by the most hardcore fans of the game) that would induce artillery strikes on the player should their number of non-hidden units exceed 6 on the field. This change radically alters how the game would play out, but we found this made the game more accessible for players.
The Bad
Sticking to the rule means refusing a lot of changes. For Skirmish Line, this means keeping things like single unit selection, the top down view, and also things like the general inaccuracy of weapons, which we felt were a core part of the game's systems. We received a fair amount of negative feedback for this, with some players claiming the game is a clone of the original game with no improvements but also quite a lot of players praising the changes and new additions. Ultimately, sticking to the 33 Rule means some players are going to think the game isn't different enough.
The Unexpected
In the attempt to copy the core mechanics of the game during the prototyping phase, the mechanics actually turned out to be different in nuanced ways. Since we don't have access to the source code of Mud and Blood 2, our own interpretations of mechanics often resulted in very slight differences that would have notable gameplay effects.
In removing certain mechanics, as the aforementioned 6 man rule, we found new problems. The 6 man rule acted as a cap/limiter on the number of units for the player and helped prevent the player from hitting a critical mass of units To solve this issue, we had to get creative, first implementing an alternative, soft version of the 6 man rule in which the enemy boss wave spawn chance are increased as the players have more units on field. When this wasn't enough, we implemented new ways for enemy units to tackle the players' defenses. We added a smoke screen that would deploy in front of a boss wave. Certain enemy units would throw smoke grenades to conceal the movement of fresh enemy spawns. Special waves that adjust accordingly based on the number of units the player has on field.
It took several months of playtesting and experimentation to fix the gap in the design left open by the removal of one mechanic. When we simply tried to implement the 6 man rule itself and variations of, players felt frustrated by the seeming randomness of artillery strikes. Our eventual solution resulted in a variety of new systems that would further distinguish Skirmish Line from Mud and Blood 2.
A hallmark of the Mud and Blood series itself is the presence of an in-game achievement system called Medals and Ribbons, which require the player to accomplish certain feats in order to unlock various bonuses.
The Good
An in-game achievement system helps add a lot of replayability. While many players already naturally attempt to experiment and try new playstyles, an in-game achievement system can help push the players towards new areas that they might normally miss or simply add new challenges for the player. All in all, this is a fairly low cost mechanism for replayability and can really help extend playtime.
The Bad
The biggest cost of in-game achievement goals is that it is often difficult to design interesting challenges. For starters, goals have to be challenging enough to be meaningful but also feasible enough for players to achieve. When you take into account varying player skills, an achievement system may discourage players. A mixture of easy and hard challenges is an important consideration for player retention.
The Unexpected
Another major decision was to reduce on the number of grindy medals and ribbons. For an example, Mud and Blood 2 had a medal that would require the player to bypass 10000 waves within their first 99 games, requiring the player to average over 100 waves a game. This is further compounded by the requirement that this be achieved within the first 99 games on a player's profile. Players would have to restart their profile if they failed the requirements.
The decision was made to cut the number of games on similar medals in Skirmish Line and to have the requirement be based on a rolling score of the player's last set of games. While many players appreciated this change, a few diehard fans actually want those grindy achievements, perhaps conflating grind with difficulty and challenge. Nonetheless, we made a conscious decision to not push our players into what seem to be an arbitrary skinner box.
Skirmish Line incorporated a mutator system we called "challenges", not to be confused with the in-game achievement system. The challenge system is a set of mutators that modify existing rules within the game. For instance, the "Just a Flesh Wound" challenge would reduce the healing rate to 10% of its normal value while providing the player with 2 additional points of resources each wave.
The Good
A mutator system was another very effective and low cost feature. Requiring no new art assets or much in the way of programming, the system added new ways for players to enjoy the game. For what was a very minor system, a lot of players praised the feature, citing it as an interesting addition to the game.
The Bad
Mutator systems run the risk of confining the game space. One of the challenges, "Jack in the Box" became very popular with players. At some point, the mechanism behind this challenge actually came in conflict with a later planned system. Since the challenge was popular with players, we couldn't just remove it. We had to modify the planned system instead.
The Unexpected
For what would be a well liked feature, the challenge system was a random idea that I felt like incorporating on a random whim. From there, I began to take the mindset of actively looking for low hanging fruits that can be implemented.
Skirmish Line has an extra feature where players can purchase units beforehand and go on the offensive. Units would be persistent across missions, which themselves can be completed unlike the endless defense missions of the core game. On paper, this all sounds pretty cool.
The Good
Campaign Mode was initially coded in 2 days after having watched a series of tutorial on serialization (how to save your game). Campaign Mode is also an extra feature that could be used to help market Skirmish Line.
The Bad
Building a feature in 2 days on a whim and expecting it to just work is a bad idea. Building a feature in 2 days because you are feeling pressured to make the game work on mobile devices because the core structure of your base game modes don't allow for easy serialization is an even worse idea. Campaign Mode was a feature that was outside of the scope of the project, and the biggest example of a feature that needed to be cut from the game early on.
At the time, I was under pressure to find a way to make the game mobile compatible. Since much of the game's systems were built using coroutines, it was very difficult to serialize the game. This wasn't a major problem on PC since games weren't expected to take longer than 2 hours, with most being under 1 hour realistically, but mobile gamers would expect to be able to play in very brief intervals, thus necessitating either shorter missions or an ability to save the game's progress.
I did a lot of tweaking of Campaign Mode, but it never was quite as fun as the two endless defense modes. Ultimately, it was a feature that probably should have just been dropped, and the development time on it spent elsewhere.
The Unexpected
Steam actually cares about what you put on your store page, at least when it comes to potential false advertising. When we submitted the game for review, we had advertised 3 game modes. One of these game modes was Campaign Mode, which we had disabled on the menu at the time being because we wanted our players' attention to be focused on the two endless defense modes for the launch period. Subsequently, we had to re-enabled Campaign Mode in order to pass Steam's review check before the game could be released on Steam Early Access.
One of the most important thing when it comes to your designing your game is to consider how to make your game distinct. A general rule of thumb that I have gathered is that there are two primary ways to make your game stand out: 1) Make your game the most polished of its kind and 2) Make your game different enough that nothing else quite matches it. As an indie developer, I can't match the graphical fidelity of most other RTS games. So for Skirmish Line, this means abandoning a lot of what would be considered normal for a RTS game in order to embrace something different.
1) No group unit selection
A popular feature of virtually every RTS game is the ability to select and move multiple units at once. For Skirmish Line, we stuck with the single unit selection as from Mud and Blood 2 because we wanted to simulate the difficulty of managing a large squad of soldiers. In addition, this helped attached players to their units, as each soldier had their own individual name and backstory.
2) Visual Obstructions
In most RTS games, a variety of UI elements allow players to easily identify and locate their units. With Skirmish Line, individual units can be buried underneath other graphical assets. For instance, smoke grenades can make it harder to spot units by concealing them under a smoke cloud, similar to how smoke work in FPS games. Large clusters of units together would make it harder for players to identify specific soldiers. Even trees can hide units underneath.
We also implemented a "Roll Call" function in the game which prompts a UI indicator above all of the player's units in-game detailing a rough estimate of the unit's health status. If players want to get a more accurate status reading, they have to click on a specific unit. Roll Call gives the bare minimum for players to make a quick battlefield assessment, and the player must make a conscious decision to order a Roll Call. This helps build the mentality of squad management and adds to the overall theme of hidden information.
3) Hidden Information
In most RTS games, the health of both friendly and hostile units are clearly visible. Even upgrades or items are usually visible. By comparison, Skirmish Line offers only limited information for the players. Whereas players can inspect their own units individually for their full status, enemy units have virtually no information revealed to the player. This helps prevent players from being able to pick one the weakest targets, as common in many RTS games. Instead, players can attempt to do so by estimating the remaining health on enemy units through observation.
4) Indirect Unit Control
Soldiers also pick their own targets. All soldiers follow a rule based targeting system but some randomization is thrown to make target selection imperfect. For instance, most soldiers in Skirmish Line are programed to target the enemy within the closest distance, but we add/subtract some random value from the distance so that soldiers will sometimes pick a target that's slightly further rather than the immediate closest.
With this mechanic in play, we implemented direct squad orders. The most notable is the "Concentrate Fire" order, which allows the player to order every soldier to target a specific enemy unit. This grants the player direct control for a quick second, but the player must use the order judiciously with respect to the order's cooldown. On a more abstract level, sometimes it may be better for the player to simply let their units pick their own targets, in order to maximize a spread of fire on enemy units.
This is an important distinction as soldiers in Skirmish Line feature a "suppressed" state. Suppressed soldiers do not move and do not fire back. When a Concentrate Fire order is given, all of the players' units will fire on a single target, thereby allowing the remaining enemy soldiers to freely fire back on the fire.
The combination of soldiers picking their own target and suppression mechanic further builds on the squad management mentality of the game.
5) Whacky Stuff
Skirmish Line is built with black humor in mind. Despite the truthfully horrifying nature of war, the game's general aesthetics, from the art to the writing, has varying degrees of humor. The flamethrower unit is described as a mobile barbecue unit. Bodies explode into giblets that spin in the air all over the screen with various organs visually intact. Crates burst open with umbrellas, rubber duckies, and other nonsensical items that wouldn't fit in a warzone. There are holiday events with turkeys, the Easter Bunny, and Santa Claus.
6) Unfair, Random, Brutality
The last element of the game is that it's brutal and sometimes even seemingly unfair. Skirmish Line has large degrees of randomization. This helps keep the game fresh, sometimes giving players a brutal game and sometimes giving them an easier run. Reaching a high wave score is only one metric for success. Instead, the game encourages the player to succeed across multiple runs, with in-game achievements that are earned by consistent performance.
Summary
These are all conscious design decisions that give the game its own distinct identity that separates it from other RTS games. Some players object to these decisions, with some players wanting perfect information, some desiring greater control over their units, some finding the game too difficult, and even some wanting the game to be more serious and less whacky. But most players tend to find these elements amusing, fun, and unique. Perhaps even more importantly, this satisfied my own creative vision.
Naming Matters
Skirmish Line features three modes: Defense in Depth, Sector Defense, and Campaign Mode. When the game was initially released, Defense in Depth was called Arcade Mode and Sector Defense was called Classic Mode. I will be inverting the order of GBU here.
The Unexpected
Many of the influencers we contacted only showcased Campaign Mode, despite explicit instructions in our emails for them to focus on the then named Arcade Mode and Classic Mode.
The Bad
Campaign Mode, with its troubled development, was not the most polished game mode. With most of the focus on the two endless defense modes, Defense in Depth and Sector Defense, and influencers making videos on Campaign Mode, the best parts of the game were essentially being ignored.
The Good
After seeing this happen, I contacted one of the influencers and asked why they decided to feature Campaign Mode without even a mention of the two other modes. It turns out Arcade Mode and Classic Mode just don't sound very good. When we renamed Arcade Mode and Classic Mode into Defense in Depth and Sector Defense, we began getting a better mixture of coverage of the game.
After Skirmish Line was released on Steam Early Access, I began grouping changes together into major builds thematically named after major battles with the Japanese during WW2. While hotfixes and small changes would be patched in, major features were grouped under the named builds.
The Good
Although seemingly arbitrary, grouping major changes under named builds yielded a lot of benefits. On the development side, this helped with pacing and morale. Being able to point to what you've accomplished in a set amount of time was a solid morale boost. On the community front, this helped focus community attention towards new challenges and let players know that progress is being made.
The Bad
When possible, I tried to group tangible content updates for players. Unfortunately, as in the case of software development, sometimes the work done on the backend is not something players can immediately appreciate. There were a few builds whose release I slowed in order to incorporate more content type changes in order to keep players excited. As a developer, I find it tempting to show my players the newest developments, but it might be worth it to keep some content items hidden or saved for later when you're working on some major refactoring or new backend systems. Alternatively, this would also be a good time to implement a few low hanging fruit ideas, such as the in-game achievement and mutator systems mentioned under the Design portion of this article.
The Unexpected
Building cluster was an expected evolution of the development process. With the game on the store front, it's important to maintain some degree of stability for players. Naming the builds though was initially done on a whim because it simply seem more interesting for major patches to have a name alongside the number.
Most of the voice acting in Skirmish Line came from fiverr, a freelancer website with an emphasis on low costs. At the time, our budget for voice acting amounted to only a few hundred dollars, and we weren't able to afford most of the requested fees from more professional websites
The Good
Surprisingly, despite very low prices, we were able to get free voice samples from the scripts I had written. A few freelancers denied our sample requests and asked for us to pay for a gig, but the majority were willing to just throw their attempt at voice acting.
It took about a month for me to finalize my decision on which voice actors to take. I spent a lot of time listening to the voice samples, listening to the samples the freelancers had own their own sales pages, and asking friends to pick between the various samples.
Many voice acting freelancers seem to enjoy voice acting for a videogame, as it was something very different from the usual commercial gigs that are brought on the site. One freelancer, who wasn't able to provide a voice sample due to a family emergency, contacted me afterwards and asked for me to consider him for future voice acting roles. Another, the Japanese voice actor, even corrected the script I had sent him free of charge in order to get the lines as authentic as possible.
The end result was that we were able to get quite decent voice acting at very low prices.
The Bad
A friend of mine had convinced me to get a non-Japanese speaker to voice act the Japanese lines because he liked how the voice actor sounded. This voice actor, who had asked for my budget, wanted the full budget that I could allocate, a figure I didn't even exactly have at the time as I was approaching the situation from a bottoms-up approach by adding together the cost estimates across the actors. The voice actor was barely able to deliver the requested lines, taking over two weeks longer than any of the other voice actors, and we had to find a replacement voice actor in the end.
When I had to find new voice actors later on, I spent a lot less time vetting out the samples. Due to time constraints and pressure to release new content, I had invested only a week in listening to voice samples. Subsequently, there was a drop in quality on some of the later voices, particularly on Santa's voice.
The Unexpected
An aspiring voice actor on a community modding forum I browse frequently had asked if he could voice act in some of the mods. When it seem that none of the mods were looking a voice actor at the moment, I sent him a private message for a role in Skirmish Line. This turned out to be a win-win situation, as I worked closely with the voice actor to help prepare his equipment setup and he was able to provide a nice set of British and Australian voices.
As with voice acting, I took a similar approach the game's music. After vetting through a selection of freelancers (this time on peopleperhour), I was able to find a musician who was willing to provide the music that fit within my budget. And similar to the voice acting, I later came across an aspiring composer looking to get into the game music industry. We worked out an an arrangement where I was able to get some low cost but nonetheless high quality tracks.
Skirmish Line was built using the Unity engine. The choice of Unity wasn't made for any particular technical reasons. After I had graduated from university, I was working with a friend to make a mobile game. Since he had used Unity for one of his school projects, the decision to use Unity was primarily because it was the engine I had known about. Although this mobile game project would fall through, I would end up using Unity by association.
The Good
Unity is a very solid engine, certainly more powerful and optimized compared to something like Flash, which was what Mud and Blood 2 was built on. Unity allowed the game to run much more smoothly even when there were a lot of units on screen. This in itself was likely a selling point, as Mud and Blood 2 was notorious for slowing down to a crawl on later waves. Documentation on the engine were also very good, with plenty of user support online.
The Bad
Unity is first and foremost a 3D game engine. Combined with the engine being a blackbox, we had to figure out Unity's kinks and how to build a game using its systems. There are likely better 2D game engines available and Unity was probably overkill for the project's requirements.
The Unexpected
Since Skirmish Line ran without any real issues, players didn't experience any slow down on later waves. A Skirmish Line game that passes wave 100 would usually be roughly 40 minutes of play. By comparison, a Mud and Blood 2 past wave 100 might have taken around 2 hours due to the huge slow down in the game processing. This is a solid benefit for players looking for a smooth playing experience, but some veteran Mud and Blood 2 players would perceive Skirmish Line as being too fast or short of an experience. Such players had already expected to be spending 2 hours on a single game.
For people looking to get into indie development as business, don't be cheap. If you haven't already, make sure you have a sizable sum of money saved up, not just for your own living expenses but to put into the project. If you need high quality art and your own work can't even come close in quality, hire someone else to draw it. If there's a technical feature you need, consider looking to see if it's been done by others on free to use license code or available on the asset store. For instance, the $30 spent on Nested-Prefab for Unity drastically cut down on the amount of work needed. Your own time is a commodity, and it needs to be used for developing everything else in the game.
After one year of development, we reached out to the Mud and Blood community to share our project. This was honestly a bit of a scary thing. This would be the first public feedback the game received, and some of the feedback will be from the developer of Mud and Blood 2 himself.
The Good
The Mud and Blood community turned out to be an incredibly supportive bunch. We received invaluable feedback back some of the most veteran players of Mud and Blood 2, who guided the development of the project. This same community would form the core of Skirmish Line's fan base early on and was likely the strongest base of supporters.
The Bad
Sharing a game before it's done can sometimes lead to unfair accusations. When we released the game on Steam Early Access, we had mixed reception. This resulted in some disgruntled Steam users attacking the game. Having someone call your game a "scam" is not something that feels good.
The Unexpected
When some of these users joined the Mud and Blood Discord, the community defended the game. On the Steam forums, members from the Mud and Blood community would show up on forum topics to address accusations of the game being a rip-off, encouraging people to at least try the game before judging it. People will defend your game if you make it clear that you are trying to do something good.
After the release of Skirmish Line on Steam Early Access, there were volunteers offering to localize the game. As I had already built a localization system prior (to work with a member of the Mud and Blood community to localize the game into Chinese), it was a fairly straight forward step of making the game's text available via Google Docs for volunteers to access. I was able to get Spanish, Russian, Korean, parts of the Chinese, and Japanese localization for Skirmish Line with only volunteers.
My suggestion is for developers to consider a localization system early on. This will help cut down on the amount of refactoring you would have to later do in order to make a game compatible for localization. Be ready to take opportunities when you see them.
I joined the gamedev Reddit almost halfway through the development of Skirmish Line, initially just to ask a few questions, some of which I hope this postmortem will answer. For most of the first year of development, I worked with virtually no contact with the rest of the gamedev world. To put it bluntly, working without a frame of reference sucks. It can turn the development process into existential hell. When you're sitting by yourself in a dark room in front of a computer all day without any kind social contact, your productivity will suffer. I know that I've had days and even weeks where I just couldn't bring myself to do any work. Instead of talking to other people, I would sit there and stare at my computer screen, trying to make myself productive.
Take the time to take a break, and don't guilt yourself for doing so. If there's one bit of advice I want for new developers to take from this article, it is for you to incorporate a social element to your work. If you are reading this article but somehow not aware that there are gamedev communities out there, reach out to some. I'd recommend the gamedev Reddit as a starting point.
After some consultation and initial research, we settled for a LLC structure. There were two founding members, another programmer named Thomas and myself. The initial idea was that a LLC would allow us to better manage the company's finances for tax purposes. This would later used as basis for determining what responsibilities each partner in the company had. Thomas and I would build the early prototype for Skirmish Line during December 2015 and January 2016.
Virtually all of the art was drawn by Clark, an artist who I had met while working on a previous mobile game. Although the mobile game project was dropped very quickly, I was able to get a good impression of the quality of Clark's work. After the initial prototype was developed, we needed an artist, and Clark was the only quality artist we knew at the time. We bought Clark on as a contractor for the project.
Unfortunately, Thomas would work on the project very sporadically. There were creative differences between Thomas and myself, from the design of the game to the programming and to the eventual business model of the game. As Thomas was working on an unrelated, non-gamedev project, he often prioritized that project over Skirmish Line. And as one of two founding members of the LLC, Thomas was entitled to 50% of the company's proceeds and was reluctant to add more funds into the project.
Thomas would regularly disappear for weeks to work on his project. Portions of the project that he had agreed to do were often left unfinished and bug ridden. Eventually, this would push the project into a situation where I would be maintaining and implementing most of the project while Thomas would occasionally show up to work on an agreed upon portion of the project.
Thomas would continue to be part of the company until 2-3 months after the Steam Early Access release. Although I had made repeated offers to buyout his share of the company before, it wasn't until the revenue flow of the project was made apparent that Thomas agree to a buyout. During this time, there were a lot of frustrations, most notably that content feature on the project had slowed to a crawl due to a lack of funding.
Taking on a partner is a very important consideration in a project. Where a contractor's relation to the project is done on basis of a contract, a partner has binding relations to the project. I would suggest working with other partners in a different capacity first, perhaps in a game jam, before committing to any sort of formal partnership agreement. Know who you will be working with because you will be working with them for months if not years.
There are major decisions that ought to be addressed early rather than later. I'll list a few of our disagreements as they are questions that need be agreed upon by people looking to be partners. Here are some chief points of disagreement between Thomas and me:
1) Business model of the product
Thomas wanted an iterative sales model in which we would release the game on mobile devices early, evaluate community interest in the product, take feedback, and release new games based on the previous. I felt this model was abusive to consumers and preferred to release the game on Steam Early Access and focus on a single product instead.
2) Funding
Under our company agreement, ownership of the company was determined by amount of capital contributed. No partner was allowed to make any addition without the consent of the other partner. After our initial funding began to run out in the spring of 2017, Thomas refused to make any additional capital contribution but also refused to allow me to contribute more money into the project as he wanted to maintain a 50/50 split in ownership. Feature development was slowed as we were unable to pay Clark for new assets.
3) Revenue Split
As Thomas was from Ecuador, the tax laws involve complicated the funding situation. As a foreign partner in a California based LLC, 30% of his income from the company would be taxed by the US Federal Government. In the initial stages of the project, Thomas was worried about his tax situation and wanted the after-tax income to be equal between the partners. This created an awkward situation where we essentially had a company agreement that was not fully written out. Although we never reached such a stage in the project, the accounting required to calculate the after-tax income would likely have been a frustrating hurdle requiring professional accountants to calculate.
4) Working Time
When people are working in a rev-share agreement, it is important to establish clear boundaries about how much work should be committed. If one partner is working more than the others, there will be frustrations. As Thomas had a habit of working in relatively short but intense sessions, this put pressure on my part to match this efforts. Similarly, when Thomas breaks away to work on his own project, there is frustration on my part as he isn't actively working on the project. This is an issue that needs be addressed early and with careful attention to how income is distributed in other successful teams. For this reason, it is often easier for there to only be a single developer with contracted help, as fair wages can be paid for when work needs to be done.
5) Future Projects and Ambitions
Also worth considering is where each partner sees themselves after the first project is completed. If you are an indie developer, you are implicitly accepting a likely substandard salary/wage/income because you want to make a game. If you are looking at making indie games as a financial prospect, then this is likely the wrong field. There will be disputes when creative decisions conflict with financial ones. Know what others want and if you see yourself working with them on future projects.
Avoid working on your game when your mental state simply isn't up for it. I've wasted a lot of time by forcing myself to work when I simply wasn't able to enjoy my game with an objective frame of mind. If you're ever in a mood where you find yourself not enjoying any of the things you normally enjoy, leave your own game alone. You are not in the mindset to properly assess if your game is fun or not, which in turn might result in you throwing away good bits of your game. Instead of being productive, you are being negative productive. You are actively harming your own game's development. Stop. Take a break.
Making games is a passion for me, and I'm sure for many others. We are willing to give up a lot to make a game, sometimes taking too narrow and too shortsighted of a viewpoint. I might not convince everyone to take a step back and consider their own mental health for the sake of doing it because I know that likely wouldn't work on me. So instead, here is my argument for why we should take better care of ourselves:
You can't make more games if you're dead.
It's as simple as that. Take a break, talk to some friends, hang out on a stream, or even just go on the gamedev Reddit. If you want to make more games, you have to survive making the one you are working on now.
At the time of this writing, I have taken a position for a normal day job starting this summer. Skirmish Line has been profitable but not enough for me to continue doing gamedev full time. I've learned a lot and feel more proud releasing this game than anything else I have done in my life at this point. I know that there have been thousands of players who have played my game, enough people buying into the game that I have committed to release two DLCs for it. By that metric, Skirmish Line is a major success.
Being an indie developer means taking on a lot of different hats. While I spent a lot of time programming, I also spent some time working as the art director, providing instructions and documentations for Clark. I worked with voice actors, essentially casting roles for the units in the game. I've also modified sound effects to fit requirements that I can't fulfill by using something from an asset bundle.
There were days, weeks, and sometimes even months where I felt no motivation to work on the project. Some of it had to do with the learning process, figuring out how to build a game is hard! Quite a bit of it was because of the working relationship I had with my other partner on the project. But a big part of the learning process is learning how to communicate and keeping yourself sane as you work.
Game development is the siren's song. My success here is sadly better than what most indie developers are seeing these days, but there will be more people diving in for their chance to make a game. Heck, if I could afford to take the plunge again, I'd do it in a heartbeat. Until then, best of luck to your endeavors! I look forward to reading your postmortems.
Read more about:
Featured BlogsYou May Also Like
