Getting Started in Game Development

         I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the sixteenth episode on starting out your game design journey:

 Welcome to another episode of the Adventure Mechanics side quest.  It's me, Chandler.  Today, I want to talk about where to get started in game design.  I have been asked that question regularly, especially from people that are either new or intimidated by the idea of developing a game.  And it is a lot to consider.  Every aspect of your game must be considered and contemplated.  You need to be at least competent enough with your prefered language, engine, or whichever tool you have decided to use to make your game.  It's almost impossible to know where to start.  There's as many answers to this question as there are developers, but I think there's a common thread in each, beyond survivior bias.  Let's talk about some of the things you should consider when starting your game development journey.

The first questions I usually hear when someone asks about how to get into game design is, "what engine should I use?"  or, "what language is best for game development?" as if there is one single answer to these.  Simply put, these questions don't matter yet.  What is your goal for your game designs?  That's where you really should start.  Once you know what your goal is, then you can start answering the earlier questions.  If you have prior programming, art or music experience, these will also inform your answer.  Have you been exposed to a specific programming or scripting language that you're comfortable with?  Use that.  It doesn't have to be the most performant, the cleanest or prettiest language, or anything else that some newer developers will rail on about.  As a new developer, you should be more concerned about how to design a game, not losing yourself in the weeds of comparing performance benchmarks of engines or languages.  If you find yourself comparing how fast one engine does a loop over another before you have released your first game, you're not prioritizing your game.  Don't get me wrong, your first game is going to have to use something, even if it ends up being cardstock.  But fixating on tiny details and pursuing perfection over finishing your game will mean you aren't likely to finish your first game.  Accept that your first game is not going to be perfect and use it as your first step into the discipline, not the start of your magnum opus.  Of all the successful Chris Roberts types that end up in the industry, there are legions of people that pursued perfection at the cost of the good of their game and have not released their game as a result.  In the worst cases, they aren't developing games at all anymore.  I don't want more people to drop game design from this common trap.  Explore why you want to make games before you start searching for the tools to use to make it.  Just as RPG maker will be the absolutely wrong tool to make a first person shooter, using a specialized tool can hinder you as much as not knowing how to design.  That being said, if you end up opting for a general purpose engine, make sure that it has the support or tutorials that you will need to succeed on your first game.  The most powerful engine is useless when you don't know how to use it.

So, assuming you've figured out what to use based on your existing skillset, what type of game should you make?  To answer that, answer this question: What games are you interested in?  If your first answer is and MMO, which part of that MMO interests you the most?  Is it the combat, the social interactions or something else?  Most importantly, can you make an entire game around that one part of MMOs you enjoy the most?  As your first project, you need to make it as small as possible.  And building a fully featured MMO to rival what you played on Battle.net isn't small.  You're learning the basics of game design, so pulling from existing designs and focusing on it will help you learn why things you enjoy were designed that way.  If you adore your favorite game because of the world and everything in it and nothing specific, then look at other short games you've played and pull from them.  You need to be able to pull out one thing that you consider could be made into a complete game and work on that.  For me, it ended up being bullet-hell games.  I made a bullet-hell style game that didn't even have bullets.  Strange, I know, but from my prototype, Log Jam!, I learned a lot about designing games.  I never ended up releasing that game, but taking a game from start to end really opened my eyes.  It sparked a passion for designing games that I've been eager to share with others.  I'm not a fan of bullet-hell style games in general, but it was simple enough to copy and finish.

My experience brings up another important thing about your first game.  Finish it.  It may sound silly, but going through the whole process really will teach you so much more than having a stack of prototypes on your proverbial shelf.  The beginning of game design is intoxicating.  You're working fast on something new and interesting.  Everything you add to your game is making a huge impact.  Once you have gotten past that stage, though, the game changes aren't nearly as impactful.  Does this UI look better over the last one?  Maybe?  How could this card read to color blind players?  These type of questions are what you're going to be working through as you transition from prototype to polishing.  This part is just as import to go through as the prototyping phase.  Sure, it's not as fun, but this phase of game design is going to teach you so much more than exploring basic mechanics in prototyping.  How you set up a menu, how to make your game "feel" better, even how to get useful feedback from playtesters comes from this later polishing stage.  This is where you take your game from an interesting concept to a great game.  In earlier talks, I refer to this time as being in production.  You're not coming up with new ideas, necessarily, rather you are working with the building blocks you placed in the prototyping phase and finding ways to showcase the core mechanics you've come up with.  This is where you can really show the interesting parts of what you have and not just putting everything in place so you get a rough idea of what the game is.  The more time you spend in this phase, the better the game you eventually finish will be.

But what does a "finished" game mean?  That's for you to find out.  For some, it's when you can't think of anything else to polish and work on.  For others, it's when you're so sick of your game you almost want to delete it in disgust.  If you feel like this, by the way, just walk away from it.  Don't delete it.  And in some cases, it can become an evergreen project, where you can always add something to it to make it more engaging.  I'm sure you can think a game like this: A game that is seemingly always in early alpha and never seems to get to that coveted 1.0 release.  Whatever camp your first game ends up in, commit to an end point.  It can be as formal as you wish, be it finishing a road map, or as simple as a date.  Hold yourself to this and when you reach that end point, set it down.  It may not be the best feeling to leave your work like that, but it's important to hold yourself to it.  Listen to my talk on accountability on why that particular point is important.  Or, if that doesn't work for you, look at what you consider a finished game.  Then apply that criteria to your game. If you find that you've already passed that criteria, odds are you're already done with your game.  Knowing when to quit is one of the harder things to learn, especially when you're working on a passion project or artwork.  Yes.  I do consider that games can be artwork, although that's a talk for another side quest.

There's a whole lot more advice that I could give in terms of getting started in game development, but I'm going to call it here for now.  It's best that I don't end up repeating myself, after all.  As always, if you have questions or have a comment on this podcast, let me know.  You can post it on our website www.theadventuremechanics.com or to me directly on twitter with my handle @jcsirron.  This has been the adventure mechanics and I'm Chandler.  I'll talk to you next time.