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.

Applying Definitions to CartograTour

  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 eighth episode on apply the definition of the genre I want CartograTour to be in to the game itself:

Welcome back to another Adventure Mechanics Side Quest.  It's me, Chandler.  If you were looking for one of the mainline episodes, don't worry, we're still doing them.  We just ran into scheduling issues and had to push the episode for July.  We'll be continuing on as normal next month.  Consider this a side quest extravaganza.  Last side quest, I ran through what genre I want CartograTour to fit into and how I, personally, define that genre.  For those who don't remember, I want my game to be a casual life sim.  I defined a casual game as a game that is easy to pick up, put down, with limited complexity and a less urgent gameplay loop.  That's quite a mouthful for my definition, but I wanted to define it as precisely as possible.  As for a life sim, I defined it as a game that simulates someone's life, or portion of their life coupled with a social aspect.  Keep in mind, I define a life sim as a casual game as well.  I can imagine that there are some life sims that aren't casual games, but I struggle to think of a specific example.  If you can think of one, leave a comment.  I would be interested in seeing a game that does that.

As for applying my definition of a casual game, let's apply it to CartograTour.  Is my current build easy to pick up?  It doesn't have a tutorial right now, nor does it have any cheat sheet for controls in-game, so that's likely not true.  I'll have to add a controls menu under options at the very minimum to even start to say yes to that question.  I'm not going to start in on the tutorial until I get all of the mechanics into the game.  This may be a mistake, but conventional wisdom for game design says that the first parts of the game should be done last, as the team is most familiar with the mechanics and will be (ideally) putting their most polished work into it.  That being said, there does need to be something to on-board the player into the game, and right now I'm doing none of that.

For the second part of that phrase, is my game easy to put down?  With the implementation of saving and loading, the player can certainly leave the game and come back at any time.  It may be too easy to do, at least looking at other casual life sims out there right now.  As it stands right now, though, I'm happy to let the player cheese the saving/loading to find their way back to the home tile.  At least I have that portion handled.  The player will be able to put the game down at any point and not feel like they need to complete something or make it to a certain point before quitting.  I don't know about you, but I appreciate that sort of laid back attitude in my games.  Well, at least the casual ones.

So, what about the limited scope?  Am I living up to that in CartograTour?  Currently, yes.  All of the game focuses on filling out the map and using that information in some way.  As I look at my game design document, however, I do see some things that aren't necessarily in service to that.  Is allowing the player to place and customize a house in service to that?  Not really.  Is creating a social network while building the town relavent to cartography?  Again, that's not, strictly speaking, relavent to the core gameplay loop.  That being said, I think those types of features will make the game more interesting and will keep the player more engaged with the game longer.  That may be worthwhile to deviate from strictly adhering to a limited scope to include.  More importantly, they are potentially the cornerstone of why I want to call it a life sim.  I'll get into that a bit later, though.

First, I should finish off my definition of a life sim.  In CartograTour, the player can spend as much time as they need exploring and planting flags to create their map.  The player doesn't even to ever engage with the quest board in the current iteration of the game.  That sounds like a really non-urgent game to me.  I don't ever plan to add any survival mechanics to the game, so this shouldn't change too much as I flesh out the day-night cycle.  The only thing that may change is that I plan to hook up the time expiration mechanic to the quest board.  That may push the player to complete the quests faster.  It may end up making players feel rushed to complete the quests before they really feel ready.  I won't know that for certain until I implement it and get some solid feedback, though.  And if it doesn't feel right, I can always pull it out.

The other part of my definition of CartograTour's genre was the social sim, so I guess I should talk about that now.  In terms of simulating the life of a frontier cartographer, putting together a map for others to use definitely feels right in the current build.  To further drive that feeling home, I need to implement more interesting things to put into the world, such as rivers and other natural barriers, animals and other hazards and whatnot.  For the astute players, these features are already stubbed out in the last release, but it's exactly that, a stub.  If this game is going to be much more than what I already have, I'll have to implement these.  I do want the player to also feel like they are on the frontier, so I plan on putting in a basic building that they customize with things that they find in the world or get as rewards for quests.

On that note, I plan on taking the quest board out and force the player to interact with non-player characters (NPCs) to get the quests instead.  That wil require a rework to the current system, but I think it will be worth it.  I want the player to get familiar with the NPCs and (hopefully) build a bond with them.  I am currently working on the first iteration of them, and, to be honest, they feel like I'm just talking to a quest board.  That's because they are little more than the quest board, but I'm working on getting them to be feel a bit better.  Hopefully by the time the next release comes out, there will be at least one NPC to interact with that doesn't feel like little more than the quest board.  I suppose that depends on how much I get done, though,

Now that I've applied the genre definition to CartograTour, I should talk about what I have been doing to it over the last couple of weeks.  I made a foolish mistake of perusing other developers' tutorials out of boredom shortly after the last release and one of them pointed to a lot better way of laying out the game, also known as the architecture of the game.  So, instead of implementing more features into the game, I spent the last two weeks on a complete rework of what I had already implemented.  It was soul crushing to do so, but I know that the new way everything is laid out will make it easier in the future to add features.  At least that's what I keep telling myself to justify spending two weeks on converting everything over.  We'll see how fast I can add features now.  If I'm wrong, at least I learned a lot from it.

Anyhoo, that's all that I have for this side quest.  Next side quest, I'm going to be talking about the importance of the tutorial.  As always, if you have any questions, comments or musings that you think I'd find interesting or funny, reach out to me on Twitter as @jcsirron.  This has been the Adventure Mechanics side quest and I'm Chandler.  I'll talk to you next time!

What is a casual 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 this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the seventh episode on how I'm defining the genre that my game is going to be in:

 Welcome to the Adventure Mechanics Side Quest and today it's just me, Chandler. As I've gotten feedback from early playtesting, I found that I've kind of lost sight of my initial design. The initial design for CartograTour, what I'm renaming my prototype I was calling The Mapper, was for it to be a casual-style cartography game.  As I've developed it, however, it's become more reflected the type of games that I've been playing, i.e. games that tend to be played more in rounds rather than as a casual experience. That made me realize that I never really went through and defined what a casual game was for me. So for this sidequest I'm going to be diving in and trying to explore what, exactly is a casual game.

So, what is a casual game? The most common definition I could find was a game that was easy to pick up and easy to put down.  But what does that mean?  Are sports games a sub-genre of casual games?  Is a one on one fighting game?  By this vague definition, they very well might be.  That doesn't feel right, though.  A sports game is pick up and play with relatively short time commitments, but if it's American Football or Cricket, the player will need to have at least some basic understanding of the rules of the game, which adds a bit of a barrier.  A more complex game is a less approachable to new players and a casual game is supposed to be inviting.  In the same vein, fighting games seem to fall flat in terms of complexity.  Sure, just playing a casual round of Street Fighter may be quick to pick up, but the complexity of the meta-game can quickly turn off a filthy casual like myself.  The competitive skill ceiling also makes playing with your more talented buddies far less interesting.  A skilled player will stomp a new player way more often than that new player will be able to beat the skilled player.  That's not really approachable as a casual game to play.  I think that this limited definition of a casual game needs to be a little bit more fleshed out.

So, what do I think it means?  Well, a casual game still needs to be easy to pick up and put down.  But the controls also need to be intuitive, as well.  If we take those requirements and rework the definition to something that encompasses it all, we can get to this first part of the casual game definition:  A casual game is limited in scope and complexity.  That means that a casual game won't have an overwhelming number of mechanics and won't have too many controls.  Moreover, any controls that are in the game need to be as clear as possible, be it through instructions in the game or leveraging the player's intuitions.  Any unexplained instructions will need to be intentional choices, not something that was overlooked in development.

That's great and all, but that now begins to include games like Diablo.  Is Diablo a casual game, too?  Is the core gameplay loop in it of killing, looting and equipping lend itself to a casual game?  It doesn't really feel like it should.  There's an urgency and agressiveness in the gameplay that doesn't really lend itself to a more casual game.  So, to better define a casual game, I'll need to refine the definition again.  It needs to have less urgency than a game like Diablo.  So a calmer core gameplay loop is necessary.  Twitch reaction and  deep strategic thinking aren't really part of the core loop for most casual games.  That means a casual game need to have a calmer core gameplay loop.

That takes the definition for a casual game to be a game that's easy to pick up and put down with limited scope and complexity that has a calmer core gameplay loop.  Does that mean we have a good definition of the genre for CartograTour?  Well, not quite.  Casual games as defined will certainly include CartograTour, but it doesn't quite fully encompass the core of what CartograTour will actually be.  After all, Cards Against Humanity could be called a casual game.  What I envision CartograTour to be is something called a life sim.  A life sim is a sub-genre of casual games that focuses on some specific aspect of life that the player may or may not be familiar with.  If they're familiar with the core gameplay, we can leverage the player's experiences in real life to intuit what to do in our game.  That greatly eases bringing new players into the game when they can guess what to do.

Just having that one definition doesn't really encompass all of what makes a life sim game, though.  Could a puzzle game like Tetris a life sim?  It currently fits into our definition of a casual game, but it doesn't really feel like it should be included in our definition for a life sim.  Sure, you can play it alone and have a blast, but ideally, a life sim is something that's shared.  A high score just doesn't feel like it's enough to me.  So what if we add that a life sim has some sort of social aspect?  That would exclude straight puzzle games from the life sim genre.  But what does including a social aspect mean?  The obvious answer is that it has people playing the game together.  Two people playing something like Stardew Valley is obviously social.  But if the multiplayer update wasn't added to it, does Stardew Valley still count as a life sim?  I would argue yes.  That's because having a social aspect doesn't necessarily mean that there has to be multiple players in the same game world.  What about the interactions that the player has with NPCs?  Trading, completing orders and being able to romance them all are something that we expect to do with people in our daily lives.  That brings back the pre-multiplayer update of Stardew Valley back into a life sim.

Life sims will also need to have some sort of major goal.  Sandbox worlds where the player can make their own goals are great, but a life sim doesn't really need to be open like that at all.  Take Papers Please, as an example.  It's a life sim of a very limited aspect of a person's life; their job.  They don't have the freedom of doing whatever they want, they are living out the life of a border guard.  This is a more guided goal meant to evoke a specific feeling.  A goal that forces the player into the mental state of that specific border guard is acceptable.  Our definition of a life sim needs to include this.  A life sim ends up being defined as this:  A game that is simulating some portion of a person's life with a social aspect and either open or directed goals.

Whew!  That's a lot of defining!  But, now we have a definition for what, exactly, I want CartograTour to be.  It's going to be a casual life sim.  In the next side quest, I'll be going over what that means for the game and if I need to adjust anything already implemented or change what I'm working on putting in.  If you have any suggestions or want to use a different definition of what either a casual game or a life sim is, reach out to me on Twitter as @jcsirron.  This has been The Adventure Mechanics and I'm Chandler.  I'll talk with you next time.

Game Design Approaches

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 sixth episode on different game design approaches:

 Welcome to the Adventure Mechanics Side Quest, and today, it's just me, Chandler.  I've been hard at work getting some mandatory features into The Mapper, such as saving and getting chunking to work, so today I wanted to talk about different approaches to game design.  For those who don't know, there are a bunch of different ways to approach game design.  There are fundamentals that cross multiple different approaches and not all approaches are truly unique.  So, what am I talking about?  Well, simply put, it's the process that the designer uses to guide how they design the game.

So, the most fundamental design that I've found so far stems from how a game is defined.  For the purposes of this talk, I'm going to call this the fundamental game design method.  In this design approach, you see a game as a start point, a goal, some opposition with decisions to work around them and a ruleset to interact with.  What is the value of designing from such a low level?  To put it bluntly, you'll have to take nothing for granted.  This is particularly useful if you are designing a simple, puzzle, or tabletop game.  When designing for tabletop, specifically, you can't necessarily assume that the player will know the state of the game off the top of their head, so you'll have to distill everything down as much as possible to conform to some part of this game definition.  And by having to put it into one of those very limited fields, you'll have something ready very quickly.  As soon as you have something more complex, however, this will quickly become unwieldy.  An RTS where there are many decisions or a casual game where the goal is nebulus at best won't really be nice to work with in this framework.  Explicitly writing every rule and how the player can interact with them is also going to become quite tedious, especially if it's going to be taken care of by a computer.  This can quickly double the workload and extend the design time beyond what is acceptable to get the game out.  That being said, being aware of this fundamental game design method is incredibly handy, especially when making small or simple games.

Let's say that you don't have a simple game in mind, but still need to have something to work from.  What could you use then?  Another option is to abstract a bit higher up and use transactional game design. In transactional game design, the core of the play space is between the player and the game itself.  That means it focuses on Mechanics, Feedback loops, interaction between the player and the game, player agency and action verbs.  This is more useful for making more interactive games.  What are the core mechanics you're going to use?  Take a look at the list of mechanics you wrote out.  With this style of game design, you look at what many consider game design, like how a game feels, how the mechanics interact with each other and how it's all shown to the player.  In this context, it's not one type of player, specifically, but rather, all players in general.  Transactional game design is focused on the interaction of the player with the game itself.  This attitude towards game design is especially useful for action oriented games, such as twin stick shooters or platforming games.  All of the focus being on the interaction of the player with the game forces the designer to really make sure that everything added makes the game better.

Transactional game design isn't the only game design method that focuses on the player interactions and mechanics, however.  One other popular game design methodology is design pillars.  For design pillars, the core idea is to focus on the primary aspects the game should have and how the player will interact with the game.  The pillars can be a feeling, mechanic or game style.  Moreover, pillars can be modified and added as development progresses, with some caveats.  Why use this design methodology?  It's a zoomed out view that allows a designer to make sure that the whole project is working towards the same vision.  If a developer is going to add something to the game, they will need to cross-check that added mechanic against the existing pillars added and make sure that it still follows the design goals of the original design.  If it's not in service to one of the pillars, then adding it isn't usually a good choice.  The drawback to this high view of the game design process is that some of the smaller details can get lost.

Let's say your game isn't small or fast paced.  What if you want to look at specific players and a more meta-level play level?  This is where situational game design can come in handy.  In situational game design, the play space is more focused on the player.  Situations, contstraints, anticipation, interpretation and finding meaning are all explicitly given focus in situational game design.  What is the player doing/thinking about while waiting for their turn?  How are they engaging with the game when they sit back and think about their next action?  These are all areas the designer will consider when using situational game design.  In this method, the constraints are things like the ruleset, controls and visual representations.  It can also include the constraints the player may put on themselves as well, like additional challenges or thematic constraints that may not actually be in the game.  This is particularly useful, since it can inspire more mechanics and aspects that fit the game.  This builds into the core loop that situational game design uses:  With constraints, moves and situations, a designer can come up with a compelling game loop.  The constraints structure the situations that the player is put into.  Situations offer the player a variety of moves to take and moves ultimately alter the constraints that the player will have as they move forward in the game.

So, let's say that you start out making an intentionally difficult game, one that demands the player to have some familiarity with your game.  You can't exactly expect them to know the ins and out of your game from the start.  So how do you get the player into your game?  One design approach that lends well to this game style is rational game design.  For this design methodology, the ultimate goal is to keep the player in a state of flow.  What is flow?  The cliff-notes explanation of this concept is that you want to keep the player in a goldilocks zone where the game is just the right difficulty.  It's not too hard that the player is frustrated, but the game is not so easy that the player is not bored by the experience.  How do you keep a player in that flow state?  It requires the designer to consider the main gameplay loop and make sure that there is enough there to keep the player engaged and that it's the right difficulty, or at least gives the player options on how to solve a situation that matches their skill level.  Early on in the game, the challenge level should be just above tutorial, since the expected skill level will be low.  As the player makes their way towards the end, the difficulty can then build upon the previous completed challenges, ideally culminating in the player mastering the game itself by the end.  This particular approach to game design lends itself to linear games, like a story-based shooter or tower defense style game.

This is by no means all the methodologies for game design, but these are the ones that I have found to be most useful for me.  So, the ultimate question is what game design methodology am I using for The Mapper?  For my purposes, I've been using the design pillars.  Instead of focusing on mechanics as my design pillars, I've been using the thrill of discovery, non-violence and cartography as the core of the Mapper.  The Mapper obviously began as a game about cartography, so I had to make it one of the design pillars.  The thrill of discovery ties nicely into the same, since mapping the unknown isn't necessarily the same thing, but still close enough to my first pillar to complement it.  My final pillar that I wanted was non-violence.  There's no part of cartography that necessitates violence, and I didn't really want to cobble a combat system to the game, especially if it could potentially overtake the primary goal of making a game about cartography.  In the end, these three pillars were enough to make a compelling game for me.  All of the mechanics that I have added to The Mapper so far have been in service to these three pillars.  Despite me using design pillars as a primary framework, I have used the other design methodologies at various times as needed.

As for the latest build of The Mapper, I do have something for you this month.  I still don't have all the mechanics implemented, yet, but I do have a large step forward in terms of the look and feel of the game.  I have implemented the rudimentary save system, along with a flag system to allow players to place on both the map and in the world.  There have also been a number of rather large changes on the back end, but in the end, that's to make my life easier and not necessarily visible to the player.  I am also going to be releasing The Mapper onto Itch.io moving forward, since I feel that it has progressed far enough along to be somewhat presentable to a wider audience.  If you have any feedback or suggestions, leave a comment!  Any and all feedback is going to make The Mapper better.

That's all that I have for this Side Quest.  As always, you can find me on Twitter as @jcsirron.  This has been The Adventure Mechanics, and I'll talk with you next time.

Bibliography:
Designing games for Game Designers: https://youtu.be/ke_kOD2D-bs
An introduction to Situational Game Design: https://youtu.be/K4xfduXlM6s
ThursDev: Game Design Pillars - Better design through definition and restriction: https://youtu.be/_EtxKlctpXw
Rational Game Design: https://amberstudio.com/whitepaper_post/rational-game-design/

Innovating vs Polishing

 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 fifth episode on innovating versus polishing your game:  

Welcome to the adventure mechanics side quest, and, once again, it's just me, Chandler.  As we prepared for upcoming mainline episodes, I couldn't help but notice that the two games we were playing were case studies on each side of the polish/innovation spectrum.  On one hand, the super polished Forza 4 Horizons has almost no innovation, only polish.  On the other hand, Phasmophobia, is very innovative, but is extremely janky.  Now, before you say it, yes, these games are in completely different genres and the developers have vastly different resources at their disposal.  That being said, they do highlight what I see as the balancing of polish and innovation. Today, I wanted to talk about this somewhat subtle issue in game design.

First, let me define some terms.  For the purposes of this episode, when I say innovation, I mean a new or novel take on artwork, mechanics, soundscape, or whatever else is being done in the game.  Innovation doesn't necessarily mean that it has to be completely unique in this case, only that whatever idea is implemented hasn't been commonly used in similar games.  Polish in this context is how much effort is put into making the existing assets or mechanics look/sound or feel better.  For a case study on polish, I'll link to a Game Developers Conference from the art director of the Forza Motorsport series, Matt Collins, where he talks about refining the art direction for the series.

So, what do I mean about the polish/innovation spectrum?  Well, in an ideal world, the development team would have infinite resources and would be able to both innovate and polish to create their perfect game.  The real world doesn't allow for that, however.  So, what is the balance to be made?  Well, it depends on how much time is dedicated to each aspect, innovating or polishing what is already in the game.  The right balance between the two will vary wildly from project to project.  In a more mature project, like a game sequel in a long-running series for instance, innovation may be small and not take much time for the team to complete.  With new intellectual property, on the other hand, the team may need to spend more time on innovation before starting the polishing stage.  Knowing when to call it on one and start on the other is a tricky art to master.

In the Forza series example, it's obvious that the genre is mature, along with the series itself.  Innovation isn't going to come in the form of radically different gameplay or a wholly new art style, like cel-shading.  If you look at the changes visible between Forza Horizon 3 and Horizon 4, the lion's share of them are different cars, new location, quality of life updates, and if you're looking really closely, subtle changes in how the screen is optimized and drawn.  These all don't seem radical, and that's for a reason.  With such a storied franchise, major changes and innovations are going to risk turning away established players.  In this specific case, most innovation has been optimizing the workflow for the team, something that almost no player will be able to see, unless they are counting down the days to play.  If you are one of those players, perhaps you should look into QA as a career.  Having an eye for detail that fine is a hard skill to master.

Let's get back on topic, though.  If your genre is resistant to change, or you can't touch what's already there in a large way, what can you do to improve?  Polish.  It's not sexy.  It's not going to get people fawning over your game.  It will, however, make sure that what is there will shine.  Applying that to Forza Horizon 4, that's exactly what we see.  Well, that and an annoying amount of Skinner boxes added to motivate the lizard brain to play it more than the content included can really support.  In this context, it only highlights the need for a highly polished product, so I'll save all my opinions of Skinner boxes in Forza for the episode on it.  It's all about keeping the players playing, and a well polished game will keep them playing longer.  Polish in this example is king.  Innovation is going to be incremental at best.

With the other example, Phasmophobia, it has no name to live up to.  It can't rely on older entries or IP that can carry a mediocre game to success.  What did the developer do?  He had to innovate and do a very smart marketing campaign to succeed.  From what I've seen of the ghost hunting game genre, most have the player or players combatting the ghosts after they are found.  Ripping that mechanic out of Phasmophobia was a good innovation.  Coupling it with voice to text and leveraging features built into Windows 10 to allow the player to talk with the ghost directly is downright genius.  The strange attractor of this game is almost too much for a large swath of players.  It gets them to play it, though.  And that's the point.  They tried out the game and, perhaps more importantly, got their friends to play it, too.  That's huge.  It's one thing to satisfy one player.  It's another thing entirely to get them to be a fan of the game where they want to push their friends to play it, too.

So Phasmophobia is innovative and got a huge player base.  What's not to like?  Polish and content.  The game has issues and many players will get bored of it after around a dozen rounds of investigating.  The rest of the content just isn't there to keep them in the long run.  Coupled with janky animation and a host of bugs, it does risk turning away more enthusiastic players and losing the community that has cropped up around it.  It may not be fair to say that of a game that is nominally in early access, but it is something that a developer should keep in mind.  Doubly so when the game ends up with such a wide appeal and needs to have a lot of players to make sure lobbies aren't empty.

The other risk is to transition over to polishing too soon.  If there aren't enough innovative things there first, there may not be enough to polish to make a truly complete experience.  For Phasmophobia, this means not having enough maps, tools, ghosts or other things to keep the player base playing longer.  If the developer transitions too quickly to polishing what's here, they risk turning off more players who felt like they've seen it all.  They may then have to go back and do another cycle of innovating to attract them back.  That's a hazard of early access, specifically, but the transition between innovating and polishing can still be painful, even for a hobbyist scrub, like myself.  I always find that it's a challenge to change between modes and it only slows me down.  Your experiences may vary, though.

One trap that I personally have experienced, and have seen others fall into as well, is assuming that once the innovative core of the game is done, it's about eighty to ninety percent done.  If you're lucky, you're about halfway done.  New content, polishing that animation, re-recording that sound for the millionth time all take up a shocking amount of time.  For me, it ends up being about ten percent coming up with that core and ninety percent polishing what I've made.  I tend to be a much slower artist and will rework my code multiple times before I'm really happy with it.  With all that in mind, I can start really budgeting what time is needed to get my idea across the line.  I'm not even done putting in all that I want for The Mapper, so by my own math, this is going to take a looong time.

Well, I guess it's time to finally apply what I've been ranting about to The Mapper.  Obviously, since I'm not done implementing all that I want, I'm still in implementation mode.  That being said, I think that what I've been calling the map space is pretty much ready for polishing.  The core of what's interesting there is already in place, so I'll be putting it on the back burner, only touching it to add a few features from feedback in the near future.  What has been taking up most of my available development time has actually been what I'm calling the meat space, where the player moves their avatar and interacts with the world.  This is going to take a lot more time testing and experimenting with a variety of ideas to really get where I want.  Although more prototyping than innovating, it's still what the game needs to really get it where I want it to be.  I've kind of been going through this episode almost using them interchangeably, so there's that.  Keep in mind that prototyping is only part of innovating.  You may find yourself playing other games for inspiration, reading, or even just daydreaming when you end up innovating.

Anyhow, that's about all that I have on this topic for now.  I'm sure that I'll have something later as I work through The Mapper more.  If you have any comments, feedback or whatever on this episode, let me know!  You can leave a comment on this episode or reach out to me on Twitter as @jcsirron.  This has been the adventure mechanics side quest and I'll talk to you next time.

Making Unique Feeling Games

 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 fourth episode on making your game feel unique:

Welcome to the Adventure Mechanics Side Quest.  I'm Chandler and today I want to talk about making a game feel unique.  Gamers always want to play something new. Something that isn't what they've played a billion times before. Coming up with completely new designs is almost impossible, though. You have to forget everything that you've played before and everything you've seen as well. For a truly unique game, you will end up spend more time explaining the world than letting the player play in it. The problem is, must gamers don't actually want to play a truly new or unique game. It takes too much time to learn new mechanics and not all truly new or unique mechanics are actually fun. So how do we come up with something that feels unique but isn't so radically off of what players expect as to turn them off of the game entirely? Today we're talking about making a quote unquote unique game.

I've heard that in order to make a game feel unique it had to be only about 15-30% different to feel unique. Why so little? Because the player won't want to go through the hassle of learning something entirely new, but does want to play something that is different enough from what they've played before that it doesn't feel like they're playing the same thing over and over again.Take the first person military shooter, for example. It's almost become a meme at this point that you need a gritty modern military shooter in order to be successful. But, if you look at the sales numbers of these games, especially the copycats and not a mainline game such as modern warfare or battlefield, you'll see that the gamers that want a military shooter don't want to play a slightly crappier version of a AAA game. They just don't have anything that stands out that's compelling enough to have the gamer put down the AAA game for the other gritty military shooter that has the exact same mechanics and feel. How can you make your game stand out in this crowded genre? Do you even want to compete in such a competitive arena? Before you sit down and commit a huge amount of your time and effort on yet another version of that latest hit, you may want to make sure you have something new or compellingly different first.

If you want to compete in a crowded arena, you're going to have to stand out in some way. A compelling narrative, a new twist on an old mechanic, a new mechanic entirely or a new art style for the graphics are all ways to stand out in a crowded field. Even with those, however, it may not be enough to put your game in front of the right eyeballs. You can do everything right and still end up being completely ignored by the gamer you want to attract. That is one of the major hazards of competing in and already established genre.  Geoff Englestein has something he calls the Rule of One to come up with a new game.  In his GameTek Classic, he justifies this by stating that by the time you've taught the player how to use all the new mechanics, you've lost them.  Hence, you only want to teach one new mechanic when you are making your game.  You won't lose the player when you go to introduce it to them.   Although Geoff Englestein works almost entirely in the tabletop space, I think this is a good rule.   You may end up having to come up with a wholly new mechanic to really stand out. In our example of the gritty military shooter, one new mechanic could be implementing a cover based shooting model.  Yeah, yeah, I know, every gritty military shooter now has this, but when you look at military shooters before that was implemented?  It was revolutionary.  Now, it's old hat and is in every shooter now.  What is a mechanic that we could implement that could shake that up?  Open level designs with minimal cover, not having a hide-to-heal mechanic, or only gaining health when you get a kill are all ways to re-imagine the military shooter.

One other design methodology I want to talk about actually comes from Nintendo. They search for new and/or different takes on existing genres and make sure that their implementation is completely different in as many ways as possible. The main idea of the blue ocean strategy is to search for your own genre or player base that isn't getting satisfactorily accommodated. If you can find that player base and cater to their needs, you will be able to find success.  This is what they call the blue ocean strategy. It's equally difficult as standing out in a crowded genre but in a multitude of different ways. How do you make gears of war kid friendly? If you're Nintendo, you make the squid-tacular game, Splatoon. In Splatoon, it's still an area control game, like Counter Strike, but it doesn't emphasize the direct combat between players nearly as much.  It's more about how much area each team has covered in their ink by the end of the round.  Mechanically, it may have a few similarities, but it stands out by shelving the gritty military aesthetic for something more kid friendly: Squid teenagers splashing ink all over an arena.  Sometimes you have to change your artistic vision to really make it stand out from the crowd.

No matter how you approach your designs, keep in mind who you want to cater towards and how you're going to stand out from the crowd. If you are making a commercial game, you will need to differentiate yourself from all the other games that are trying to do the exact same thing. And in coming up with a unique design, make sure that it isn't so radically different that you won't be alienating the player base you are aiming for, either. A unique feeling game doesn't necessarily have to be completely pulled from the void. Lean in where appropriate on existing norms, but don't be afraid to change, or challenge them, to come up with something more compelling. You can accomplish this by taking as much time as practical during the prototyping phase.  You really want to explore the design in a number of ways to arrive at mechanics that you rarely, if ever, see in the type of game you're making.

In the case of The Mapper, I struggled on how to make it work as a cartography game. I haven't seen many video games where you make a map as part of the core gameplay loop. On my first try, I came up with something, but it really wasn't what I wanted. I struggled to see the application of the primary gameplay loop. The secondary and other loops weren't compelling in this first draft. I had to look for outside inspiration.  I took a look at casual games, like Stardew Valley, Harvest Moon and Littlewood and examined what they did for their gameplay loops.  I then came up with the design I have now, which is a lot more interesting, and I dare say, unique.  Although I did examine those games, I ended up coming up with a more thematic interepretation of what a player does in my game.  I wasn't really interested in having the player be a jack-of-all-trades.  I wanted the player to be important, but not all important, so I decided to not include most of the other things that you can do in The Mapper. Remember that game design can be an iterative process and it make take a number of iterations on a given design to come up with an implementation that really shines.

And now for what I've done with The Mapper since the last release.  Over the holidays, I went on somewhat of a hiatus on working on my new build of The Mapper. That being said I now have a new build ready for you to try out. This build is not by any means a vertical slice of the gameplay I expect to see in the completed game, but it does implement the main mapping components.  You can move about the world, recording on your map at your leisure.  I have also put in some rudimentary artwork to give a better feel of what I'm going for.  I'm not going to say final artwork, but they get the idea across. Over the last, how many months since the last update? I put in the questing system, which now includes a number of different types of quests and a fast way to add more types of quests as I think of them.  This means you can also accept quests and, more importantly, get them wrong, especially if you aren't careful on the accuracy of your map.   Building off of this, I improved the map generation for both the map space and the physical space that the player will move around in. I rounded it out with a few quality of life things that make working on the mapper much more pleasant.  I haven't implemented any of the other map details, such as features, animals or improvements, but they won't be as difficult to add now that the terrain is in a better state.  Putting a semblance of a story on it is just a pipe dream at this point, too.

Anyway, that's about all that I had for this episode of the adventure mechanics side quest. For any feedback, leave a comment!  As always, you can find me on Twitter as @jcsirron. I'll talk to you next time.