Hey everyone,

After almost 8 months spent developing a Playdate game (not a great strategic move for a new studio — spoiler alert), we figured it was time to write up a little postmortem about the whole thing.

So if you’re reading this — first, thank you — and I guess you already know we released our first Playdate game, ARMADA, on itch.io about two weeks ago. Our studio is called Random Encounter, and we founded it together with my younger brother. My wife joined the team a few weeks after we kicked things off.

The idea for the project started the very same day I got my Playdate as a birthday gift. We just wanted to mess around and try building something for the console. Just for fun. But of course, we never do things "just for fun". It’s not our first game project, but it is our first game actually released. We've always struggled to keep things small and simple — we get hooked on ideas and end up adding features, systems, content… even when that wasn’t the plan to begin with.

And yeah, same thing happened with ARMADA. What was supposed to be a weekend jam turned into 8 months of dev.

Origins & Design

From the start, ARMADA was meant to be a kind of "Missile Command meets roguelite survivors" game. We wanted to use the crank exclusively, and brainstormed a bunch of gameplay concepts around it. The missile command idea stood out — super simple core mechanic, perfect for full crank input, and it gave us room to focus on player progression, difficulty levels, and cool challenges.

With Playdate, it's really easy to go wild — there’s so much unexplored design space (which is part of why the Playdate is amazing). The crank alone gives you so many possibilities. But I think sticking to a really simple gameplay loop let us pour our energy into other areas: content, polish, cutscenes, game modes, etc. If we’d gone more complex with input or mechanics, the game might have felt bloated instead of polished — so we’re really glad we kept it lean.

Building for Playdate

One of the best things about developing for Playdate is that you’re always testing directly on the real console — not a devkit or emulator. You see exactly what the player sees, and that’s both super practical and very motivating. I know mobile devs have something similar, but they also have to deal with screen responsiveness, hardware diversity, etc. With Playdate, there's just one device. One version. That’s it.

That said — when you're developing on a fancy RTX i9 desktop, then deploy to the Playdate, you really feel like you're holding a GBA in your hands. Some devs manage to push the hardware to crazy heights with C and low-level optimization — PlayStation-level stuff — but for most of us using Lua or Pulp, it's a GBA situation.

So yeah: optimization is key. You’ve got to constantly monitor your stack, and learn (sometimes the hard way) what best practices work for the system.

The Playdate Community

You might assume that, because Playdate is such a niche device, help and dev support would be hard to find. That couldn’t be more wrong. The Playdate community is insanely helpful and supportive. Like, almost suspiciously wholesome. Maybe it’s just that the console only attracts good vibes. Or maybe the crank literally boosts serotonin?

Anyway — huge shout-out to the Playdate Squad Discord and everyone who gave us advice or helped us out of tough spots. You kept us moving forward. Thank you.

The 1-Bit Art Journey

So — me (Morgan) and Adrian (the two brothers behind Random Encounter) are both coders and game designers. We are not artists. But for ARMADA, we had to do everything from A to Z — visuals included. Adrian dove headfirst into 1-bit pixel art and, over time, came up with something I think is honestly amazing. One of ARMADA’s strongest points is its visual identity and diegetic UI — all crafted by someone who had never done pixel art before. Massive props to him.

We actually changed the game’s art direction 4 or 5 times over the course of dev. That kind of personal demand — being picky, always pushing further — can lead to some really great things in game dev. Know what you don’t want before you figure out what you do want. Develop that sixth sense that tells you, "This isn’t it," even when you don’t know exactly what "it" is yet.

On Flow & Scope

That said, you need to balance that kind of drive. And we didn’t — at least, not early on. We spent weeks trying to make a single weapon or perk work, even though it tanked performance. In hindsight, we probably should’ve cut the feature and moved on. We even tried rebuilding the game in direct drawing instead of using the SDK’s sprite system, hoping to boost performance and cram in more animations and particles for better game feel. That alone cost us at least a month.

Those are important decisions, yes. But if you go too deep on the wrong ones, you end up wasting time or fighting for a feature that just wasn’t worth it. It sounds obvious, but knowing when to let go is crucial. More importantly: recognizing early which features actually matter — and whether they’re worth the bugs, perf issues or rebalance headaches they might cause.

Ask yourself: “This will definitely cause performance issues — do I power through and optimize later, or cut it now?”

Answering those kinds of questions well is what keeps the flow of the project alive.

The Value of Flow

Project flow is a kind of internal rhythm — an equilibrium that needs to be maintained all throughout dev. It’s linked to the overall health of the game at every stage, to the quality/cost ratio of decisions, to the team's morale. When flow is respected, people actually want to wake up and work on the game. Individual motivation and project flow go hand in hand.

So don’t sacrifice someone’s morale for a tiny feature, or a risky refactor, or a poor decision that forces a full rework. Making games is hard — you can’t control everything. But that’s exactly why vision matters. The sharper and clearer the vision, the better the project flow, and the more grounded and inspired the team will feel in their creative work.

Final Thoughts

All that being said — it’s pretty much impossible to avoid mistakes when developing a game. And that’s okay. They call it “production chaos” for a reason. But we should always try to reduce that chaos as much as possible.

Thanks for reading!

Morgan & Adrian
Post-Mortem for ARMADA, out now on Playdate