Digging into user reviews

 Welcome to The Adventure Mechanics, it's me, Chandler.  I've noticed that a lot of eager game devs want to "know the secret" of marketing your game.  How do I know?  Well, the best performing side quest on game development we've had was on how to start your market research.  And since that's a point of interest, I'm going to talk about it again, but with a smaller context this time around.  Today, I want to focus in on user reviews and what you can learn from them, and more importantly, how to use them to make your game better.

Now, why would you want to dig into other games' user reviews?  It's not your game, nor is it a carbon copy of  you're making now, at least ideally.  Well, the answer is rather simple.  You can examine what bothers players in other games in your genre/niche/whatever and use that to inform your game's development path.  That one piece of UI that just drives players nuts in that other game?  You can make your UI more sleek.  It's a way to learn from those that came before you on what you can do better without having to make the same mistakes.  You can then make all new mistakes and learn and teach others not to make them.  Hopefully your mistakes end up more lucrative, at the very least.

In my first marketing side quest, I said you should go through the existing market and come up with a list of comparable games that you can use to estimate how much you could potentially get from making your game.  Assuming you've gone and done that footwork, you'll have a ready list of user reviews to pull from.  This is where the real fun begins.  You're going to have to read through their reviews and start noting what is popular, what isn't, and what the players wish they could do in the other games.  This isn't a "sexy" part of market research, but it's entirely necessary.  If you are making a game similar in vibes, mechanics, or whatever, and that mechanic you plan on adding in is a hated feature of the games you're researching, maybe it isn't a mechanic that is necessary.  Or maybe it's something you'll need to adjust and re-imagine to either answer or side step the complaints of the players.  Either way, you'll be saving yourself some headache by being aware of that as an issue before spending time making it in the first place.

Let's do a specific example.  Let's say Cartogratour played most like Carto from the previous market research we did in the last Side Quest.  Let's dive into the Carto from a high level.  At time of writing, it's overwhelmingly positive with over six thousand reviews.  That's promising, especially if Cartogratour plays similarly.  That's a good first pass.  That means there's potential in the design.  But, what is the typical reason for the positive reviews?  Barring going through all six thousand reviews, we'll go off the reviews shown as most helpful in the last thirty days.  Looking at those, it's apparent that the key phrases used in Carto reviews are: cozy, comfy, short, puzzle, little, simple mechanics, great visuals.  Great, these are all descriptors that I also want to apply to Cartogratour, so the audience I'm aiming for not only exists, but also will enjoy these if I execute them well in my game.

Now, let's look at the most helpful negative reviews from the last thirty days.  These are where the sticking points people have with Carto.  The descriptors that show up in these I'm actually going to split into two: positive and negative.  It seems odd, but there's value in seeing what people who won't recommend Carto still enjoyed from the game, even if it's just something that they put out to make their review more "even handed."  On the negative side, we have the following: simple puzzles, childish story, only one solution to puzzles, poor interface, repetitive music and sound effects, unskippable cut scenes, boring story.  It seems like the main problem people had were lack of challenge for puzzles, agency on ways to solve puzzles, bouncing off the story for a variety of reasons and UI issues.  None of these are game breakers, specifically.  It means that I need to make sure that whatever puzzles I put into the game are clear and signposted in a variety of ways.  I also need to make sure that any issues with my user interfaces are ironed out and tested by a lot of people before I call it "good enough."  In terms of story telling, giving the player an option to skip it if they're not interested in it is going to be mandatory if I want to keep the focus on the puzzles.  Now, there is an argument to be made that forcing the story to the front is worthwhile, but doing that will cause the same complaints to be made about my game if I choose to make it that way.  I'll save that for when we go over the overall takeaways, though.

On to the positives in these reviews: creative puzzle mechanics, cute artwork, well polished, original concept and artwork.  It seems even those who didn't like the game itself liked the artwork, polish and novelty of the puzzle mechanic.  Applying this to Cartogratour, it means that I need to come up with an art style that evokes the sense of wonder from exploration.  In terms of novelty of the puzzle mechanic, I'll need to have new play testers come in and try the game out, possibly people that are interested in puzzle/mapping games specifically.  *I* think my game has a novel puzzle loop, but I'm also the developer.  That means I'm too close to it to be objective and I need to get some more people involved in the feedback cycle to vibe check me.  And, of course, polish, polish, polish.  The never-ending bugaboo of any game developer.  The more you polish your game, the more people will be interested in continuing it.  The reality of having your game polished possibly beyond what you think is necessary will never really go away.

So, what are the takeaways from diving into the reviews of Carto?  Even this cursory look at the "most helpful" reviews from the last thirty days reveals that the strengths of Carto are it's novel puzzle mechanic and cute aesthetic.  The main perceived weaknesses are boring and limiting puzzle design and story coupled with poor user interfaces.  Is this fair?  To be sure, I need to play the game.  And as a developer working on something similar, I already have done so.  I don't necessarily agree with the criticisms made of Carto, but I can certainly see where the frustrations are coming from.  I won't go into my full thoughts of the game, but I bring it up because this is also an important step, whether you enjoy the game or not.  At the very least, you need to have a familiarity and opinion of other games in your game's genre.  Whether you play the game before looking at reviews or after is up to you.  Playing before reviews gives you the most raw opinion of it, whereas playing afterwards will cue you into the perceived weaknesses in the game you're examining.  Both approaches have value and it'll be up to you to decide what information you want more.  I would limit the games you play for research to one or two titles that closest represent the game you're making, however.  Getting too many games just means you're adding to your "to play" backlog and not actually focusing your efforts on your game research.  So, be mindful of that.

The last part I want to focus in on is internalizing the feedback from other games.  Earlier, I mentioned that one of the pieces of feedback for Carto was the unskippable cut scenes and rather basic story.  If one of my design pillars is a heavy influence from storytelling elements, I may still want to include unskippable story beats.  And that may be the right choice to make, too.  But that is something you'll have to weigh before putting it into your game.  There is going to be a group of players that will just bounce off your game because of this choice.  They just want more engaging puzzles, in the case of Carto.  Your choice to bring the story to the fore will lose them.  And as long as you're aware of that and accept it, do it.  Not every game should be made for everyone.  This is just one example, but you will eventually need to make hard choices like these to make sure you're building for the audience you want.  And more specifically, not building your game by committee and losing sight of who you are making it for in the first place.  If the feedback you get from diving into similar games actively conflicts with your vision of your game, don't just discard it, prioritize it.  If it's not high on the priority list, then consider accepting it as the tradeoff for your idea.

Anyway, I feel like this is a good point to call this side quest.  If you're ambitious, don't limit your review diving to the last 30 days, look at the entire backlog of reviews.  Just keep in mind that if the game is actively changing, you're going to have to discard older data that is no longer relevant.  As always, if you have any questions or comments, reach out to me on various social media as jcsirron or leave a comment on this side quest.  This has been an Adventure Mechanics side quest and I'm Chandler.  I'll talk to you next time.

Know your secret sauce

             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-third episode on finding your secret sauce for your game: 

Welcome to another Side Quest of The Adventure Mechanics, it's me, Chandler.  I've talked quite a bit about prototyping versus production in the past.  By that I mean what to do in the prototyping phase, where you're supposed to be exploring what makes your game special.  And what needs to get done for production and what you should be prioritizing during it.  I haven't really talked about what should make your game special, though.  More importantly, when you should look for it.  Today, I want to talk about making that secret sauce for your game. 

Not all games find their "secret sauce" at all, let alone while they're being prototyped.  But before production is really where you want to put in the time and find what makes your design special.  You need to find your secret sauce before you put in the content.  I know in cooking, you usually use sauce to clench up the flavor of a dish, but in game development, you really need to figure out what's in the sauce before you make the dish, if that makes sense.  And that means you're going to be making and setting aside a large number of metaphorical dishes before you find that right flavor for your game.  You're going to be working on this one design for quite some time, so you better be sure it's going to be good. 

But, what exactly is a secret sauce? That depends entirely on what you are designing.  In an RTS, that may be avoiding the multiplayer aspect in exchange for a deep story.  In a farming simulator, that may be dealing with the dead instead of plants, like in the game, Graveyard Keeper.  Whatever the secret sauce is, you need to make sure that it is going to carry your game, or at least be the interesting thing that brings players to it.  It should tie all of your disparate mechanics and art together into one cohesive whole.  It's the interesting thing that gets everybody's attention in the first place.  But most importantly, it's what sells your game.  If your secret sauce follows the recipe seen in too many other games, like making yet another pixel art Metroidvania, for example, you may not hit the goals that you set for your game.  If your pixel art Metroidvania has a time travel element to it, that would make your game stand out a bit more.  Sure there are a lot of pixel art Metroidvanias, but not nearly as many that use time as a resource.  That's just one example, though. 

Another way to stand out is to have a very distinct art style.  Let's say you still want to make that Metroidvania, but you don't want it to follow the pixel art aesthetic.  You can make your game focus around bugs, while keeping the gothic flair seen in many other Metroidvanias.  If you're not familiar with it, this is exactly what Hollow Knight did.  That is basically a love song to Castlevania Symphony of the Night, but with the aesthetic of bugs and Castle Crashers mixed in for good measure.  And if you compare Hollow Knight, as popular as it is now, to other Metroidvanias released around the same time, you'll see that it leaned into its art style to really stand out.  Not all games can have a strong and distinct art style, but not all games need it, either. 

Thomas was alone took the platformer genre and put a heavy narrative to it, but left the characters as blocks. It still has a distinct art style, one that is very easy to initially replicate, but the interesting part of that game wasn't the art style. Listen to our full episode on it if you want more context.  The art was consistent but it wasn't what kept people talking about that game.  It's a great example of leaning into the narrative as the secret sauce.  The game narrates every level.  And it is telling you quite the story while you are playing what in essence is a level-based platformer.  The game plays incredibly differently when you both mute the narrator and take the text off the screen.  And it's much to the game's detriment when you do so.  That's the secret sauce of Thomas Was Alone.

There are many other examples of secret sauces that work well.  I'm sure if you look at any of your favorite games, you'll be able to pick out one or maybe a couple things that are interesting in them.  The features that really sold you on the game in the first place.  In fact, do that as an exercise and compare your favorite games' secret sauce to what you have planned for yours.   If you are anything like me, your secret sauce isn't going to be at the same level as the games you compare to.  It's still a good exercise, though.  It can even make you think of your game more critically and really examine what you think is special about your design.  Again, that's what I'm talking about when I say "secret sauce."  It's not meant to be a convoluted design concept that is only relevant to academic game design.  It's meant as a tool for you to bring your game's best foot forward and, most importantly, put a spot light right on it.

But, let's say you've found an interesting prototype, but you haven't quite found your secret sauce for it, yet.  I know some people will say to find it in production.  But this is really going to put an effective ceiling on your game.  After all, in production you aren't exploring base mechanics or art styles or special audio tricks.  Nor should you, to be honest.  Production is for the swamps of content creation.  You're making all of the assets and all of the story and all of the levels for your game there.  Doing a sidebar and trying to find out what makes your game special is going to make production that much worse.  That's not to say that you can't change your game in production, but rather you want to limit change in production.  Like in software design, shifting as much risk to as early as possible, called shift-left testing, reduces cost.  And let's be honest, exploration in production is expensive.  That's why you really really want to find that secret sauce for your game before you even start doing the content pipeline.

Once you have figured that out for your game in the prototyping phase, you are going to want to emphasize and polish polish polish that secret sauce until it shines.  You may remember me advocating for using assets to get your game out faster, but the secret sauce is one of the cases where you absolutely want to put as much of yourself into it as possible.  If you end up using assets in your secret sauce, spend time making them yours, at the very least.  This is the highlight of your game, after all.  You need it to be the best that you can manage, given your skills, time and effort available.  Yes, I have been working in Scrum and Agile world for years, how can you tell?

If you have your secret sauce, put it into your pitch.  Use that pitch on as many people as possible and see the reaction to it.  Is it piquing interest?  Is it getting people excited about your upcoming game?  Or is it getting polite, but neutral, responses?  This is the first "playtest" of your game.  If you're not getting the reaction you expect from your pitch, it's time to evaluate it and possibly look at another secret sauce for your game instead.  Keep in mind that pitching your game is a skill, though.  One you should be working on as much as possible.  That's a good talk for another time, however.  For now, just focus on polishing how you get your game's secret sauce across to the potential player base.  If it's getting the responses you want, the easy part is over!  You now have to make the game.  Hopefully using the secret sauce you pitched.

Okay, that's enough on secret sauces for now.  At this point, I think I'm hitting the jamais vu experience for the phrase "secret sauce".  That being said, what has been your experience looking for what makes your game special?  Let me know in the comments section below.  If you want to follow me, I am on various social media as jcsirron.  This has been another Side Quest for The Adventure Mechanics.  I'll talk to you next time.

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.