No Review Games on Steam: Pixel Knight

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 Pixel Knight: 

Welcome to another Adventure Mechanics Side Quest. I'm Chandler. Today we're going to continue the zero review games series on Steam with Pixel Knight.  Pixel Knight was released in 2023 under Eross Video Games.  It's not their first game, either on Steam or on Itch. They have since released the beginning of another game on Itch a month after releasing Pixel Knight in 2023. So, we aren't talking about developers first game here.  Although the developer may be inexperienced, they have released several games before Pixel Knight. It does appear they have gone dormant after their last game in 2023, with no notable updates or new releases since then, however.

But let's talk about the game in question.  Pixel Knight is a platforming beat 'em up. In it, you will face platforming challenges on top of fighting various flavors of goomba style monsters. The artwork is very good, although it is missing a lot of transition frames, such as jumping and getting hit. I'm not particulalry surprised, since I was able to find the asset pack used for the skeleton enemy on Itch.io.  As such, I'm not going to comment further on the art, since it's likely composed almost entirely from asset packs.  The choice of packs do work well together, which is is a point to the designer.  I will, however, note that even when you purchase assets, unless the license forbids modification, change them to fit your game, like making jump animations for the main player. I talked about assets more in a previous side quest if you're interested in more of my thoughts on asset packs.

The musical choices in the game are surprisingly upbeat and definitely make the vibe of the game more engaging. I suspect that the music follows art, in that it's likely a "best fit" instead of music composed for the game directly.  Like art, that means I'll only be critiquing on how it fits the game.  Some of the pairings, such as the level select screen, don't really match the rest of the theming.  If the designer chose music more holistically and went for a specific style, then the audio scape may have been a bit better. 

There are a lot of additional mechanics in this game that you can engage with, or you can ignore. There is a dash, for example that I never touched while I was testing this game. It shows in the steam trailer, but I never ended up feeling like I had to use it. Overall, this game is a decent representation of an action platformer, but there are a lot of things missing and that is holding the game back.

Let's talk about movement. In an action platformer, you typically have a ramp up to max speed ramp down situation. It makes the game feel like it has weight. This game is all or nothing in terms of speed. And that doesn't feel great. Jumping has no pre or post jump animations, and this makes it feel stilted while jumping. There's no animation of the player in air, either up or down, which only adds to the stilted feel of the movement. I didn't notice jumping itself feeling particularly bad, per se, but it didn't feel great, either.  And may the jump gods have mercy on your soul if you want to attack in mid-air.  That WILL kill all horizontal momentum and send you to the briny depths. I know it sounds like I am harping on this game's movement, and I am, but it is competing with the likes of Shovel Knight, Hollow Knight, Abathor, to say nothing of pure platformers like any entry in the Super Mario series. And missing the most fundamental mechanic of the game is going to turn off players at the very start. If the developers spent more time working on how movement felt, I feel like this game would have reached a larger audience alone. Level design needs to be changed as well. 

For some reason, the designer has a fetish for blind jumps and jumps just at the edge of the players capability. I know that creates tension, but from level 1 to when I stopped playing, every jump felt like it was going to be my end. And, don't get me started on how the blind jumps we're not telegraphed very well. It even shows one in the steam trailer for this game. If you watch the video and that blind jump doesn't bother you, great, you might enjoy this game. But I don't know very many people that enjoy blind jumps. They weren't fun in platformers in the '90s and they're not fun now.

The one note jumps make all the levels feel absolutely basic. There is just enough detail in the background to not call it a test level. It's not much beyond that, though. If the designer wanted to continue working on this game, he needs to go back and think of the challenges that each level is going to have. The leaps of faith and blind jumps each level gets tiresome very quickly and there's not much beyond running from the left to the right with some borderline unfair jumping challenges in between. If certain levels were dedicated to more interesting challenges, or interactions with the enemies, then I feel like this game would have a lot more to it. I'll save most of my thoughts on the enemies for later, though.

The second part of the game is the combat. It is basic, but it has just enough feedback to the player that it is functional. It's not great, much like the movement was, but it is good enough. The player can strike from head to toe with one click and take out the vast majority of enemies quickly. Most of the enemies will flash when hit and emit a sound along with usually a pain state. This is the very minimum I expect from a game that involves combat. It does not do anything beyond this, though. Yes, there is a dash, but as I said earlier you don't really need it. There is also magic, but again, you don't really need it. There are a lot of stats in this game that you won't ever really care about. There's a lot of mechanics that you won't ever use. Do you get where I'm going with this? The designer put more mechanics in before they fully fleshed out any of the mechanics.  They're all functional, but none of them feel great.  Even fighting enemies feels bad in the trailer on the same page. It seems like the designer was trying to make it feel like a slower game than it is, especially when you can speed click enemies to death.  If I can speed click an enemy to death, why would I want to use dashing or magic? The main solution I can think of is to make the enemies more interesting. But that isn't in the game. 

As I said in the beginning, enemies will move left to right on a platform. Once they either hit the edge or the end of their patrol route they will turn around and go to their other edge.  This isn't bad for a starting enemy, but as far as I've gotten into the game, every enemy has this behavior. There are no static enemies that provide a combat challenge. There are no real flying enemies, aside from one that is placed slightly above your attack range. On that note, there are no range enemies for that matter. If they are found later in the game, like in the infinite dungeon, they are introduced too late to be relevant.  Combat ends up being one note and flat.  If there were more variance, it would make the game more engaging.  But as it stands, enemies don't add much to the game.

When you visit town, you will experience the trouble with UI.  You can open up inventory, magic, or whatever with a single button press.  That's not the issue.  The issue is when you want to do anything on the windows.  I was able to brute force myself into figuring out how to stash things, sell loot, and purchase potions.  I never could figure out how to upgrade equipment, however.  Sure, you can put your greaves in the upgrade window with components, but how do you actually do the upgrade?  The menu doesn't say, nor does it show anything helpful in the controls.  This game seems to revel in being obnoxiously obtuse.  For instance, you can not only open up the inventory, but you can open up the pets, magic, and trade windows all at once, too!  Not the type of thing you want to see in your UI.  At all.  Having more control explanation, possibly being optional to turn off in each menu, would go a long way towards making them more user friendly and understandable.

Does this game deserve to be put on the no-review list?  Maybe.  There is an interesting idea here, but it's either not fleshed out enough or not implemented well.  Pixel Knight feels like a game that was made by one person that did not get any notable feedback from playtesters before being released.  If it did get playtest time, it certainly wasn't blind playtesting.  And it made the game so much worse for that.  Yes, the game has a low price and yes, it's a relatively short play, but if the developer wanted it to actually find an audience, there needs to be a lot more work done, mechanically, artistically, layout-wise.  Considering I'm reviewing it years after the fact, I doubt it will ever reach an audience beyond the morbidly curious.  I certainly understand why it has no reviews after examining it, though.

I don't want to bash on this game any more than needed to understand why it's on the no review list, though, so I'll stop here.  If you are the developer and want to talk about Pixel Knight, please reach out!  I would love to hear what you went through designing this game and what process you had.  If you're just a listener and have thoughts on this game or this series, reach out below or on various social media.  My handle is @jcsirron.  This has been another Adventure Mechanics Side Quest.  I'll talk to you next time.

No Review Games on Steam: SpaceWorm

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 Space Worm: 

Welcome to the Adventure Mechanics, I'm Chandler. Today I wanted to try out something a little different from what I'm normally doing for these Side Quests. I've been looking at a number of games on Steam that don't have any reviews, and I was curious why they didn't.  Instead of just doing this for my own edification and keeping it all to myself, I've decided to turn it into something we can all learn from. And to start it off I found a small game that feels like Alien Invaders and Snake, with a dash of Vampire Survivors. So let's talk about it.

The game is Space Worm. Space Worm was developed and created by Brazilian programmer Filipe Izalon. He has a rather amusing website that is based off of what appears to be a Linux command line.  Although Space Worm is his only published game on Steam, he has produced a number of other games as shown on his GitHub page. And a quick look at that page shows that he's still developing games and tools. Most of his commits have been in the last year or so on a variety of different projects.  That's a promising sign. It means that he's not so disheartened by poor performance of Space Worm on Steam that he gave up on the discipline entirely. Although it does appear that he's been focusing more on tools rather than games as of late.

So what is Space Worm? It's actually a series of games made in PICO-8, one of which is similar to Snake mixed with Vampire Survivors, and the other which is similar to an old arcade game where you're just storing stuff for points. There's also technically a third game included, but it appears to be a cutscene only as far as I can tell. Let's start with our exploration of what the main game is, Space Worm.

In Space Worm you are unsurprisingly a worm that navigates the cosmos, eating stars and planets. There are other galactic-sized enemies with unknown motivations trying to stop you. You have the ability to shoot, upgrade, and use different special abilities in your pursuit of eating that cosmos.  It plays very much like Snake. You go around collecting stars and planets to upgrade your snake, and when you collect enough to level up you get a choice of three different icons, very much like Vampire Survivors. None of these icons are explained in-game, although they are on the Steam page. The game ends when you run out of life by getting overwhelmed by your opponents. What is great about this game? I actually love that this game is a marriage of Snake and Vampire Survivors. That's not something I was expecting to see, especially with a PICO-8 game.  The presentation is easy to get into and hard to master, much like Snake. That's a pretty powerful motivator to keep playing the game. Unfortunately, it's not exactly perfect.

To start off with the obvious, the Snake play area is finite. The theming of the game isn't, at least not really. If you go too far in one direction, you'll hit a wall with little or no feedback to where you are.  And although the sizzle reel in Steam shows that there is a white bar when you hit the edge, I didn't see that when I was playing the game. This can and will get you killed. The second is what I mentioned in the description of the game.  The upgrades have no description or glossary in-game to reference. This may have been okay with the arcades, where you could put all of that information on the cabinet itself, but not so much when you don't have access to a cabinet. Modifying the edge behavior and adding a glossary in the pause menu would go a long way to making this game feel a lot better.  It also does not have any noticeable music of any sort. I think that is another place that it could possibly improve.

The second game we have is called Consequence.  It is a simple abduction and destruction game. It has appealing graphics and a tight little gameplay loop. With the additional graphics it has, it actually feels more like a game than the headliner, Space Worm.  The only thing that's really missing from it is a soundtrack and a little bit of wonkiness with the controls I'll go into later. I'm somewhat surprised that Consequence wasn't the headlining game, to be honest. That's not to say it's a perfect game.  It doesn't have diagonal movement, which you'll surely feel when trying to avoid enemy projectiles. There's also no sound effect for  abducting people, which I think is a major missed opportunity to make the  game feel better. And one of the most cardinal sins I feel there is in a game  there isn't a way to go to the top menu without having to mash your keyboard. This applies to all games in the collection.

And the last game, if you can  call it that, is called Another Side. This seems to be the story trying to tie  the two games together.  Although I don't really get what is trying to be conveyed in the cutscene, I do appreciate that they put the effort in to at least have a cutscene. There's no hint that this is a non-interactive cutscene, at least from a player perspective though.
So why do I think this game doesn't have any reviews? The answer is rather simple. Polish. This game lacks a lot of polish. It does have a decent minute-to-minute game loop for each game that you can play, but it doesn't surface what's expected of the player. And for its price point, it's competing with things like its inspiration, Vampire Survivors. And that means the polish level needs to be close, if not on par, with its inspiration. Now don't get me wrong, I'm not saying that it needs to be the exact same quality level, just that it needs to have the same level of effort put into it, especially if you're taking inspiration from a game with such a high level of polish. I actually think that if this game had more juice, it would be more competitive. That means adding more sound effects and music, making it so you can navigate the menus in an obvious way, and quit the game without having to use Alt-F4, and exposing how mechanics work more transparently to the player. I think it would have found a wider audience if the level of polish was that high. It has a solid core in both games, but they just aren't quite tied together even with the extra story, at least not yet. And if we're spitballing here, I would actually take the level up system in Space Worms and apply it to Consequence as well. That would make both games feel like they're minigames inspired by Vampire Survivors.  And that would tie both of them together mechanically, not just thematically. I think this needs to be iterated over a couple more times with playtesters, at a minimum.  It's apparent that the game didn't really see much playtesting before it was released.  Otherwise the issues I brought up would have been at the very least surfaced to the developer, if not addressed.

So, closing thoughts. Does this game deserve to have been buried without a review? As it stands right now, maybe.  The reality is Steam has tens of thousands of games competing for your eyeballs. And this isn't one that's forward enough to demand your attention. That's not necessarily a bad thing, but it does mean that it will be overshadowed by everything else that is.  And that's what we see with it. It's been out for just under a year and a half, at least at time of writing, with no user reviews to speak of. I think there's a good game in here, but it needs much more development time. And by that, I mean it needs to be polished. It needs a lot more polish. And if you happen to be the developer and are listening to this, I'd love to interview you and get your story on the game.

That's about all I had for this game, Space Worm. As always, if you have any comments or questions, reach out to me on either various social media as @jcsirron, or leave me a comment below. This has been The Adventure Mechanics, and 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.

Know your secret sauce

             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-third episode on finding your secret sauce for your game: 

Welcome to another Side Quest of The Adventure Mechanics, it's me, Chandler.  I've talked quite a bit about prototyping versus production in the past.  By that I mean what to do in the prototyping phase, where you're supposed to be exploring what makes your game special.  And what needs to get done for production and what you should be prioritizing during it.  I haven't really talked about what should make your game special, though.  More importantly, when you should look for it.  Today, I want to talk about making that secret sauce for your game. 

Not all games find their "secret sauce" at all, let alone while they're being prototyped.  But before production is really where you want to put in the time and find what makes your design special.  You need to find your secret sauce before you put in the content.  I know in cooking, you usually use sauce to clench up the flavor of a dish, but in game development, you really need to figure out what's in the sauce before you make the dish, if that makes sense.  And that means you're going to be making and setting aside a large number of metaphorical dishes before you find that right flavor for your game.  You're going to be working on this one design for quite some time, so you better be sure it's going to be good. 

But, what exactly is a secret sauce? That depends entirely on what you are designing.  In an RTS, that may be avoiding the multiplayer aspect in exchange for a deep story.  In a farming simulator, that may be dealing with the dead instead of plants, like in the game, Graveyard Keeper.  Whatever the secret sauce is, you need to make sure that it is going to carry your game, or at least be the interesting thing that brings players to it.  It should tie all of your disparate mechanics and art together into one cohesive whole.  It's the interesting thing that gets everybody's attention in the first place.  But most importantly, it's what sells your game.  If your secret sauce follows the recipe seen in too many other games, like making yet another pixel art Metroidvania, for example, you may not hit the goals that you set for your game.  If your pixel art Metroidvania has a time travel element to it, that would make your game stand out a bit more.  Sure there are a lot of pixel art Metroidvanias, but not nearly as many that use time as a resource.  That's just one example, though. 

Another way to stand out is to have a very distinct art style.  Let's say you still want to make that Metroidvania, but you don't want it to follow the pixel art aesthetic.  You can make your game focus around bugs, while keeping the gothic flair seen in many other Metroidvanias.  If you're not familiar with it, this is exactly what Hollow Knight did.  That is basically a love song to Castlevania Symphony of the Night, but with the aesthetic of bugs and Castle Crashers mixed in for good measure.  And if you compare Hollow Knight, as popular as it is now, to other Metroidvanias released around the same time, you'll see that it leaned into its art style to really stand out.  Not all games can have a strong and distinct art style, but not all games need it, either. 

Thomas was alone took the platformer genre and put a heavy narrative to it, but left the characters as blocks. It still has a distinct art style, one that is very easy to initially replicate, but the interesting part of that game wasn't the art style. Listen to our full episode on it if you want more context.  The art was consistent but it wasn't what kept people talking about that game.  It's a great example of leaning into the narrative as the secret sauce.  The game narrates every level.  And it is telling you quite the story while you are playing what in essence is a level-based platformer.  The game plays incredibly differently when you both mute the narrator and take the text off the screen.  And it's much to the game's detriment when you do so.  That's the secret sauce of Thomas Was Alone.

There are many other examples of secret sauces that work well.  I'm sure if you look at any of your favorite games, you'll be able to pick out one or maybe a couple things that are interesting in them.  The features that really sold you on the game in the first place.  In fact, do that as an exercise and compare your favorite games' secret sauce to what you have planned for yours.   If you are anything like me, your secret sauce isn't going to be at the same level as the games you compare to.  It's still a good exercise, though.  It can even make you think of your game more critically and really examine what you think is special about your design.  Again, that's what I'm talking about when I say "secret sauce."  It's not meant to be a convoluted design concept that is only relevant to academic game design.  It's meant as a tool for you to bring your game's best foot forward and, most importantly, put a spot light right on it.

But, let's say you've found an interesting prototype, but you haven't quite found your secret sauce for it, yet.  I know some people will say to find it in production.  But this is really going to put an effective ceiling on your game.  After all, in production you aren't exploring base mechanics or art styles or special audio tricks.  Nor should you, to be honest.  Production is for the swamps of content creation.  You're making all of the assets and all of the story and all of the levels for your game there.  Doing a sidebar and trying to find out what makes your game special is going to make production that much worse.  That's not to say that you can't change your game in production, but rather you want to limit change in production.  Like in software design, shifting as much risk to as early as possible, called shift-left testing, reduces cost.  And let's be honest, exploration in production is expensive.  That's why you really really want to find that secret sauce for your game before you even start doing the content pipeline.

Once you have figured that out for your game in the prototyping phase, you are going to want to emphasize and polish polish polish that secret sauce until it shines.  You may remember me advocating for using assets to get your game out faster, but the secret sauce is one of the cases where you absolutely want to put as much of yourself into it as possible.  If you end up using assets in your secret sauce, spend time making them yours, at the very least.  This is the highlight of your game, after all.  You need it to be the best that you can manage, given your skills, time and effort available.  Yes, I have been working in Scrum and Agile world for years, how can you tell?

If you have your secret sauce, put it into your pitch.  Use that pitch on as many people as possible and see the reaction to it.  Is it piquing interest?  Is it getting people excited about your upcoming game?  Or is it getting polite, but neutral, responses?  This is the first "playtest" of your game.  If you're not getting the reaction you expect from your pitch, it's time to evaluate it and possibly look at another secret sauce for your game instead.  Keep in mind that pitching your game is a skill, though.  One you should be working on as much as possible.  That's a good talk for another time, however.  For now, just focus on polishing how you get your game's secret sauce across to the potential player base.  If it's getting the responses you want, the easy part is over!  You now have to make the game.  Hopefully using the secret sauce you pitched.

Okay, that's enough on secret sauces for now.  At this point, I think I'm hitting the jamais vu experience for the phrase "secret sauce".  That being said, what has been your experience looking for what makes your game special?  Let me know in the comments section below.  If you want to follow me, I am on various social media as jcsirron.  This has been another Side Quest for The Adventure Mechanics.  I'll talk to you next time.

Getting Started in Game Development Part 2

             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-second episode on tooling for your game and keeping your game in mind:

Welcome to another Side Quest for The Adventure Mechanics.  I'm Chandler.  If you don't know, I run a game design group that talks about game design theory and showcases progress on the games each person is making.  It's that one form of accountability that I find most helpful, even though sometimes I don't live up to my ambitions.  As new people join the group, I find that they tend to ask very similar questions, especially if they are trying to break into game development as a career.  As such, I've been thinking about how I can help them figure out how they can get into the industry and potentially land a job at a studio.  Today, I'm going to build off of my last installment of getting started in game development and explore considerations on how to grow both your skill set and your hire-ability after you've taken your first steps into the game design world.

So, in the last installment, I spoke as if you just started your journey.  It covered surveying your existing skill set and looking at types of games that would be best to work on to get you started.  That includes breaking down your first game into the smallest pieces possible to ensure that you actually finish the game.  Using that as our starting point, let's take a look at the next step: building upon that first game and taking your second (and third) step.  What could the next step be?  Iteration.  Getting your first game out is a huge first step, and not an easy step to achieve.  And although that first step is rough, it's not enough.  You need to go back and build another game.  I know, you just climbed the mountain once, why do it again?  Well, if you want to work on games, that's your life now.  You might as well get into the groove of things and practice, practice, practice.  And that means the whole thing: Prototyping and pre-production all the way through to release and support need to be practiced.  You don't want to be the buff person at the gym with chicken legs, do you?  All those muscles need to be exercised.

Let's say you don't want to go back to the blank page of a new project, though.  What else can you do?  There's a few options, but my personal go-to for iteration practice is a game jam.  I've spoken on them before, but they really are going to be the fastest way to get through an iteration and expand your skill set.  Many even provide either theme or mechanic guidance so that blank page isn't as intimidating.  And with jam calendars on sites like itch.io, you can comb through and find a jam that both fits your goals and time frame you're looking to work on a new project.  They really are a powerful tool to build your game design muscles.

Although they are a very quick way to expand your skill set, they are also exhausting.  Pacing yourself on the number of jams you join per year is a must.  When I first entered into a jam, I was hooked.  My first Ludum Dare was a mess, but it was fun.  I wanted to do it more, so I participated in the next six consecutive mini-Dares, which were tiny monthly jams.  Needless to say, I burnt myself out by the sixth one.  In order to get myself back into balance, I took a few months hiatus on game jams.  If you want to participate in jams, great!  In your preparation for the jams, make sure you're giving yourself enough recovery time between jams, and possibly more importantly, time for real life, too.  Designing games is fun, but you're human and need to take care of yourself first.

One objection to the concept of game jams is the competitive aspects of them.  You are technically competing either against your last jam or others, if the jam is rated.  That can be overwhelming.  I get it, competing, coupled with the short time frame to get your game out is intimidating!  It can easily force you into a grindset that can and will quickly exhaust both your enthusiasm and your will to continue.  Game jams aren't for everyone.  That doesn't mean you don't need to iterate on your design skills, though.  It just means you need to find a lower impact way to get your iterations in.  You can still use a game jam as inspiration, especially if the blank page problem plagues you, like it does for me.  Pull from game jam themes, or use sites like https://letsmakeagame.net/game-jam-theme-generator/ to generate a theme to work with.  There are also jams that focus on mechanics instead, if that's the way you prefer to work.  Once you have that figured out, you need to design the game. Avoid putting code to your project at first.  Really dig into your game and flesh it all out, noting each mechanic, a list of artwork needed, story beats that need to happen, et cetera.  Once you have that laid out, you want to set a deadline.  This is important because you're going to need to make an endpoint where you need to put the proverbial pencil down and walk away from it.  And if you want to design games, walking away from a project *is* as skill.  Learn to manage your game projects and stick to what project manager-you laid out.  You need to make multiple games and finish them to be a full-time designer.

One other way to get iterations in without using external prompts is to revisit previous designs.  There's no shame in going back and taking another iteration on one of your previous designs.  It does require you to have previous designs, however.  Make sure you write down game ideas and key mechanics whenever you have an inspiration.  That way you'll have a design backlog to work from.  Once you have that backlog, be it previous completed games or just ideas, there are a couple of ways to revisit a design.  You can wipe the slate clean and redo the work from the ground up.  You can also pull the previous version of your game and do a combination of refactoring and augmenting your previous work to expand on it.  Both approaches have merit and drawbacks.  The clean slate approach allows you to build up a new structure, bringing in the lesson from the previous iteration to make a potentially stronger framework.  The augmentation approach allows you to practice revisiting previous work and getting back into the mindset when the old framework was designed. Obviously, if you are only working off of one of your design ideas, then you really are just looking at it with fresh eyes and will need to start from the ground up.  Whichever method you end up doing, you'll still need to go through the whole process that I previously described.

And remember that whichever way you choose to build a game, stick to it.  You need to build and finish games.  That's the designer iteration cycle.  Each game needs to be taken to it's logical conclusion, even if that conclusion ends up being dropping the game and retiring it to the backlog.  Getting too attached to a given design puts you at risk of stagnating and putting you that much further away from going full-time as a game designer.  If your goal is to go full-time, you need to have your portfolio.  And in order for that portfolio to be built, you need to complete games.  Building one game *technically* makes you a game designer, but if you want to make a career of it, you need to have more than one.  Like in the TV and movie industries, the best known actors are the ones that are in a lot of shows and movies.  The same applies for game designers, especially since games are a hit-driven industry, too.  You need to start making your portfolio to show both the skills you have and the style you've developed as you design games.  If one of the methods you choose to build games doesn't work, try a different one.  There's no shame in abandoning approaches or tools that don't work for you.  At the end of the day, it's only a failure if you both didn't learn from it and it caused you to quit.  Trying again and again is what distinguishes a real designer from one-shots.

Anyway, that's the main thrust of what I wanted to cover in this Side Quest.  As always, if you want to ask a question, leave a comment, or commiserate with the challenges of designing games, you can reach out to me on various social media with my handle of jcsirron or leave a comment on this episode.  I am curious what your experience has been in the industry, be it from a hobbyist perspective like myself, or all the way up to a project manager on a project overseeing hundreds of people working towards a triple-A title.  This has been an Adventure Mechanics Side Quest and I hope to talk to you next time.