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.

The Case for Game Jams

 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 third episode on the game jams and what to expect when entering into one:

The case for Game Jams:

Welcome back to my Side Quest for the The Adventure Mechanics.  I'm Chandler and, once again, it's just me for this episode.  Between episodes, I participated in a Game Jam called OMGJam8, link in the show notes.  If you've listened to the last two episodes of the side quest, you'll know that I talk about game jams.  I talk about them a lot.  And I haven't really explained the anatomy of a game jam. So, let me divert from progress on my game, which is in the middle of making and putting art assets into it, to talk about the process of participating in a game jam.  Trust me, this is still relevant to finishing my game for wider release.

WHAT IS A GAME JAM:

For those who haven't heard me rant about game jams before, a game jam is a a time-limited game design challenge where a theme or restriction is given at the beginning of the jam.  Once the timer starts, the developers or teams have the time given to come up with a design and execute on it.  It's the entire design and execution process condensed down into a small chunk of time.  It's a great way to determine where you're weak in the process and improve on it.

Now that you have a general idea of what a game jam is, let's talk about preparing for one as a participant.

GETTING READY FOR A GAME JAM:

First and foremost, you're going to have to set time aside for the jam.  Like, all that you can muster.  Make sure that you're not committing to any social engagements during the jam.  Let everyone who could interrupt you know that you're going to be unavailable during that time.  It may be obvious, but interruptions during the jam will pull you out of the flow and need to be mitigated before the jam starts.  It's hard for me to get back into the state of flow once I'm jarred out of it, so this early mitigation strategy really does pay dividends when I start.  Next, make sure that you have all provisions needed for the jam before starting.  Need caffeine?  Grab enough for a crunch.  Need snacks?  Grab days' worth of your favorite snacks.  Need to force yourself to sleep (and get up early)?  Set alarms to remind yourself when to sleep and when to wake up.  And don't forget to take care of meals while jamming.  All of these preparations will save you from spending time during the jam figuring them out.  That mental overhead does not need to be there and taking care of it will keep you working longer on what you want to.

When you're done with physical and social preparations, then comes time for getting your tools ready.  This may sound like a given, but I've seen many teams spend an inordinate amount of time learning their tools and getting them working during the jam.  This is not only counter-productive, but also a sign you're not ready for a jam.  If you want to practice with a new framework or engine before the jam, then do a dry run beforehand.  Go through a couple of tutorials so you know the basics and package/build your results.  This will save you time during the jam trying to figure out the packaging process works for the engine.  You don't want to go through the entire jam only to get stuck at the end trying to figure out how package it up for release.  It's hard to diagnose issues when you're tired and burnt out from a weekend of jamming.  Trust me.  I've ran into this exact issue multiple times and hate myself every time.  Don't do this to yourself.  Prepare!

STARTING THE JAM:

Once you have all of your affairs in order and you are comfortable with your tools, it's time for the start of the jam!  If it's a theme release, you will want to brainstorm some ideas on what you, and potentially your team, want to make.  Brainstorming will help you organize your ideas and how feasible they are to get done during the jam.  It may feel like it's a waste of time, but like the preparations made before the jam, it will pay off later.  Don't go with your first idea.  It may not be the best one for the jam.  Work out several ideas and keep the scope as small as possible on each idea.  As you work through them, you'll likely lean towards one idea that you particularly like.  Spend some more time on it and flesh it out some more.  If it fits the theme and you feel confident that you can complete it, work through what needs to done to get the game to your vision.  Write out all the details in a way you can track.  Some ways that I've done this is writing everything on a whiteboard, putting everything onto sticky notes or sharing a Trello board.  However you organize it, make sure that you're updating it as you go along.  Planning without followup is not very useful.  It's also nice to see the progress you've completed when you move the sticky note or erase the task from the board.  That little action may be the difference between getting overwhelmed and actually completing the game jam.  Every thing you can do to keep motivation high is something worth trying.

WORKING THROUGH THE PAIN:

One thing I've noticed that isn't really mentioned whenever someone talks about participating in a jam is the inevitable exhaustion and blocks that come up.  Exhaustion is going to happen.  That's normal.  I have hit this every time I have participated in a game jam.  Every one.  Taking a break, a nap or a walk aren't going to bite into your dev time more than you trying to "gut" through the exhaustion is going to.  Do what you need to do to get back to a good mental state.  If you're working exhausted, you're not giving the jam your best.  The same really applies to all things, come to think about it.  In that same vein, hitting a design or mental block isn't something to fear, either.  You're going to be working on a whole game all at once.  Getting stuck on one thing doesn't mean that you're no good at being a dev.  It means you may need to switch to something else or spend some time away from the game.  There are going to happen and you'll want to accept it early so you don't spend time fighting it instead of developing.  It's all about getting a complete game.

FINISHING STRONG:

When you have a complete game, congratulations!  It's no easy feat getting a game done on time for a jam.  On the other hand, if you find yourself running out of time and still have that wall full of things to do, it's time to finish what you can and prepare your game for release.  You entered into the game jam to finish something, so having something to show for your efforts should always come first.  There's no shame in having to cut features to get your game over the finish line.  Other devs are having to make the same hard decisions to get a finished product.  If anything, it's a sign that you're willing to make the hard choices to finish a game.

As for the worst case scenario, you don't have enough of a game to release for the jam and need to withdraw.  It sucks, but it's going to happen.  Life came up and you don't have the time to finish.  It's okay, don't beat yourself up.  You still learned a lot during the jam.  That's something to be proud of!  Take the lessons you've learned and carry them forward.  It's only a failure if you don't learn from it.  I always feel like crap when I have to withdraw, but every time I've withdrawn, I just couldn't get to a completed game.  Regardless of the reason why you don't finish, make sure that you go through the proper channels and either withdraw or announce that you won't be able to finish.  Don't ghost everyone, especially if others are depending on you.  Be a good participant of the jam.  It's supposed to be fun, after all.

THE AFTERMATH:

Once you've finished the jam, you're not done.  Most jams have a rating period, like Ludum Dare does.  If the jam you have entered doesn't have a rating period, you will still want to go through the entries and play other entries.  See what other people came up with and give feedback.  Not only is it a good way to get feedback on your entry, it's a just a good thing to do for the jam community.  You all went through the jam and it's time to see what people came up with.  Who knows, maybe you'll see something amazing or see someone else you may want to do future jams with.  This little bit of extra time after the jam is important.  Use it!

One final thing that is useful is to do a blameless post-mortem.  It's time to evaluate what happened during the jam, what can be improved and, most importantly, what you did well.  Not a whole lot of people do this, and it's only to their detriment.  Post-mortems are the critical lens needed to grow as a developer and acknowledge your accomplishments.  Go over the project with a critical eye.  If you really need it, use something like an Agile Retro.  I can't believe I just said that, but it's a good tool.  I think I gagged a bit using work lingo in this podcast.  Ugh.  That being said, a retro formalizes the process of doing a post-mortem and may help get it started for you.  I'll link to an explanation of what an Agile Retro is for those interested.

TAKEAWAYS:

So, I've gone over all of this and for what?  Well, being true to myself, I'm going to use this as an opportunity to talk about my entry for OMGJam8 and do a proper post-mortem on my own work.  The theme for OMGJam8 was Recycle.  I spent the morning of the first day thinking of games I could make for the theme.  I ended up with a tile based puzzle game where the player can switch bodies and "recycle" them for the next level.  I initially wanted to use bodies, a la Carbon Frame, but decided against using meat bags, since that would bring up other issues thematically that I didn't want to tackle in this jam.  The jam hosts, Game Devs Quest, provided an asset pack to work with for the jam.  I found some music and sound effect that worked from the asset pack, but the asset pack didn't have any artwork that really inspired me for what I had in mind.  I wanted to stay in the spirit of recycling, so I went out to OpenGameArt.org and found an asset pack that matched the feeling for what I was envisioning.  I found a workable CGA style asset pack with a variety of robots included.  I spent the first night fleshing out the core mechanics.

I woke up early the next day and started implementing the base of the engine I was making.  I spent a good portion of the day looking at rectangles and got sick of it after dinner.  I spent the rest of the night adding and mapping out the asset pack that I chose.  I think I spent too much time getting the asset pack to map properly, but now I have a robust way to map and scale the images for future games, so that is one small win.  By the end of day two, I was able to go through one level with one of the robots, but I didn't have the features unique to each robot implemented yet.  I knew I wanted three unique robots at a minimum, so I knew that I had to come up with something for each tomorrow.  I went to bed thinking on that one.

On the third day, I started by finally nailing down the capabilities of the robots.  I implemented their behaviors and then started making the instructional levels for showing the powers to the players.  I got the tutorial levels implemented and even added a couple more for posterity, totaling five levels for the jam.  I ran into issues with coming up with puzzles for the design I had, but I am happy with what I came up with.  When I finally added the sound effects, music and menus that evening, I felt good about ending the jam on a high note.  Then I had to package the game for release.  It just wasn't cooperating with me.  My first try ended in abject failure, not packaging at all.  I spent the next two hours trying to get a successful package.  By the end of the night, I finally got it working, but I was not a happy camper with the effort.

I had the Monday after the jam off work, so I went through and played all twenty five games entered into the jam that I could play and gave feedback on them.  I got some pretty good feedback from some people and went to bed happy.  On Tuesday evening, a streamer named Darzington mentioned that they would be playing my game with a number of others on Wednesday.  Needless to say, I was surprised that any streamer would be interested in playing games from such a small jam.  I watched her stream while I was working and got admittedly sidetracked, since those were the same games that I played a couple of days before.  There were a number of participants in the chat, so it was really fun spending time with them as Darzington played various entries and gave feedback on each.  There were a number of suggestions that she gave on my game that were very good (and I noted in the code for potential revisiting...).

Overall, I had a really positive experience with this game jam.  I may not have gotten as many levels into my game as I wanted, but I did get more into it than I expected.  Packaging the game up was the main stumbling block I had, and that was mostly thanks to me being tired when I went to package the game.  There are a number of things that I am weak at, especially designing a compelling puzzle, but I felt that I was able to make something interesting despite that handicap.  Having art and sound assets already available for use when the jam starts was a whole new experience for me.  One that I would certainly like to repeat.  In future jams, I may create a few art assets to work with before the jam begins, so I can just pull from them and get working on my idea.  I really liked not having to spend a whole day working on art, only to have to set them aside when I don't have time to implement the mechanic that uses them.  To top it off, participating in a stream that talked about some of the more interesting entries was a novel experience.  For larger jams, like a Ludum Dare, participating in something like that may not be possible, but whenever it is, I will absolutely want to do that.  It was such a wild experience.

Well, that's all that I really want to say about game jams in general and OMGJam8 in particular.  Next time, I'll be giving a beefier update on my game and another topic that relates to it.  If there's anything you'd like me to address next time, reach out to me on Twitter as @jcsirron.  This has been the Adventure Mechanics Side Quest and I'm Chandler.  I'll talk at you next time.

Some Issues Getting Feedback

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 second episode on some issues getting feedback for your games:

Welcome back to The Adventure Mechanics Side Quest and, once again, it's just me, Chandler.  I am using this audio format to push myself to complete one of my prototype games and have it ready for a larger release.  Last time, I said I would have the prototype ready for you to look at.  I made it through most of my pre-production goals, but ran into a few snags along the way.  I did make it through the art mockup for both representing the map and player avatar in the overall space. Once I was done with that, I started looking for my previous code base to springboard off of.  To my horror, I couldn't find the original source code for The Mapper.  I only had my compiled version of my entry.  That meant I had to start from scratch on it.  I was able to recreate the basic movement of the player quickly.  I even added a little bit of polish where the player will shift in the center of the screen a bit as they move around.  I even reached feature parity with the jam entry version and added objects that spawn in the tile that the player can collide with.

The map portion of the prototype pushed me into a desert of redesign, however.  I realized that in my original jam design, I limited the size of the play area.  Meaning, the player started on an edge and eventually hit the other side of the map.  This ended up being in direct conflict with the game design I wrote out for pre-production.  So, I had to stop looking at the old compiled version of my game jam game and start working towards my planned design.  I wrote the map to be able to add to the existing map for an arbitrary amount of time.  Moreover, the map that I wrote pulls double duty and handles both the meat space and the map space with no code duplication.  I'm particularly proud of that fact.  This ended up taking much longer than expected, though.  I did end up with a much more flexible design in the end, but it meant that the month I budgeted for this prototype went right out the window.  This forced me to decide whether I was comfortable with sacrificing my original timeline I had envisioned and keep moving forward with what I have currently.  Since I'm terrible at decision making of this caliber until it's far too late, I ended up just adding features to my prototype.

The other thing that this meant was that I didn't get any of the art assets completed for this prototype.  All of it is blocks and text.  Sure, I have the mocks that I made, but they are cobbled together from assets pulled from Open Game Art dot org or existing copyrighted games.  That won't do if I plan on showing this to anyone.  Moreover, I don't want to introduce the possibility of missing those assets later and having them sneak into my final product.  That sort of potential is something that will keep me up at night with cold sweats if I put copyrighted assets in.  I don't want to even flirt with the potential of getting a Cease and Desist on something I spent so much time on.  But enough about my progress, let's get into a topic I want to talk about today: Feedback, specifically issues when getting it.

I have tried getting feedback for my games many times.  Over all the games I've shown and tested, I've noticed a few things that reduce the feedback quality:  First, and most common, is the audience I'm getting feedback from is not the audience that would get excited about my game. The second issue I run into is vague feedback.  And lastly, I end up getting irrelevant feedback to my game in particular.  Let's go over these points:

The easiest people to get feedback from are your friends and family.  I mean, they're right there, sometimes literally.  They tend to give the WORST feedback when it comes to your game, though.  My partner really isn't into top down mapping games, so she's not really invested in what I'm showing.  My family don't really play video games and they only play a few select board games, so there's they really don't have a point of reference to compare what I'm coming up with.  And as much as I trust the opinions of my fellow Mechanics Devon and Tom, they're not going to give me as hard of an opinion on my work as I really need.  For better quality feedback, I'm going to have to search outside my social circle.  Other developers make decent guinea pigs, since they're familiar with the early jank that prototypes entail.  Other good playtesters are groups that enjoy playing games in an early state, or otherwise rougher than normal.  Before the pandemic hit, I was going to local Protospiel events.  For those who don't know what those are, it's a gathering of playtesters and designers who spend a weekend playing games in various states of readiness.  In my case, these were for board games.  Another good option is local meetups for game developers, such as an IGDA chapter.  I'll throw a link ot them in the show notes.

As for vague feedback, I run into this VERY often.  In many cases, the person giving feedback isn't sure what to respond to, so they say, "yeah, it looks good," with little or no additional feedback.  Other times, they see something, but don't want to hurt your feelings/insult your work, so they end up sugar coating their feedback. Both of these are supremely unhelpful.  If you're going to grow as a developer, you're going to have to get comfortable with prying out the details from these people.  Sometimes, when you're asking for feedback, it's worded too broadly.  Questions, such as, "how do you like it?" and, "what do you think?" aren't enough for your playtesters to latch onto.  You need to ask some probing questions, especially in the areas that you're looking to have them really look at.  In the instance of the prototype I have, questions that would be more helpful for me would be about the controls.  Since I have not implemented any of the artwork or audio, questions about the feel of the game are not going to get me useful responses.  The guiding questions that you want to be asking will put a highlight on certain mechanics but not bias the answers.  So, in looking for feedback on controls, I wouldn't want to ask, "were the map controls awesome?"  In that question, I'm trying to bias the responses towards a positive comment.  That's not going to help me get honest feedback.  I'm not going to go over biasing questions, but be aware of it as you craft questions.

The last issue I commonly run into is people giving "advice" on how to improve my game, or worse yet, advice on how to change your design to match an idea they've had.  Don't get me wrong, suggestions on how to improve the overall feel or change a mechanic for the better should absolutely be taken.  The type of advice I'm talking about here is something like, "Hey, I like your game about mapping, but it would be a lot cooler if it was a game about fighting!"  Not only is this not going to help my design, it's actively pulling my design away from the core that I've so painstakingly put together.  The most input feedback that this gives is that the person giving it wasn't really interested in the design.  This may be useful, especially if that person represents a group you want to appeal to, but more often, it's just not going to be worthwhile to implement their ideas.

This only scratches the surface on the topic of feedback.  There is a whole field of study on it and I'm not an expert in it by any means.  This is just my experience when I've tried getting it for my games.  If you've ran into issues as well and want to either talk about it or have me talk about it in a future podcast, reach out and leave a comment.  I'd love to hear your experiences while playtesting.

In the interest of getting feedback as early as possible, I'll be releasing the small mock-up of what I have so far for the map user interface (UI).  There won't be anything in terms of gameplay, but I still want input.  Hopefully I'm making it obvious that it's almost never too early to get feedback on your design.  Yes, the game is your baby, but unless you are planning to never release it, you're going to have to be comfortable with the idea of people looking at it and, occasionally, trashing your idea.  Although it may be hard to hear, even those who trash your game are giving you a nugget of truth, even if it's something as simple as, "I'm not your target demographic."  The more you have people look at your design, the better the game you're designing will become, even if doesn't feel like it at the time.  Who knows, maybe they'll even give you that one tidbit that solves an issue you've dealt with for a while.

Oh, and in that same vein of fast feedback, if you are listening to this podcast around the time of release, OMGJam8 is coming up November 6th through the 9th of 2020.  I plan on entering it to scratch my itch for some rapid development.  I'm not sure what engine/framework I'm going to be going with, but I'm really looking forward to participating in another jam.  I missed out on Ludum Dare 47 and want to push myself with time crunch another time.  If you haven't given a game jam a try, join me in the OMGJam.  It's a fun way to practice, learn, or just execute on an idea that's been rolling around your head.

Anyway, that's all that I have for this episode of the side quest.  As always, you can reach me on twitter as @jcsirron.  I'll talk at you next time.