This post probably resonates for many jams and a lot of other things, and the wisdom behind it is extracted mostly from my long history of failed wins (we don't say losses in this article) at Magic: the Gathering drafts. It's not that I don't learn in order to win next time, but more that the moment just before winning or losing is the goal for me, and the risk of losing is usually pushing further. Here's what I learned!

B.R.E.A.D.

Magic players of old have learned about BREAD if they ever played a draft: the acronym gets you to separate your cards into these five categories - Bomb, Removal, Evasion, Aggro, and Dud, which can be sorted in a descending order of usefulness. If your whole deck could be Bombs, that would be epic; if you're playing with only Duds, you might as well go home right away. In very few words, a Bomb is any card that can really shake the field when it enters, usually something that wins you the game if the opponent let it come out. Removals are spells that can remove stuff from the board, usually in several specialized ways, Evasion means that a spell can help bypass the default defenses the opponent has and hit anyway, Aggro is something fast and furious, usually without too much afterthought, and Duds are... well, you don't really want to play this, but it's the only thing you have.

I would say that for 7DRLs, we have a similar way to organize with regards to what to do, whether to do something, and how to split time amongst features, and it's...

F.I.S.T.S.

This acronym stands for Foundation, Interaction, Sell, Theme, Systems. Yes, it's not good to have a single letter twice, but I have FISTS so dare fight me!

Foundation

Starting from the top, we have Foundation, which is mostly all the core things that make your game a part of this genre: turn-order, the ability to spawn things, to think about them on a grid, to remove things, to accept inputs, show things on the screen, and to have access to arbitrary algorithms that work on your data. You may need field of view, pathfinding, procgen algorithms, whatever you'll be using all the time for everything else. I want to make sure I have this foundation down, hopefully before the jam starts.

Interaction

The next layer is Interaction, which enables your game events to bubble and cause/trigger each other. This can be done in many ways, but you should be able to start working on it as soon as your foundation is down and it should basically define the remaining layers: this is how you interact as a player, as well as how your character interacts with the world. What happens when you press left to move - is it move or fail, or a bubbling of move-bump-hit or unlock; are your inputs immediately consumed or buffered; is your game modal (has specific modes for different commands) or not; do you commit to an input or preview it and allow for confirmation? Similarly, if something hits you, does it just do damage or does it query some other potential actions; do things break; do you have speed or just update on player inputs? You're not implementing HOW this all would work (for example, the item breaking system that I mentioned would definitely NOT be a part of this!), just that you need it and are laying the groundwork. You're planning actively. This doesn't mean you're drawing nice pictures and procrastinating: you are putting into code whatever it is you want to include in your later interactions with the next layers. If you didn't put it in, you're not working on it later!

Sell

Usually, you got an idea about what sells your game and makes it special. For games that want to sell, the sell is the most important step. For our needs for 7DRL, the sell is a point of focus: is this feature I'm thinking of helping people focus on my sell or working against it? If the answer is against, try removing it - see if it works!

My sell this year was "wouldn't it be cool if health points played an additional purpose as markers for stat increases due to magic influence?" The answer, in very short, is "no", and in long is "do not underestimate decades of trained detail-focused goal-oriented brain-eye coordination" ever again. This doesn't mean it wasn't a good sell: remember, the quality of your sell is secondary to how well you execute it. You learn by failing, but seven day gamedev challenges are the places where we WANT to push the envelope with stuff that maybe wouldn't sell itself but does open our eyes towards other more sellable things. Sometime, you just need to get something out of your system to be able to move on.

From a programming standpoint, the sell is a natural extension of your foundation and interactions: this is why you've been building stuff up to now, so it should fit in nicely and click into place. If not, don't go on: go back and iterate over whether your interactions are up to the task, and then whether your foundation was laid well. Hopefully, it fits though.

Theme

Make it stick. Fluff it up. Choose colors. Choose symbols or sprites. People see what they want to see, and an ugly game is more often incoherent, too plain and uninformative, or just too entropic - full of moving parts and without an anchor for people to reach out and grab onto.

If choosing between what to show and what to not show, keep the things that fit your theme. In RUNNER, a wonderful megacorp heist 7DRL entry from this year, there could have been a lot of time spent on what this world is, and who the corp is that your character is stealing from, or what lore the datadisks you steal have on them. You know who has no time for that jazz? A runner stealing from a mega corporation, hunted by a violent bot, wallsliding over sentries! Informations slows down perception, so choose where you put it depending on the theme you are invoking. There were several cyberpunk entries this year, I consider RUNNER one of them, but out of all of them it has the most minimal palette, and the smallest number of symbols used. You know who doesn't have the time for experiencing pretty colors of the neon-and-chrome server rooms? That's right. The theme is shown, not told.

Systems

At this point, your game is there. It has a window that opens and draws it, your inputs start interactions, someone who starts playing it says "oh I get it" after a short while, then they notice (maybe not consciously!) the flow of your chosen themes, they enjoy it, can't stop, or they would... if there was just some more meat on the bone! This is where systems fit in. You've set up your interactions for this moment. Remember that one more mechanic you considered but it wasn't absolutely required, but supported your sell quite well? Time for bringing that in! Be careful to lay things over instead of pushing them against existing systems. You want to tint the image, not bucket fill it!

Maybe your potions could break, but nothing happened as a result. Lay it in. Maybe your trees were combustible but didn't burn. Maybe your empty vaults could have had a timer that starts locking them up. Maybe there's a veil of magic that is awoken from your choice of active spells over multiple turns -- something I could imagine while playing the wonderful spell-shouting entry Arcanist's Heritage.

Systems are only limited by two factors: time (depending on how you factored out time for the first four parts) and the inherent tightness of your theme! Sometimes, less is truly more, and you should know when to stop.

With all that said

The F.I.S.T.S. method isn't something I spent a lot of time on, just something that showed up after the panic cleared and once I could look back and find a semblance of order in my thoughts by reading my furiously scribbled thoughts. It's not a methodical school of thought as much as... well, more scribbles, made somewhat less furiously. This method helps me organize internally, but it's only as strong and solid as you let it be, in the end. I'm going to use it to prioritize my weekend projects as I develop Svarog: it's a library and needs many examples, after all. Being what it is, this method also be a good first step in leaning the ancient dwarven martial art of Kisat Dur, if used hard enough. Tell me if you try!