Baren81 Devlog

Every Launch, I Redrew the Same Table

Title card: Every launch, I redrew the same table — Call the Cat Devlog

Written by

in

Call the Cat — devlog

TL;DR: Across four games I kept re-solving “how do I attach login, payment and save.” The words were the same every time; the actual thing behind each word was different. So I finally wrote the table down — seven slots that have to line up before any release.

So far I’ve built a game in GameMaker, a second mode on top of it, Galaxy in Unity, and Delivery on web tech. Every time a new game or a new platform came up, I started from scratch on the same three questions: how does login attach, how does payment, how does save. This time I worked out why.

Same word, a different object every time

“Login,” “save,” “payment,” “ads.” All four games use those four words. But the implementation behind each one changes completely with the engine and the surface it runs on.

One feature name, four implementations — login, save, payment and ads across GameMaker, Unity, web-wrapped Android and Steam.
One feature name, four implementations — login, save, payment and ads across GameMaker, Unity, web-wrapped Android and Steam.

Change the engine or the execution surface and you don’t get to copy the console settings across. The SDK, the app identifier, the signing, the products, the testers and the save slots all have to be re-wired for the new environment, every time.

It was never one value — it was a chain

Here’s the part I kept missing. These settings aren’t a list you fill in one by one. They’re links in a chain. One slot out of line makes the other six irrelevant.

Getting one slot right never meant the whole thing was right. That’s why I ended up redrawing this table from scratch every single launch.

App identifier, signing, login, save, payment, ads, release — seven slots wired to each other.
App identifier, signing, login, save, payment, ads, release — seven slots wired to each other.

Code exists ≠ the service works

There’s one illusion that came up over and over in this series. The code is in the source, the build passes, the artifact gets produced, it uploads to the console — and none of that means login actually completes or the payment sheet actually opens.

Static check, build check, artifact check, console check, install check, device check. Those are six different kinds of evidence, in order. Clearing one rung doesn’t let you skip the next. That’s exactly why “the class is in the code” must never be rewritten as “payment works.”

From static check to device check — the distance between code existing and a service working.
From static check to device check — the distance between code existing and a service working.

If you’re starting this

Before you start a new game or add one more platform, fill in those seven slots first. Writing down what the app identifier, signing, login, save, payment, ads and release each demand — before you write code — is what stops the “but I definitely set this up already” loop from repeating.

And before you hand a new platform connection to an AI, this one line helps:

“Show me, as a table, what login, save, payment and ads each require on this platform. Code comes after that.”

One caveat on this table: it’s an inventory of what I hit, not a verified specification. Platforms change their requirements, and your engine and store combination won’t match mine slot for slot. Use it as the shape of the questions to ask, then confirm each answer against the current console for your own setup.

Solo dev of Call the Cat, shipped after 178 days
on Google Play
and Steam.
The sequel, Call the Cat: Galaxy, is now on the App Store — still building it in public.

Comments

Leave a Reply

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