TL;DR: Forget about all the non-game things you could do, like making a website, starting a company, or marketing your unfinished game and just finish. Give yourself a deadline and make it your sole priority.
Last year my great friend and long-time collaborator, Jake Jefferies, and I decided to start a video game studio called New Beings. We released our first game for iOS, Android, and the web called Infinite Orbit in the beginning of 2015. A lot of people have asked us about this process, especially people like us who are trying to go from the place we were a year ago - that is, never having made a game - to where we are now. We wanted to write something so we could share this process with others and to remind ourselves what it was like and how we can improve. This kind of thing is usually called a post-mortem, but we don’t like that name. We are not doing an autopsy, and our subject isn’t dead. Updates can come when you least expect them! We just want to share our thoughts on one experience that is part of a continuum.
Early 2014: It’s very cold, snowing, and windy. Jake and I have been meeting regularly (also known as “hanging out”) to discuss the mechanics of our top down battle/racing game. It’s gonna be great. It’s going to have powerups and strategy and fast paced action. It’s also going to have online multiplayer. Jake started programming the game using Processing and lots of Java libraries. He fleshed out some of the mechanics, collision detection, and a very basic working multiplayer LAN setup. However, things weren’t lining up timewise. I couldn’t offer any help with the actual programming or art because of prior commitments, so Jake was doing all the real work. We ended up losing steam without a clear finishing line or release strategy, and a game that was too big for our first project. We learned a lot, but we didn’t end up with anything close to a finished game.
Months later, I got a clear picture of a simple mobile game that was basically a spin on Flappy Bird or the Helicopter game. I drew sketches of every screen, with notes on gameplay and what every button did. These became the wireframes that laid out everything a player could possibly see, which didn’t take long because the game is quite small. I got really excited about the game because there was a clear plan about exactly what we needed to execute. I showed Jake and asked him if he wanted to work on it. He said yes, but that he wanted to make it in 3D. We went back and forth about how we should program it and eventually settled on using Unity, which Jake already had experience with.
Workflow and Planning
Jake and I work well together. We get excited about similar ideas and have complementary skills. Jake is a professional 3D artist who has been developing his artistic voice for years, working for other people and making his own 3D art. He’s also a programmer with really deep coding chops. I am a professional web developer with good UX/UI skills. I’m working to learn the art of game design and I’m a good planner. Jake thinks a lot about the artfulness of our projects and I think a lot about the concrete details of getting it done. We both have a common game vocabulary - that is, similar games we’ve played and loved. If you happen to be looking for someone to make a game with (or any other project), try and find somebody who complements your skills, inspires you, and also pushes you just enough. Also, pick someone you admire and who you’d describe as a “beast” at what they do (a la Paul Graham). Hopefully, you’ll be lucky like me and one of your friends will already fit the bill!
For this game we ended up splitting the work pretty evenly between art and programming, with Jake creating all the 3D assets and animation, while I did the programming and user interface design. This gave me a chance to learn C# and Unity, with Jake there to provide any help with all the new concepts I needed to learn. For the most part, we worked in the same room. I went to Jake’s apartment after work about 2 nights a week and slept on an air mattress if we ended up going really late. Both of us were, and still are, working full time. Both Jake and I felt that our main goal for this game was above all, to finish. I recommend this approach to anyone who has wanted a game but hasn’t been able to make it happen. Forget about everything else and just ship it.
We used a Google spreadsheet to keep track of what had to be done, but we are now transitioning to Trello for planning after seeing the planning situation of a kickstarter project we backed called Moonman, that basically involves three columns - todo, doing, and done. I like it because you get to watch your “done” column filling up and your “todo” column… also filling up : )
One of the nicest things about software, and the distribution systems that have been set in place for games especially, is that you can update it and inform your players quite easily. You can fix your mistakes and add features. This is something we had to remind ourselves of over and over again. Not because we were scared something wouldn’t work, but because of what I learned to be the biggest obstacle in creating a game: scope creep. This is because when you get into the thick of making a game, you start seeing endless possibilities. What if we added multiplayer? What if there was a power up that sent you through a black hole? What if there was an online level creator?
You have to strike a balance in this situation. On the one hand, you have to realize that adding that killer feature might take months, especially when its just the two of you working for a few hours a week. You can always add it in later. But don’t squelch your creativity too soon! This is the fun part, and if you don’t listen to what your game wants you might miss something important! This talk by Jonathan Blow is something we came upon later, but I think it really speaks to the way you can find the right features by listening to your game.
What we came up with, to solve this problem was this: We gave ourselves a set period of time, about 3 weeks in this case, where we said we would implement any crazy feature we had in our heads in the quickest possible way. We tried a lot of things, and ultimately decided to put many things back to how they were before. We were able to let go of a lot of things only because we had been allowed to try them. Also, since it is our intention to continue making games, when we realized that certain features might not feel right in this game, we consoled ourselves with the thought that entire games could be built from the leftover mechanics we had explored.
Deciding When It’s Finished
So after all that, how do you decide what to keep? For this game we let our choices be guided by fun, which is only one possible way to make these decisions. It really matters what your intention is, and what you’re trying to achieve with your game. It’s nebulous and it’s only our version of fun anyway. In the end games are software, which opens up unlimited possibilities to what you can do and include. At this point, Jake and I are trying to fit ourselves into a software niche called “games”, and before we break out of the mold we think it’s important to understand that mold.
But enough mumbo-jumbo. How did we actually decide when it was finished? We did what most people do in this situation: we gave ourselves a hard deadline. A hard deadline means that no matter where the game is at that moment in time you have to release it. As a result, if you stay true to that deadline, you push yourself to get it finished in time. This is easier when there’s two people because when one person is trying to get out of the deadline, the other person can put their foot down. I feel that any task will take up however much time you give yourself anyway, so don’t put your deadline too far away. And once again, with software, you can always add more.
I really like what Rami Ismail of Vlambeer has to say about motivation. Basically, he says that motivation is everything for a small game studio. You can’t make a game without it. Even if you can’t program or do art, if you have enough motivation you can learn or hire people to make the game that’s in your head.
When our motivation wore down under stresses, blizzards and deadlines for our full-time jobs, we often shared with each other talks or writings of other game designers that inspired us. We kept an ongoing email chain of all the things that made us especially excited, and we hope to share this list in the near future. Additionally, Anne Lamott’s Bird by Bird is a great book about the creative process that we found inspiring. The book offers advice to writers, but is honestly some of the best advice to any professional creative person. It helped us to think up simple goals or events that would get us excited. We sprinkled those throughout our development calendar, especially around otherwise stressful times. We call them #pump-ups.
Another one of our biggest motivators was to get involved with the local indie game community. Luckily, since we live in Brooklyn, there’s a thriving scene here and lots of events. We started showing our game at Playcrafting NYC events which happen every three months or so at the Microsoft offices near Times Square. These events gave us deadlines where we knew we’d be showing our game to strangers, and one event even ended up becoming the deadline for finishing the game. This deserves it’s own section, but I can’t stress enough how important playtesting is for understanding your game and your audience. Don’t keep your game a secret. Show it to people often and early.
Paradoxically, what is even more motivational than going to events was finishing the game itself. Once the game was out there we started thinking about things a lot differently. It lit a huge fire under us. We started meeting even more regularly and working on our own a lot more. I’ll talk about this a little more in the final section, but this is just to say, if you have dreams of making games, nothing will get you more motivated than finishing your first game. I highly recommend it!
What We’d Do Differently
One thing I’d do differently is wait to start an actual company. Along the way we started an LLC, which took time away from the actual work of making the game. The flip side of this is that we’re all set up for the future and now we don’t have to worry about it. It also made us think about ourselves differently, in that it set our intention towards the future and towards making games in the long term. I guess starting a business is a lot like starting a band for software developers. It gives you a different outlook on the whole situation.
Another small thing is that I spent a lot of time vacillating between the options for different game engines. In the end it doesn’t matter - just pick one and go for it. I’m very happy that I know how to use Unity now. It’s probably got a bigger learning curve than some of the other options out there, but once you’ve got it you’re set for a good while. In my opinion, if you have the time and motivation, choose either Unity or Unreal Engine. They’re looking to stay dominant for the foreseeable future, and they’re in a price and feature war, which is great for developers.
We’re already working on two new games and putting what we’ve learned into practice. A big thing that this essay doesn’t go into is the whole process of getting the word out there. That’s something we’re still trying to figure out, but I think it’s fine to let this part slide a little bit, especially if your main goal is to finish. We didn’t do any outreach leading up to our release, and I think it would have overwhelmed us if we’d tried to do both things at once this time. If you want to know what I really think about “marketing”, I’d say you should go read 1,000 True Fans by Kevin Kelly and Purple Cow by Seth Godin. These sources pretty much outline how I plan to do outreach in the future. Anyway, I hope these thoughts were helpful or motivating or inspiring. It helped me to write it. Now back to making games!