Hello there!  Wizard's Age had been on a bit of a hiatus, but the Wizards came together again for the recent https://itch.io/jam/pirate. An earlier instance of this jam spawned one of our favorite jam games of ours, Oh Noir! https://wizardsage.itch.io/oh-noir

The theme for this jam was: Shadows and Alchemy.

So now we needed a prototype.

Purposefully Prototyping

The Wizards assembled on the first day of the jam and got to chattin'.  We almost never build intentional prototypes.  Often, we discuss, get some ideas on paper, spin up an engine and start hacking features together. We quickly agreed we'd love to build our prototyping skillset and flex a bit into some new tools and territories.  We spun up a small prototype in usual engine of choice, GameMaker.

Design vs. Development

I can't remember where I read this, but I was struck by some gamedevs making an intentional difference between *Design* and *Development* happening at coding time.  I sometimes think about game design as something abstracted away from your "hands on keyboard" time, but you're absolutely making design decisions in every line of code you lay down.  If initial design is unclear, you have to make spot-decisions on the fly.

There's nothing wrong with this, its fun, and it works for some people.  When you start working with a larger team though, any off-the-cuff decisions can start to have the game drift away from the shared concept.  If you're engineering your systems to be durable and long-lasting, it can be expensive in terms of programmer time to line it back up with what the design intended.

A traditional solution here is to have a robust Game Design Document that acts as a source of truth.  In practice though, there's almost no way I can write a game design document that I know is going to be "fun".  "Fun" is what we're trying to do here, and as indie devs we can't just plow through a lack of fun with anti-aliasing and Star Wars collaboration skins.

Even in the smaller scope, old habits die hard, and our GameMaker codebase became a bit inflexible.

What's a dev to do?

Finding Fun In Prototypes

Make a dedicated sandbox for exploration!  Historically, we have used a single codebase as both our prototyping space for exploring ideas, and as the repository for the final game.  This has been a mistake.  Its easy to convince yourself you're saving time by re-using code, but you aren't.  Technical Debt and Feature Creep, those two great evils, must be fed a sacrificial codebase to slake their bloodlust.

Prototyping doesn't have to be in your final engine of choice either!  Prototypes are meant to look bad and play fun, and all of this code will be burned as an offering to Project Health.

Tabletop Simulator "Paper" Prototyping

Our team had used Paper Prototyping on Warhorn Saga, and found it exposed a lot of needless complexity and potential interface problems way before we started laying down code.  It was a great experience, but not something that's easy to recreate over the web.

Our team is now sadly all remote from each other and we needed a new tool.

In the board-game design community they often use Tabletop Simulator (https://www.tabletopsimulator.com/) for getting player feedback and iterating on designs.

We booted it up and mocked up a Prototype!

The process is largely the same as true paper prototyping:

• One player is the actual "Player".  
  • They'll provide inputs like, I press A, move left, etc.
•  Other players are the "game".  
  • They'll make the game pieces react to inputs, carry out the "tick" and other core game loop logics.

Through "Paper" prototyping in TTS, we were able to refine the design, cut it down to what was absolutely needed for "fun".  Some shared game notes helped the "Game" players to carry out actions as we went.

We barely scratched the surface of what TTS can do, but it was enough for our purposes.  If you really want to go all out, you could rig a semi-playable game using its Lua scripting API! https://api.tabletopsimulator.com/

We developed a set of definitions of our Minimum Viable Product for this game, blocked them out in Trello, and we were off to the races, ready to start on our game.

Abject Failure

We didn't even remotely finished in time for the game jam cutoff :(

We failed.

If the intent was to submit something to the jam.

But it wasn't!  The intent was to get familiar with new tools, step outside of our normal modus operandi, and design a small game that we could finish in a reasonable amount of time.  Great Success!

We now have that: Tinymancers, a party strategy game with a focus on frantic decision making.

Stay tuned as we continue our prototyping journey on this project into the next phase:  playable prototype!