Since 1999 (the founders are old or, as they say, “seasoned”), Ian Jardine, Craig Martin, Julio Carneiro, Steve Parkes and William Gibson (who provided the story and background) have wanted to get into the game-making business but lacked time, funding, and expertise. By building a successful web application consulting company over the past seven years, they were finally confident enough to start their dream company. They had an inkling of what they wanted to build: namely a multiplayer tank-based game that harkened back to Bolo from the ’80s. “We wanted to make the game hard. We felt that too many current games make it too easy for players to win. We wanted the player to explore their surroundings and get that “aha!” feeling upon discovering something new and weird inside the game. We were missing one key ingredient: Game Company Expertise”, Skunkwerk Kinetic’s CEO and founder Ian Jardine recalls.
Drive and Ambitions Above All, Experience Not Necessary
We aimed to build our team around a talented group of developers who had drive and ambition, though not necessarily game industry experience. Provided below is a brief description of three team members who we think represent a good cross-section of the overall spirit of our company.
You always remember your first hire, and we picked our lead engineer Jonas, a beaming Belgian with a passion for strategic games and a rock-solid coding background. At our first meeting, Jonas told us his story: upon graduating from an obscure university in Belgium, he and his lovely girlfriend (seriously, how did she get stuck with Jonas?) packed up all their belongings and moved to Vancouver. That showed us he was willing to take risks and take giant leaps of faith…very good qualities to have in a startup.
Jonas is also very good at asking questions…lots of questions. He forces us to really think through all of our crazy ideas, not hesitating to bring up the myriad technical difficulties associated with an ambitious new feature. It has been a real pleasure watching Jonas grow into his role as head engineer, and as a person (new dad!!).
Erik, the game/audio designer, is a good example of a team member adapting to the ebb and flow of a company’s needs as they change over time. Erik was hired as our ‘sound guy’ early on, but we were too busy making art assets and solving the technical issues of creating an online multiplayer game from scratch to spend too much time on audio. Erik’s passion for games and insight into game design were evident from the start.
He became our primary game designer and produced all the internal documentation needed for feature design in both the Art and Dev departments. He still has his hand on sound design, managing our sound consultant and offering advice on thematic audio design in the game.
Kevin, the lead engineer, is a good example of how an undergrad in Japanese Studies turns into a dev at a game company. He is fluent in French, German, and Japanese. He plays guitar. He sings. He can do Flash….oh, and he is a helluva coder. Realizing that the Arts degree was not quite enough to land for a full-time work in a game company, he went back for a second degree in computer science.
Kevin came to Skunkwerks as a co-op student, worked his way up to a key member of the team, and we never want him to leave.
Multi-talented Flexible People: A Solution for Small Teams
We refer to our team members as “Swiss army knives”. Our company is too small to have a specialist in every department. Instead, we need people who are flexible and multi-talented; it also helps if you’re a musician (our backup plan: if this whole game thing doesn’t work out, we’ll hit the road as a hair metal band called “The Skunkwerks 5” or whatever number of members we can rope in!).
Through two years of development and working with a small team, we have felt the sting of developers leaving our team for larger companies (*cough* Amazon *cough*) with much more money to throw around than we do. Our entire server team was demolished within two months leading up to a critical release, forcing our downsized client team to pick up the slack within a number of weeks. The remaining dev team not only learned about the server-side codebase, but was also able to fix a number of longstanding issues with the server architecture. Lemonade out of lemons, baby! The good news is that the people left are in it for the duration, while all we lost is “deadwood” - like pruning a tree makes it healthier.
Before Legit Game Engines Started Suggesting Affordable Deals
When we decided to make a mobile game, it was about six months to a year out from when legit game engines began offering more affordable deals to indie developers in a meaningful way. After initial research, we decided to string together our own custom engine using a variety of open-source and licensed components. This proved to be a double-edged sword in the long run, although we learned a great deal about each part, including Scaleform for UI, FMOD for audio and Sparrow for texture rendering.
The ease-of-use and implementation took much longer than expected, compared to a more conventional approach using an all-in-one engine. Moving forward, we now know how to be able to fully utilize a commercial engine should we choose to use one and also roll our own if necessary.
Why just Apple?
“Where is the [insert any platform other than iOS] version of your game?” We get this question quite often, as our game is currently an iOS exclusive title. We chose the iPad as our primary device for a number of reasons: we liked the development pipeline and usability of the Apple mobile framework, and the lack of variability in screen size amongst the various retina and non-retina iPad models.
While we agreed that Android would be a good choice for the type of game we’re making, we were wary of the expansive device list and the necessity of making our game experience work consistently across many different screen sizes and resolutions.
Apple’s 30 percent cut of profit from App Store revenue was quite steep from a business perspective, although we did appreciate the distribution platform as a service.
The submission process proved to be frustrating during our initial release of MEG:RVO - we ended up getting rejected for minor UI issues (like where to place the “Restore InApp Purchases” button), and then felt like we got approved without any actual human verification. It felt like dealing with an amorphous gatekeeper at times, and unpredictable release and update schedules proved to be a challenge for our server-based game (we didn’t want to make updates to the server until the App Store update goes through, for fear of breaking previous versions).
After our PAX East experience this year, we have received significantly more support from Apple, and the whole process has become somewhat smoother. It seems that as our app started getting more attention and updates on a consistent basis, the review timelines have shortened substantially.
Buying/Selling Wasn’t Fun - So We Removed It
One of the many things we learned from PAX East 2014 was that our game was suffering from lack of polish and usability in terms of the HUD design. PAX attendees who came to our booth approved the concept and look of what we had going on, but by the end of the three-day expo, we were all hoarse and exhausted from having to give a detailed explanation of the game mechanics to each person who stuck around to play.
We then decided to re-design our menu and in-game UI in order to present all controls and information our game contained in a simplified and concise format. We removed some features that we felt were too complex or not fleshed out enough to belong on a release version of MEG:RVO. For example, we decided to get rid of the Marketplace for the next release, since buying/selling items didn’t seem that fun and in fact might have had a negative impact on first-time players. Instead, we built a combat training mission that we strongly recommend new players to try out before getting into a match with other players.
The incentivization process was altered as well; we ended up giving players all of the weapons upfront. It’s now a balancing practice rather than a “pay to buy better weapons” system. Players gain experience the more they play and participate. Leveling up unlocks more maps, but the gameplay remains generally the same.
We hope that these changes along with our focus on user experience will allow users to stick around a bit longer and appreciate the depth and relative complexity of our game compared to more casual mobile games.
We’d Better Have at Least Someone With a Gamedev Experience
Hiring people with no prior game knowledge had its pros and cons. It would have been nice to have at least one person with prior industry experience. This might have helped us avoid some common pitfalls in our design, and reckless ambition in terms of what we wanted to create.
Should we have hired people who were passionate about games instead of people who just wanted a job? Definitely. Did we assume that most people would “just figure out” how to play our game without any guidance? Yes. We have since realized that we need to show people how the game works first, and then let them explore. This has shifted to our primary focus over the last few months and we hope that this will be reflected in our next release around August 1st this summer.
The value of our team comes from learning from these mistakes, and we feel significantly more prepared to deal with design and implementation of features than we did at the outset. Our website tag line “Doing things the hard way” is very apropos. We’re looking forward to making more mistakes in the future and further sharpening our expertise through them!
Grants: A Framework for the Business Plan
What we did right was to apply for grants (CMF) as it forces you to think through your game-plan. We used those grant applications as a framework for our business plan which we then used to to raise money. Have a proper budget and stick to that budget! Do not assume you launch the game and get an instant cash-machine. This is not going to happen. Plan for no money, but hard work, loads of “impossible” problems, and all for a very long time.
Be adaptable to changing situations; the only constant is constant change: “We adding dragons today? - No wait, robots, yea, more robots and some sparkly stuff…”
Probably the most important thing we did was to be naive. If we knew all the pitfalls from a suspect iTunes market (bots much?), technical problems (server down again..ack), personnel problems, and day-to day operational problems (why are there plants in the bathroom? payroll is due today?), we would never have started the journey. And that would have been a shame as everybody is having a blast doing what they want to do.
