Not Invented Here Syndrome. For those not familiar with this malady, it means that I have no problem dissecting and reimplementing anything I find interesting. So when starting Ananse Productions I had to put in place some rules to make sure my curiosity doesn’t hurt us. When deciding whether to use our own code or to start using another game engine like Unity, the following 5 questions helped me decide on the (hopefully) right path for us and can hopefully help you out.[1]
Is engineering your specialty?
I’ve always been a generalist, knowing just enough about graphics and audio to be dangerous. The elegance of managing complex relationships in real time, not just getting games to run blazingly fast, is what drew me into game programming[2]. However, in the game industry I’ve found a lot of programmers that have the “hack it together until works” philosophy which left me really frustrated.
I’ve always believed that good structured coding leads to better tools that empower content creators to iterate more and lets the team focus on making or changing features without running into a cavalcade of bugs. So with Ananse Productions I’m testing that theory. Plus it keeps me interested as a programmer which is important if I’m going to live and breathe this company.
Can you keep your scope small?
Stem Stumper was made in 6 months. And we only had our Artist, Audio Guru and Level Designer for 3 of those months. I think this was only possible because we kept our scope very tiny because our engine could only do so much. Constraints are a great source of inspiration[3].
Our main priority was making a great game. But just underneath that was making sure we were battle tested and I had a clear understanding of what worked and what needed to be fixed to make our pipeline smoother. I committed to limiting the scope of the game to what the we could handle and being really hesitant to add new features. This is a paradigm shift from the industry standard of forcing in features because your scope demands it.
How much risk are you willing to take on to grow expertise?
Like most “entrepreneurs” I have age on my side. If Ananse Productions doesn’t work out (knock on wood) I have a lifetime of earnings in front of me to make up for it. I have no one dependent on me and no one’s retirement funds to watch out for. On top of that if Ananse isn’t around this time next year (again knock on wood), I get to walk away with the experience of writing an engine, starting a company, managing a team, and learning how PR works. For me, that’s a win. My risk tolerance is about as high as its ever going to be.
Even if you’re not a kamikaze start up like us, there’s still an enticing risk/reward dynamic to doing things in house. If your artist needs to know how animation works in the game, someone on the team can answer her right away. If our sound person needs to know what audio format to use she can get an answer right away. Yes, proper documentation helps but having someone on the team who’s an expert in every system can be immensely helpful. You’ll not only have someone who understands how a physics system works but who has also actually implemented one. Engineers know there’s a huge difference between the two. You’ve just grown your human capital and cultivating talent can outweigh the time savings of a engine in the long run.
Are you OK with the external dependencies?
One thing that was very important in Stem Stumper was that we were able to talk to the screen reader tech of the platform we’re running on. It’s very easy for us to make sure our engine can do that because well… we built it from the very start to include that.
When we wanted to the game to work on Android (something we’re currently working on and will post about soon) we reimplemented our platform specific layer for Android. It sucked and it was painful but next time around we should have something that just works (although nothing ever does on Android). And learning the ins and outs of the Android platform set us up to do contract work for others. We weren’t reliant on working on an engine that already did this for us. And we didn’t have to touch the innards of an unfamiliar code base.
What’s your long term plan?
I’ll admit the questions above say more about my personality than my business sense. But one serious business reason for writing your engine is company stability. When you look at the big independent studios like Valve and Epic they each have ways of making money outside of game development. Valve has Steam, which allows them to take as long as they want with Half Life 3. Epic has Unreal which everyone and their grandma uses for console development (yes its starting to branch out onto other platforms). Even The Behemoth uses merchandising to help pay the bills. While riding an initial blockbuster can help setup a studio, for long term growth and stability I think you need something that isn’t as hit or miss as a game. And and making the code a potential product is hopefully a smart move for us. We’re obviously a while a way from acting on this and it slows us out of the gate, but we’re in it for the marathon not the sprint.
Summary
You’re not dooming yourself when you decide to roll up your sleeves and take care of things yourselves. But just like any other business decision you have to carefully evaluate the risks and see if its in line with what you’re trying to accomplish. We use WordPress for our site because we’re not about web development. And we’re not going to implement our own custom source control. I hope this helps others afflicted with NIH lead long and successful lives.
Notes
here. I wanted to focus on how it applied to Ananse Productions and game development.
Game Programming Gems books. I fully read the sections on Architecture and the rest of the articles are gravy.
pretty strict rules when making Bugs Bunny and Wile E. Coyote cartoons. While there’s debate on the Wile E. Coyote rules, constraints get rid of indecision which frees us to focus in on what’s important.
“Real Programmers” comic from http://xkcd.com/378/
“Scope Creep” from http://test.ical.ly/tags/scope-creep/
“Risk Assessment Cat” from http://cheezburger.com/TemplateView.aspx?ciid=4401869
Trapeze artist image from http://usrportage.de/archives/911-Not-having-globals-state-doesnt-mean-youre-doomed.html
“Scrooge McDuck” image from http://listsoplenty.com/blog/?p=13032