They say anything worth doing, is worth doing badly. So in the first month of working on my game, that’s what I set out to do: make a bad game. And that’s what I did! Some call it a vertical slice, or a minimum viable product, or my personal favorite, the bottom of an inverted pyramid (as Adam Saltsman describes in this GDC Talk about choosing what games to make.) Unfortunately, I made a game so bad, nobody wanted to play it, not even my friends and family, unless I opened it in front of them and asked them what they thought. I clearly have a long way to go. But before we get to that, let’s talk about what I have so far.
The rules of the game are thus: Each player plays rock-paper-scissors with each other over and over. The losing player takes damage, and whoever runs out of health first loses. Additionally, players also gain experience points every round. Bonus exp is rewarded for taking damage. Once the exp bar fills up, the player gets to take an upgrade. Check out the game for free on my itch! I love any and all feedback.
Behind the Design
When I started out, the goal was to hone rock-paper-scissors into a game that was easy to learn, but hard to master. So the first thing I had to figure out was how to determine when a player has won. Traditionally, rock-paper-scissors is played with the “best of” system. Best of 3, best of 5, best of 7. It doesn’t take much to realize that it is essentially a health system, just inverted. For some reason, it feels better to decrease your opponent’s health than to raise your own points. I decided on 20 total health points partially arbitrarily, and partially through playtesting the game. Initially, each win is worth 1 damage, but as players accumulate upgrades, their ability to deal damage goes up, often to 4 or more points. This means that later rounds are rightfully worth more than earlier rounds. This keeps things interesting for both players, because it’s never too late for a comeback. But we still want the initial rounds to be meaningful; if the max health was 100, each initial round would be 1% of the total game, which feels completely inconsequential. So 20 it is, for now.
The other big question was how to determine when players would take upgrades. Initially, I had a round system, where after enough rounds, the game pauses, and both players take turns picking upgrades. But this posed a problem. Who picks first? I had already decided that both players would have full idea of their partner’s upgrades; I don’t like games that hide information before I make decisions. But if you know your opponent upgrades scissors, you’d be a fool if you did anything besides upgrade rock, right? Whoever upgrades 2nd automatically gets a disadvantage. So, I switched to a health threshold. After taking a certain amount of damage, that player will get to pick an upgrade. This worked great because the losing player will always upgrade first, so they get to catch up, along with the aforementioned long-term advantage to the winning player. But this approach has its own downside: if you never lose, you’ll never get to upgrade, so it almost feels like you have to lose on purpose in order to win. I then landed on my current system, experience points. Every round, both players get experience points, regardless of winning, losing, or tying, with extra points rewarded for taking damage. This keeps all the pros of the health system, while solving all of the cons, letting players progress even through ties and winning.
What Went Wrong
Even though I put so much thought and energy into making the game fun, why didn’t anyone play it? Well to me, the elephant in the room is that it’s fucking ugly. I focused so much on the game mechanics themselves (and learning how to use Godot) that I neglected to make something that actually looked appealing. This was partially intentional, as I was told game design recruiters would rather see the raw design on a game portfolio than art I haven’t made. But 99.9% (with maybe a couple more 9s) of people aren’t game design recruiters! The first and foremost goal with designing a game is to bring people joy, and very few people will find any joy in a dull looking game. So yet again I run into the biggest problem of being a solo game developer: being solo. Having to wear many hats, having to be a project manager and a programmer and a UI designer and not just the game designer I sorely want to be.
Where to Go Next
One of my new main goals for the June update of my game is to make the game UI look slightly more palatable. This is a struggle for me because I’ve never been very good at front-end design. I’ll find someone else to do the art, eventually. My ms paint scribbles will have to do for now. My other goals are the ones I’ve had since the beginning of the project: I’m going to split the game into multiple characters, each with different themed upgrade paths, and maybe different personalities? I want a character who really likes playing the same hand over and over, and a character that never wants to play the same hand twice (which is in itself a predictable pattern). You can kind of build this out in the current version of the game by picking the right upgrades, but splitting upgrades into their own character paths opens up the design space to allow for distinct strengths and weaknesses. For example, in fighting games, some characters are light and speedy, some are slow and hard hitting, and many are in-between or completely different! Part of the joy of those games is finding the playstyle that meshes with one’s personality the most, and I’m eager to share that joy with the people who play my game. Thanks for reading, and wish me luck!