No Review Games on Steam: Vagrant Knight

    I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to see how games fail before 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 Vagrant Knight:

 Welcome to the Adventure Mechanics, I'm Chandler.  On this Side Quest, I'm going to continue to examine games with no reviews.  And today's game is Vagrant Knight.  Vagrant Knight is a single player top down arena battler created by Gamester and released March 28th, 2023.  According to SteamDB, this appears to be the third and last game the developer released on Steam so far, but strangely, the developer doesn't seem to be linking their games together.  Their first game, Torden, is currently not available for sale at time of writing.  I suspect that they attempted to differentiate the games from the developer in an attempt to not make their library obvious.  Considering the previous game, HELLPIT, is at about 40% for their rating, that makes sense, albeit not a good look when you find out about it as a player, if I'm being honest.  I suspect that Gamester is not going to be releasing any more games.  They stopped updating their socials and all media presence shortly after the release of Vagrant Knight.  Not a great way to start a review, but that's what I found when I looked into the developer.

Let's talk about the game itself, though.  How does Vagrant Knight play?  In each turn in the arena, glibly called "Torture Rooms" in the game parlance, the player needs to wildly swing their sword and avoid the enemies that spawn while the timer at the top of the screen counts down.  When the timer stops, the enemies will stop spawning.  Then it's time to clean up the enemies you didn't kill.  Once you have completed that, you are shown three upgrade options to choose from, either a buff of some sort, a melee special attack or a spell.  After choosing the upgrade, you are sent back to the torture room until you complete a certain number of rounds in it, with new enemies added to the mix.  Not just reskins of past behavior, either.  You have enemies that will slowly chase you.  Others will jump at you at a regular interval.  Some will shoot in from off-screen at your position.  As you get deeper into the game, more are introduced, too.  After the rounds in the torture room are won, you move onto the next randomized torture room.  Play continues until you are bested.

Why did I want to talk about this game?  Well, I thought it had a decent store page and trailer.  And there is a lot to say about your game having a cohesive art style and a good trailer on Steam.  The game header capsule image is well executed, showing the player's avatar in an action pose, sword at the ready, surrounded by the enemies you will face seemingly coming out of the shadows.  It's not anything fancy or complicated, but it clearly shows the player what to expect in this action game, even if they don't know what, exactly, that action will be.  It caught my eye because it showed rather than telling in the capsule art.  It also knows the genre conventions and leans into them, even if it's rudimentary.  In the GDC talk, "Empathizing with Steam: How People Shop for Your Game," Chris Zukowski explains that you should be doing exactly that, much as the romance novel does to signpost to their readers the "flavors" in this particular novel.  On a completely unrelated note, I highly recommend looking at romance novels and trying to guess the major plot points just by looking at the cover.  My partner and I call it, "judging a book by it's cover," as a tongue in cheek nod to the old addage, "don't judge a book by it's cover."  And much like that silly activity, your game should signpost what the player is in for in the capsule art.  And Vagrant Knight does that.  Well.

It's not just the art that works well, either.  The trailer starts with the action, showing all the interesting stuff and monsters you'll face in forty four seconds.  No slow fade in and out of the developer's logo, no build up to the action by showing the arenas.  Just starting off with the action and quickly showing the upgrades you can get on any given run.  Short and to the point.  I liked that.  It follows the Derek Lieu idea of showing two or three things that are interesting and focusing entirely on that.  In the case of Vagrant Knight, it's the action on screen, variety of enemies and torture rooms, and the upgrades.  It makes you want to try the game with every second that the trailer runs.  Simple and well executed.  Now, does the game have more than those three things in it?  Not really.  That's not to distract from the game, per se, but it really made the trailer work so much better only having those three things to look at and nothing more.  I fully expect that Gamester would have absolutely tried putting everything in if there were more features in their game.  But they didn't have that issue in this particular instance.  Even though there's not much to this game, everything in their trailer and on their Steam page are focused on showing you the best parts of Vagrant Knight.  Gamester definitely knows how to make an appealing Steam page if nothing else.

That's great and all, but why is Vagrant Knight on the games with no reviews pile?  It's the game feel.  What the trailer and Steam page don't show is how the game feels.  The player moves around stiffly around the screen.  The "combat" feels exactly as I described it earlier:  You swing your sword wildly and with seemingly little feedback when you hit an enemy with your gesticulating sword.  Yes, I do mean that the sword is made for talking, not fighting.  It stays in place when you click around the combat radius of the player, doing a left to right swinging animation.  And it stays there until the animation is done.  It makes the game feel stilted, somehow.  And that's not a great feeling.  I fully expected the sword to dance around the player, doing damage when it came into contact with enemies with any momentum.  And maybe that's me wanting this game to be something it's not, but I feel like if Vagrant Knight had that, it would be getting a lot more eyeballs and recommends from people who played it.  Lean into a bit of Wuxia, or some other sword art, and make it feel like the player is dancing around the enemies in the arena, slashing them with a quick flick of the wrist.  Even if you don't end up killing them in a single blow, it would feel like you were doing more than just wearing out your mouse, clicking on enemies endlessly.

The magic system is somewhat basic, as well.  While you get the opportunity to select magic when you win, you aren't guaranteed to get a spell.  That's not bad, but when you aren't guaranteed to get one, starting with a basic one would be nice.  I initially didn't even know how to equip a spell.  After selecting a boon, the player is shown a pair of lists.  On your first pass, most, if not all, of the lists will show as locked.  In order to select a spell and special attack, you need to actively click the skill/spell you want.  It's not a big deal, but it's not obvious when you look at the Skills screen.  When you use the skills in game, it's lackluster.  Almost no effects, weak sound effects, the works.  The spells are locked in place, which looks odd when you are using something like inferno, which is a short range spell that should remain centered on the player for greater effect.  That's just the lack of juice.  I would say that's expected for a game in early access, but it's pretty clear this game has been abandoned.  Nothing is really popping out and screaming, "hell yeah!" when I play, despite what the trailer gave.  If there were fewer but more consequential spells, I think it would have made a better game.  In that, I mean that the spells and special attacks that remain feel more consequential and make the big boom that getting a new weapon in Vampire Survivors feels.  We didn't need a bunch of half done abilities for early access, we needed a few finished ones that give the player an idea of what we could expect when others are added.  Really awe the player with what you have cooking, if you know what I mean.

I'm getting into the weeds designing an entirely different game here, and I should certainly stop, but I think I'm getting my point across: The combat, at a base level, just isn't entertaining.  And that could have been easily exposed if the developer did a bit of a sanity check and had some playtesting feedback before releasing into Early Access on Steam.  I genuinely think that if it took base combat and made it interesting, it could have been a unique take on the Vampire Survivors genre.  That sort of power fantasy, coupled with the pomp and circumstance of Vampire Survivors could have been something.  But that's not what is sitting forgotten in Steam's Early Access now, sadly.

The rest of the parts of the game?  Well, they are serviceable and mostly consistent, and that's good enough.  The audio could do with another pass, since some of the sound effects are noticeably louder than the entire rest of the game.  And there are some features in the options that I would personally expect, like music and sound effect controls.  I would appreciate a credits screen, too, but that's mostly a personal thing.  The artwork is simple and consistent throughout, but none of it is particularly bad or good.  And as strange as it sounds, that's a good thing.  It's consistent.  All of it is at the same level and doesn't demand more attention from the player over other artwork.  I know this sounds like I'm bashing it for being bland, but with games in the zero review pile, consistent art is not a given.  Bland is frankly a massive step up from a lazy asset flip or AI dump.  And Vagrant Knight is nothing if not consistent.  No crashes, no noticeable bugs, nothing hilariously out of place.  It's a competent game as-is.  I'm curious where it was planned to go from here, but that's not going to happen at this point, so I won't ask further on that.

Does Vagrant Knight deserve to be in the no review pile?  No.  Not at all.  It's a competently done game with an unfortunately boring combat loop.  Everything I've seen in it is not great, but rather executed decently.  And that's saying a lot compared to it's peers.  I'm not saying that I'll get an itch to play it again, but I am saying that this game had an audience it could have connected with if the moment to moment gameplay was better.  And like the game itself, I would be interested to see where Gamester goes from here, but that's similarly not going to happen.  I truly think that the developer was tantilizingly close to something, but fell just short of getting there.  It's sad to see, especially since they beat the first hurdle on Steam of making it past one game released.  It does give me an idea for a small game, however.  And that's some silver lining at looking at this game.

I'm going to stop waxing poetically about Vagrant Knight.  I feel like I'll just be guilding the lily if I go further.  As always, if you have thoughts on this Side Quest, or anything else game related, reach out to me below this episode or on various social media.  My handle is jcsirron.  This has been another dive into no game reviews on Steam for the Adventure Mechanics Side Quests, I'll talk to you next time.

No Review Games on Steam: Justice For All

   I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to see how games fail before 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 Justice For All:

Welcome to The Adventure Mechanics, I'm Chandler.  In today's side quest, we'll be taking a look at another game with no reviews and see what went wrong.  On the chopping block today, we have Justice for All.  It was made in Unity and released in October of 2022 by Charles Wolfe.  This appears to be the only game he released under his name.  As you know, not having prior finished games or subsequent games in the pipeline isn't a good sign for him as a game developer.  From what I can find, this may have been a school project of some sort, and that would be in line with my time playing Justice For All.  I think it's optimistic to publish a school project on Steam, but it certainly is not unique, especially in the games with no reviews listings.  I enjoy the enthusiasm, but if you're doing a commercial release, you'll need to up your level of polish.  But before we answer that question, what is Justice For All?  It is a platform shooter, with a basic story line and a variety of weapons and enemies to take out.  Once you have taken out enough enemies, the level ends and you are onto the next one.  It's really a simple game, all things considered.

So, what's wrong with it?  To be blunt, a lot.  First of all, the artwork is actually just a series of an asset packs.  That's not a bad thing, per se, since it allowed the designer to consider other parts of the game, like level, enemy and weapon design.  But like using any tool as a shortcut, you need to give it your personal touch and not just flip assets to make your game.  Thankfully, the assets (mostly) work together.  There are a few glaring areas it doesn't, though.  The pixel art style in cutscenes completely clashes with the flash style of the gameplay.  If the designer wanted to use both, they could have put a tv filter or something over the pixel art to try blending it in, or saying the pixel art parts are television broadcasts or something.  There are some assets that, when put together, make it harder to identify what is and what is not actually a platform, leading to some situations where you will jump up thinking you're going to land on a platform, only for the platform to not actually exist.  This makes the game so much harder to play than it needs to.  And all that needed to make this happen was to darken the background tiles while keeping the actual platforms bright.  It's not a huge deal breaker in the short time I dedicated to this game, but I can easily see that putting the player down a death pit later in the game.  It may be worthwhile to compare the artwork in this game with how old games, like the Nintendo Entertainment System game Rolling Thunder, or it's arcade precursor.  I'm not just being an elderly millenial here, the fundamental gameplay between the two are essentially the same and the limitations of an 8-bit system makes level readability the main focus of the artwork.

The paired issue with discerning which parts of the level you can actually use and which are decor is how the player controls.  It's awful, frankly.  You stop immediately when you attack, eliminating any horizontal momentum you may have had beforehand.  And that will kill you.  The jumps are floaty, which isn't a bad thing, but it also makes the player feel like they don't weigh anything.  That makes it feel like you are trying to move a balloon around the world instead of a freedom fighter.  You have limited ammo, but I'll be damned if you know how much ammunition you actually have.  And your controls are hardcoded, with no option to change to something more intuitive to you.  All of that coupled together, it makes it incredibly difficult to feel like you know what's going on in the game.  You will seemingly run out of ammo, grenades and magical(?) things to inflict ranged damage at random and be forced to use a knife.  On one hand, it's nice having a melee weapon in case you run out, but on the other, it's infuriating not knowing how much ammunition you have in your possession.  All of this could have been mitigated by putting the ammo count on top of the weapons themselves in the UI.  Or putting the number above you after shooting, or any other way of bringing that information to the attention of the player.  It then forces you to use this toothpick of a knife to try to poke bullet spongy enemies who are in constant motion.  So you either run into them and cause yourself to get hurt, or you trail them swinging at the air behind them like an idiot.  It's not a great feeling.  This could have been improved by allowing the player to move while swinging, but I fear that it would have taken more work to get that to feel right.  Again, I'll point to Rolling Thunder as inspiration on how game feel could be much better, with the UI having life, bullets for each weapon, and controls that may be stiff, but they work with the level design and enemies implemented in the game.

And let's talk about the enemies.  They are basically red koopas from Mario.  They move back and forth, changing direction when they reach the end of their platform.  It doesn't matter if they are a lowly melee animal or a heavily equipped boss of the level, they will only ever move back and forth, stopping to attack when they encounter the player.  For a platform shooter, this is simply not enough.  There need to be more enemy behaviors, even if they aren't smarter than what's here.  Ambush enemies, flying enemies, or even a slow chasing enemy would be a welcome change in the behavior.  Give me another move besides getting behind an enemy and shooting them in the back.  And if enemies are going to be respawning, telegraph it!  Doors should open and dump a new enemy onto the platform.  Another should parachute from above.  Or just move them in from off-screen.  Make it more engaging than *poof* another enemy is right where you killed one.  That's lazy and bland gameplay.  There is one "boss" enemy on each level, which is effectively your ammo sponge that you must spend the majority of your ammunition on.  If you waste ammo on minions, you won't have enough to kill the boss.  Then, you're stuck with your knife to try killing them, with predictable results.  Who are these bosses?  Hell if I know.  I just know I need to kill them in order to progress.  You can just give them a name above their health bar.  That would motivate me, at least a little bit, to try killing them.  Give your bosses importance.  They should be something more than just a larger enemy pacing to and fro, soaking up all the shots and grenades you have with seemingly little effect.  This is the main part of the game, and should have been explored much more than what little is in the game right now.  All there is in this game is platform shooting.  Make it more interesting, please!

The story is similarly bare-bones.  There are a few friendlies you can speak to, but you'll end up spending a silly amount of time trying to figure out how to communicate, since the window to talk to them is so very small.  They move around, much like the enemies.  And you must, must be within that tiny window to start the conversation.  Chasing friendlies is not a fun experience.  Widen the window to talk to them or stop them from moving.  You can't have both.  And it's not like they are giving much to the story.  The first level has a farmer acting as the worst tutorial I've ever seen.  "They're over there.  Practice a bit before moving on."  Great advice, farmer.  I couldn't ask for more.  No story, no explanation of controls, just "practice a bit."  This is a waste of the friendly on level one.  If this game is being pitched as story-rich, the developer should have given more than an after thought on how to use conversations in Justice for All.  Story should be the driving force, or at least interesting context on why I keep going from level to level killing bosses.  It's not even up to that latter, lower level, in this game, unfortunately.  Motivation doesn't need to be much, but I should care why I'm killing seemingly random armed people and wildlife.  Why is the wildlife on the side of the elites, anyway?  I didn't think boars were smart enough to choose sides in another species' conflict.  They're right there with the bees, fighting one human for another human, though.  That's actually stranger to say out loud.  Anyway, that's why you need to give your story at least some time in the oven.  This one isn't even out of the metaphorical biscuit tube.

The last part of this game that I can comment on is the music and sound effects.  They are... competent.  What else should I expect from another asset pack, though.  The tracks are a credit to their authors, being in line with the game, but not too interesting as to take attention away from the gameplay.  The sound effects feel worse, but that's because they don't have the impact I usually expect from shots and explosions.  They feel flat, somehow.  Like they were meant for either a lighter game or one with a more diverse soundscape where a louder shot or explosion would drown out other important information.  Needless to say, I think the designer should have spent more time juicing up their audioscape to make it feel like the player is in an oppressive world, like how Gears of War or This War of Mine do with their scapes.  Heck, even look at what Minecraft does in caves.  If you're making a fight against oppression, make it feel like it.  Not a Kenney assets bubbly platformer, with weak explosions and anemic shots.

The question now must be asked:  Is this game rightfully in the no review club?  Sadly, I think so.  The developer could have had something more if they added more enemy types, focused more on the effects and how they worked together, or leaned more heavily into story, like the game Deadbolt did.  Any one of those could have elevated this game, but sadly aren't present in this game.  If Charles Wolfe wanted to see other, better implementations of this design, I would try playing some older "cinematic" platformers, like Another World, Blackthorne, the Rolling Thunder series and others.  There's a lot to learn here, but most of it goes back to the idea of emphasizing the interesting bits of the game.  That means working on the movement and making it feel good.  Getting more varied enemies and a better reason to fight them.  Making each shot sound impactful and not the first sound effect that could conceivably fit the bill.  Justice for All needs all these things to be more than what it is.  I hope that Charles Wolfe continues to work on games and learns from this game, but statistically he probably is done publishing on Steam.

That's about all that I'm going to say about this game, though.  If you have something you'd like to add, leave it in the comments below, or reach out to me on various social media as @JCSirron.  I'd love to hear what you think of this game, this series, or anything game design related.  This has been another Adventure Mechanics Side Quest.  I'll talk to you next time. 

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.