Steel Penny Games

It's time to do our post-mortem now that all the facts are in and we have had time to catch our breath before diving back into development.  I'll use the traditional Game Developer Magazine format, since it's easy and familiar.

What went right:

1. Build our own tech. One of the goals in starting a game company, for me, was to get a chance to do whatever technology I found interesting. A selfish reason, I admit, but most entrepreneurs are selfish in this way. While many engines exist, spread across the rather extreme ends of the features/cost spectrum, the longest term investment one can make is to invest in oneself. Some powerful good came from building our own tech, though, even in this first iteration. It taught us the relative merits of the Wii's hardware capabilities, up close and personal. It provided a timetable that prescribes the size and capabilities of games we hope to make in the future, and forced use to think small and first concern ourselves with how to run a business, how to manage the development process, and how to succeed and fail at different aspects of this process without losing a great deal of money in the interim. You see, once you license technology, the clock is ticking and the longer it takes for you to produce a game, the more that technology has cost you. When building your own tech, this is also true, but at the end of the day you still own it. Kind of the difference between leasing and buying a car. I was also careful to make decisions to integrate or license certain technology that we had no real expectation of finding advantage by reinventing. Examples include sound, physics, and possibly networking. But even though we didn't write each of these ourselves, we did use different vendors for different platforms... largely because of licensing fees, but a happy consequence was a nice wrapper that allows us to drop in new sound systems easily and compare their relative merits in a concrete rather than theoretical setting. Overall, the time invested in building our own tech was quite lengthy, but it's one thing that allows us to always move forward rather than rewrite or refactor a middleware solution that just doesn't do what we want.
   
   
2. Make the smallest game possible. Originally, we were working on a game whose design was evolving and contingent upon technological breakthroughs that had yet to be made. After a few months, it was clear that the game was heading towards vaporware and that we needed to step back and focus on a game we could definitely do. Andrew and I spent a weekend jamming out different ideas, from which a few became mockups. All these potential games had in common was their reduced size and scope. We selected the smallest of them. Why? Several reasons: to contain feature creep, to focus the technological demands of the engine on an enumerable set of requirements, to allow our tools pipeline time to mature into a usable system, and also to give our engine an opportunity to run through the final QA process at Nintendo with a fairly small chance that game-related problems become the holdup. This last point is important, because the QA process tends to find all sorts of errors and sometimes requires significant rework, some of which would be painful to do in a larger game on its first submission. By reducing the size of the game to a manageable parcel, the theory was that future games would be easier to release. All these objectives have been met, to some extent. Also, by making the smallest game we could, we can now say that we've shipped a title. Plus, putting code into a practical setting as early as possible is the best way to harden it for production, and by bringing several systems online and getting through a full development cycle, I know which ones I can depend on and which need more work. Lastly, a smaller game means introduction to the business and publishing side of the games business (which I had been mercifully sheltered against prior) with a product that is hopefully small enough to tolerate inevitable mistakes while we learn the ropes.
   
   
3. Allow tech limitations guide art and design. Just because we were doing a small game did not mean we wanted to do the bare minimum to make the game. We had more than enough ideas and not nearly enough time to pull off what we'd wanted to do. So, as a compromise, we listed out all the relevant game systems we could think of onto the whiteboard. Then, I wrote out several features that I believed were do-able within the time constraints. We picked the tech that gave us the best overall experience and went to work. As new features came online, the art and design shifted a bit to take advantage of them. For example, animated cameras came quite late in the project. Once that was added, we found several places where animated cameras could be used artfully and put them in. For much of the project, we were mainly working on the appearance and functionality of only one "level", it gave us a place to iterate and hone the art style and presentation to match the engine's capabilities. Later, when more levels were built, these disruptions caused changes to more assets, however, which became troublesome. That's about when new development on tech features stopped and all energy was put into shipping. As a result, we have some very nice features that more advanced engines have, but the feature list is very spotty. Anything not demanded by the game was not implemented, and everything implemented in the engine was used extensively. There was no significant waste in the development effort on the tech side.
   
   
4. Economize early for a longer runway. To run a startup, you must understand the relationship between cash-on-hand and time-to-market, or you're doomed. I started out thrifty by buying used office furniture, shopping for cheap servers, making all our own cables, and generally doing everything we could to reduce the monthly burn rate such as running our own Trixbox VoIP system off a budget carrier. We bought a bulk lot of good, but older, CAD/CAM machines off eBay that came with high end certified video cards, and got them for a song. We worked out of my garage apartment for almost a year before getting office space, and even now, it's just a roof and a few walls. What mattered most was keeping the company alive long enough to ship a title, not the luxuries that developers have come to demand from their employers. By spending very little on creature comforts, we had the funds to bring in help when we needed it, the time to polish the game near the end, and the ability to scrap things that just weren't working and try again. And despite all this scrimping to get to a launch date, we didn't budget enough. More on this later.
   
   
5. Connecting with the game development community. Game development is a team effort. Startups are also a team effort. Unfortunately, when your startup is only 2 or 3 people in different disciplines, it's easy to feel isolated, cut off from the world. And often there were difficulties where we had to lean heavily on expertise from the general game development community, our personal networks, LinkedIn, GDAlgorithms, Polycount, Nintendo Developer Support, and sometimes just a visiting fresh pair of eyes to lend us some perspective. Andrew and I are both active participants in various online communities, and while we gave quite a lot, we also received, and in its own way was therapeutic.
   
   
6. Separating tools from runtime code, prototype features from production code. Since the codebase that Steel Penny Games started with was my collected personal tinkerings, there was very little logic to the organization. The tools and engine grew rapidly, but without much structure. The game was first built on PC, where the tools and engine both could be built from the same project file. What a disaster! The moment we received the Wii Development Kit, I took a step back and realized the error of my ways. The tools and runtime had grown together in a horrible unibrow of classes and structures. There was unfinished or purely experimental code scattered around in production-worthy libraries. It was clear that a couple of weeks was going to be sacrificed to obtaining some measure of order, and it was well worth the time. Once I split out the game and engine from the tools, it became easier to figure out what needed to be ported to the Wii and what could stay PC-only. I was also careful to make sure that the runtime build process was never more complicated than selecting all the files in the runtime and compiling them... no special build steps, no preprocessing of files, and no special macro definitions except for a couple of environment variables for re-rooting the include and object file directories. This gave me tremendous flexibility and required minimal effort to maintain. Also of incredible importance was collecting all the questionable, experimental, and otherwise non-production quality classes and moving them to their own library where they could stew or be forgotten. In that library, I maintain a set of unit tests that exhaustively verify the behavior of every new engine-level class. Once the test unit is complete and I'm satisfied with the new system, I move it (but not the test code) to a production library. Should new problems show up, I can always add more checks to the unit test and re-run them. Sometimes, great ideas in theory did not work out in practice, so the code never moves out of the experimental sandbox. It's much easier to avoid using semi-tested code when all the files have "experimental" in the filename. And the process of pushing code into production is accompanied by a feeling of accomplishment and the attendant notification to the art staff that the engine can do something cool that it couldn't do before. Small victories like this kept me sane throughout development.

What went wrong:

1. 3d in a 2d world. The typical game player doesn't really understand the difference between 2D and 3D. Not in development terms, at least. We made a 2D puzzle game into a 3D game. While our company is planning to do 3D games for the most part, it may have been a mistake to start with one. Adding that one extra little dimension demands you use it. So, in comes some of the typical 3D features, like a movable camera to show off the dimensionality of the level. Once you can move the camera, the art needs more work. You suddenly need to make sure the objects look good from many angles, especially if you can get closer to some objects and the low resolution textures show themselves, but looked fine from a distance. In the end, I'm not sure how much players will appreciate the incredible amount of effort it took to make the levels look nice, especially compared to the time required to just paint up a few billboards and make the game 2D. I know it would have cut many months off our timeline if that were the case.
   
   
2. Poor hiring practices. As a startup, economize on depreciable assets, not talent. The most precious commodity a game developer has is time. Spending any time teaching someone who may not be capable of producing final-quality work is money down the tubes. I am NOT saying to avoid interns. I am saying that each inexperienced person will have a much longer ramp to climb before becoming useful, and the more specialized they can be, the better. Startups are not good places for people who want to do, or are only capable of, one thing. Over the last year or so, we've gone through 5 interns and a couple of contractors who only produced certain things well--and not generally what they represented as their strengths. Consequently, I ended up doing most of the coding after everyone went home for the day, because so much of the day was spent troubleshooting or educating the interns. That doubled my hours at work, but did not double my output. The one intern we kept, Alina, showed the most promise, had the best attitude, and wanted to learn everything we threw at her. While the right attitude goes a long way, the process of managing and educating someone with limited experience is a massive distraction. To be fair, we also had some trouble with contractors who had experience but were hard focus on doing any work. In our defense, we got better toward the end of the project and tended to be very clear about the deliverables and payments, and work less on handshakes and good mojo. And we no longer hire anyone without long experience and a reference. We're too small to afford that. Cheap labor is often a net negative as a startup.
   
   
3. Contracting to lengthen the runway stalls the project. When the funding started perilously approaching zero, I took on contracting jobs at several local studios to provide for the company's expenses. All these studios were great to work with, were full of fun and energetic people, and made it painfully obvious that I didn't need to work so hard to live better than I was--just take a job with them and put in an honest day for an honest wage. There were multiple problems with this scenario. The morale at Steel Penny fell when I was away... the feeling of progress ebbed when programming features slowed to a trickle, even when art was producing at the same rate. When artists are irritated, they don't do work they end up keeping; the fact that I was buying time for them did not ultimately gain us too much, and merely prolonged the agony of the working conditions. What I should have done is gone back to the bank and extended our credit, and kept going as we were. It seemed logical to me that giving us a longer runway before launch or failure would be a good thing, but I failed to recognize the psychological impact that a fragmented team has on the work being performed.
   
   
4. Certain tech limitations were inhibitive. While we generally selected wisely from the list of technical tasks required to make a great game, there were a few that severely limited the kind of environments and presentation that we could pull off. There are two specific examples I can give. First, DXT1 compressed textures. This relatively simple format is a little complicated to produce and might take a while to get working, but takes 1/4 the space of the next full color texture at the same resolution. Most games use this fact to crank up their texture resolution for "free". As a download title, we would have happily used it to reduce our download footprint, since our textures are sized about right for the resolution and camera distances involved already. I had guessed this was a 2 week task, and punted on it early-on, and made do without it. I was wrong. Some public domain compression code exists that made this all of a 2 day task, and it would have cut our package size a fair bit (maybe 20-25%?) with little noticeable impact. Second, animated texture matrices and dynamic lights were similarly considered too time consuming for this game. As a result, our particles aren't as interesting as they could have been, and the environments don't have cool fireflies circling the pieces and there's no flickering as the transformation effects go off. These little things would have helped the experience in subtle, yet important ways, particularly since neither take up significant download space but add a lot of life to the world. It was a challenge to get full, immersive 3D levels into such a small download footprint, especially given these limitations. Moving forward, I will be careful to evaluate not only the game features each tech system allows, but also the ramifications for the art and design if the feature is absent.
   
   
5. Underestimating the finaling process. Nearing the end of the project, I began work on the QA requirements Nintendo expects from all developers who release on their system. This is nothing unique, as Sony and Microsoft both have their own lists of expectations. However, I was thinking these could be injected into our code in the matter of a week or two. I spent 5-6 weeks finishing all the necessary work to comply with the expectations, only half of which was programming. Luckily, this is generally a one-time cost, but it was unfortunately more than we'd planned on, and pushed our release date back by over a month. Also, most large developers have a period where all the designers, artists, and programmers go home at the end of the project and don't come back in for a few weeks. Being in a small company that self-published its first game was very educational. I learned what happens during those few weeks when everyone else is gone--lots of paperwork, emails, and waiting. Unfortunately, we underestimated the amount of time this would take and the number of minor but show-stopping problems a new engine would have passing Nintendo's stringent QA checks.
   
   
6. An inestimable schedule. Since our project planning was largely whiteboard-driven, I organized myself with notebook after notebook of check lists and filled them with future work as well as daily accomplishments being checked-off. At no time did anyone sit down and figure out how long each task took. But we always knew how much longer we were going to need before shipping... 6 weeks. It was always the answer, because 6 weeks is longer than a short term task, but sooner than a long time from now, and sufficiently nebulous that almost anything could happen in that span of time. If we've learned anything from running this project from start to finish, it would be that a regimented art process is still useful even on a very small team. We experimented with rapid silhouette prototyping, basic concept sketching, 3D mockup prototyping, and just skipping past concepts and jumping into production sometimes. The lack of a single, clear process for greenlighting and reviewing art made it difficult for us to come to a consensus when some assets were "done", and when they were merely a work-in-progress. This made our schedule even less possible to predict than a list of tasks on a whiteboard. I have to take a substantial part of the blame for this personally, but as a studio I think we grew a lot from this failure. And to make matters worse, without a schedule that included both art and programming together, it was not possible to know when the game would be done, so it was impossible to predict the budgetary requirements.
   
   

In conclusion, we are human and make mistakes, but we did get lucky sometimes and make the right call. I hope there will be an opportunity for us to move forward and address some of our shortcomings in the near future. In the meantime, enjoy Bruiser & Scratch and let us know what you think.

JH