What I learned about game development while making Plunderful

What I Learned about game development while making Plunderful

Plunderful is a project made out of passion for the TTRPG genre. Its development was plagued with challenges, but finishing this game has taught me alot about making games, something I would like to share with others that may choose to go down this same path.

A TTRPG (Table-top roleplaying game) is a difficult first game to make. These games work with interlocking mechanical systems, but also have to be flexible enough to serve whatever story a group of players may want to tell. While there are games that contradict this genre statement, Lasers and Feels by John Harper is a good example of this, this game genre is one that solely relies on its core system being good, a perfect way to challenge solely game design.

To continue, I have found physical games to be the best starting point for anyone who wants to make games. Even if you intend to make digital games, creating a card/board game first will expose you to developing a game design mind set. Physical games allow for ‘fail-fast’ iteration and overcome the barrier that is coding, learning how to code when also designing a game for the first time is too much in my opinion. You can design a game without code, you can’t code a game without design.

(Photos of my kickstarter physical game and of a Plunderful Playtest)

So what kind of game should someone make? Choose something you know. Making a game is already a challenging experience and through that journey you will always be learning new skills or ways to do different tasks, but for a first outing, choosing something you are familiar with helps a lot as the process of learning and struggling with something new can be sandwiched between the familiar to keep you going. For me that meant a game where I could spend time in fields I was comfortable in, like art, or adjacent ones, like graphic design.

What helped me as well was the use of base systems. While one could make their own system from scratch, for a first game finding some kind of premade foundation, especially for a short term project, can be extremely helpful to get the project rolling. For digital games this could be looking at games you have enjoyed and seeing what you might have done differently if you made it or expanding on an idea a game presented but you wish could have been explored more. For TTRPGS this would be systems, be it the Kids on bikes system, the D20 system or the one that I used as Plunderful’s starting point: Powered by the Apocalypse.

Powered by the Apocalypse, developed by Meguey Baker and Vincent Baker, is a system primarily made for urban fantasy storytelling. While PBTA is great, I’ve never felt satisfied with its combat system, unlike games like DnD, combat and roleplay are not separated. And while it helps with narrative flow and keeping combat as open as roleplay it’s always felt a bit lacking in my own sessions. This is what I wanted to bring to Plunderful, in turn creating the game’s main mechanic, its card based combat system.

Generating a core mechanic is definitely the hardest part of game design. This is what your game should be built around, like a seed the rest of your game should grow from. And while story concepts or themes for a game can come first as well, I do think a good game should have mechanics that support those ideas. For myself I take what genre I wish to create in and see how its conventions can be changed or twisted in new ways and how things from other genres can be incorporated to enhance that. For Plunderful it started with seeing how combat could be done differently within the PBTA system. And while I am skimming over the scrapped concepts, the final idea came from integrating Troka’s initiative system and then having a player’s move take the form of cards like spell cards in DnD. This also led to its pirate theming, having a system where players lock in what they want to do and hope everything goes well, fit wonderfully popular media depictions of pirate escapades.

Having a solid unique mechanic at the start of production presents later mechanical problem solving in a different light than starting with a story idea. By developing a mechanic first all problem solving will be framed using that mechanic to solve it. Take the Mario series for example: its core mechanic is jumping through a level to get to the goal, the problem that needs to be solved is how do you make that challenging? The solution to that problem is putting in obstacles and enemies, but if you have enemies how do you defeat them? If creating without mechanics first some might add in a weapon mechanic making a seperate system for combat, and depending on the tone of a game that might be appropriate, but with mechanics first thinking the answer would be jumping on them for your jumping mechanic centric game.

To bring this back to Plunderful’s development, this was a problem solving mindset also found within some playtests where new mechanics were proposed to solve present problems, making it difficult to understand what part of the game’s design actually needed to be changed to make the experience better. The main one being the game’s enemy cards, originally just statements that would happen in combat no matter what this original design made what the enemies were doing feel disconnected from the actions the players were doing. Originally it was proposed to make the game master roll for this, but I found this was simply doing the same thing with more steps, instead I took that the GM’s roll in roleplay is, to make the NPCs react to what the player’s roll, and translated it over to the cards, giving the gm options they would choose from on a card, choosing the one that fits best with the games narrative.

(Old and New Enemy Cards)

My take away from making Plunderful is how to make, develop and cultivate a strong core mechanic and how to work as a game designer throughout a project. I previously thought a designer's job would only be relevant at the start but a game’s design is something polished and tweaked as production moves. It’s a job about problem solving and not just coming up with solutions, but reworking problems to make them easier to fix.