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.