Getting Started in Game Development Part 2

             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 twenty-second episode on tooling for your game and keeping your game in mind:

Welcome to another Side Quest for The Adventure Mechanics.  I'm Chandler.  If you don't know, I run a game design group that talks about game design theory and showcases progress on the games each person is making.  It's that one form of accountability that I find most helpful, even though sometimes I don't live up to my ambitions.  As new people join the group, I find that they tend to ask very similar questions, especially if they are trying to break into game development as a career.  As such, I've been thinking about how I can help them figure out how they can get into the industry and potentially land a job at a studio.  Today, I'm going to build off of my last installment of getting started in game development and explore considerations on how to grow both your skill set and your hire-ability after you've taken your first steps into the game design world.

So, in the last installment, I spoke as if you just started your journey.  It covered surveying your existing skill set and looking at types of games that would be best to work on to get you started.  That includes breaking down your first game into the smallest pieces possible to ensure that you actually finish the game.  Using that as our starting point, let's take a look at the next step: building upon that first game and taking your second (and third) step.  What could the next step be?  Iteration.  Getting your first game out is a huge first step, and not an easy step to achieve.  And although that first step is rough, it's not enough.  You need to go back and build another game.  I know, you just climbed the mountain once, why do it again?  Well, if you want to work on games, that's your life now.  You might as well get into the groove of things and practice, practice, practice.  And that means the whole thing: Prototyping and pre-production all the way through to release and support need to be practiced.  You don't want to be the buff person at the gym with chicken legs, do you?  All those muscles need to be exercised.

Let's say you don't want to go back to the blank page of a new project, though.  What else can you do?  There's a few options, but my personal go-to for iteration practice is a game jam.  I've spoken on them before, but they really are going to be the fastest way to get through an iteration and expand your skill set.  Many even provide either theme or mechanic guidance so that blank page isn't as intimidating.  And with jam calendars on sites like itch.io, you can comb through and find a jam that both fits your goals and time frame you're looking to work on a new project.  They really are a powerful tool to build your game design muscles.

Although they are a very quick way to expand your skill set, they are also exhausting.  Pacing yourself on the number of jams you join per year is a must.  When I first entered into a jam, I was hooked.  My first Ludum Dare was a mess, but it was fun.  I wanted to do it more, so I participated in the next six consecutive mini-Dares, which were tiny monthly jams.  Needless to say, I burnt myself out by the sixth one.  In order to get myself back into balance, I took a few months hiatus on game jams.  If you want to participate in jams, great!  In your preparation for the jams, make sure you're giving yourself enough recovery time between jams, and possibly more importantly, time for real life, too.  Designing games is fun, but you're human and need to take care of yourself first.

One objection to the concept of game jams is the competitive aspects of them.  You are technically competing either against your last jam or others, if the jam is rated.  That can be overwhelming.  I get it, competing, coupled with the short time frame to get your game out is intimidating!  It can easily force you into a grindset that can and will quickly exhaust both your enthusiasm and your will to continue.  Game jams aren't for everyone.  That doesn't mean you don't need to iterate on your design skills, though.  It just means you need to find a lower impact way to get your iterations in.  You can still use a game jam as inspiration, especially if the blank page problem plagues you, like it does for me.  Pull from game jam themes, or use sites like https://letsmakeagame.net/game-jam-theme-generator/ to generate a theme to work with.  There are also jams that focus on mechanics instead, if that's the way you prefer to work.  Once you have that figured out, you need to design the game. Avoid putting code to your project at first.  Really dig into your game and flesh it all out, noting each mechanic, a list of artwork needed, story beats that need to happen, et cetera.  Once you have that laid out, you want to set a deadline.  This is important because you're going to need to make an endpoint where you need to put the proverbial pencil down and walk away from it.  And if you want to design games, walking away from a project *is* as skill.  Learn to manage your game projects and stick to what project manager-you laid out.  You need to make multiple games and finish them to be a full-time designer.

One other way to get iterations in without using external prompts is to revisit previous designs.  There's no shame in going back and taking another iteration on one of your previous designs.  It does require you to have previous designs, however.  Make sure you write down game ideas and key mechanics whenever you have an inspiration.  That way you'll have a design backlog to work from.  Once you have that backlog, be it previous completed games or just ideas, there are a couple of ways to revisit a design.  You can wipe the slate clean and redo the work from the ground up.  You can also pull the previous version of your game and do a combination of refactoring and augmenting your previous work to expand on it.  Both approaches have merit and drawbacks.  The clean slate approach allows you to build up a new structure, bringing in the lesson from the previous iteration to make a potentially stronger framework.  The augmentation approach allows you to practice revisiting previous work and getting back into the mindset when the old framework was designed. Obviously, if you are only working off of one of your design ideas, then you really are just looking at it with fresh eyes and will need to start from the ground up.  Whichever method you end up doing, you'll still need to go through the whole process that I previously described.

And remember that whichever way you choose to build a game, stick to it.  You need to build and finish games.  That's the designer iteration cycle.  Each game needs to be taken to it's logical conclusion, even if that conclusion ends up being dropping the game and retiring it to the backlog.  Getting too attached to a given design puts you at risk of stagnating and putting you that much further away from going full-time as a game designer.  If your goal is to go full-time, you need to have your portfolio.  And in order for that portfolio to be built, you need to complete games.  Building one game *technically* makes you a game designer, but if you want to make a career of it, you need to have more than one.  Like in the TV and movie industries, the best known actors are the ones that are in a lot of shows and movies.  The same applies for game designers, especially since games are a hit-driven industry, too.  You need to start making your portfolio to show both the skills you have and the style you've developed as you design games.  If one of the methods you choose to build games doesn't work, try a different one.  There's no shame in abandoning approaches or tools that don't work for you.  At the end of the day, it's only a failure if you both didn't learn from it and it caused you to quit.  Trying again and again is what distinguishes a real designer from one-shots.

Anyway, that's the main thrust of what I wanted to cover in this Side Quest.  As always, if you want to ask a question, leave a comment, or commiserate with the challenges of designing games, you can reach out to me on various social media with my handle of jcsirron or leave a comment on this episode.  I am curious what your experience has been in the industry, be it from a hobbyist perspective like myself, or all the way up to a project manager on a project overseeing hundreds of people working towards a triple-A title.  This has been an Adventure Mechanics Side Quest and I hope to talk to you next time.

Keep your eyes on the prize

            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 twenty-first episode on tooling for your game and keeping your game in mind:

Welcome to another The Adventure Mechanics Side Quest.  I'm Chandler. I am rarely a social media person.  I know, that's weird coming from a podcaster, but it's true.  I do lurk in a number of game design forums, though.  One thing that came up on Reddit prompted me to consider this question:  How much time should you spend on your tools?  At what point does your toolset become work on building an engine instead of building a game?  These are important things to consider while working on your design.  After all, if you're building an engine, you're not building a game.  Let's talk about how you can find a balance between working on your tools versus working on your game.

Tools are great.  They can, when done with the game in mind, cut down drastically the amount of time it takes for you to put in new story elements and other content.  But they shouldn't be the main thing you're working on, especially while you are in production for your game.  During prototyping and early production, sure, spend time working on tools to speed up the rest of the process.  Keep in mind, though, there's a limit to how much return on your time you'll get from spending more and more effort on your tools.  The more time you spend working on your tools doesn't necessarily correlate to the less time spent stitching everything together.  Is that fancy UI for your tool useful?  Sure, but if you spent weeks working on it to get it just so, is that time worth it?  Maybe not so much.  On the other hand, is the dialog creation tool important to get right for your visual novel or long RPG?  Probably.  It's important to know where you should and should not spend time when it comes to working on your tools.

Let's say that we're building a metroidvania.  Before we go into tooling, let's ask what the main focuses of our game are.  Is a deep and complex dialog system part of it?  If we are following classics like Castlevania, probably not.  What about an intricate and expansive map?  Absolutely that's important.  In these two examples, we already know where to focus our time:  In making map chunks easier to generate.  We can spend just enough time on the dialog system to be functional, since it's not one of our main focuses.  That map generation tool has to be fully featured and ready for us to spend a huge amount of time in.  That means we need to make sure it has all the features we want in it before we start production.  Planning comes into play here to determine whether we have the power we need in our tool, or not, to get all the features we want into the map.  During prototyping, we will want to make a test area with the tool and make sure it has all the capabilities we need for all the challenges we plan on putting into the map.  Importantly, that doesn't mean building out the entire map, but rather making a sandbox that covers the basics of each challenge we plan on putting in.  Most importantly, we need to make sure our map generator can do this easily and without fighting with it do get the areas working.

Where do we stop working on our map generation tool in this example, though?  That's a tough question.  The obvious place to stop is when we implement that last feature we need to get the map generation working.  Is this tool going to be the basis for all of our projects going forward?  Then we will have another bite at working on it in future projects.  Leave notes on places to improve for you and your team.  You may get to them, you may not.  Future you will appreciate past you doing this if you touch it again, though.  On the other hand, if this tool is going to be paired with the release of the game, we are going to have to spend more time polishing it and making it ready for wider consumption.  This brings up one thing that I implied in this section:  That tools don't need the same level of polish your game does.  An internal-only tool looks vastly different than a tool you expect a wider audience to use.  Meaning, an internal tool can be rougher and have bugs that, although ugly, don't affect the functionality of the tool.

A tool for wider consumption, however, needs to have a nicer workflow and be ready for people outside your team to be able to work with.  It needs to have the help files updated and current.  It needs documentation on most, if not all, of the expected workflows.  It needs to have the vast majority of the crashes ironed out and fixed.  Polishing tools to this level is non-trivial.  Ideally, all of our tools would be up to this level.  But that effort needed isn't going towards the main show, that metroidvania we are working on.  Unless we plan on selling the map generation tool, polishing our tools (heh!  I'm so mature for laughing at that...) should only get one or two passes, at most.  Tools are needed for generation and should work, but at the end of the day, players won't care about our tools if we don't release them and our game sucks.  Our priorities need to take this into account.

 So, we defined clear areas where we shouldn't work more on tools and where we should.  What about that grey area in between? Well, if you haven't caught it, yet, where I tend to stop is where the benefit of adding a feature is less than the time cost it takes to build that feature.  And to a certain degree, the same applies to bugs, at least for me.  Tool-breaking bugs obviously need to be fixed, but if the bug can be worked around with little effort, or are only encountered in edge cases that won't be encountered in your game, can be noted and worked around.  Each time you look at changing the tool, after the initial build, obviously, you need to consider the benefits of adding it versus getting your game one step closer to finishing it.

There is one caveat on this methodology is that it assumes you are building a finite game, not a lifestyle game that you'll be working on a decade (or longer as the case may be).  Tooling in this context has significantly different considerations and is a topic all on it's own.  And considering that I'm just a hobbyist developer with literally no experience in either playing or developing a lifestyle game, I'm probably not a good resource to pull from in the first place.  That being said, I suspect that a number of considerations I've laid out here will still apply to that style of game.

I think this is enough to get started really thinking about your toolset and leveraging it to make your game.  As always, if you have a question or comment, you can either find me on various social medias as jcsirron or leave a comment below.  I'd love to hear your experiences with tooling and game design.  This has been another Adventure Mechanics Side Quest and I'm still Chandler.  I'll talk to you next time.