Scramble Quest Devlog #2: Ending things
June 13, 2026
Been a busy week!
On behalf of the IGDA Foundation, I held a talk as part of the STEM Game Lab panel for the German American Chamber of Commerce (probably should’ve plugged that here. Whoops) and I had a seminar through the MGZsheroes program.
The panel was interesting, as not only did I get to word vomit about what I do and what I value in game dev (curiosity, learning, knowledge sharing, communication), but I got to hear from others how they handle game dev education. I was pretty impressed, it sounded exactly like what I’d want from an experienced developer’s point of view.
Now, the seminar was largely on generative AI, and while interesting (and the speaker was genuinely nice and really knowledgeable in his non-AI discipline), I still can’t see a reason to use it, specially considering the costs (specially, but not only, environmental costs). And as much as I might hate writing long documents and presentations, they invariably help me think through the topic at hand in a different way, giving me new insights and a more solid understanding. And I wouldn’t want to lose that.
Alright, but we’re here for Scramble Quest. What did I manage to do?
In Scramble Quest you pick an action from a slew of options, and then scurry around the map, trying to position yourself so you can hit your target with that action. Most importantly, All players pick from the same pool of actions, which are sourced from their own individual decks. Initially I put the two decks together, shuffled them, and then drew X amount of action cards. Why? Uh, I dreamt it that way. I played the game in a dream, and that’s how it was there. Turns out, it’s not great.
Now, currently my favorite format of Magic: The Gathering, when playing with my partner, is Jumpstart. You have two random 20 card decks, mix them together, and you’ve got a semi-functional 40 card deck. That works. The issue is, the larger the deck (and I still haven’t locked card count), the harder it becomes to find a particular card. Throw two 40-60 card decks together and it just becomes awful. You’re trying to do a damage type of action, but you’ve got only healing and defending on your hand. Terrible experience.
The solution of course is to divide it up again. Each side draws from their own deck to their own hand, even if ultimately the cards are available equally to all. I put one hand to one side, the other to the other, and the selection pucks in the middle between the two, so they’re equally accessible to all players. Now each player has a proper equal chance at accessing cards from their decks. They have full access to their strategy.
It sounds like it should be an easy refactor, but it’s a weirdly fundamental change to the first system made for this prototype. Everything was built on this one deck that was mixed from two. Though not changed as quickly as desired, it still was a blip in the grand scheme of things, and so worth it.
The result screen though… It feels stupid, but I keep pushing it out for as long as possible on every project where I need to make one. It’s just… it feels so big, because after all, it’s the culmination of a competition. It needs to be flashy, and rewarding, and give you loads of information about what happened in the competition. Heck, you need to define and track things that happen during the competition. You need win conditions, and various things that could happen, so you can show it on your result screen. You need to have buttons that work perfectly to return to specific previous states and whatever else the player might want that I’m not thinking of.
No. Just do the damn thing. Yes, of course you need buttons to leave or restart. And you need “a” condition that triggers the screen (not even a proper one). But that’s all. It doesn’t even have to be bug free! After all, this is an early prototype, and even if it wasn’t… Gotta start somewhere.
Frankly, this applies to pretty much everything you want to do. Don’t let it balloon in your mind. Reduce it to the bare minimum. Make it a small step. Everything else can come later. Heck, it will be clearer later, so don’t even think about what comes after.
So that’s what I did. I first set up a win condition object that gets checked at the end of each round and I made it check if there’s any team with no undefeated units left. And then… I simply display a quickly thrown together screen that displays winner, team composition, and defeat state. I also have the win condition add a widget with further information relevant to the win. In this case, in which round which unit got defeated. This latter feature is still buggy, but that’s fine. It’s fine. Absolutely fine.