Lessons learned as a greenhorn dev

A little over a year ago I started on an independent game development adventure with Zenzizenzic. I began with knowing virtually nothing on coding or anything that goes hand in hand with game development. All I had was 15 or so years of experience of just playing games, which gave me a fairly decent sense of what feels right in a game. Now, a year later, I know a little bit more. The following will tell of a couple of (hard) learned lessons, which may prove to be of some value to those in a similar position as I was a year ago. It's all just advice and opinions, nothing is fact, so take it as you want. And inexperienced or experienced, either way I'd love to hear your thoughts!

Keep it small

When I began learning to code and working on Zenzizenzic I quickly realized that I would have to start small, as small as possible. But starting small isn't actually the greatest challenge, keeping it small is. It's not that difficult to not start out with building an MMO, it is however to keep your 2D platformer contained and decide not to add three difficulties, dozens of different pickups and collectibles, five worlds with twenty levels each and six playable characters. Before you know it you're working on a game for two years, which should have taken much less.

Set out goals

This also relates to starting out with a clear goal in mind, and sticking to it. However, if you're like me and you didn't know a whole lot about approaching the task of building a game, it is difficult to set a starting goal which can see you through until the very end of the project. In that case it is especially important to keep the scope of your game limited and focused. Setting goals throughout the project has helped me a lot to come to grips with the challenges I had to overcome. Questions like "How do I save player data?", "What happens with my UI on different resolutions?", "How can I switch between controller and keyboard/mouse inputs organically" or "How do I optimize my code?" (which is a particularly nasty one when just starting out) were tackled one by one. Bite sized challenges allow for small personal achievements, which help tremendously in keeping up a positive attitude towards development. It keeps it all manageable and prevents that overwhelming feeling of where the hell to start. It differs from person to person as to what result the act of setting and reaching goals has, so it's all up to yourself and your own preferences on how to manage those goals and their specific aspects, like timetables. One person might do good with long term goals, the other has a better working experience with short term goals. All I can say is, try to find your own balance. But really do try to find it.

Gaming literacy

In the intro I already mentioned it briefly, but one thing that proved vital is indeed knowing what feels right and what doesn't. This isn't really something you can learn over a fairly short period of time, like a year or two. This is something you have to internalize, make it your own, and continuously build upon. You aren't ever done learning what makes a game feel right. And a danger is stopping on improving that experience and knowledge base. How to prevent that from happening? Just play games. Expanding on your "gaming literacy" can be considered as a vital part of your game design and development proficiency. It was for me, hell, it was all I had and it served (and still does) as a great foothold throughout.

Experience

So what to do about that certain stifling aspect of a hard lack of experience? With experience comes things like foresight, knowing well ahead of time what certain design decisions will mean for your game, or management, how to structure your project, or having a network for press coverage, or already knowing what kind of workflow you're most comfortable with. These things come with hard earned experience and there isn't an easy way around it. Over the past year I have taken on two attitudes to address this "problem". The first concerns being experimental. This simply refers to poking things, seeing what happens, dealing with the results and poking it again, over and over. It's a lot of trial and error, and this approach asks for a certain degree of curiosity, hardheadedness and forwardness, but what you learn from it will stick with you. It's a slow and meticulous process. The second attitude is brute forcing it. Just doing what at that point of time feels right and rolling with it. You'll get quick results, but don't be surprised when you have to restart the project from a clean slate. I had to do that twice early on with Zenzizenzic, and I probably should have done it once more. Having to rebuild your project from scratch may feel like a setback, but it's not. Your final product will be all the better for it. Old code will be cleaned up (you don't really want code in your project which dates back to when you just started out), working through the project will be more comfortable and you'll be more confident with the results. Between these two attitudes it wasn't a case of either-or. Both have their place and both can be applied effectively. There is no right or wrong, just be conscious of what you're doing.

Feedback

Value feedback, value it tremendously. With how opinionated the internet is, it is surprisingly difficult to get solid feedback. Try your best to accommodate for it. Have a clear place people are directed to when they want to spill their thoughts. You could roughly say feedback can come from four sources: the public (just regular players), peers (other devs), testers and press. Feedback from the public can be qualified as quantitative data. Often this doesn't come in words, but more in the shape of likes, follows or possibly in-game gathered analytics. The press and peers are valuable sources for qualitative feedback, which is valued on its depth and argumentative structure. Don't expect to receive this kind of feedback from the public. Getting feedback from peers can be done through forums at all times, while feedback from press is of course restricted to when you send them a build and if they feel like writing about your game. I haven't had a lot of experience on structurally using testers. All I can say on that is that you need to find the right people who are willing to spend time on your game and let you know about things that could be better. Also, be sure to structure the testing phases of your game and divide it into portions so attention to bugs and stuff is focused and not diluted over too wide an area.

Reach out

About finding people, it's important to reach out. There are a lot of people out there who will help you, support you, maybe even collaborate with you. All you have to do is let people know that you exist. And it's made horribly and excitingly easy to do so these days. Hop on Twitter, follow people, interact with them, and results will come, promise, just stick with it, be persistent. Send emails to other developers you admire, ask for a quick word of advice (note 'quick', don't write them an essay). They all have their own story and there are valuable lessons to be found there. Also, don't be a dick while reaching out. Be friendly with the people around you. Don't go and burn bridges you might not even know exist. They might prove to be useful in an unexpected way.

Passion and determination

Now, what makes me a creditable person whose advice you could follow? Have I had any noteworthy successes? Is my game on Steam and selling thousands of copies? No, such goals are hard to achieve in a year. Just see me as a guy who is giving it his all and is absolutely determined to make the most of a project he started passionately without knowing a damn thing. And in the end that might just mean everything: passion and determination.