Sidequest: What I done did

Sidequest: What I done did

Sidequest #3, eh? Time for some next-level rambling, cause boy do we have a topic fit for that: my projects!

See, while completely shitting on other people’s work is rude, completely shitting on your own work is actually a good thing. Being “self-critical”, whatever that means. Whichever way you spin it, if you have nothing but good things to say about your projects, I’d think you’re lying. It’s one thing to know you made mistakes, it’s another to be comfortable sharing those with the world at large for shits and giggles. Who knows, maybe someone will learn something from it.

The suspects

IDIOT

The first quote-unquote “serious” project I started back in 2016, which I just realized isn’t, in fact, 2 years ago… IDIOT was my RPG system. A response to playing Dungeons&Dragons for the first time, and being less than a fan of the combat system, that is to say, I fucking hated it. So, me and my friend who actually spent the $$$ on the DnD thing decided to try streamlining things a bit. Still fascinated with Magic: the Gathering at the time, we decided that we could try using cards for items/abilities etc.

Eventually, IDIOT got its first draft thing, and by that point it was still more or less a DnD mod. However, since neither of us had any real experience with tabletop RPGs in the past, I think you can guess how well it went. Suffice to say, I quickly went back to the drawing board.

Now, considering this was my first big foray into game design, there was an absolute metric fuckton of things I still had to learn, but things were moving along slowly. At some point before the second prototype, I decided to make the cards a reality, and for that, I had to create a template.

As always, the disclaimer here is that the artwork isn’t mine, but the rest of the frame is.

4 years later… IDIOT still isn’t done. It kinda went off the deep end after that second draft, with me realizing that I didn’t really have the skill/experience to do it properly yet. However, as of a couple months ago, I started to tinker with it again, only this time, it was ever so slightly different: IDIOT was no longer a system. It was now a framework for making systems.

What that means is that it’s still a set of rules and mechanics, but it doesn’t go much further than the absolute basics. There is no setting or flavor attached to it, and it’s meant to be a backbone for creating setting-specific systems. All in all, nu-IDIOT is a far cry from the old DnD mod that never was. Here’s hoping I don’t fuck it up a fourth time…

Uncharted Realms

Since we seem to have already started on the topic of ‘games InvertedVertex started but then realized was far too dumb to finish’, let’s look at the next one. Started about a year after IDIOT, Uncharted Realms was/is a game where the goal was to explore, well, uncharted realms, and eventually claim them (you’ll see why this is stupid in a minute). Mechanically, it came from a similar thing I tried with custom MtG cards at the time. After the MtG version crashed and burned spectacularly because I was a very stubborn moron who didn’t know how to take feedback, I decided that rather than pushing Magic’s system to its breaking point with realms, it was better to try and make it a separate game.

Realms is, in its core concept, a game about movement/positioning. The idea is for it to be a board game, where the board itself is made dynamically as the game goes along, through the realm cards. The first version of the game was still heavily MtG-influenced, and it had all the staples of dude-basher games: creatures, spells, combat. The only difference was that you could claim realms by sitting in them uncontested for a few turns, and you won through a ‘first to X realms’ method.

Needless to say, if you want a make a game about exploration and movement, you don’t fucking make combat the key aspect of it. That was about the point where I learned exactly how much of a game-breaker tracking complexity could be. Also, the value of early testing. Also, how important a well-defined scope was… you get the idea.

The 3 different templates that Realms had through its multiple versions. Left is from its MtG counterpart, the latter 2 are ones I made for the game proper (from the bad combat-focused version, and from the untested third version, respectively).

Realms was my big learning experience, and since that first version, there were 2 other attempts, only one actually making it to playtesting. However, Realms is a game that I still feel is a bit out of my reach, and I’d want at least a bit more experience with design in general before I feel like I can solidify the ideas present for it in a single, coherent game.

BossRush

First of all, I just want to make it clear that most—if not all—of my game titles are internal WIP shit. That being said, let’s move on to the next one. Stemming from a weird idea based on IDIOT’s ability system and playing Dark Souls 3 with a bosses-only mod at the time, I came up with the idea for BossRush: a co-op players vs boss card game.

To say that BossRush has a turbulent history is an understatement, even in comparison to Realms. The game is currently on its 5th iteration at the time of writing, and unlike its predecessors, the versions didn’t fail because of complexity or clunky gameplay. No, they failed because of direction. That’s a fancy way to say that while it works as a game, it doesn’t have the feel I want from it. The goal is to have it be a fast-paced cooperative game, where players need to figure out how to defeat the boss while surviving its constant onslaught.

The 4 cards from my The Trials of Error (1/2) article image were from the first 4 versions of BossRush, shown here again for clarity:

The first version is by far the most finished-looking, but in reality the final version was the most mechanically polished one. However, I did a public playtest of the first version at a local board game event, so I had to make it presentable.

The main challenge of BossRush is figuring out how to make the entire gameplay flow smoothly and quickly. While v4 was good as a system, it completely missed the point of fast-paced action combat, and instead was a very tactical game that required you to think too far in advance, completely ruining the intended feel. The system itself might be better suited towards PvP, and I think I’ll look into that option soon-ish.

By now, it might seem like I don’t really have any games that make it further than the post-first-test-trashpile. However, you’d be dead wrong there, because…

Neon Arena

This game. This fucking game is a statistical anomaly. A bolt from the blue. It started with trying to think of an asymmetric siege board game idea with a friend, when I had the bright idea of trying simultaneous turns. About 2 days later, I decided that something like that was better suited to some kind of arena-combat only game, so I went over to my friend’s house with a barely coherent concept in mind, and went back home with Neon Arena.

Notice how I didn’t say ‘first version of Neon Arena’ there. That’s cause there is only one version, and it’s the current one. I’m not superstitious, but I don’t want to jinx the damn thing either. I think the reason Arena hasn’t failed so far is because it’s far too simple to fail. The game’s a Quake-style arena shooter played on a square grid. Players have movement/attack tiles in hand, which they secretly organize 3 of for each turn, before simultaneously revealing the planned actions and resolving them.

Stupidly simple, quick to play, and most importantly, exciting. It’s a simple little game for when you want to unwind and convince your opponent that you totally read their next move, when you’d never admit you shot in their direction completely by accident.

Now, not having crashed and burned yet doesn’t mean that Arena hasn’t had its share of nightmare periods. It took me a long while to figure out the best way to reduce the randomness of it while not eliminating it completely. This is the game that taught me how important having different-value actions is, and that homogeneity only leads to samey gameplay. It is also by far the most tested of all games I have made so far, mostly because theorycrafting in a game where you can’t do solo tests doesn’t really get you anywhere.

I’ve been doing all these 4 games more or less at the same time, actively only working on a couple at any given time, though. However, the last game I want to talk about is a bit of an oddity as well.

Project: Confluence

At some point in summer 2019, I discovered a little game called Android: Netrunner, and I was immediately fascinated by it. A major card game that isn’t a dude-basher? Asymmetric gameplay? Holy shit that was cool. And it was sci-fi! I think you can guess what happened next.

I work as a software developer, and for a while I had entertained the idea of making a game inspired by programming. I figured it had to be a card game, cause then you can combine cards to ‘write’ programs. I immediately started working on the new idea.

By this point I knew better than to do some of the major mistakes I had with my earlier games, or so it seemed. I made the first prototype for Confluence… and it didn’t survive the first match. In my quest to explore the idea of ‘what if players had different win conditions that they picked at the start of the game’, I had forgotten the #1 rule of gameplay: Games need to create conflict between the players. I had no intention of fixing Confluence at that point, so it was left in the idea drawer for a few months. But then, late 2019 came along, and I remembered that weird game I tried making over the summer.

The goal for the new version was simple: Create conflict by enforcing restrictions. Long gone was the fully-freeform program making, in favor of a much easier to manage fixed-slot system. Gone were the dumb per-player objectives, replaced with a set of global objectives that were the same for both players. The game’s formula was finally simple: ‘use your cards to make programs to try and complete objectives. First to X points wins.’

First playtest passed. So did the second. On the third, we already felt that one of the game’s mechanics, the one that was supposed to provide the conflict between players, didn’t really work. A couple of days later, we tested using the same cards, but with their effects house-ruled to fit the new mechanical changes.

It worked. Even with the wonky cards that had to be played in a way that often went against the text of the card itself, the game was stable, playable, and fun. So, after fixing the cards and exploring a bit of the design space, I shelved Confluence. I had to quit while I was ahead, and give the game a couple of months room to breathe. It was one of the most important lessons I had learned with my previous projects, and I’m still waiting for a good chance to resume working on it.


Well, there we are. State of my projects, April 2020. Each of these has enough material for an entire series of articles to be written on it, and I may do that at some point, to use the games as specific examples for topics I want to talk about. As I’m writing this, I’ve had a bit of a game design hiatus due to work these past couple of weeks, but I want to get back to BossRush, seeing as the newest version is different enough from the previous ones that it might just be crazy enough to work.

Until then, I leave you with not one, but multiple songs, one for each of my games (except IDIOT), as the main songs I associate with developing each of the projects:

Realms
BossRush
Arena
Confluence

This is InvertedVertex, signing off.

Tags: ,

5 Responses

  1. […] of my projects, BossRush, which I mentioned in the relevant Sidequest, had a major direction issue. While the systems and mechanics worked eventually, and satisfied M, […]

  2. […] will vary based on the rest of the game’s state. In my game, Project:Confluence (more on it here), I use this exact type of resource, in order to remove/mitigate the overhead that a varying amount […]

  3. […] an example, let’s take one of my games, working title Neon Arena (or just Arena, for short). The important thing to know is that […]

  4. […] test the interactions. For games that have hidden info as a core staple of the design (e.g. my game Neon Arena), solo testing becomes pretty much […]

  5. […] an example, for my card game, Confluence: A Digital Odyssey, I made a fork to try and see what an absolutely core-level change would be like. Confluence is a […]

Leave a Reply to Sidequest: Why you should never listen to playtesters! – Tabletop Designers Association Blog Cancel reply

Your email address will not be published. Required fields are marked *