Prototype your gameplay first November 8, 2021 on Kenneth Dodrill's blog

It has been about three months since I released my first video game, my brother lives in a canyon, on Steam and Itch. Here’s what I’ve done so far:

This post goes over how I approached each scrapped game, what I did right, what I could’ve done better, and also how those experiences compare to game jam games.

Prelude

After I left my previous job and decided to pursue game development, I had an odd feeling. It was imposter syndrome. Imposter syndrome is very common for many independent workers and freelancers, and it is defined as “doubting your abilities and feeling like a fraud”. I would be a liar if I said I don’t feel like this sometimes even now, 6 or 7 months after quitting my job.

Despite how I felt, I pushed forward with my first game. I felt accomplished upon release, but also immediately began work on a new project - mostly because of imposter syndrome driving me towards learning and doing.

Game 1, Office Scrum

I had the name figured out before any real code, which is a problem. The first idea I had was to set the stage as a 2D platformer (think Mario basically) and have the player control the end-of-level boss. The twist was to have them have to race the player to get to the boss room. I thought the idea was interesting, but once you think about actually playing the game, this idea falls apart.

I then thought, “Wait, wouldn’t it be cool if this was multiplayer? One person would play the protagonist, another would play the antagonist.” Making a multiplayer game is hard enough, but this extra idea that changes the core concept didn’t solve the above issues.

Eventually I decided that the players would fight. I would make two games - a speedrunning platformer for the first bit, then a fighting game for the boss room. Great, now I have two games to make all while being multiplayer. I then decided that:

Lastly, I decided on the theme for the game - a sarcastic, anti-corporation office setting where the protagonist is a kerfluffled worker that is going to combat his boss (the antagonist). The game name was to be Office Scrum. I could already see the game’s Steam capsule artwork (and also it appearing on the front page)…

All of these features try to solve issues with the core concept, but it introduced a new problem - I would be making two games (platformer and fighter). If one side of those is mediocre or less, the other would have to hold up the game. Did I really want to do that? Plus, I would have to make sprite work for each game. You can’t really reuse artwork for a platformer in a fighting game. Thus, more questions. Would people still want to play the game if the platforming sucked or the fighting part wasn’t great? Do I even want to make this game? No, I did not. The game changed so much from my original, simple idea, and I had barely written any code.

So, I scrapped the project. It was sort of tough to do, as it was my first real game idea that I thought could be successful, but now it was just in a zipped folder.

What did I do right?

Something I feel great about is that I didn’t spend that much time on this project. The entirety of the above happened within two weeks. I learned a lot about multiplayer games in Godot and how to use Steam’s multiplayer API components. I also sort of felt proud that I could lay the idea to rest - some people get very attached to their game ideas and keep going for months (or years), only to realize that they have made a huge mistake. I successfully realized that the core concept was flawed, and I decided to set it down after only two weeks.

What did I do wrong?

I went too fast. My mind raced with “oh this would be cool” ideas, and I didn’t really stop to think if they were realistic or if they made sense within the context of the game (which was ever expanding).

What did I learn?

Here’s where the prelude about imposter syndrome really comes into play. My imposter syndrome drove two things during this project: my ignorance of solving foundational game design issues, and the inability to stop doing something. When my first game was done, I felt accomplished, but also felt empty - I had nothing to work on. There was nothing I could tell my family and friends about. So, of course I had to keep going, had to keep working - even if it’s not realistic, or profitable, or marketable! “Just keep doing something!”, I would tell myself. This type of thinking is okay if you’re actively learning things (which I do), but it’s not good when you’re building something that you’re trying to make money from.

I would not call this project a waste of time, because I learned something very important - I don’t need to be working on something all the time. I can’t have a good game idea right away. That takes time and work.

Game 2, Medieval Horror

My next game idea was largely born out of a video I saw about King’s Field 3. I thought - what if I took Resident Evil, but made it first person in a medieval setting, with a focus on realistic weapons and armor?

Can you guess what I did next? Yes, that’s right, I figured out all the core gameplay concepts and built a prototype! Actually, no, that’s not what happened. I watched videos on medieval weapons, armor, penetration tests, castle building, peasant living…the list goes on. I did this for a whole week, thinking of it as “Research! For my next great game!”. Really, I was just very interested in all of it and my excuse was a single line of text I had in medieval-horror-game.txt.

Why didn’t I build a prototype first? Because I thought the gameplay was already figured out. Resident Evil with modifiers, right? Gameplay = done. Obviously, that way of thinking didn’t work. Those modifiers are too extreme, and create different games. The realism modifier combined with the medieval setting is the main thing that does this. For example, consider Resident Evil’s combat gameplay loop. Open door, enemies approach, you shoot them or run away. There is only one “gun” that we know of in medieval times, and it was very slow. Crossbows, bows and arrows, and other similar ranged weapons are slow. I was not super interested in making a game about melee combat. These are my last notes on the project before scrapping it:

Something to really think about is - would this game actually be fun? Is being more realistic fun? What are the goals of this game? Because I’m bringing realism as a core concept into this game, things that are not realistic will seem out of place. Furthermore, does something that is “fun in testing but isn’t realistic” belong in the game at all? Let’s consider the gameplay loop. I [would] have enemies placed carefully with patrols and all. They are undead or similar, so they would not move exactly like humans. I don’t want the game to be insanely difficult, but I do want the realism to play a part of the difficulty. The gameplay loop might be like: Go to area or mission, possibly sneak through some, kill enemies if alerted by using ranged or melee, reload if needed, repeat. Problem is, reloading would take forever. Melee combat would end up being the focus, because the player would be forced to draw their sword. I don’t really want to make a game that is super focused on melee combat, it just doesn’t really interest me. So, really I have two choices - make the melee combat very fleshed out and focus on that, or make the game less realistic and basically turn it into a DOOMish type game.

I had already made a model of a crossbow and bolt, began work on animations with it and arms I downloaded, combined three different kinds of first person character controllers, and completed a large part of the enemy systems. I even spent a few days learning a new tool, TrenchBroom, for making the levels. I did all of this without really prototyping anything, without learning how the game was going to play. Once I finally booted up the game with these systems in place, I wrote those notes and decided to scrap the project.

What did I do right?

Just like with Office Scrum, I didn’t spend too much time on this project. I spent about a month on this project, much longer than Office Scrum - but this game was “riding on” the success of Resident Evil, right? Ugh.

What did I do wrong?

I assumed that taking a game idea that has been proven to work would automatically flesh out my game’s foundation. I imagined that the modifiers were things that would make it different enough and that those “features” would be my selling points. “Resident Evil style gameplay, but set in a medieval time period, and it’s first person, with realistic armor and weapons, and the world is interconnected like Dark Souls…”, it all starts to sound like a CEO or project manager who wants everything and isn’t thinking realistically.

What did I learn?

You absolutely must focus on making a small prototype of your games before doing anything. That’s right, don’t make any artwork, don’t make music or sound effects, don’t even think about marketing the game. Just figure out how you’re going to make the game fun.

Conclusion

Make your game idea’s foundation first. If it’s not fun, it’s probably not worth making.

So, what can you do to improve on making prototypes and generating ideas? Game jams. Game jams are all about making small little games, usually not more than 5 minutes long. They typically have a theme involved, or some modifiers to include if you’re feeling up to the challenge. My last two game jam games came out rather well. The first one I made this year, dungeonyx, is my most popular game on Itch by far.