No Review Games on Steam: Vertical Descent

  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.  In that pursuit, I'm reviewing Steam games with no reviews to get an idea of why they failed.  Here is the transcript for Vertical Descent:

  Welcome to the Adventure Mechanics, I'm Chandler, and this is another Side Quest. Today we're going to continue our No Review Games Examination with Vertical Descent.  Vertical Descent was made in Unity and released in March of 2025 by RuHix.  They appear to be a Canadian developer and Vertical Descent appears to be their only game released, on Steam or otherwise. I can't really find any other information for them on the internet at all. So their presence is minimal at best. Cannot find a valid website, itch.io page, Twitter handle, BlueSky handle or anything like that. So all the information that I can get on RuHix is from this one game.

Vertical Descent is a first person puzzle game consisting of roughly ten puzzles spread across seven floors in a mini tower.  Each puzzle usually contains a letter or some context for clues.  Once you figure out all the puzzles, you'll exit the lobby of the tower.  Sounds pretty straightforward, doesn't it?  Well, it's complicated.  Let's talk about the build I played.

The current build on steam is broken, there's no sugar coating this.  The lighting, one of the most important things shown on the Steam page, isn't included in the latest build.  And depending on how you set up the game, there may or may not be more or less broken textures throughout the level.  When I compared playthroughs with my co-host Devon, I ended up having a lot more broken textures than they did.  Your mileage may vary, but the broken textures will never be zero.  And since you don't start on the top level of this Vertical Descent game, you can actually just open the screen door on the elevator and fall out of the game.  And once you've broken containment, you can do wacky things like walking off the map, channeling your inner Jesus and walk across water, or even just say fuck it and run to the end trigger.  The possibilites are limited, but none of those are intended.  And this is all before we actually engage with the intended puzzles in the game, too.  Both Devon and I were able to "beat" the game in under a minute.  Before we used the elevator.  Not a great first playthrough.

Because of how broken this game is, Vertical dissents smells like this developers first commercial game.  Judging by how little footprint they have online, I'm pretty sure that's the case. That's not to say this game is completely unredeemable, but rather this game needs to be reworked with the player in mind.  And that's why I find it so fascinating.  This game has potential.  It's just so marred by heads-down developer-itis.  Like they needed to step back, get some external perspectives on their game and regroup.  I'll hold off on further thoughts on this as we get to them, though.

Let's assume that you want to play the game as intended and you're able to make your way to the roof, the seventh floor.  You'll see your objective pop up on screen then.  This makes me suspect that there's a build of this game that starts here, but I digress.  There's a clue on the mattress that relies on meta knowledge (i.e. your U.S. layout keyboard) to give you the code that you'll need to enter into the keypad in the elevator.  That's the level of puzzle the designer put into the game.  Now, I'm not saying it's bad to use meta knowledge, per se, but relying solely on meta knowledge will frustrate players that don't have the same keyboard you do.  And that shows in the Steam community hub for this game, too.  When you enter in the correct code, it will unlock a button for the next floor in the elevator.  The game continues on to each lower floor where the player must solve a variety of puzzles, many tied together, to reach the tower lobby.  I'm not going to go through each puzzle, but I will say that if this game is getting reworked, more clues will need to be sprinkled throughout the environment for each puzzle.  Some solutions straight up felt like they were trolling me.  I'm sure that wasn't the developer's intent.  It was the lack of parallel clues for the puzzles to figure out what to do.  For example, the fourth floor has four candles that need to be lit in order to go to the next floor.  There are no clues for that puzzle anywhere.  And I searched for the clues on how to solve it.  I ended up brute forcing it, assuming that the developer wanted me to run from room to room.  You know what?  That was the solution.  If I wasn't intrigued by the absolute state of this game, I would have gotten frustrated and walked away from the game at this point.  You start on the fourth floor.  Take that in.

Vertical Descent is easily broken and the puzzles can be somewhat obtuse.  Why is it interesting, then?  Well, despite not having lighting, I feel like the story has promise.  It mostly avoids jump scares and has at least one touching moment where you see the deceased person the letter writer tried to bring back.  Trying to bring back the dead by any means necessary is a solid plot point to base a game off of.  And RuHix touched lightly upon the grief of loss.  The puzzles that weren't obtuse were interesting as well.  That's a pretty solid base to build from.  Like most horror games, the game lives or dies on a story execution.  There are hardly any mechanics in the game, so it only leaves ambiance and story-telling to make the game engaging.  And I feel like this game can be changed to make it work.  It's not going to be easy, or quick, but if the dev wanted to build upon this, maybe make a sequel or something, they wouldn't be starting from zero.  And there's a lot to be said about that.  As it stands right now, though, this game deserves to be in the no reviews pile.

Let's no leave it there and say we're revamping this game, though.  Where would we start?  Step one would be to VASTLY increase the internet presence of RuHix as a studio.  It appears that their website has lapsed, and that's unfortunate, but not insurmountable.  Getting a new domain isn't that hard.  I don't expect them to pay the almost six grand that a domain squatter is currently trying to extort.  The dev will also have to get more into a social media they can handle.  That means sitting on handles where the dev is comfortable having them, like Bluesky, Twitter, Twitch, whatever.  Put out a few dev logs, or something to indicate you're alive as a studio.  If you're not leaving a trail, you're making it so much harder for people interested in your game to learn about you, either as a studio or as a developer.  You need those bread crumbs.  Being an indie dev, that's the one way we can get an edge on the AAA space:  We're small, reachable, and approachable.  Use that advantage.  Don't make hard for your customers to reach out to you if they are interested in what you made.  Put yourself out there in some capacity!  If you make a fanbase, they will be able to latch on to your presence online and, hopefully, evangelize you and your studio.  Don't waste that opportunity.

Next, do some market research and play some similarly short horror and puzzle games that are well received.  It doesn't have to be on Steam, either.  If there is a popular horror game in the same vein on itch, try it out.  Take notes on what works for you and what doesn't.  Write down the memorable moments, scares and set pieces.  Really dig into the artistry on display.  Get inspiration for level layouts, puzzles or scary moments that would fit into Vertical Descent.  Examine puzzle games and see how they layout hints, clues and puzzles.  Mock up the puzzles from Vertical Descent to match that style and see if it makes the puzzles easier to engage with.  Just because you're an indie developer doesn't mean you shouldn't try out what your peers are making.  I know some devs prefer to avoid similar games while making theirs, but from what's on display in the current build, external inspiration is needed.  And it's inspiration, not copying.  Take the inspiration and make it yours if you plan on putting it into your game.  Your game will turn out better if you have a base that you enjoy to work from.  I promise you that.

That's all fine and good, but that doesn't rehab this game.  How do we do that?  First, and foremost, it needs to have the expected player path described.  That includes the potential scares, the visual set pieces, and where they can look for clues, and most importantly, the story being told in this environment.  Each floor should ideally have a visual set piece that feels at home in world.  Not having a morgue on the second floor of an office building or a random pair of school rooms on the fourth floor sort of thing.  Make the whole building cohesive.  Once that's figured out, we need to make the characters: The letter writer needs to have clues of his or her presence described and fleshed out.  The player is following them, metaphorically.  We should know more about them than we currently do.  The elevator, yes, the elevator, needs to be better fleshed out and made to fit in the world.  That means making it more like an elevator and not a box that takes you to a series of screen doors.  The dead lady needs to be given more context with the letter writer.  And what came back instead of her needs to be hinted at, too.  Only once we have all of that defined can we then look at remaking the map.  And yes, this map needs to be remade.  There are far too many dead spaces with nothing in them and unintentional red herrings spread throughout.  Each floor should have a clear theme and goal instead of using the elevator to move the player to each floor.  Make this feel tower feel lived in!  It's the home of the letter writer, the dead lady, and presumably, the player.  It shouldn't feel like a broken-ass Unity asset.  Give each character space to tell their story.  Hell, if it's appropriate, use them directly and give them a voice, too.  You can make text boxes for speech and not necessarily need a voice actor to do that part, either.  If there's time, voice acting would be a beautiful addition, though.  It may be out of scope for this remake, and that's fine.  Using grunts and other human sounds will work just fine with what I'm envisioning.

If you're putting up a hundred dollars on a steam page, you need to be sure you're going to at least make that hundred dollars back.  Maybe even make enough to reclaim the studio domain, who knows.  And that means the game needs to be polished.  I find myself saying that a lot each time I make one of the games with no reviews:  You need to polish your game.  And it keeps being relevant because it's the last step in production.  Each and every part of the game should be taken to a base level of polish, and it should be consistent throughout.  No random blood spots that will throw off players from a puzzle.  Each blood spot should have a distinct purpose, to say nothing of everything else put into the game.  Ambiance is good, but the goals and motivations should be clear at all times, especially in a horror game.  You don't have mechanics to lean on, you need to make your environment clear.  Always, always, always.  You want to make sure, even when unsettled or scared, the player will be able to make it to the next area of your game.  Nothing pulls the player out of the world faster than strange or rough edges not intentionally put there.  Except maybe having to do the same "scary chase" scene again.  That's a different topic, though.  It needs to feel like every part of the game is ready for someone to skulk, hide, or get chased down.  And when it's there, the playtesting cycle can finally begin.

Once that's all been executed, playtest.  And I'm not talking about using the dev or their friends or family, either.  People unassociated with the game at all need to play it blind and comment on it.  That's why all of these puzzles feel obtuse.  It never got cross-checked with other people.  All games need to be playtested before release.  It's abundantly clear that Vertical Descent was not.  Not in any real sense, anyway.  Even a short smoke playtest would have revealed not starting on the roof and the shading not appearing as expected.  Before bringing in outside playtesters, the game needs to be as far along as possible.  If needed, break up the testing to puzzle testers and blind playtesters.  You can lean on the puzzle playtesters to get the vast majority of the puzzles into a good state, swapping out the puzzles they are testing each time and adjusting those in isolation.  If possible, don't even put the puzzle into the world.  Make a dedicated build that only shows the intended puzzle without the ambiance.  If it's possible in the best situation, it should work in world.  Save your blind playtesters for when you have everything nailed down to your satisfaction.  Sure, there will be minor issues around, there always are, but you should not be putting a build with obvious issues in front of those willing to test your game.  It's not going to get you the same level of feedback as if you were giving them a nearly complete game.  Blind playtesters are a valuable resource, so squandering them on broken builds is a waste of everyone's time.  They will give you the end-to-end overview you need to push your game up to the next level.  Use them as such.

And once you get your first playthrough feedback, you have more work to do.  Ideally, you'll get a screen recording of them playing and you'll see where the rough spots were and what the player was thinking when they were working out your puzzles.  You need to iterate on each puzzle and make it so your playtesters don't get stuck for longer than you intend.  Some red herrings are fine, and good ways to introduce story bits, puzzle clues, or scares, but they shouldn't be so convincing that you see players fixating on those areas.  And remember, it's always lock before key.  Introduce the locking puzzle before giving clues on how to solve it.  You will see players appreciate that design flow and it will pay off as you go through the feedback process.  Go through this process as many times as you're able to, and hopefully the game that comes out the other end lives up to the horror genre you love so much.

When I started playing Vertical Descent, I was not expecting it to blow up into such a fascinating game to examine.  It absolutely deserves to be in no review town, but it does not need to stay there.  If RuHix plans on taking another chance on this game and is willing to overhaul it, I believe it would be able to stand proudly in the short form horror game genre.  And I'm not really a horror game player, either.  Something in this beautiful and campy mess inspired and intrigued me enough to spend far too much time looking at ways to make it what the developer RuHix originally intended it to be.  And that means something, especially in the environment the video game industry is in right now.

I'll leave my rant here.  As always, if you have any questions or comments on this episode, leave a comment below or reach out to me on various social media.  My handle is @jcsirron.  If you have a game with zero reviews that you want me to review, let me know!  I've been inspired by this series and want to keep making these sort of episodes.  This has been another Adventure Mechanics Side Quest and I'm Chandler.  I'll talk to you next time.

Mechanics Make The Point

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

  Welcome to another adventure mechanics side quest.  I'm Chandler.  Good games aren't easy to make, per se, but they can stumble on how everything interacts and still be good.  Great games take all things and make them work in concert.  A story that works with the actions of the player to not only make the game more immersive, but also get the intended emotion across.  Today, let's talk about using mechanics in your game to make the point.

If you've ever played a game where it intentionally pushed you to a specific playstyle, such as the desperate decisions in Papers Please or being a true hero in The Legend of Zelda: Breath of the Wild, you'll notice that the mere act of playing gets you into the game more than, say, an abstract puzzle or bit of expository lore does.  As the old idiom goes, actions speak louder than words.  When a player is doing something diagetic in your world, you're demanding that they buy into what you've created.  You're asking them to be an active participant, not just an observer.  This buy-in is very powerful.  It's forcing them to actively think about the action they're doing and can push them to do things they otherwise would object to.  And if your game is about getting a message across, that is valuable.  Let's talk about that.

Do you have a specific emotion that you want to get across to the player?  Do you want them to feel desperate or overwhelmed or like they're contributing to something good, bad, or ugly?  Make them do something.  Sure, you can preface it with lore and audio dumps, but those are the appetizers to the main thing you want to get across.  When a player realizes that they're not the good guy and are committing heinous acts, they're more likely to think about what they're doing.  When the player has to balance their home life requirements with their duty to check all the paperwork at a checkpoint, they're going to feel that pang of desperation.  And as long as you don't get too heavy handed with the message, you'll get the player to consider what you're getting across, at the very least.  For a less extreme example of this, let's look at a contentious mechanic in Legend of Zelda: Breath of the Wild and it's sequel: Weapon durability.  In previous installments, your weapons were linear improvements and indestructible.  You could rely on them being there when you needed them, unless they were consumables like arrows or bombs.  In the latest installment, however, you can lose your weapon mid-fight.  You'd then have to either scrounge a new weapon, retreat, or stockpile weapons for that eventuality.  This encouraged more planning, reacting, and the feeling that you're just scraping by.  It made the collapsed world of Breath of the Wild feel, well, wild and dangerous.  Sure, you have a stockpile of weapons, but the red moon is just around the corner and you're a long way from safety.  It made the world feel challenging, not just being told that the world is now a dangerous place.  All of that is in service to the story that the game is telling, too.  This isn't the comfy Hyrule you've played through in other games, it's different.  And when you pair weapons breaking and being a finite resource with the respawning enemies, it's hard to not feel that the game is actively trying to kill you.  And that makes the world so much richer and more engaging, as opposed to just telling the player it's a dangerous place, but letting them clear out areas to be safe.

If you do this poorly, however, you can have mechanics that actively conflict with what you're trying to convey.  Take, for instance, the return to office situation that Adam Jensen has in Deus Ex: Human Revolution.  It's the first social hub in the game.  And like any social hub, it's encouraging you to stop, talk with everyone and explore.  Especially after the intro, where Adam is thrown around and grievously maimed, it feels like narratively we should be doing the "welcome back from sick leave" with our old co-workers.  But the game is actively fighting this by having a radio buddy incessantly nagging us to get to the helipad for our first mission.  This builds tension, but it's also demanding the player to ignore all of this interesting stuff they've just been introduced to and chase the main plotline.  There's something to be said for putting that tension on the player, especially towards the climax of the game, but this isn't really near a climax.  It's at the very beginning of the game.  Barely introduced to our character, barely familiar with the controls, a new area to explore, and being demanded to ignore it all and chase the story.  Now, I'm not a particularly good writer, but this, at a high level, seems to be a good place to change plot points around, to better align the story to the mechanical progression.  What mechanics are we looking at here, though?  It's a social hub, so we want the player to get used to the controls and learn that actively talking to people yields rewards.  Sure, there needs to be something to push the player along to the first combat mission, but the timer introduced here mechanically is actively pressuring the player to go in half ready.  Now, if that was the point of putting this exploration social hub before the action, fair enough.  But it doesn't feel that way to me.  Instead, it feels like the game is trying to get a message across, but the message is clashing with the mechanics.  And while I'd love to critique Deus Ex further, let's get back to the reason I brought this up:  The mechanics are actively fighting against the message here.  If you want to keep the player actively engaging with your story and world, you need to be mindful of what the current mechanics and story are telling them.  They should be working together to get the overall message across.  And in the case of Human Revolution, that's just not happening at the beginning of the game.  The only mechanic that is conveyed with this area is that if you dawdle and explore the area, you're going to be punished by the game later.  And that's not necessarily the point of a social hub, especially in a Deus Ex game.  Be extremely careful about what actual message you're sending to the player with your mechanics and story at any given time.  If you're having issues identifying either, playtest the area in detail.

When you're looking at the message and story, make sure you're not judging the player for their choices.  There can be consequences, sure, but the game shouldn't moralize those consequences.  In the Deus Ex example, the first mission is a hostage rescue.  And if you're too slow to get to the chopper in the social hub, you're put in an actively worse situation when you finally get to that first mission.  It works to get the message across.  But then the game has your radio buddy yelling at you for being too slow, moralizing the consequences.  And then the message becomes you're working for a terrible boss who wants to micromanage you and not actually resolve anything.  That's a different message, isn't it?  If that's what the team was going for, then that message comes across clearly.  But if not, then the moralizing done by your radio buddy has single-handedly pulled the message off the tracks.  That's why I say to be very careful when you want to moralize or criticize the player's actions in your game.  You may have made a fun mechanic, but if the message is that your fun mechanic is bad, actually, then you're going to have the mechanics and message conflicting with each other.  And you don't want to have that in your game.  You want them both to be working together.  A moralizing message is much easier to disregard when you're having too much fun with the mechanics.  Don't ask your players to make the choice.  You may not like what they're going to do.

Well, that should be enough for this side quest.  As always, if you have any comments, suggestions, or feedback, reach out under this episode or to me directly on various social media.  My handle is jcsirron.  This has been an Adventure Mechanics Side Quest.  I'll talk to you next time.

Building your player profile

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

 Welcome to The Adventure Mechanics and I'm Chandler. Today I want to talk about player profiles. I've seen a number of early game devs try to sell their games to other game developers. And I want to address that.

It seems to be a common thing that happens with new developers. They have their copy of a game they really like, and then they shop it to other game developers. This isn't exactly a good way to get your player base started. Sure, other developers will be able to give you feedback, and often it's very useful feedback, but there's not going to be enough developers in the world to support your game unless you're building it in a week. If you're not building for other developers, who should you be building your game for? This is where the idea of a player profile comes in.

A player profile is who you expect to be interested in your game, specifically. There's a number of different ways to make a profile, but the one I like the most is the player motivation model made by Quantic Foundry. I'll link to their model in the show notes, but the short version of it is that players are motivated by twelve factors, clumped into three main groups: The action-social, the mastery-achievement, and the immersion-creativity motivation clusters. Each cluster represents broad motivations players have, be it immediate gratification, deep interaction with mechanics or broad interaction with narratives. I'd highly recommend that you take their gamer motivation profile to see where you're at as a player and get a feel for how their model works. I'm not sponsored by them in any way, I just think that their model works well to create a player profile for your game. Let's play with this model a bit.

If you're building a real time strategy game, your target audience better be strategy focused players. You don't want to make a RTS for the cozy farming sim crowd. Or maybe you do. If you're making it for yourself, the player profile is you. Assuming you want to make a commercial game, however, you're going to need a larger audience. Similar to advertising your game only to other developers, having too small a pool of potential players will fundamentally limit the potential success of your game. On the other hand, the wider net you cast for your target audience, the harder it's going to be to actually attract them. If your game is made for everyone, it's going to have to be everything for everyone. And like in relationships, that's just not feasible. You'll exhaust yourself before getting anywhere close to achieving that goal. You need to find that sweet spot if you want to have a hope of success for your game.

So, how are you going to build your player profile? Look at comparable games, and take a look at the people that are interested in them. For the RTS example, your game is going to attract an older audience that maybe grew up on RTS's from the late '90s. Or it's going to attract people who played multiplayer online battle arenas like DOTA. Either way, you have a very specific audience in mind in this case.

With the former audience, twitch reactions and a frenetic pace aren't necessarily going to be attractors for that type of audience, at least not anymore. In all reality, many of those people are going to have a slower reaction time, more disposable income and a desire for deeper tech trees. Having a good base game with a varied tech tree and a slower game pace, but missing some mechanics that could be saved for a DLC is probably a sound strategy.

With the latter audience, you're looking at people who really thrive on the competitive aspect of RTS, yet still want strong characters and a more personal feel with the units they command. You'll want to emphasize the smaller scale strategy layer and stronger character design. More ways to customize each character in the army and really pushing the character aspect and what makes each unique would be a better approach for that audience. Not all player profiles are going to be this easy, though.

Let's say you are actually making that RTS for the cozy farming sim crowd. That's going to be a hard audience to find. At first blush, I would think this crowd wouldn't be interested in that sort of thing, as a cozy game doesn't lend itself to mechanics mastery and competing with other players, like Stardew valley or similar titles. Let's say that's your dream project and you want to fuse the cozy with the real-time strategy, though. Who are you targeting with this game? If it's the farming simulator crowd, you are looking at people who like to take things slowly and build relationships with other characters in the game. You will likely want to emphasize an overarching story and minimize the competitive aspects of typical RTS games. Knowing this, you may change the direction you want to take your game.

If you want to make a "cozy" RTS, on the other hand, you're likely looking at people who want to have a similarly slower pace, but will still want to have the challenge and push from other players, either real or AI, to keep it from a managerial sim. In this case, you may be looking at games like Majesty or Offworld Trading Company and their audiences. The challenge is still there, but it's changed to either be more espionage, in the case of Offworld Trading Company, or character driven, as in Majesty. Or it could be something akin to Factorio, where automation is the key. Each of these games garners a different audience and knowing what they are and are not interested in will be key to your game's success.

If you have a comparable game, look through their forum posts, discord channels or whatever other thing the community has formed around and see what they are like. Instead of looking for what they like and dislike about the game, look at who the people are. Build your player profile from an aggregation of the community. That's now who you're building your game for. That means every decision you make in your game will have something to test against. The joy of manual labor in a farming sim isn't going to really appeal to an automation player, whereas having a list of recipes they can use to get to their goal definitely will. As you build and market your game, you will then have a much better idea of who you need to reach out to and get interested in your game. And that means you'll be one step closer to actually reaching the audience your game needs to succeed.

I'll stop here, but this is just a start to the player profile topic. It's a much deeper topic, one you could build an entire career around if you're interested enough. As always, if you have any questions or comments, leave them below or find me on various social media as jcsirron. I'm still Chandler and this is the end of this Adventure Mechanics Side Quest. I'll talk to you next time.

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.

Getting to "good enough"

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

Welcome to another the adventure mechanics side quest.  I'm Chandler.  For this side quest, I wanted to talk about getting a specific feature for your game to good enough.  By that, I mean getting your game into a good enough state that you are both satisfied with what you made, yet it doesn't bog you down working on one feature for so long you risk derailing your project entirely.  This came up because one of the participants in my game design forum asked about it.  I initially struggled with a good response to it, so I had to sit and think on it before I had a satisfactory response.  That being said you get to reap the benefits of this question being asked.  So, let's talk about getting to good enough.

When the person in the forum asked about getting to good enough specifically they were talking about getting one mechanic, or I think feature rather, to a good enough state for play testing purposes. Obviously, this is a subjective opinion on what is good enough. So, this is going to depend entirely on you as a game designer. This is a different question than asking if you can use outside resources to accomplish what you are looking for in a given future or mechanic.  I know I previously talked about using existing resources to make a complete game, but this is the flip side of that. We are looking at the core parts of your game that need to get your special touch to really make it your own here.  That means we are looking at the core part of your game that should absolutely be custom designed for your game specifically.  If the core of your game is about farming, for instance, you would want to spend a good majority of your time looking at the farming mechanics. And this is where using outside resources is going to make your game feel more generic. If, however, you spend the majority of your time looking at the core mechanics of farming and forget the rest of your game, Your game is going to feel horribly lopsided and probably incomplete. So, how do you find that balance between asset flipping and or mechanic flipping and sacrificing the rest of your game as a whole for one feature or mechanic? This is going to be your call as a designer.

What does good enough look like?  For some, it's going to be the mere presence of a feature or mechanic. For others it's going to be that feature in a completely finished and polished state. For the purposes of this talk, however, it's going to be somewhere between these two. Not every feature needs to be completely finished or polished , yet it will have to have more than just it's mere existence in the game to be considered good enough. Now , this leaves a huge chasm of wiggle room for you as the developer to work in. What's good enough for me may not be good enough for you. And that's kind of the point of this talk. How can we get you to your good enough state? It's not good enough to compare yourself or your games to a finished one when doing this . I would argue that that is actually actively harmful to you as a designer . If you are comparing your metroidvania movement set to castlevania Symphony of the Night, for example, you are going to put yourself at risk of failure . I say that because Symphony of the Night was made by a very large team over a course of years I believe. If you are a solo developer, you are never going to reach that level at the same speed. Instead, you are going to want to look at the small pieces that you can change and compare those to how you want them to feel. I know that's going to be somewhat difficult, especially if you are looking to make that metroidvania to rival Symphony of the night , but it will be more useful to look at features in isolation as opposed to the game as a whole.  Let's talk about some of the rules that I have for getting a feature or mechanic to good enough.

The first rule that I have is to do a future or mechanic in multiple passes. I don't know about you, but I struggle to have the best idea for a mechanic the first time I come up with it.  There's a phrase in life that I've come across that says, "If something is worth doing, it's worth doing right the first time."  And I'm not necessarily certain that this is useful when it comes to game design. After all, sometimes an idea needs to have more time to figure out what it wants before you can call it complete.  A more useful phrase that I've found is, "If something is worth doing, It's worth doing halfway." Now this doesn't seem like a great way to design something (I.e. doing it only halfway or getting it halfway done), but it is useful in a game design context.  It seems counterintuitive, but giving yourself the space to fail on a given mechanic or feature will allow you time to revisit it in the future when you figure out what was missing from it the first time around. And allowing that failure state, for lack of a better phrase, is going to allow you to play with the feature more later.  Failure states aren't necessarily bad things, especially in game design.  You need to allow yourself to fail at some level.  Game design is hard.  This rule is forcing you to "bake-in" the times where you will fail.  It's not that you are leaving that feature there permanently, it's more that you are giving yourself the ability to walk away in the first place.

The second rule that I have when designing a feature or mechanic is to leave it in a state that can be shipped. In the context of the video game, that means even if it's not perfect , I can still get useful feedback out of it if I release it as is. This is important because you always want to have your game in a playable state . I know I just talked about that, but this is a really important thing that I will never not harp on. Leaving it in a shippable state means that you will have at least the latest iteration of the idea that you had for a feature or mechanic. If it's in a broken state that you cannot play, it is of zero use to you or your players. It also looks bad on you as a designer , as if you didn't consider that feature or mechanic as important. Just go take a look at any early access game that was abandoned and, if you're strong enough, look at the reviews of that abandoned game. You will see a lot of very salty players venting about how a mechanic wasn't "done" or "broken" or "missing".  Now, to be fair, many games in early access are abandoned for a variety of reasons, so it's not exactly fair to look at them as an example of what not to do. But, the point I'm trying to make is if those mechanics were left in a relatively stable state , even if they were able to be exploited in some way shape or form , the game is still playable. And that's the main point of having a feature ready to ship. Even if it ends up getting pulled for not being relevant, it's still there for somebody to look at and engage with. And that's kind of the point of this rule.  You need to make your game as complete as you can at any point. Obviously, this doesn't really apply to prototyping, but even there having a rule of leaving a given game idea in a playable state helps. Nothing sucks worse than having to play detective on your own game prototypes.

The third rule is more nebulous. Whenever I am frustrated, or annoyed, or blocked in some way, on a given feature or mechanic, I will step away from it for a short time. For me, that's usually a week or two. And then after that time away, I'll take a look at the feature or mechanic that was giving me problems and try again. Just because a mechanic or feature is "good enough," it doesn't mean that I'm done with it. I know a lot of artists of various types will never consider their works "done".  I am one of them.I guess the rule here is to walk away from a given mechanic or feature after it blocks you. With the caveat that you're going to need to leave it in a playable state, this is useful because it will allow you to let these slower parts of your brain ruminate on the issues you're having with that feature or mechanic. And you may come to the conclusion that what you have now is fine. That's great. Other times, you'll realize that you need to take another pass at that mechanic and give it another go. That's also fine. Sometimes you just have to sit on a problem to really find a satisfactory answer to it. And if game design is anything, it's a series of really hard problems.  However you get to good enough is entirely up to you. Just remember, your definition of good enough isn't going to be the same as your players. You will want to adjust accordingly.  But that's for another talk.

This only touches the surface of what I consider important for good enough, but I think it's a good start. If there's enough interest in this topic for another talk I'll get a little bit more into the weeds on it. That being said, this has been the adventure mechanics sidequest on getting to good enough. As always, if you have any feedback or any questions on this side quest, you can reach out either below this episode and leave a comment, or talk to me directly on mastodon.gamedev.place.  My handle there is @jcsirron. I'd love to talk about most topics game design related.   I'm Chandler, and I'll talk to you next time.

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.

Getting Started in Game Development

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

 Welcome to another episode of the Adventure Mechanics side quest.  It's me, Chandler.  Today, I want to talk about where to get started in game design.  I have been asked that question regularly, especially from people that are either new or intimidated by the idea of developing a game.  And it is a lot to consider.  Every aspect of your game must be considered and contemplated.  You need to be at least competent enough with your prefered language, engine, or whichever tool you have decided to use to make your game.  It's almost impossible to know where to start.  There's as many answers to this question as there are developers, but I think there's a common thread in each, beyond survivior bias.  Let's talk about some of the things you should consider when starting your game development journey.

The first questions I usually hear when someone asks about how to get into game design is, "what engine should I use?"  or, "what language is best for game development?" as if there is one single answer to these.  Simply put, these questions don't matter yet.  What is your goal for your game designs?  That's where you really should start.  Once you know what your goal is, then you can start answering the earlier questions.  If you have prior programming, art or music experience, these will also inform your answer.  Have you been exposed to a specific programming or scripting language that you're comfortable with?  Use that.  It doesn't have to be the most performant, the cleanest or prettiest language, or anything else that some newer developers will rail on about.  As a new developer, you should be more concerned about how to design a game, not losing yourself in the weeds of comparing performance benchmarks of engines or languages.  If you find yourself comparing how fast one engine does a loop over another before you have released your first game, you're not prioritizing your game.  Don't get me wrong, your first game is going to have to use something, even if it ends up being cardstock.  But fixating on tiny details and pursuing perfection over finishing your game will mean you aren't likely to finish your first game.  Accept that your first game is not going to be perfect and use it as your first step into the discipline, not the start of your magnum opus.  Of all the successful Chris Roberts types that end up in the industry, there are legions of people that pursued perfection at the cost of the good of their game and have not released their game as a result.  In the worst cases, they aren't developing games at all anymore.  I don't want more people to drop game design from this common trap.  Explore why you want to make games before you start searching for the tools to use to make it.  Just as RPG maker will be the absolutely wrong tool to make a first person shooter, using a specialized tool can hinder you as much as not knowing how to design.  That being said, if you end up opting for a general purpose engine, make sure that it has the support or tutorials that you will need to succeed on your first game.  The most powerful engine is useless when you don't know how to use it.

So, assuming you've figured out what to use based on your existing skillset, what type of game should you make?  To answer that, answer this question: What games are you interested in?  If your first answer is and MMO, which part of that MMO interests you the most?  Is it the combat, the social interactions or something else?  Most importantly, can you make an entire game around that one part of MMOs you enjoy the most?  As your first project, you need to make it as small as possible.  And building a fully featured MMO to rival what you played on Battle.net isn't small.  You're learning the basics of game design, so pulling from existing designs and focusing on it will help you learn why things you enjoy were designed that way.  If you adore your favorite game because of the world and everything in it and nothing specific, then look at other short games you've played and pull from them.  You need to be able to pull out one thing that you consider could be made into a complete game and work on that.  For me, it ended up being bullet-hell games.  I made a bullet-hell style game that didn't even have bullets.  Strange, I know, but from my prototype, Log Jam!, I learned a lot about designing games.  I never ended up releasing that game, but taking a game from start to end really opened my eyes.  It sparked a passion for designing games that I've been eager to share with others.  I'm not a fan of bullet-hell style games in general, but it was simple enough to copy and finish.

My experience brings up another important thing about your first game.  Finish it.  It may sound silly, but going through the whole process really will teach you so much more than having a stack of prototypes on your proverbial shelf.  The beginning of game design is intoxicating.  You're working fast on something new and interesting.  Everything you add to your game is making a huge impact.  Once you have gotten past that stage, though, the game changes aren't nearly as impactful.  Does this UI look better over the last one?  Maybe?  How could this card read to color blind players?  These type of questions are what you're going to be working through as you transition from prototype to polishing.  This part is just as import to go through as the prototyping phase.  Sure, it's not as fun, but this phase of game design is going to teach you so much more than exploring basic mechanics in prototyping.  How you set up a menu, how to make your game "feel" better, even how to get useful feedback from playtesters comes from this later polishing stage.  This is where you take your game from an interesting concept to a great game.  In earlier talks, I refer to this time as being in production.  You're not coming up with new ideas, necessarily, rather you are working with the building blocks you placed in the prototyping phase and finding ways to showcase the core mechanics you've come up with.  This is where you can really show the interesting parts of what you have and not just putting everything in place so you get a rough idea of what the game is.  The more time you spend in this phase, the better the game you eventually finish will be.

But what does a "finished" game mean?  That's for you to find out.  For some, it's when you can't think of anything else to polish and work on.  For others, it's when you're so sick of your game you almost want to delete it in disgust.  If you feel like this, by the way, just walk away from it.  Don't delete it.  And in some cases, it can become an evergreen project, where you can always add something to it to make it more engaging.  I'm sure you can think a game like this: A game that is seemingly always in early alpha and never seems to get to that coveted 1.0 release.  Whatever camp your first game ends up in, commit to an end point.  It can be as formal as you wish, be it finishing a road map, or as simple as a date.  Hold yourself to this and when you reach that end point, set it down.  It may not be the best feeling to leave your work like that, but it's important to hold yourself to it.  Listen to my talk on accountability on why that particular point is important.  Or, if that doesn't work for you, look at what you consider a finished game.  Then apply that criteria to your game. If you find that you've already passed that criteria, odds are you're already done with your game.  Knowing when to quit is one of the harder things to learn, especially when you're working on a passion project or artwork.  Yes.  I do consider that games can be artwork, although that's a talk for another side quest.

There's a whole lot more advice that I could give in terms of getting started in game development, but I'm going to call it here for now.  It's best that I don't end up repeating myself, after all.  As always, if you have questions or have a comment on this podcast, let me know.  You can post it on our website www.theadventuremechanics.com or to me directly on twitter with my handle @jcsirron.  This has been the adventure mechanics and I'm Chandler.  I'll talk to you next time.

Accessibility

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

 

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

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

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

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

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

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

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

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

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

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

Achievements

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

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

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

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

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

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

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

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

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

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

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

Momentum

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

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


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


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


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


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


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


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


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


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

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.