Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Postmortem: Skirmish Line

    - Tony Hua

  • Community Outreach

    Sharing 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.

    Community Localization

    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.

    Connecting With Other Developers

    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.

    Company Structure and Team Members

    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.

    Your Mental Health

    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.

    Final Thoughts

    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.


comments powered by Disqus