The Final Check Before the First Submission
Freeze one candidate, verify six acceptance layers, trace artifacts and device behavior, and make an evidence-based Go or No-Go submission decision.
Read part 18Making Games with AI
From the first idea onward: a record of making a game through human judgment and AI-assisted production.
中文
Review Submission Takes More Than Upload
A binary is one deliverable. Review readiness also needs aligned store copy, privacy, localization, screenshot slots, remote readback, and device evidence.
Read part 17
Keeping Analytics and Platform Services Separate from Game Logic
Isolate analytics failures, define event facts, label environments, and sync leaderboards after local saves without letting platforms change game outcomes.
Read part 16
Why Ads Must Wait for User Consent
Consent before ad initialization: UMP, ATT boundaries, privacy options, rewarded-ad fulfillment, non-blocking interstitials, and historical validation gaps.
Read part 15
Why Purchase Success Is Not Fulfillment
Why payment confirmation is only part of fulfillment: transaction IDs, atomic saves, duplicate prevention, rollback, and two distinct recovery paths.
Read part 14
Connecting a Game to Native iOS Services
Game scripts, Objective-C++, and Swift: one bridge, four channels, traceable async requests, build integration, and distinct layers of verification.
Read part 13
Adding and Removing Features Both Matter
Formation foundations, starter items, a stage cap, complete pause behavior, and removing an event branch: making features serve one release goal.
Read part 12
How Battle Mechanics Go Beyond Bigger Numbers
Stable targeting, seven effects, explicit Boss combinations, and five items: how mechanics change decisions through readable signals and learning pace.
Read part 11
Why Balance Needs More Than Playtesting
Historical simulations reveal the cost of rewards, upgrades, enemy pressure, losses, and waiting—and why one successful playtest cannot prove balance.
Read part 10
How Animation, Backgrounds, and Effects Enter the Game
How Kibble Street TD connects character states, frame layouts, building animation, layered backgrounds, parallax, and effects to game rules.
Read part 9
Why AI Art Isn't Ready to Use
From AI art candidates to usable game assets: actual-size checks, runtime references, component boundaries, deterministic processing, and human approval.
Read part 8
Why Keep Reworking the UI After the Game Is Playable?
Why a playable game still needs UI rework: hierarchy, wireframes, shared components, battle space, and screen-size checks in Kibble Street TD.
Read part 7
The First Complete Playable Version
Making Games with AI, part 6: how Kibble Street TD connects startup, battles, rewards, upgrades, and saving—and separates playable from ready to release.
Read part 6
Why a Finished Battle Is Not a Finished Game
Making Games with AI, part 5: how startup, Home, preparation, rewards, and saved progress turn one working battle into a complete game loop in Kibble Street TD.
Read part 5
The Screen Is Not the Battle
Making Games with AI, part 4: how Kibble Street TD uses state snapshots to connect battle rules, summoning, animation, hit feedback, and the HUD.
Read part 4
How the First Battle Came to Life
Making Games with AI, part 3: how energy, summoning, movement, attack range, and victory conditions became the first complete battle loop in Kibble Street TD.
Read part 3
Can One Person and AI Make a Game Team?
Making Games with AI, part 2: how one developer divides design, code, art, audio, and testing with AI, with a real revision from Kibble Street TD.
Read part 2
A Game Begins with One Sentence
Making Games with AI, part 1: how the cat-versus-dog idea behind Kibble Street TD became a testable core loop, a playable prototype, and a foundation for a game.
Read part 1Follow the development process in order.