Digging into user reviews

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

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

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

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

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

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

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

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

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

Always have a playable prototype

           I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the nineteenth episode on working on your game development weaknesses:

Welcome to another adventure mechanics side quest. It's me, Chandler.  Today I wanted to talk about something very important to do as a game developer, but many don't actually do.  I'm talking about always having your game in a playable state.  Sure, a lot of developers usually have *a* version ready, but they then fall back on, "Oh, this isn't the latest version," or "Just wait until you see the new version I'm working on!" whenever someone asks about where their game is in development.  I am not immune to this, either.  If you've looked at my itch.io page, you'll notice that the last version for Cartogratour is from June 2021 (!), a full two years ago.  That's not a great look, honestly.  What can I do to remedy this?  By always having my playable prototype up to date and ready for feedback.  Let's talk about always having a playable prototype ready for play testing.

Right now, Cartogratour is in *exactly* the same state I said they should not be in.  The features that I have been working on are in various states of completion, from half-baked to barely mixed together, to say nothing of even touching the oven.  That's not great in terms of being presentable, is it?  No one wants to play with unexplained features or grapple only partially implemented functions that are supposed make the core of the game.  And because of that, there my last version sits, unloved and unplayed.  Players that are into development want to be part of the game development journey, not anxiously waiting for a new build that will never come.  That means I need to get a new build ready and out.  But what is going to go into this new build, or more succinctly, how do you determine what goes into each update?  Let's take a short aside and talk about that.

There are a number of schools of thought on what should go into updates, ranging from a constant rolling update train, to well curated semi-annual events.  It's up to you to decide your release schedule, but have an idea for how big you want your updates to be.  Are you early in development, where each feature is groundbreaking and need to have that new feature attention and bug fixing?  Or are you later in the development cycle where it's content time and prodcution can take a while to get everything just so?  That will determine where you want to cut off features for your builds, then.  Obviously, earlier in the cycle means you want attention on your idea, and making a new build each time you get a new feature mocked up and ready to be played with may help you start building an audience and testers.  Be careful when doing this, however.  As I mentioned in my talk on getting feedback, everyone will want to suggest changes, many of which will end up radically changing your game, sometimes for the worse.  You need to be confident in your feature design and show the people playing your build your vision, not give thme a blank slate to project their desires onto.  If you aren't sure about a feature and need time to explore it more, don't include it in your build.  If, on the other hand, you want some more eyes on it for whatever reason, wrap it up into a build and start looking for feedback.  That's the fun part of game design:  You can get feedback on it and see where it takes you.

As you move further into production and (hopefully) have all your features fleshed out, if not complete, you may end up having to wrap your builds around content instead.  This is both exciting, since you're marching towards the completion point for the game, and terrifying.  Is all that content in this build enough?  Did you put enough into it to satiate your audience's need for content, while not expending everything on one update?  In this context, I'm thinking of one particular character's story arc, especially if it requires many pieces to be in place before it can all be revealed.  In that case, it may make more sense to break up that arc into smaller pieces that can be mixed with the other pieces as they are completed and have the arc follow production that way.  It's going to be up to you to try to figure out how to handle that Gordian Knot if you decide to chunk it that way.  Planning out content releases end up being a lot harder, at least to me.  Looking at my games, though, that's probably not surprising. These aren't the only way to divide up how you make a release, but are merely useful ways to structure your releases.

Now that we've looked at how to parse builds, why would you want to have one ready at all times?  Simple: you want to be prepared to give your game to someone at a moment's notice.  Think of it as preparing for success.  If you get an opportunity to showcase your game and potentially get feedback or build a fanbase, why would you want to show your older stuff?  It's giving your game a bad foot to show off if it's not the latest thing you've been working on.  Granted, I've said that there are going to be some compelling cases where you won't want to include everything in a build, but that doesn't mean you should be holding back on making builds that best reflect the current state of your game.  If you feel that the one feature you've been working on is far enough along to showcase, spin up a build.  Worst case scenario, it's not quite what you want and gets some unhelpful feedback.  Even that can get more eyeballs on your game, even when it's not done or ready for prime time.

There's another reason to have your game ready to be played at a moment's notice.  I don't know about you, but every time I fire up my latest version of my game, it makes me want to work on it more.  And when you're in the content mines making yet another quest, mission or whatever and it's dragging you down, that little bit of motivation may be exactly what you need to get over this particular hump.  That's not to say that it's going to work every time, but the one time that it does and it prevents you from quitting is a success story in my book.  And if you've stuck with me in these rants, you'll know that I want to get more games across the finish line and developers moving onto their next game.  At the end of the day, being able to show your work with pride may be enough to keep you chiselling away at that proverbial block and exposing the sculpture that is your game.  I'm waxing a bit poetic, so let's get back to the talk at hand.

The last reason you really want your game always playable is to be prepared to show it off whenever there is a good chance to do so.  You don't want to be caught flat-footed and miss out on showcasing your game when the ideal opportunity arises.  In the same vein, sometimes opportunities will present themselves for you to be the first in the door to have your game reviewed or plugged.  With a hit-based industry like gaming, each and every opportunity you fail to capitalize on will potentially limit your game's reach when it comes time to release it to the public.  And that means your game is going to wallow in obscurity, along with a mountain of other games from equally talented people.  Seriously, look at your favorite genre on itch.io and scroll for a while.  You'll see games that absolutely deserve to be recognized, but aren't for one reason or another.  Make sure your game doesn't fall into the same fate by making sure you're ready to have the latest version playable at all times.

And on that note, I'm going to be releasing the latest version of Cartogratour at the same time this episode goes live.  It's a current snapshot of everything that I have sufficiently done up until this point.  There's a number of things missing, obviously, but it includes a basic NPC that will wander around the town tile, a proof-of-concept conversation system that you can progress and a few other things that I'm not going to mention.  Go take a look!  You can find it on my itch page jcsirron.itch.io.  If you want to leave a comment, suggest a topic, or something else, you can post them on our website, theadventuremechanics.com.  This has been the Adventure Mechanics, and I'm Chandler.  I'll talk to you next time.

Working On Your Weaknesses

          I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eighteenth episode on working on your game development weaknesses: 

 Welcome to the adventure mechanics side quest, it's me, Chandler.  For this month, I've committed myself to focus on one solitary thing for Cartogratour: Art.  I've committed to this because I feel like it's needed at this point. I have the bones for much of what I want in the game and I've kinda hit a doldrum of sorts. I was inspired by a game jam that I entered mid-April which was just doing a mockup of an imaginary game. It was called the mockup game jam. Original title, I know, but it helped me personally practice making artwork for a game. So, let's talk about practicing things you aren't good at in game design.

We should probably start by talking about how to take an honest inventory of your skill set. Meaning, you need to look at your previous work and evaluate yourself. Some things are going to be really proud of, other things not so much. And don't just do it for your last game, you should do it for every game. The primary thing to remember is that you did the best that you could after the time.  A faultless self-inventory, if you will.  Game design is a skill, after all. The best way to learn is to evaluate what you've done and how you could improve it. A useful metric to judge yourself by is what the Ludum Dare rating categories use for the compo. They are: overall, fun, innovation, theme, graphics, humor and mood. You don't have to use these metrics, but I have found them extremely useful in judging my own works.  I'll post some of my post-mortems for my game jam games into the show notes for those interested. If you find a metric that works better for you, great. Just be consistent with it when judging your previous works.  Comparing by using one methodology to another using an entirely different one isn't going to help you.

Nobody is a perfect developer i.e. No one can make an entire game by themselves and have it turn out exactly the way they want it to by themselves.  That inlcudes the savants that hav made their dream game and released them by themselves.  With the wide spectrum that game design touches, this is to be expected. That doesn't mean we shouldn't practice all of our skills, however. There are certain blind spots that all we will have in game design that we should be not only aware of, but willing to practice to get better at. For me, personally, that's artwork and anything audio related. Sound effects and music both mystify me, despite my best efforts. The music that I make for games ends up looping horribly and sounding like a child playing with a xylophone.  Although I have some experience making decent sound effects for games, most the time the sound effects come across completely different than how I imagined them.  Same with making art. I can do characters relatively okay, but doing world design and generating textures for said world is beyond my average skill set.  Don't get me started on concept art that I produce.  I don't think I've made anything I've been happy with in that department.

Programming, on the other hand, I'm pretty decent at. I've done coding on pretty much every project that I've worked on thus far. I feel like I have gotten a pretty good grasp on how to go about the design process and actually implement it. Not relying on a game engine has forced me to become quite proficient at figuring out how to make a given mechanic. It has also given me a low level understanding of how to implement a graphics library and other fundamental things that a decent game engine provide for you out of the box. I have found that immensely useful and it has worked for me.  I have also exposed myself to several game engines on top of working close to the processor.  Although limited to working with them on game jams, I've worked with both Unity, Godot, and Game Maker.  Each has their own strengths and drawbacks, but they don't really scratch the programming itch for me for some reason.  I just love working at that low level and coming up with elegant solutions.  The parts that make a game engine run just fascinate me. That being said, only build a game engine if you want to learn how a game engine works. But, that's a talk for another time.

So let's say we've gotten all of our strengths and weaknesses figured out. There are a number of ways to improve them, ranging from focusing an entire game jam on just one or only a few weaknesses, to only spending an hour a week on it as focused study. Make sure that you aren't overwhelming yourself by adding an additional amount of work that you aren't prepared for. But also, make sure that you're giving enough time to work on your weaknesses so that you aren't just saying you're working on them. The goal of practicing with them is to focus intentionally on your weakness and making it an asset. However you end up practicing, make sure that you are consistent about it. After a week or two, or whatever length of time you feel is appropriate, go back and look at your progress from that time period. If you feel you have made enough progress improving, you can always choose another skill to focus in on. Continue on doing this until you feel like you have become a well-rounded game developer. I say that as if that's an easy thing to do.

One way to encourage you to work on your weaknesses is to give your self a little treat to work on after you've reached a milestone in your practice.  One of the developers that I regularly chat with does exactly this.  They will give themselves a month long goal to focus on for their project, and then work on something art related when they finish their goal.  Applying this methodology to practicing a weakness is pretty straightforward.  If you are weak in one field, make a goal for yourself in practice terms, such as making a certain number of character studies or something, then you can do a bug bash, or add some small feature that you want to put into your game as a reward. It's been a pretty effective method for me to do personally, but there are some things you should remember about this when working on a weakness.  You have to make sure that you don't half-ass your efforts in improving your skill.  The popular phrae, "practice makes perfect," is somewhat misleading.  It's more like, "practice makes permanent."  Meaning, anything you've practiced will be become the first way that you will approach the skill.  If you practice your weakness in a sloppy or lazy way, that laziness will only be perpetuated when you use it in the future.  Make wise use of your practice time.

So, in terms of me becoming a better developer, I'll be focusing in on artwork this month. Specifically, I'll be working on mockups for the mini games that I want to put into Cartogratour. I've been threatening this for a while now, but I'm going to be using the energy I got from the Game Mockup Jam and springboard back into Cartogratour. And as another form of accountability, I'll be posting the results of this focused time onto my personal blog for all to see. I'm not sure whether I'll post them on a weekly basis, or in one big dump when I finish the month.  It's not exactly a huge amount of accountability, but I feel like that will be enough to get me to want to actually post what I make. And if you want to call me out on not actually posting, go ahead! I need the kick in the butt to actually finish Cartogratour. And, who knows, I may actually want to work on it even more. Only time will tell, however.

That's about all that I wanted to talk about in terms of working on your weakness in game design. As always, if you want to leave a comment, ask a question, or anything else reach out on various social media. My handle is @jcsirron on Twitter and Mastodon. Or, you can always leave a comment under this episode on our website: theadventuremechanics.com. this has been another Adventure Mechanics Side Quest and I'm Chandler. I'll talk to you next time.

Starting market research for your game

         I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the seventeenth episode on starting market research for your game:

Hello and welcome to The Adventure Mechanics, this is another side quest.  I'm Chandler.  Today I wanted to talk about doing market research for your game.  I know it's not the sexiest thing, but it will mean the difference between your game being moderately successful and an utter failure.  After all, there are thousands of games being made right now and I'm willing to bet that you don't know about the vast majority of them.  Let's talk about doing your research before diving into that next game design, so you don't end up disappointed when it comes to release.

So, how do you do market research?  It starts with knowing what your game is.  Are you making a puzzle-based metroidvania?  Then you should look at both puzzle games and metroidvanias.  Is your game harder to define the genre for?  Then you'll want to spend time nailing down what, exactly, genre your game falls under.  You want to make sure that you are casting your net to be as broad as possible at this point to cover the most potential audience that you can.  Why do it this way?  Because it gives you most optimistic picture as you go about defining your audience.  And that's important because if your game is requiring a certain number of people, and your market research says that your audience is smaller than that, it's a pretty good indicator that you shouldn't be building your game.  At least not in the way that you have it currently.

That's not to say that you should define your game so broadly that you're not going to get useful information out of research for it.  If your game falls into the genre of survival crafting, for instance, try to narrow it down a little bit further.  Yes, there are a lot of games that fit that genre, but you're not going to get a whole lot of useful information out of your research if your delta is so large that it can be anywhere from zero to infinity in terms of audience.  In the instance of survival crafting, think about what theme you have for it.  Is this an environmentalist survival crafting game?  Then include the environmentalist tag in your search.  Is it zombie themed?  Put that zombie tag in your game search.  The idea is to get as many tags that can apply to your game as possible and still properly define it.  Once you have that, then we can move on to the next step.

The next step being looking at other games with the same tags and seeing how they perform.  You can use resources like steam spy or steam charts if you're planning on making a PC game and releasing it on steam.  Note the top selling games from your search results and note their sales numbers.  This is going to be your market ceiling.  Also, if you can, take a look at the average price of the game and use that to estimate about how much that game has made.  It's not going to be a perfect number, but that will give you at least a general idea of what a breakout game can make when it's similarly tagged.  This is how much you would potentially, and I stress potentially, make if your game happens to repeat that same lightning in a bottle.

Don't just look at the top performing games, however.  Likely your game is not going to be the breakout hit that you're hoping it will be.  It would be nice if it was, but statistically speaking it's not going to live up to your expectations.  Look down at the mid and a few of the bottom tier games that match all of your tags, or most of your tags.  Do the same calculations with these games, too.  This will give you the medium and low range for what a game in your genre could potentially make.  Obviously, the floor for any game sales could potentially be zero, but hopefully you're putting enough effort into it to at least make a few sales.

These games are also useful for looking at for other reasons.  They will be more informative of your likely audience.  People who buy these games are looking for your game, specifically.  This is where you'll find feedback on what your audience enjoys about the genre or similarly tagged games and what they don't like about them.  You can use these pieces of information to inform your game design.  Did you plan on copying something that one of these games already implemented?  If yes, what did the audience say about it?  Was it positive, negative, neutral?  Use that information to guide your decision making.  Remember, all of this is to reach your goal of making a successful game, however you define successful.

Let's use Cartogratour as an example here.  The most successful game as a reference point I can use would be stardew valley.  That game has a huge audience and countless fans.  It's also a farming simulator, not a cartography game.  That means it's not going to be the best reference point for what I'm making.  What other games come to mind?  Well, taking a look at the steam charts for casual sim games isn't really going to help me.  I could put pixel art and map in as tags, and that might actually help narrow down other games that match it.  I kind of already know a moderately successful game that matches Cartogratour better, though.  It's a game called Carto.  Carto is a much better reference point, since it also focuses on cartography as one of the main mechanics and will likely have more audience in common with mine.

Let's take a quick look at the steam spy estimates for Carto.  The list price for it is $20.  The range of people who own it on steam is between 200,000 and 500,000.  That's a lot.  And a wide range as well.  This is probably going to be my top performing reference point.  To get a rough estimate of how much they made from selling this game on steam will half the price of the list price, because nobody buys a game full price, and multiply that by the lowest bound and highest bound.  That gets us between $2,000,000 and $5,000,000 in sales.  That seems like a pretty high upper bound, honestly.  Far more than I would expect, or dream of, Cartogratour to make. Keep in mind that number is not the end profit they made off the game, but rather the raw funds they will get.  Steam has a thirty percent fee for the average game, which means that two to five million figure is cut down to 1.4 to 3.5 million, to say nothing of game returns and other issues. It's not strictly relevant, but I wanted to mention it nonetheless.

Now that we have the upper bound of our research, let's narrow down the tags that we can use to find other game options that would match Cartogratour.  I'm going to choose five that I think will attract the most audience to my game: Exploration, Casual, Indie, Relaxing and Adventure.  This covers the vast majority of the features that I would use to describe my game. When I searched Steam in preparation for this talk, these tags narrowed the results from the absolute firehose on Steam down to 47 games.  That's a lot more manageable.  There are a number of irrelevant games in the results (I'm looking at you, Euro Truck Simulator), so I can't really use those.  So, to narrow it down further, I'm going to eliminate games released in the last month, along with games that have over a thousand reviews or less than one hundred.  When I did this, the results matched better the games that I see Cartogratour competing with.  I ended up with the following three games: Teacup by Smarto Club released in 2021, Miner: Dig Deep by Substance Games released in 2020 and Time on Frog Island by Half Past Yellow released in 2022.  When I do the same analysis on these games, I get the following: Teacup: $0-$100,000, Miner: Dig Deep: $0-$90,000, Time on Frog Island: $0-$200,000.  All of these titles have anywhere between no and 20,000 owners for the game estimated on Steam.  I took a quick look at the titles on steamcharts and this seems reasonable to me.  If I release Cartogratour on Steam, I now have at least a rough idea of what I can potentially expect in terms of income.

So, what does that mean for Cartogratour?  If I wanted to release it on Steam, I can only reasonably expect roughly $60,000 to $140,000 over the next two years.  That may sound like a lot, but if I have to solely rely on that to fund my next game, that only gives me a short runway.  I need to be able to keep my next game to less than a year of development to just make it.  It's not a rosy picture, but that's game development, I suppose.  This is why you want to take a look at the existing games, both the blockbusters and less successful ones, to see what to expect.  Sometimes your game just won't have the audience needed to keep you in business.  It's that information that you need if you plan on having game development be your main job, or not.  Like all information, it's up to you to decide what to do after getting it.  For me, knowing this basic market research, it's not going to stop development on Cartogratour.  I'm not necessarily building it to make money.  I'm making Cartogratour to scratch an itch for game design, and that's enough for me.

Whew!  That was a lot, wasn't it?  And that's not even the really crunchy parts of market research that you may end up doing.  I'm not going to go through these three games and their reviews today.  I know I mentioned that it's an important part of market research, and it is, but I don't want to overload this side quest just to fit it in.  I may do a second side quest on breaking down reviews specifically in the future.  If that sounds interesting to you, let me know!  I want to make side quests that are useful for others as well as myself.  Needless to say, but I'm not an expert in the field, only a solo developer looking at the potential market for one of my games.  Take anything I'm saying with a grain of salt.  As always, if you have any comments, questions or suggestions, reach out to me on either Twitter as @jcsirron or in the comments section of this episode.  This has been another side quest for the Adventure Mechanics and I'm Chandler.  I'll talk to you next time.

Tabletopping your game

        I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the fifteenth episode on making paper versions of your game first:

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

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

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

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

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

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

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

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

Momentum

     I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the twelfth episode on momentum and how to keep it going for a project:

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


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


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


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


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


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


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


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


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

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.

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.