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.

Tabletopping 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 fifteenth episode on making paper versions of your game first:

 Welcome to another Adventure Mechanics side quest. I'm Chandler. I have been getting swamped by the overwhelming nature of Cartogratour lately. In an attempt to still make forward progress, I have been trying to break down the game into all the smaller mini games that will make up the bigger game as a whole. Even that's has proven to be a problem for me, though. I keep getting stuck in the development swamp, not sure if the game I am making is even fun. So, I'm going to try something different with the mini game I'm currently working on: I'm going to make a paper version of the game and try it out before spending time committing it to code.  In this side quest, I want to talk about prototyping your digital game on the table first.

So, what does that mean? If it's a puzzle game, that means building and testing them using tokens and board game pieces before you put them to screen. In some other cases, you may be able to proof out the game using just a deck of cards.  For one game jam, the team I worked with did exactly that. We pulled out a set of playing cards and made a game using those cards and a couple of tokens.  It was fun to play in person, too!  The rest of the jam, everyone had a better idea of what the game was supposed to be because we sat down and hashed out all the details beforehand.  In the end, the trash talk from the table didn't get included for the AI we put in, but the core was still there.  Not having trash talk, along with poor instructions, made the digital version confusing and feel kinda flat, but it was amazing to play test the game on night one of the jam.  I'll put a link to what we made in the show notes, but that experience turned me onto this methodology for testing game concepts.

What games can be prototyped like this? It turns out a lot.  If you haven't seen how the original Super Mario Bros was developed, each level was plotted out on graph paper and checked against the constraints before they could be coded into the game.  Everyone had a chance to look at it, see where it wasn't going to be fun, and adjust parts to be able to fit into the tiny amount of memory on the original Nintendo Entertainment System.  By the time they were play testing the game, the team had confidence that each map was going to at least keep the flow of the game, if not be fun.  Keep in mind that at the time, they didn't have the same type of tools that we have today.  Committing to code wasn't as fast as mocking up a pre-fab and pushing it to the scene.  It took more effort to put it in, so making sure it was the way you wanted was more important.
 
Another, probably more obvious, example is Civilization.  The Civilization series centers around the 4x genre; Explore, Expand, Exploit, and Exterminate.  This obviously lends itself to converting to tabletop, since the game that it is famously named after started there.  New game mechanics can be tested and refined in a night of gaming, instead of waiting for weeks to have features implemented. Moreover, developers can set up a specific situation to really test a scenario over snacks.  No one is spending huge amounts of time doing a rudimentary implementation of a game before seeing if it's fun.  It also allows for rapid iterations to see if any tweaks are necessary as you adjust rules to better match the game loop you want the player to experience.

One other, possibly less obvious, reason to make a tabletop version of what you're building is to see if it's engaging.  As Mark Darrah of BioWare fame mentioned in his talk, Will it be FUN?, it can be used to test seemingly inappropriate types of mechanics, such as real time melee combat in an adventure game.  At the end of the day, whatever you end up with for your combat system, you'll have to come up with a model, or some other way to represent it.  If that combat can be represented in some way, it can be represented on the table.  It doesn't necessarily have to exactly be represented on the table, either.  If your combat relies on percentage, you can use two d10 to represent that, or use opposing card draws from a deck of cards.  Whatever you can use to get the same expected feel with a given mechanic will work.  The point isn't to make a full blown tabletop version of your game, but rather to only test to see how engaging it is, or can be.  At the end of the exercise, you should expect to set aside what you build and start work on implementing it digitally.

So, why do this at all?  Well if I haven't convinced you that there is value in examining games, or even single mechanics, before implementing them, I suppose that's your perogative.  Planning out something and getting iterations in when it's relatively cheap will make your game not only better, but also faster to finish.  If you are on a tight budget, or have extremely limited time, spending some time on a table version of things will make your vision more clear earlier in the project.  And that's the point.  I'm not advocating that making a tabletop version of you game will be the magic bullet you need to get you game done.  Far from that.  It's only a tool to explore what you want to make, and maybe expose a flaw in it early.  Like all tools in your toolbox, it's up to you to make use of them, or not.

Now that I've convinced you of at least the value of tabletopping your game, let me talk about how I'm applying this to Cartogratour.  I am currently working on the gardening portion of Cartogratour.  I plan on planting and harvesting being a story point in the game, so I need to have it be engaging.  I examined gardening and farming that a few other casual games, especially ones with a larger focus on story telling, but none of the minigames on farming were really what I was looking for.  I decided to take a mechanic from one of the tabletop games I play with family.  In the game Patchwork, each player is trying to build out their quilt using pieces from the center to make their blanket with as many buttons and as few holes as possible in order to win.  For my take on gardening, I wanted to evoke the feel of getting into your garden and really planning it out, making sure that each plant is getting it's proper framing and can really shine in context.  I didn't see any real incentive for aesthetic consideration in any casual slice-of-life game, so I want to bring that in using the quilt building mechanic in Patchwork.  Instead of building up the quilt, however, you're building up a garden bed.  Each plant will have it's own requirement, and each garden bed will have it's own conditions, including shading and types of soil.  All these considerations will determine the ultimate value of the garden.

That sounds ideal to mock up on the tabletop, doesn't it?  In my initial test, I'm setting up a static version of the garden plot and trying a few different plants, with different layouts.  For the layout of each plant, I'm envisioning that each will be something similar to a tetrimino.  You know, the tetris pieces.  This will force the player to make less than optimal choices and enable a sort of high score for a given garden.  I'm not quite sure how shading will be visualized, but I am going to start with a card that is drawn to give a quadrant that is shaded on the plot to start off with.  My initial plan for scoring is to score each plant in it's ideal conditions, matching the soil types, along with shade requirement.  If there are any blank spots in the garden, that will be some sort of point penalty. Once I have all of these mocked up on paper and play test it a couple of times, I should be able to see if the game is engaging.  I'll let you know the results in a follow up episode.

But, that's enough about tabletop testing your game.  As always, if you have suggestions, observations, or any other thoughts on this, leave a comment or reach out to me on Twitter.  My handle is @jcsirron.  This has been another Adventure Mechanics Side Quest.  I'll talk to you next time.

Accessibility

       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 fourteenth episode on accessibility and including some in your game:

 

 Welcome to another Side Quest for The Adventure Mechanics.  I'm Chandler.  Today, I wanted to spend some more time talking about another topic that we brought up in our Deadbolt episode; Accessibility.  The core of accessibility is making the game available to the widest number of people possible.

This isn't the same as approachability, however.  This is, you know, making the mechanics and gameplay clear and understandable.  There is a case to be made that accessibility and approachability are, in fact, the same thing, but I don't think they are.  It is possible to make a game's controls and visuals accessible to everyone, yet still be obtuse and have topics that make the game almost completely unapproachable to most people that try to play it.  A walking simulator that tackles tough topics, like a person's role in society or one's own mortality would be a good example of what I'm talking about.  If you think I'm making a distinction without a difference, let me know in the comments.

With that caveat out of the way, let's talk about accessibility.  I know this can be a somewhat contentious topic, with many erroneously claiming that making things more accessible will somehow compromise the developer's original vision.  I'm going to state right now that this is nothing more than a red herring.  As the industry currently stands, there is nothing preventing a person, company, or entity from making a game that only people in peak physical and mental condition can play.  Flashing lights, quick time events that demand millisecond reaction times and more can all still be developed.  The fact that we don't see many commercial games that do this is rather telling, however.  There isn't much incentive to do so, outside an intentional or artistic statement of some sort.

Moreover, those who are arguing that making a game more accessible only diminishes their experience in the game are arguing in bad faith.  The fact that they are arguing that a game can make them feel lesser somehow if it includes things like a difficulty slider or a color blind mode, indicates that they are projecting onto their hobby far too much.  Developers are more than capable of both including modes or features to allow those with disabilities to play and enjoy the game and not ruining their vision for the game.  Sometimes those features added even add to the game and make it more enjoyable to play, such as the high color blind mode in Fortnite.  Blending in using ridiculous skins may have been an unexpected feature in the game, but not everyone was capable of seeing them.  The fact that color blind mode began to be used by those without colorblindness to combat the abuse was just a happy side effect. Having a hard game for the sake of being hard is one thing.  Doing so to make players with fragile egos feel better is a whole other ball of wax, though.  You can add in, or exclude, features to cater to both your goal of the game and include more people as well.

So what do I mean by putting in features?  It could be something as simple as having textures or patterns to go along with colors so that players with color blindness can play your game.  It won't cost much more in terms of design time and you aren't limiting your game to those who can see colors the way you intended.  In this example, if color is paramount AND you can't put in a pattern as it would ruin your aesthetic, just be absolutely aware that you're cutting out potentially up to ten percent of the population with a bad implementation of your aesthetic.  In indie game terms, ten percent more or less sales could mean the difference between a successful release and failing as a development company.

Now, that's not to say that your implementation will be so bad that color blind people won't be able to play your game at all, but I use it to illustrate a point.  Disabilities, such as color blindness, low vision, and deafness are all things that you at a minimum consider while designing.  It doesn't take much to walk through what you can accommodate and what you cannot in your game.  Is a quick-time event really the best way to get the player to feel that emotion, or can you put it into a cut scene?  Is it really that hard to put in closed captioning into your cut scenes?  These are the type of questions that you should be asking as you design.  If you are adding these in at the end of your development, you are too late.  A bit of foresight will do wonders to make sure that your game can be played by as many people as possible.

As I point out ways to change your game, notice that I haven't touched on anything that changes the difficulty of the game.  At all.  That's because I'm just looking at the low hanging fruit.  With accessibility in mind, you can go to town and tune your game into a game anyone can play.  Or not.  It's entirely up to you how much effort you put into including everyone.  As you design your game, however, remember that all design changes that you make can be a barrier you're putting in for someone that wants to play your game.  I, personally, don't want to be responsible for causing someone to have a seizure, so I don't include many rapidly flashing colors in my games.

So far, I have only pushed for accessibility from the money perspective.  Let's say that you don't care if many, if any, play your game.  You just want to make it.  Good on you.  I get the feeling.  You should still at least look at making your game at least somewhat accessible.  Good art strikes a chord with those that engage with it, and not everyone is you.  Art games have a different audience, even if that audience is a population of one.  Getting your vision or point across to that one person is still the point of an art game.  Making a game accessible will only help you get that vision across.  It's still worth spending time to consider things that make your game easier to engage with.  Like a handrail on a ramp, not everyone will need them.  Those that do will certainly appreciate it, though.

Obviously, this is a deep topic and can take a developer deep down a rabbit hole trying to accommodate everything possible.  I am not advocating for that here, but I do want to bring it up, since whether you like it or not, putting accessible parts into your game will change the way a non-trivial amount of players view it.  When I playtest my tabletop games, if my prototype is not color blind friendly, I don't have nearly as many play testers as I would otherwise.  It may be shallow of me to say it, but losing those play testers makes my game objectively worse.  Not only do I lose their input, which could be the change I need to take my game from good to great, but I am also souring the well to be able to use them in the future.  That's a straight up lose-lose for me.  Your experiences may vary, but I would be surprised if you didn't run into at least one person that was disabled in some way in your playtesting group.

This is absolutely not all that I could talk about in terms of accessibility, but I feel like I have done at least a good introduction to the topic.  As always, if you want to talk about it more, think I missed something, or just want to comment on this episode, leave a comment on this episode or reach out to me on Twitter.  My handle there is @jcsirron.  I'm still Chandler and thank you for listening to this Side Quest.

Achievements

      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 thirteenth episode on achievements and putting them into your game:

 Welcome to another edition of the adventure mechanics side quest.  It's me, Chandler.  Today I want to expand on a topic that we got side trackedo n during our Deadbolt episode:  Achievements.  You know what I'm talking about, the little toast that shows up seemingly randomly while playing a game.  The strange ways to play games that the developer thinks that you should do to truly "complete" the game.  They seem so straightforward, yet their simplicity belies the massive amount of effort that goes into creating them.  Make trivial ones and your game feels like it doesn't take achievements seriously.  Make achievements impossible for all but the most talented players and you make your game unapproachable.  Let's talk about some of the considerations that go into designing achievements so you don't end up alienating large swaths of your audience and taint their view of your game.

First of all, let's go ahead and actually define what an achievement actually is.  Achievements are essentially challenges in the game for bragging rights of some sort.  They've been around since at least the Atari era, but they really came into their own when they began getting tracked on the XBox 360.  With that, you could really show off what you've done and rub your achievements into the face of that kid that always claims to have beaten every single game you bring up.  Ever.  Or so I'm assuming.  I never actually got into the XBox 360, so my first experience with achievements was through using the PC gaming service, Steam.  Whatever the bragging right, achievements getting tracked forces game developers to consider what is worth implementing as an achievement and what is not worth tracking.

As Devon mentioned in our Deadbolt episode, not all achievements are created equal.  Some achievements focus on progression, especially for story-driven games.  Others will focus on challenges that the player must complete in order to get.  They can veer into the absurd and have the player searching for trinkets or other things and find them all.  Since achievements don't have to fit into the game's world, they can get the player to do things outside the game as well.  For the sake of this talk, I'm going to break achievements into three main categories:  Progression achivements, where the player is likely to get them as long as they are playing the game, Challenge achievements, where the player must do something difficult to complete, and Meta achievements, things that aren't necessarily challenges or story progression, but still are ways of interacting with the game.

As we start talking about achievements, let's step back and ask about how often to use them.  Ideally, they should be uncommon.  They should be a surprise that the player stumbles across while playing the game.  If the surprise is too common, they won't really be surprised by them.  Tripping over them will make it feel like achievements don't have value to them.  Done poorly, it will feel like walking through spider webs; you just can't get away from them and they're always in your way.  Don't make your player feel like this.  Let's talk about the types of achivements now we know to not use them too much.

Let's start with progression achievements.  These are the most straightforward.  When the player makes it to a certain beat in the story, they get the achievement.  As long as your game is broken into chapters, acts, or whatever, you can tie achievements into these sections.  And since achievements are typically tracked, this provides valuable data points from your playerbase.  Is everyone making it to the end, or is there a sudden drop in progression achievements after a certain chapter?  You can use this data to change the way that area plays or make it easier to progress in some other fashion.  You don't necessarily have to change anything, either.  It's just valuable information to have to make sure you're both serving your player base and the story you've created.

Next up, we have challenge achievements.  These are the achievements that are for the those that love your game so much that they need more of it in some fashion.  The story of the game is over, but they can still go through and beat it in a different way, or faster, or whatever.  These are a bit harder to implement.  They need ot incentivize the player to do something , but they can't be so hard that no one can achieve them.  Requiring a world record speed on your game isn't reasonable, but on the other hand, requiring the player to do something trivial isn't reasonable, either.  Challenge achievements must be balanced to a difficulty slightly above the average player's capability.  Challenge achievements should not end up in tedious fetch quest style missions, however.  No one really likes killing the same thing over and over and incentivizing the player to do so with achievements only crystalizes that.  Tedium is not fun, no matter what pat on the back there is at the end of it.

Then we have the last category; Meta achievements.  These are achivements that aren't like the other two.  Defeating a specific character or monster with a comedy weapon, doing something specific on a specific day, or something like watching ads *shudder* can all be meta achievements.  The player knows that they're not part of the world and they're doing something arbitrary just for the sake of achievement hunting.  These types of achievements are the most challenging to pull off and should be used the most sparingly.  You don't want to pull the player out of your game and these types of achievements do exactly that.  If you want the player to experience something specific, then put an achievement in for it.  You must control the urge to put in a large number of these, though.  You can inadvertently make your game another progression path by doing so.

Let's talk about the other part of meta achievements, though.  If you need players to watch ads to make money, for the love of whatever diety you choose, do not make it an achievement!  This signals to your player that you don't actually care about them.  You only care about their eyeballs for money.  While this may be true for you, coming out and saying it poisons the well of players before they give you their attention.  Another way to alienate your playerbase is to wall off achievements in some way.  I'm talking specifically about date specific achievements or one time achievements.  If you want your players to do something on specific days, you can.  Doing it through achievements is not the way to do so.  If you force the player to be online at a specific time (and perhaps only at one opportunity), you're going to annoy players.  This shows to your player that either you didn't think out your achievements, or worse, you're an arbitrary and capricious developer.  Challenge is fine, but time-limiting something?  It's just not worth it.  Give players multiple chances to get something, even if it demands they play through again.  I guess i'm saying, just don't be mean to your players, as tempting as it may be at times.

So, what's a developer to do with these three types of achievements, besides use them sparingly?  Use them to get the player to interact with your game in novel or strange ways.  Get the player to be delighted when they come across an achievement.  If they've already peeked at the list of achievements, make it a puzzle that they must solve.  Make your achievements interesting.  Show your players that you respect their time and you want them to play it more.  There's a lot of examples of doing achievements well, and even more that are garbage at it.  Do  they add anything to your game, or are all of the ones you can think of boring and tedious.  Unless you plan on releasing to a platform that requires them, consider leaving them out.  As with any creative medium, one thing may not fit a given design.

Although I have more to say about achievements, I think this is a good spot to stop for now.  As always, if you have any thoughts, comments, or whatever, reach out to me on twitter. My handle is @jcsirron.  This has been another adventure mechanics side quest.  I'll talk to you next time.

Momentum

     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 this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the twelfth episode on momentum and how to keep it going for a project:

Welcome to the adventure mechanics side quest and it's me, Chandler. With the holidays in the rear view mirror, I've come up against this unenviable situation: I've been officially working on CartograTour for over a year. Sure, I haven't worked on it as much as if it was my day job, but I still haven't gotten nearly enough of it done. I've taken a look at my version control history, and, I've got to say: it's a sorry sight. There are periods of manic pushes coupled with rather large swaths of... Well, nothing. Some of those lulls were due to personal issues, but most were due to lack of inspiration. I had trouble refining the main gameplay loop in my head for quite some time. I have only recently come up with other things for the player to do that fit diegetically. With those last pieces in place, I think I have a relatively good foundation to start executing on the game. Artwork continues to be a struggle for me and sound design hasn't even come up, yet. That being said, those things aren't something I had to focus on quite yet. But now the project is now to the point where coming up with ideas is finally ending and it's time for me to look at something I haven't really done for a game: production. For today's side quest I'm going to talk about production and keeping momentum going on a project.


Now, I know I just did a side quest on motivation and you may wonder why I'm talking about momentum. They're roughly similar in terms of goals and results, so why focus on something so close to it? Well, honestly, it's because of the difference between the two: motivation is about starting, momentum is about continuing. That is one step closer to the end product, after all. More importantly, that's what you need for production. All of it is in service of that end goal; getting the game out the door and into your hands. Motivation is the micro issue every day, momentum is the issue for every update. I'm not going to be obtuse and say it's a macro issue, but it is certainly an issue. Without momentum, you can easily get stuck in "the swamps" of game design. And, oh boy, you do not want to get stuck there. Trust me.


First, let me clarify what "the swamps" of game design actually are. They are the time between first prototype and final polishing. That time where you're not quite sure the design is actually fun. You're in production, yes, but you're not done with tooling up, yet. These are times where momentum is absolutely sucked from you. The swamps may be short, or they may take a long time. Bioware programmer and producer Mark Darrah somewhat loathingly describes the end of the swamps as "Bioware Magic." This is that magic point where productivity shoots through the roof and the roadmap to finish the game finally hits something more realistic than finishing a decade from now. Now, to be clear, that typing point is also a sign of crunch in a team and I highly recommend listening to his reasoning why you shouldn't use the term "Bioware Magic" at all, but that's not really why I brought it up. It's more so because of that time before suddenly becoming more productive. The times where you're struggling to find the fun in the game, to get the real core of what the game you are developing should be. Time in the swamp can be short, or it can be years. How can you avoid, or at the very least minimize it? Keeping momentum.


Keeping momentum going in your project is rough. If you need any proof, take a look at any dev log for an eventually abandoned game on YouTube. Solo devs spend a year (or more?) on a single project, only to end up abandoning it later. They may lose motivation, they may have a life event that prevents them from developing further. Whatever the reason, though, their game is left only visible in dev log videos, a stark reminder of what could have been. Now, some of these games were appropriately abandoned, others, not so much. One thing that is common to most of the projects I see is that the developer tends to spend more time producing the dev log updates than actually working on their project. That’s certainly not true with all projects, but enough of them want to talk about their game and produce “sizzle reels” over actually getting the game done. After all, time spent on producing other things can take away from the project itself. Sometimes you need to walk away from it and come back with a fresh mind, but if you’re working on a consumable related to the game that isn’t in service to the end goal, you really are taking away from it. *cough* I’m looking at you, Chandler… *cough*


So, how can you avoid that fate and keep on track? Well, in perfect honesty, I’m probably not a good role model to look at. That doesn’t mean that I don’t know what's necessary to get a project done, though. Small wins are key. They are the things that you look back at and point at that you completed, or are really proud of. That doesn't mean amazing artwork or a really appropriate soundtrack or sound effect, either. It's making the main menu, the options screen, all the small things that make a game complete. Sure, there may be some days where you look back at what you've worked on and not really be able to point at anything, but you need to keep those days to a minimum. Even if it's a tiny improvement, completing that one feature or even tweaking it to feel better will keep momentum going. In the game forum I'm part of, we have a saying, "no zero weeks." The real quote is, "no zero days," but most of the forum goers have day jobs and family and can't necessarily work on our game designs every day, hence why we changed it to weeks. The point still stands, though. If you want to get a game done, you need to put in the time to finish it. It will never get done if you don't put in the time. And for me, at least, that means having small wins every time I sit down to work on Cartogratour. That little bit of dopamine keeps me wanting to come back to work on it.


That's not to say that's the only way to keep momentum. Another way to keep momentum is to have some form of accountability. It may be something you announce publicly, or to yourself, but having accountability will force you to have someone, or some time to be done with your game. I know I literally just railed against devs that did it and quit, but dev journals can be one method of making yourself accountable. I personally don't find them to be really motivating, since your accountability is more nebulous than having a friend that can take you to task when you're not done when you say you were supposed to be. A public dev journal does provide some sort of accountability, though. If that's going to be enough for you to get your game done, do it. Personally, I need something more to keep myself on task, though. As I said earlier, I am part of a game development forum. Part of that is updating everyone on what you've done over the last week. It's not a whole lot more, but having to say that you haven't gotten much, or anything, done on your project does give a tiny bit of a guilt trip to keep making progress on it. So far, that has actually kept me working on a game design longer than when I didn't have the forum for accountability. Having to update a group on a regular interval is what helps me the most in terms of keeping accountability.


Whatever you use to keep accountability, make sure that you're not losing the end goal of having it in the first place: Getting the game out the door is the first priority. If you no longer are getting value from one form of accountability, jettison it. If the accountability isn't helping you get closer to your goal, change it's form or ditch it entirely. Accountability is only as good a motivator as you allow it to be. If that accountability changes to something else and becomes another hobby or whatever, make sure to find a replacement. Most importantly, if you don't get motivation from the accountability, don't spend time trying to conjure it. Switch to a different strategy that works for you.


On that note, one last way to keep momentum is to make a timeline, or set a short term goal for what needs to get done. In more formal company environments, I would be advocating for scrum or sprints. In this case, I'm advocating to chunking out the work into as small of pieces as possible to get the game done. It's not sexy, or even interesting for that matter, but it works. Small pieces are just easier to finish over getting something huge done. That ties into my first method, go for the small wins. Having small pieces planned out can prepare for just that situation. I may not like mixing work and my hobby, but this is genuinely one thing I have pulled from my professional life into my personal life that helps me. The important thing is to not plan out everything in such detail that you feel like it's "just executing" on it to finish the game. Things change in design and when they do, you'll be throwing away that effort that you put into the later parts of the plan that are no longer relevant. And that's just wasting effort that can be put towards the game itself. So, plan in smaller chunks and get those parts done. Then repeat that cycle as many times as needed. And if you find yourself getting overwhelmed by the pieces you've made, it's a good sign that you aren't done breaking apart your work. I'm currently in the throes of doing exactly this to Cartogratour. I'll make another update for that when I'm done planning it out, though.


That's about all that I have for this side quest. Hopefully you find it entertaining, if not enlightening. As always, if you have any questions, ideas or comments, reach out to me on Twitter. My handle is @jcsirron. I will talk to you next time.

The Dreaded Crunch

    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 this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eleventh episode on crunch and how it damages a project:

Welcome to the Adventure Mechanics Side Quest.  I'm Chandler.  I haven't been able to get much done on Cartogratour over the last month and a half, and it's not due to lack of passion on my part.  Over the that last chunk of time, I have been knee-deep in work crunch, for a variety of reasons.  With work taking up all my spare time and creative energy, little has been left for game development. Instead of just complaining about my latest foray into crunch and how unfair it is, I'm going to go over why crunch is bad, and not just from the perspective of the people going through it.

I'm sure you've heard about crunch, but what do I mean when I say crunch?  Well, crunch is an intensive effort over an extended period on a given project.  That means that you could be crunching on a project that you're only dedicating some time per week on.  In most cases, though, it's typically associated with working inordinate hours on something, often to the detriment of work/life balance.  Crunch means that you're working harder and longer on a project than you can comfortably accomodate.

Now let's talk the human cost of crunch-time.  When you're crunching, you're not taking care of yourself as well as you do when you aren't crunching on a project.  That dentist appointment?  You don't have time for that, you're crunching.  Need to workout?  Tough, you're either working while working out, or you're just not going to have time to work out.  This push to get the project, or thing, or whatever, requires you to set aside other things in your life to get closer to that finish line.  That's not only going to be a cost you'll have to pay later, but it may also be something that you'll have to pay during crunch, anyhow.  Crunch will end up just wearing down everyone working on the project.  And with people worn down, quality will suffer.

Why do I say quality will suffer?  Well, I've been subjected to crunch twice this year alone (thank you poor management!) and I have seen what work "quality" comes out of crunch.  It's frankly subpar.  Now, I'm not throwing my coworkers under the bus, far from it.  I am just gauging their output.  Sure, the first week is okay, but the longer the crunch drags on, the worse the code becomes when it eventually gets checked in.  And I do mean eventually.  On a normal, non-crunch day, my team can commit multiple times, no sweat.  During a crunch, though, some days may be commit-free.  To be fair, that may be because of things beyond their control, such as a poorly defined tickets or ones that are ginormous.  On the other hand, those also indicate that the project wasn't well defined before setting the team loose on it.  Worse yet, it sets up the team for failure.  A poorly planned project will absolutely waste precious time and end up delaying the project, despite how much project planners may argue to the contrary.  As the old addage goes, failure to plan is planning to fail.

But let's say that the project was planned out in a sane fashion.  Enough time was alloted, at least according to initial estimates.  One delay leads to another, and you're staring down crunch again to get back on track.  This may be tempting, but the initial crunch to get back on track will more often lead to burnt out people and, paradoxically, less work done per hour put into the project going forward.  Moreover, when a person gets burnt out from crunch, it takes more time for them to recover from the crunch itself.  It depends from person to person, but from what I've seen, crunch may be linear, but recovery time is geometric.  What do I mean by this?  For each day someone is crunched to burnout, you'll need to double the number of days needed for recovery.  That doesn't mean that they'll necessarily need to completely off work, but they'll need a lower workload to take care of themselves and have time to reset.  If crunch happens too often, then the team will begin losing expertise and members.  That shouldn't be worth it, but I know some managers are willing to make that sacrifice to the team to get a project done.  Thankfully for me, I haven't been in that situation.  Losing team members to crunch, especially during crunch time, is a recipe for disaster.  The crunch effectively becomes a dreaded death march.

If you're not familiar with the term, I envy you.  A death march is when most people, if not everyone, is crunching for months on end.  The team may be smaller from attrition, but new people aren't brought on to replace the losses, since that would take even more talent away from the project to bring them up to speed.  So everyone just crunches a bit more to make up for the losses incurred by crunching.  Obviously this isn't a good place to be.  Bugs normally caught, handled and resolved are passed by or, worse yet, allowed to persist in the product.  There's simply not enough time to resolve them and continue to add new features, at least that's the perception.  Those external pressures aren't going away any times soon, so why not let those relatively benign bugs through and tackle them after release?  Nevermind the fact that these bugs will damage sales in the first place.  Needless to say, but once a project is in a death march, it's only a matter of time before a collapse.  It's only a question of whether the project finishes or the team breaks first.

What I've said so far could apply to any software project.  What makes making games unique?  The culture.  Everyone is hyped to high heavens for the upcoming game and want it NOW.  Management sees the dollars slipping by the longer it takes to push out that new game, so they're pushing as hard as possible on the developers to get it done.  They claim that overtime isn't required, but if you're a contractor on a game and don't do overtime, you're not likely to have your contract renewed.  This leads to an extremely unenviable position of crunch or get fired.  Talk about stressful.  That speaks volume to both the concept of contractors and salaries, but I digress.  Numerous exposes have come out over the last couple of years about crunch and how it ends up sucking the souls out of teams and leads to some extremely toxic situations to work in.  Despite the exposure to this, we as gamers still demand to have games ever sooner with more and more polish.  We are part of the vicious cycle of crunch and death marches at game studios.  I'm not putting myself above this, either.  I'd be remiss if I said that I didn't get antsy when a game I was looking forward to was delayed.  One thing to keep in mind when a studio announces a delay, though, is that it's giving the team behind it time to put on the finishing touches on their game.  I know the Miyamoto quote, "A delayed game is eventually good, a bad game is bad forever," no longer really applies in our current world of massive day one patches and "evergreen" games, but at the same time, giving a game time to put it's best foot forward is important.

Obviously I'm still a bit salty about having to go through crunch yet again this year.  Hopefully I've given you insight on what crunch is, why it's a problem and why patience is going to make up for getting what you want a bit later.  As always, if you have any questions, comments or suggestions, reach out on twitter.  My handle is @jcsirron.  This has been the Adventure Mechanics Side Quest, and I'm Chandler.  I'll talk with you next time.

Looking at Motivation

   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 this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the tenth episode on examining motivation and my development as a designer:

  Welcome to The Adventure Mechanics side quest and it's just me, Chandler. When I first started getting serious about game development, I created a blog as a way to write down my musings and spread my interest and game design with people. Looking back at it, one of the first posts I made was about motivation and completing a solo project. At this point, I was mostly working on game jam games. I feel like I need to readdress this issue, especially in light of how much time it's taking me to get Cartogratour into something resembling my original vision for the game. So in this episode of the adventure mechanic side quest, I'll be doing a little bit of naval gazing and comparing what I thought I needed for motivation when I started and what I think I need now and see how they compared to each other.

In my second blog post, I focused on three things that I thought were hindering me from completing a game: lacking the rush of game jams, the quick burst of game jams versus the slow burn of finishing a game, and the issues of being a solo developer. When I first wrote that blog post (link to it in the show notes), I had done about 6 months worth of game jam games. This equated to about six or seven different games all in various states of having a complete core gameplay loop. That means they're all incredibly rough and barely have anything beyond the core gameplay loop implemented. But, as these are technically games, I felt that I was doing very well in terms of being a developer. At the time, I was working on a number of small prototypes, none of which were worthy I guess, to develop further. Despite that, I felt that I could finish a game and publish it in a relatively short period of time. I mean I got six games out in 6 months, why couldn't I polish one of my prototypes to completion? Now that I'm almost a year into developing cartographer and don't have anything beyond that prototype to show for it, I see that getting a prototype and finishing the game are two very very different things.

To be honest, the rush of game jams is hugely addictive and over estimates your ability to actually build a game. All of the patchwork and papering over that has to happen in a jam are these sort of decisions that are much harder to make when working on your own game. All the shortcuts you make to get the game done in the time frame just don't quite work when you're developing the game yourself. You end up having to go back and rework those quote unquote patches over and over again to make your vision a reality. You have to focus a lot more on polishing than you normally would in a game jam. And I think I was off on the wrong foot when I started thinking I was a game developer because I made six (or I think 16 at this point?) games for game jams. In short, I was able to beat the spread metaphorically speaking and actually set myself up for failure.

I kind of foretold that with my second point. I instinctively knew that it wasn't going to be as simple as a game jam to get a game out, but I still underestimated the amount of effort that goes into actually completing a game. And, maybe it's just being locked away for so long talking, but I underestimated how much work would go in to fighting myself. Doing things that I don't want to do, or haven't come up with a good answer for, yet, is especially difficult for me. Sometimes I end up just staring at my code, not knowing what to work on, or worse yet actively avoiding the things that need to get done to get to that next milestone. I find myself doing this more and more as I get into the more complicated details for Cartogratour. I'll be honest, there have been more than a few 0% weeks, which is the concept of not getting anything done on your game over a given period of time. As this is quickly becoming too introspective, I'll leave that for a bit later.

Difficulties I've run into with cartographer actually ties in nicely with the last bullet point of this post. In the third bullet point I talked about being a solo dev, and relying on yourself to get things done. To that end, I am still crappy at this. Accountability is a thing, and I am terrible about it. If I haven't mentioned it before, I run a game developers forum every weekend. For those interested in what we do, we go over some game theory, what we've done on our games over the last week or whatever amount of time it's been since the last forum, and then go over some lenses to look through for our game. In this context, it's a game design lens. If you're interested, there's a link to the book and the lenses themselves in the show notes as well. This is been my primary form of accountability over the last six years. And although it's been a hell of a lot of fun, it hasn't actually helped me actually get a game out the door. I find myself putting more effort into the forum in some weeks than I do into my games themselves. This is becoming increasingly problematic, especially considering I know how limited my weekly time is, and what I need to do to get cartographer into a more playable state. I can see why some people want to quit their day job to focus on their game, gambling on the facts of that it's going to be successful enough to support them moving forward. Unfortunately, I don't have the faith in my own game design skills, nor do I have the desire to risk my livelihood on a bet like that.

So, where does this leave me? Well, since we've been having a bit of a hiatus for the main line adventure mechanics, it's given me an opportunity to use these side quests as a form of accountability as well. That's why I'm taking a look at my seemingly perennial weak point of self-motivation for my own games. If the last year and a half has proven anything, it's been that left to my own devices (and without having external social commitments), I can't actually get a lot done. I think the key is, though, that I have to be able to say no I need to focus on x today. Despite being an introvert, I do thoroughly enjoy spending time with people face to face. It is obvious to me, though, that I need to budget at least one day a week or something to focused game development time. Talking about game design and researching it is great and all, but if you're ostensibly a game developer, you still need to sit down and actually design and develop games. And I think I haven't given myself enough time over the last few months to do so. We'll see if a dedicated amount of time will help in terms of actually getting a game done.

So, have I changed much as a developer?  Not really.  I still thoroughly enjoy the rush of game jams, especially when working in a team to get something done.  I still need to internalize that making games for a jam does not equate to making a commercial game for release.  If anything, doing game jams can put you into bad habits where you think that you're actually further along than you really are.  I really need to get the last few features into Cartogratour and start the polishing phase so I can call out for some more in-depth playtesting.  I feel that there is a good nugget in what I have already, and if anything, having people look at it and give feedback will motivate me to get more done.  Accountability is going to be a continuing issue, especially since this is my hobby and I don't really have the push to get it out that I would have if it was my job.  I'm partially okay with that, however, since I just want to release the game for people to enjoy, and don't really expect to make much, if anything, off of it.  One of the curses of making your hobby your job is that it no longer is fun.  At least, so I hear.  I don't really want to ruin game design and development for myself by pushing so hard that I burn myself out.  That's not to say I don't want to have my work appreciated, it's more so that I don't want to jade myself.

Where is Cartogratour at right now? I'm actually in the middle of putting NPCs into the game. This is a non-trivial task, especially given the rework that I did a couple months ago, but I still need to get it done since it is one of the core tenants of Cartogratour. I went on a bit of a side tangent and attempted to put a day night cycle into the game, but I ran into a limitation of pygame where changing too many surfaces at once will severely degrade performance. I may end up having to cut the day night cycle from the game at this point. Either that or radically change what's the day night cycle looks like in the game itself. This is been one of the issues that I haven't really wanted to address, obviously. It sucks having to run into those hard limitations and trying to find a workaround. We'll see if I can come up with an adequate work around in the next couple of releases, though.

That's about all that I have for the adventure mechanic side quest this time. As always, if you have any suggestions, comments, or questions reach out to me on Twitter. My handle is @jcsirron. This has been the adventure mechanic side quest and I'll talk to you next time.