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.

Getting to "good enough"

            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 twentieth episode on working on getting to "good enough":

Welcome to another the adventure mechanics side quest.  I'm Chandler.  For this side quest, I wanted to talk about getting a specific feature for your game to good enough.  By that, I mean getting your game into a good enough state that you are both satisfied with what you made, yet it doesn't bog you down working on one feature for so long you risk derailing your project entirely.  This came up because one of the participants in my game design forum asked about it.  I initially struggled with a good response to it, so I had to sit and think on it before I had a satisfactory response.  That being said you get to reap the benefits of this question being asked.  So, let's talk about getting to good enough.

When the person in the forum asked about getting to good enough specifically they were talking about getting one mechanic, or I think feature rather, to a good enough state for play testing purposes. Obviously, this is a subjective opinion on what is good enough. So, this is going to depend entirely on you as a game designer. This is a different question than asking if you can use outside resources to accomplish what you are looking for in a given future or mechanic.  I know I previously talked about using existing resources to make a complete game, but this is the flip side of that. We are looking at the core parts of your game that need to get your special touch to really make it your own here.  That means we are looking at the core part of your game that should absolutely be custom designed for your game specifically.  If the core of your game is about farming, for instance, you would want to spend a good majority of your time looking at the farming mechanics. And this is where using outside resources is going to make your game feel more generic. If, however, you spend the majority of your time looking at the core mechanics of farming and forget the rest of your game, Your game is going to feel horribly lopsided and probably incomplete. So, how do you find that balance between asset flipping and or mechanic flipping and sacrificing the rest of your game as a whole for one feature or mechanic? This is going to be your call as a designer.

What does good enough look like?  For some, it's going to be the mere presence of a feature or mechanic. For others it's going to be that feature in a completely finished and polished state. For the purposes of this talk, however, it's going to be somewhere between these two. Not every feature needs to be completely finished or polished , yet it will have to have more than just it's mere existence in the game to be considered good enough. Now , this leaves a huge chasm of wiggle room for you as the developer to work in. What's good enough for me may not be good enough for you. And that's kind of the point of this talk. How can we get you to your good enough state? It's not good enough to compare yourself or your games to a finished one when doing this . I would argue that that is actually actively harmful to you as a designer . If you are comparing your metroidvania movement set to castlevania Symphony of the Night, for example, you are going to put yourself at risk of failure . I say that because Symphony of the Night was made by a very large team over a course of years I believe. If you are a solo developer, you are never going to reach that level at the same speed. Instead, you are going to want to look at the small pieces that you can change and compare those to how you want them to feel. I know that's going to be somewhat difficult, especially if you are looking to make that metroidvania to rival Symphony of the night , but it will be more useful to look at features in isolation as opposed to the game as a whole.  Let's talk about some of the rules that I have for getting a feature or mechanic to good enough.

The first rule that I have is to do a future or mechanic in multiple passes. I don't know about you, but I struggle to have the best idea for a mechanic the first time I come up with it.  There's a phrase in life that I've come across that says, "If something is worth doing, it's worth doing right the first time."  And I'm not necessarily certain that this is useful when it comes to game design. After all, sometimes an idea needs to have more time to figure out what it wants before you can call it complete.  A more useful phrase that I've found is, "If something is worth doing, It's worth doing halfway." Now this doesn't seem like a great way to design something (I.e. doing it only halfway or getting it halfway done), but it is useful in a game design context.  It seems counterintuitive, but giving yourself the space to fail on a given mechanic or feature will allow you time to revisit it in the future when you figure out what was missing from it the first time around. And allowing that failure state, for lack of a better phrase, is going to allow you to play with the feature more later.  Failure states aren't necessarily bad things, especially in game design.  You need to allow yourself to fail at some level.  Game design is hard.  This rule is forcing you to "bake-in" the times where you will fail.  It's not that you are leaving that feature there permanently, it's more that you are giving yourself the ability to walk away in the first place.

The second rule that I have when designing a feature or mechanic is to leave it in a state that can be shipped. In the context of the video game, that means even if it's not perfect , I can still get useful feedback out of it if I release it as is. This is important because you always want to have your game in a playable state . I know I just talked about that, but this is a really important thing that I will never not harp on. Leaving it in a shippable state means that you will have at least the latest iteration of the idea that you had for a feature or mechanic. If it's in a broken state that you cannot play, it is of zero use to you or your players. It also looks bad on you as a designer , as if you didn't consider that feature or mechanic as important. Just go take a look at any early access game that was abandoned and, if you're strong enough, look at the reviews of that abandoned game. You will see a lot of very salty players venting about how a mechanic wasn't "done" or "broken" or "missing".  Now, to be fair, many games in early access are abandoned for a variety of reasons, so it's not exactly fair to look at them as an example of what not to do. But, the point I'm trying to make is if those mechanics were left in a relatively stable state , even if they were able to be exploited in some way shape or form , the game is still playable. And that's the main point of having a feature ready to ship. Even if it ends up getting pulled for not being relevant, it's still there for somebody to look at and engage with. And that's kind of the point of this rule.  You need to make your game as complete as you can at any point. Obviously, this doesn't really apply to prototyping, but even there having a rule of leaving a given game idea in a playable state helps. Nothing sucks worse than having to play detective on your own game prototypes.

The third rule is more nebulous. Whenever I am frustrated, or annoyed, or blocked in some way, on a given feature or mechanic, I will step away from it for a short time. For me, that's usually a week or two. And then after that time away, I'll take a look at the feature or mechanic that was giving me problems and try again. Just because a mechanic or feature is "good enough," it doesn't mean that I'm done with it. I know a lot of artists of various types will never consider their works "done".  I am one of them.I guess the rule here is to walk away from a given mechanic or feature after it blocks you. With the caveat that you're going to need to leave it in a playable state, this is useful because it will allow you to let these slower parts of your brain ruminate on the issues you're having with that feature or mechanic. And you may come to the conclusion that what you have now is fine. That's great. Other times, you'll realize that you need to take another pass at that mechanic and give it another go. That's also fine. Sometimes you just have to sit on a problem to really find a satisfactory answer to it. And if game design is anything, it's a series of really hard problems.  However you get to good enough is entirely up to you. Just remember, your definition of good enough isn't going to be the same as your players. You will want to adjust accordingly.  But that's for another talk.

This only touches the surface of what I consider important for good enough, but I think it's a good start. If there's enough interest in this topic for another talk I'll get a little bit more into the weeds on it. That being said, this has been the adventure mechanics sidequest on getting to good enough. As always, if you have any feedback or any questions on this side quest, you can reach out either below this episode and leave a comment, or talk to me directly on mastodon.gamedev.place.  My handle there is @jcsirron. I'd love to talk about most topics game design related.   I'm Chandler, and I'll talk to you next time.

Always have a playable prototype

           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 nineteenth episode on working on your game development weaknesses:

Welcome to another adventure mechanics side quest. It's me, Chandler.  Today I wanted to talk about something very important to do as a game developer, but many don't actually do.  I'm talking about always having your game in a playable state.  Sure, a lot of developers usually have *a* version ready, but they then fall back on, "Oh, this isn't the latest version," or "Just wait until you see the new version I'm working on!" whenever someone asks about where their game is in development.  I am not immune to this, either.  If you've looked at my itch.io page, you'll notice that the last version for Cartogratour is from June 2021 (!), a full two years ago.  That's not a great look, honestly.  What can I do to remedy this?  By always having my playable prototype up to date and ready for feedback.  Let's talk about always having a playable prototype ready for play testing.

Right now, Cartogratour is in *exactly* the same state I said they should not be in.  The features that I have been working on are in various states of completion, from half-baked to barely mixed together, to say nothing of even touching the oven.  That's not great in terms of being presentable, is it?  No one wants to play with unexplained features or grapple only partially implemented functions that are supposed make the core of the game.  And because of that, there my last version sits, unloved and unplayed.  Players that are into development want to be part of the game development journey, not anxiously waiting for a new build that will never come.  That means I need to get a new build ready and out.  But what is going to go into this new build, or more succinctly, how do you determine what goes into each update?  Let's take a short aside and talk about that.

There are a number of schools of thought on what should go into updates, ranging from a constant rolling update train, to well curated semi-annual events.  It's up to you to decide your release schedule, but have an idea for how big you want your updates to be.  Are you early in development, where each feature is groundbreaking and need to have that new feature attention and bug fixing?  Or are you later in the development cycle where it's content time and prodcution can take a while to get everything just so?  That will determine where you want to cut off features for your builds, then.  Obviously, earlier in the cycle means you want attention on your idea, and making a new build each time you get a new feature mocked up and ready to be played with may help you start building an audience and testers.  Be careful when doing this, however.  As I mentioned in my talk on getting feedback, everyone will want to suggest changes, many of which will end up radically changing your game, sometimes for the worse.  You need to be confident in your feature design and show the people playing your build your vision, not give thme a blank slate to project their desires onto.  If you aren't sure about a feature and need time to explore it more, don't include it in your build.  If, on the other hand, you want some more eyes on it for whatever reason, wrap it up into a build and start looking for feedback.  That's the fun part of game design:  You can get feedback on it and see where it takes you.

As you move further into production and (hopefully) have all your features fleshed out, if not complete, you may end up having to wrap your builds around content instead.  This is both exciting, since you're marching towards the completion point for the game, and terrifying.  Is all that content in this build enough?  Did you put enough into it to satiate your audience's need for content, while not expending everything on one update?  In this context, I'm thinking of one particular character's story arc, especially if it requires many pieces to be in place before it can all be revealed.  In that case, it may make more sense to break up that arc into smaller pieces that can be mixed with the other pieces as they are completed and have the arc follow production that way.  It's going to be up to you to try to figure out how to handle that Gordian Knot if you decide to chunk it that way.  Planning out content releases end up being a lot harder, at least to me.  Looking at my games, though, that's probably not surprising. These aren't the only way to divide up how you make a release, but are merely useful ways to structure your releases.

Now that we've looked at how to parse builds, why would you want to have one ready at all times?  Simple: you want to be prepared to give your game to someone at a moment's notice.  Think of it as preparing for success.  If you get an opportunity to showcase your game and potentially get feedback or build a fanbase, why would you want to show your older stuff?  It's giving your game a bad foot to show off if it's not the latest thing you've been working on.  Granted, I've said that there are going to be some compelling cases where you won't want to include everything in a build, but that doesn't mean you should be holding back on making builds that best reflect the current state of your game.  If you feel that the one feature you've been working on is far enough along to showcase, spin up a build.  Worst case scenario, it's not quite what you want and gets some unhelpful feedback.  Even that can get more eyeballs on your game, even when it's not done or ready for prime time.

There's another reason to have your game ready to be played at a moment's notice.  I don't know about you, but every time I fire up my latest version of my game, it makes me want to work on it more.  And when you're in the content mines making yet another quest, mission or whatever and it's dragging you down, that little bit of motivation may be exactly what you need to get over this particular hump.  That's not to say that it's going to work every time, but the one time that it does and it prevents you from quitting is a success story in my book.  And if you've stuck with me in these rants, you'll know that I want to get more games across the finish line and developers moving onto their next game.  At the end of the day, being able to show your work with pride may be enough to keep you chiselling away at that proverbial block and exposing the sculpture that is your game.  I'm waxing a bit poetic, so let's get back to the talk at hand.

The last reason you really want your game always playable is to be prepared to show it off whenever there is a good chance to do so.  You don't want to be caught flat-footed and miss out on showcasing your game when the ideal opportunity arises.  In the same vein, sometimes opportunities will present themselves for you to be the first in the door to have your game reviewed or plugged.  With a hit-based industry like gaming, each and every opportunity you fail to capitalize on will potentially limit your game's reach when it comes time to release it to the public.  And that means your game is going to wallow in obscurity, along with a mountain of other games from equally talented people.  Seriously, look at your favorite genre on itch.io and scroll for a while.  You'll see games that absolutely deserve to be recognized, but aren't for one reason or another.  Make sure your game doesn't fall into the same fate by making sure you're ready to have the latest version playable at all times.

And on that note, I'm going to be releasing the latest version of Cartogratour at the same time this episode goes live.  It's a current snapshot of everything that I have sufficiently done up until this point.  There's a number of things missing, obviously, but it includes a basic NPC that will wander around the town tile, a proof-of-concept conversation system that you can progress and a few other things that I'm not going to mention.  Go take a look!  You can find it on my itch page jcsirron.itch.io.  If you want to leave a comment, suggest a topic, or something else, you can post them on our website, theadventuremechanics.com.  This has been the Adventure Mechanics, and I'm Chandler.  I'll talk to you next time.

Working On Your Weaknesses

          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 eighteenth episode on working on your game development weaknesses: 

 Welcome to the adventure mechanics side quest, it's me, Chandler.  For this month, I've committed myself to focus on one solitary thing for Cartogratour: Art.  I've committed to this because I feel like it's needed at this point. I have the bones for much of what I want in the game and I've kinda hit a doldrum of sorts. I was inspired by a game jam that I entered mid-April which was just doing a mockup of an imaginary game. It was called the mockup game jam. Original title, I know, but it helped me personally practice making artwork for a game. So, let's talk about practicing things you aren't good at in game design.

We should probably start by talking about how to take an honest inventory of your skill set. Meaning, you need to look at your previous work and evaluate yourself. Some things are going to be really proud of, other things not so much. And don't just do it for your last game, you should do it for every game. The primary thing to remember is that you did the best that you could after the time.  A faultless self-inventory, if you will.  Game design is a skill, after all. The best way to learn is to evaluate what you've done and how you could improve it. A useful metric to judge yourself by is what the Ludum Dare rating categories use for the compo. They are: overall, fun, innovation, theme, graphics, humor and mood. You don't have to use these metrics, but I have found them extremely useful in judging my own works.  I'll post some of my post-mortems for my game jam games into the show notes for those interested. If you find a metric that works better for you, great. Just be consistent with it when judging your previous works.  Comparing by using one methodology to another using an entirely different one isn't going to help you.

Nobody is a perfect developer i.e. No one can make an entire game by themselves and have it turn out exactly the way they want it to by themselves.  That inlcudes the savants that hav made their dream game and released them by themselves.  With the wide spectrum that game design touches, this is to be expected. That doesn't mean we shouldn't practice all of our skills, however. There are certain blind spots that all we will have in game design that we should be not only aware of, but willing to practice to get better at. For me, personally, that's artwork and anything audio related. Sound effects and music both mystify me, despite my best efforts. The music that I make for games ends up looping horribly and sounding like a child playing with a xylophone.  Although I have some experience making decent sound effects for games, most the time the sound effects come across completely different than how I imagined them.  Same with making art. I can do characters relatively okay, but doing world design and generating textures for said world is beyond my average skill set.  Don't get me started on concept art that I produce.  I don't think I've made anything I've been happy with in that department.

Programming, on the other hand, I'm pretty decent at. I've done coding on pretty much every project that I've worked on thus far. I feel like I have gotten a pretty good grasp on how to go about the design process and actually implement it. Not relying on a game engine has forced me to become quite proficient at figuring out how to make a given mechanic. It has also given me a low level understanding of how to implement a graphics library and other fundamental things that a decent game engine provide for you out of the box. I have found that immensely useful and it has worked for me.  I have also exposed myself to several game engines on top of working close to the processor.  Although limited to working with them on game jams, I've worked with both Unity, Godot, and Game Maker.  Each has their own strengths and drawbacks, but they don't really scratch the programming itch for me for some reason.  I just love working at that low level and coming up with elegant solutions.  The parts that make a game engine run just fascinate me. That being said, only build a game engine if you want to learn how a game engine works. But, that's a talk for another time.

So let's say we've gotten all of our strengths and weaknesses figured out. There are a number of ways to improve them, ranging from focusing an entire game jam on just one or only a few weaknesses, to only spending an hour a week on it as focused study. Make sure that you aren't overwhelming yourself by adding an additional amount of work that you aren't prepared for. But also, make sure that you're giving enough time to work on your weaknesses so that you aren't just saying you're working on them. The goal of practicing with them is to focus intentionally on your weakness and making it an asset. However you end up practicing, make sure that you are consistent about it. After a week or two, or whatever length of time you feel is appropriate, go back and look at your progress from that time period. If you feel you have made enough progress improving, you can always choose another skill to focus in on. Continue on doing this until you feel like you have become a well-rounded game developer. I say that as if that's an easy thing to do.

One way to encourage you to work on your weaknesses is to give your self a little treat to work on after you've reached a milestone in your practice.  One of the developers that I regularly chat with does exactly this.  They will give themselves a month long goal to focus on for their project, and then work on something art related when they finish their goal.  Applying this methodology to practicing a weakness is pretty straightforward.  If you are weak in one field, make a goal for yourself in practice terms, such as making a certain number of character studies or something, then you can do a bug bash, or add some small feature that you want to put into your game as a reward. It's been a pretty effective method for me to do personally, but there are some things you should remember about this when working on a weakness.  You have to make sure that you don't half-ass your efforts in improving your skill.  The popular phrae, "practice makes perfect," is somewhat misleading.  It's more like, "practice makes permanent."  Meaning, anything you've practiced will be become the first way that you will approach the skill.  If you practice your weakness in a sloppy or lazy way, that laziness will only be perpetuated when you use it in the future.  Make wise use of your practice time.

So, in terms of me becoming a better developer, I'll be focusing in on artwork this month. Specifically, I'll be working on mockups for the mini games that I want to put into Cartogratour. I've been threatening this for a while now, but I'm going to be using the energy I got from the Game Mockup Jam and springboard back into Cartogratour. And as another form of accountability, I'll be posting the results of this focused time onto my personal blog for all to see. I'm not sure whether I'll post them on a weekly basis, or in one big dump when I finish the month.  It's not exactly a huge amount of accountability, but I feel like that will be enough to get me to want to actually post what I make. And if you want to call me out on not actually posting, go ahead! I need the kick in the butt to actually finish Cartogratour. And, who knows, I may actually want to work on it even more. Only time will tell, however.

That's about all that I wanted to talk about in terms of working on your weakness in game design. As always, if you want to leave a comment, ask a question, or anything else reach out on various social media. My handle is @jcsirron on Twitter and Mastodon. Or, you can always leave a comment under this episode on our website: theadventuremechanics.com. this has been another Adventure Mechanics Side Quest and I'm Chandler. I'll talk to you next time.

Starting market research for your game

         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 seventeenth episode on starting market research for your game:

Hello and welcome to The Adventure Mechanics, this is another side quest.  I'm Chandler.  Today I wanted to talk about doing market research for your game.  I know it's not the sexiest thing, but it will mean the difference between your game being moderately successful and an utter failure.  After all, there are thousands of games being made right now and I'm willing to bet that you don't know about the vast majority of them.  Let's talk about doing your research before diving into that next game design, so you don't end up disappointed when it comes to release.

So, how do you do market research?  It starts with knowing what your game is.  Are you making a puzzle-based metroidvania?  Then you should look at both puzzle games and metroidvanias.  Is your game harder to define the genre for?  Then you'll want to spend time nailing down what, exactly, genre your game falls under.  You want to make sure that you are casting your net to be as broad as possible at this point to cover the most potential audience that you can.  Why do it this way?  Because it gives you most optimistic picture as you go about defining your audience.  And that's important because if your game is requiring a certain number of people, and your market research says that your audience is smaller than that, it's a pretty good indicator that you shouldn't be building your game.  At least not in the way that you have it currently.

That's not to say that you should define your game so broadly that you're not going to get useful information out of research for it.  If your game falls into the genre of survival crafting, for instance, try to narrow it down a little bit further.  Yes, there are a lot of games that fit that genre, but you're not going to get a whole lot of useful information out of your research if your delta is so large that it can be anywhere from zero to infinity in terms of audience.  In the instance of survival crafting, think about what theme you have for it.  Is this an environmentalist survival crafting game?  Then include the environmentalist tag in your search.  Is it zombie themed?  Put that zombie tag in your game search.  The idea is to get as many tags that can apply to your game as possible and still properly define it.  Once you have that, then we can move on to the next step.

The next step being looking at other games with the same tags and seeing how they perform.  You can use resources like steam spy or steam charts if you're planning on making a PC game and releasing it on steam.  Note the top selling games from your search results and note their sales numbers.  This is going to be your market ceiling.  Also, if you can, take a look at the average price of the game and use that to estimate about how much that game has made.  It's not going to be a perfect number, but that will give you at least a general idea of what a breakout game can make when it's similarly tagged.  This is how much you would potentially, and I stress potentially, make if your game happens to repeat that same lightning in a bottle.

Don't just look at the top performing games, however.  Likely your game is not going to be the breakout hit that you're hoping it will be.  It would be nice if it was, but statistically speaking it's not going to live up to your expectations.  Look down at the mid and a few of the bottom tier games that match all of your tags, or most of your tags.  Do the same calculations with these games, too.  This will give you the medium and low range for what a game in your genre could potentially make.  Obviously, the floor for any game sales could potentially be zero, but hopefully you're putting enough effort into it to at least make a few sales.

These games are also useful for looking at for other reasons.  They will be more informative of your likely audience.  People who buy these games are looking for your game, specifically.  This is where you'll find feedback on what your audience enjoys about the genre or similarly tagged games and what they don't like about them.  You can use these pieces of information to inform your game design.  Did you plan on copying something that one of these games already implemented?  If yes, what did the audience say about it?  Was it positive, negative, neutral?  Use that information to guide your decision making.  Remember, all of this is to reach your goal of making a successful game, however you define successful.

Let's use Cartogratour as an example here.  The most successful game as a reference point I can use would be stardew valley.  That game has a huge audience and countless fans.  It's also a farming simulator, not a cartography game.  That means it's not going to be the best reference point for what I'm making.  What other games come to mind?  Well, taking a look at the steam charts for casual sim games isn't really going to help me.  I could put pixel art and map in as tags, and that might actually help narrow down other games that match it.  I kind of already know a moderately successful game that matches Cartogratour better, though.  It's a game called Carto.  Carto is a much better reference point, since it also focuses on cartography as one of the main mechanics and will likely have more audience in common with mine.

Let's take a quick look at the steam spy estimates for Carto.  The list price for it is $20.  The range of people who own it on steam is between 200,000 and 500,000.  That's a lot.  And a wide range as well.  This is probably going to be my top performing reference point.  To get a rough estimate of how much they made from selling this game on steam will half the price of the list price, because nobody buys a game full price, and multiply that by the lowest bound and highest bound.  That gets us between $2,000,000 and $5,000,000 in sales.  That seems like a pretty high upper bound, honestly.  Far more than I would expect, or dream of, Cartogratour to make. Keep in mind that number is not the end profit they made off the game, but rather the raw funds they will get.  Steam has a thirty percent fee for the average game, which means that two to five million figure is cut down to 1.4 to 3.5 million, to say nothing of game returns and other issues. It's not strictly relevant, but I wanted to mention it nonetheless.

Now that we have the upper bound of our research, let's narrow down the tags that we can use to find other game options that would match Cartogratour.  I'm going to choose five that I think will attract the most audience to my game: Exploration, Casual, Indie, Relaxing and Adventure.  This covers the vast majority of the features that I would use to describe my game. When I searched Steam in preparation for this talk, these tags narrowed the results from the absolute firehose on Steam down to 47 games.  That's a lot more manageable.  There are a number of irrelevant games in the results (I'm looking at you, Euro Truck Simulator), so I can't really use those.  So, to narrow it down further, I'm going to eliminate games released in the last month, along with games that have over a thousand reviews or less than one hundred.  When I did this, the results matched better the games that I see Cartogratour competing with.  I ended up with the following three games: Teacup by Smarto Club released in 2021, Miner: Dig Deep by Substance Games released in 2020 and Time on Frog Island by Half Past Yellow released in 2022.  When I do the same analysis on these games, I get the following: Teacup: $0-$100,000, Miner: Dig Deep: $0-$90,000, Time on Frog Island: $0-$200,000.  All of these titles have anywhere between no and 20,000 owners for the game estimated on Steam.  I took a quick look at the titles on steamcharts and this seems reasonable to me.  If I release Cartogratour on Steam, I now have at least a rough idea of what I can potentially expect in terms of income.

So, what does that mean for Cartogratour?  If I wanted to release it on Steam, I can only reasonably expect roughly $60,000 to $140,000 over the next two years.  That may sound like a lot, but if I have to solely rely on that to fund my next game, that only gives me a short runway.  I need to be able to keep my next game to less than a year of development to just make it.  It's not a rosy picture, but that's game development, I suppose.  This is why you want to take a look at the existing games, both the blockbusters and less successful ones, to see what to expect.  Sometimes your game just won't have the audience needed to keep you in business.  It's that information that you need if you plan on having game development be your main job, or not.  Like all information, it's up to you to decide what to do after getting it.  For me, knowing this basic market research, it's not going to stop development on Cartogratour.  I'm not necessarily building it to make money.  I'm making Cartogratour to scratch an itch for game design, and that's enough for me.

Whew!  That was a lot, wasn't it?  And that's not even the really crunchy parts of market research that you may end up doing.  I'm not going to go through these three games and their reviews today.  I know I mentioned that it's an important part of market research, and it is, but I don't want to overload this side quest just to fit it in.  I may do a second side quest on breaking down reviews specifically in the future.  If that sounds interesting to you, let me know!  I want to make side quests that are useful for others as well as myself.  Needless to say, but I'm not an expert in the field, only a solo developer looking at the potential market for one of my games.  Take anything I'm saying with a grain of salt.  As always, if you have any comments, questions or suggestions, reach out to me on either Twitter as @jcsirron or in the comments section of this episode.  This has been another side quest for the Adventure Mechanics and I'm Chandler.  I'll talk to you next time.

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.