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.
Starting Out
Your Starting Skills
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.
Money
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.
First Lesson
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 Idea
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.
Art
Single Sprite Expression
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.
Minimalist UI
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.
