In early 2006 I was a freshly minted computer science graduate with dreams of starting my own video game studio. A few semesters prior I had helped a lead a student run project that ended up turning into a simulated studio course (which continues today). Before graduating I was lucky enough to be invited by my professor, and soon to be business partner Clarke Steinback, along with a fellow student to help form a game studio. Our first planned product was to be a re-worked version of a proprietary play-by-mail game that was developed by Clarke many years prior. The plan was to keep the company light, nimble, lean and to focus on niche under-represented titles and markets. Part of which meant I would continue to work at a major wholesale/retail warehouse while developing the initial product “The Campaign of 1863” (C63). There were plenty of ups and downs over the following seven years with many valuable lessons learned. I hope this postmortem helps any others toiling away in part time development purgatory.
What went right
Began with a prototyped, tested and balanced game
Found our player base (eventually)
Learned how to learn
Job change
Began with a prototyped, tested and balanced game. The original play-by-mail version of the game which was developed by Clarke and his brother ran for only a short time. It was stopped as the time it took to process turns for the number of games and players became too great for their small team to bear. The play-by-mail version did however run long enough to function as a paper prototype testing phase for what would eventually (with some major tweaking) become C63. Not having to spend time concepting, prototyping and iterating the paper version saved us some very valuable development time. Especially since our part-time system takes much longer than other studios.
Learned how to learn. When I graduated I felt, like most graduates, woefully underprepared (I’m speaking of my feeling here. In retrospect I was probably more prepared to enter the video game industry than many of my peers due to my affiliation with the APCG program at CSUChico and specifically the simulated studio course I mentioned previously). And when we decided to launch our own studio, I felt doubly so. I mean, what kind of classes can you take that will prepare you to found a game company. It quickly became very apparent that I needed to learn some new programming languages, APIs, and business strategies. Here is where I definitely credit the computer science department at CSUChico. In all of my CS courses, excepting a few of the entry level ones, students were expected to do quite a bit of self directed learning. As I was wading into the unknown waters of a studio launch I can say that at least I felt comfortable that I had done similar things in the past. This made the task of learning new things like how to fill out business forms and new programming languages less daunting.
Found our player base (eventually). At the very beginning of our work we did some preliminary market research by looking into sales analytics for some of the niche market magazines that the old play by mail version of the game had used to recruit its player base. Our initial take on the findings was that we should be targeting Civil War reenactors. After all they had been the largest consumers of the original paper version of the game so it stood to reason that a digital version would be a natural progression and we would be safe to assume that our target audience could remain the same. What we found with our initial outreach efforts, however, was that this wasn’t necessarily the case. There was/is some overlap in the reenactor market, but the number of early testers showed us that digital strategy gamers were a much larger segment of the player base that was grown organically. By organic I mean players that found our alpha/beta test version of the game without any paid advertising. We were able to determine this through our early use of Google Analytics. At the time GA was a relatively new tool and we were lucky in that we chose a web based system rather than a direct peer to peer game architecture. Once we were able to analyze who among our registered players were actually sticking around to play it made a significant impact on several of our design decisions. Most of which revolved around our decisions about how “authentic” the game should be versus what hardcore strategy gamers might want and expect.
Job Change. This one is more of a double edged sword so I’ve included it as something that went right and something that went wrong. In late 2012 I ended leaving my job at the wholesale/retailer. The good thing about it is that enabled us to make huge strides in the development of the user interface and web based front end systems. Which wasn’t a huge surprise since the time I was able to devote to development skyrocketed from 2-4 hours a day on up to 8-10 hours a day. We were able to reach a Beta state much more quickly than our original estimates, so of course this would be a huge benefit to us. I should also mention that I was fortunate enough to have an excellent business partner that had set enough contingency money aside that would allow me to move to development full-time for a short period of time. And for that I’m still grateful.
What went wrong
Job Change
Loss of a Business Partner
Actionscript 2
Complex Rules/Interface
Job Change. So the flip side to the positives of being able to move to temporary full-time development mode was the loss of my health benefits I enjoyed previously. If it was just me on my own without health coverage I would have been less concerned but I also have a family to support and going without health coverage for a wife and two young children was, quite frankly, scary. Im not the only indie developer to go without, so Im sure there are others out there who can relate to the constant worry of a health problem when you have no insurance. After going without for sometime and being unable to afford the astronomical cost of private insurance it made sense for me to start looking for a solution. Fortunately for me my business partner Clarke, again came up with a solution. All the time we were working on growing our business he was also working on growing the APCG program at CSUChico. In fact it had grown so much that he was in essence working a double load by administering the program and continuing to teach. His solution was to have me apply for the part-time teaching pool at CSUChico. I was hired a short time later and became eligible for health benefits about six months later. This slowed development of the project again, however the short period of time that I was able to do full-time development had resulted in the almost completion of the UI and web interface. Also I have to add that I really do enjoy teaching. The students in the APCG program are great and I really enjoy their enthusiasm for the industry.
Loss of a business partner. This is one of the major regrets of my entire game dev experience to date. We initially launched our little micro studio with myself, Clarke and another recent fellow computer science/APCG alumnus and friend. Things initially went very well, with all three of us splitting the workload on a part-time basis as best we could. Life, however, started to disrupt our established work patterns and methods. Our third partner got married and we noticed a dip in her work productivity. We decided not to mention it and to hope that as she settled into life with her husband things would shift back to normal. Unfortunately that was a mistake on our part. In retrospect if we had addressed the problem at the time we probably could have avoided what ended up being a messy separation of her from the company.
Actionscript 2. For any devs that never had the “pleasure” of working with AS2 let’s just say you dodged a bullet my friends. While light years better than its predecessor, AS2 had what I consider to be a fatal flaw. While billed as an object oriented scripting language what actually happens “under the hood” is procedural. So you can write some nice classes and think that object interaction will happen just like C++ or Java, things will fall apart when push comes to shove. I spent much longer than needed dealing with issues that should have just worked if AS2 was truly OO as advertised. Some of you may ask why we even chose AS in the first place so I guess I should address our reasoning. We first started development of the UI in 2006. AS3 was only a rumor at that point, and html5 wasn’t even a rumor. Our choices were AS2, Java, or Javascript (pre-jquery). AS2 offered a huge install base and a large dev community. At the time we had no idea that our dev cycle would be so long, so it made sense.
Complex Rules/Interface. The initial paper design of C63 was made as an homage to the old SPI and Avalon Hill boardgames. Anyone who’s played those games knows how complex the rule systems are. We knew that modern gamers would never have the patience to read through a long complicated manual, so we attempted to obfuscate as much of the rule system as possible. In some ways our approach worked. New players aren’t required to read a huge manual to get started. And players don’t have to use look up tables or know intricate and complex rules to play. However this has lead to some areas of confusion for our players, the main issue being a time/distance hex based asynchronous game. The initial basic design for C63 is that of a team based WEGO system. So all players plan orders for their units to follow, then at a predetermined day/time everyones orders are gathered together and processed simultaneously. While we like our system and feel it’s unique, we failed to impart to the players that when they submit their orders for their units they are submitting a plan. And while they are moving units around on the game board the units are not moving in real time or even in a manner that they are used to like an IGOUGO system. The other stumbling block for our players has been our abstraction of the concept of units moving in time to Movement Points (MPs). In C63 different types of units have different amounts of MPs. So an Infantry unit has 3 MPs while Cavalry has 5 MPs. Players become confused when they try and rendezvous units at a hex but if it takes an Infantry 2 MPs to get to that hex and a Cavalry 4 MPs to get to the same hex our players tend to forget that they don’t arrive at the same time. And timing in a strategic game like ours, can make all the difference. We do have plans to address these issues, but that’s a different blog post (hint: we’ve got big plans for our little studio, so stay tuned)
Conclusion
So here's to you, fellow part time developers. I hope this helps in some way, even it its just as a small word of encouragement. Enjoy a tasty beverage and keep on working. You will make it eventually!
