W4D1: Workflow, building and publishing

The last week of the course starts with the unglamorous half of game development: planning a project, tracking it, getting it onto a store, and keeping it alive after launch. Lucian spends the first half on process and the second half actually building and shipping the Duck Invaders project to four platforms, including a real Google Play internal testing release and an Apple Developer enrollment done live. If you can write gameplay code but have never turned a Unity project into something a stranger can play, this is the session that closes that gap.

What’s covered

Course admin and the certificate

• How the final test works: roughly 100 mostly multiple-choice questions drawn from all twenty days, weighted toward MonoBehaviour event order, prefabs and prefab variants, and basic C#.
• The second half of the certificate is a project assignment — a small 2D platformer or similar, a few days of work, graded subjectively.
• Lucian’s blunt view on why he built it this way: he doesn’t want to encourage a world where people collect diplomas, and he’s openly running the free course as an experiment to see whether free motivates people to actually do the work.

Starting a project properly

• Time horizon first. Whatever you estimate, double it. The longer the horizon, the more the game design document has to carry.
• A GDD for a real commercial game is three to five pages: overview, story and progression, target platforms and their order, sub-games, graphics and sound direction, monetisation. For the course assignment, one or two pages.
• Why deciding “mobile or not” early is a Pareto decision — costs nothing today, saves weeks six months in.
• Milestones as energy, not motivation. Ship something visible every week so the reward compounds.
• Alpha, beta, release mean whatever you decide they mean. Beta is more finished than alpha. Don’t let anyone tell you otherwise.

Tools and process

• Trello for small projects, Jira for medium and large, Notion as a possible replacement for all of it. Confluence as the project wiki that ties into Jira.
• The trap of doing work to feel like you’re progressing. If your GDD says you’re at 46% and you were at 46% last week, the tracking board isn’t the problem.
• Kanban versus Scrum, story points as perceived complexity rather than hours, and why a stable velocity lets you predict the future.
• canny.io as a lazy but effective feedback board — users post, users upvote, prioritisation happens for free.

Launch and promotion

• Build in the open. Lucian reckons out of the 80% of developers who won’t show their game, maybe one in ten is actually right to hide it.
• Instagram skews friendlier to visual and art posts, Twitter needs Blue for reach as of 2024, post under your own name if you can.
• itch.io as the free, low-friction alternative to Steam for a first release. Kickstarter as a validation and funding path worth trying.
• Store dashboards eat far more time than you expect: privacy policy, terms, content ratings, screenshots, feature graphics, per-country targeting. Start as an individual account, upgrade to a company later.
• LiveOps: events, holiday bonuses, changing the main menu background — cheap ways to make a game feel alive. The Counter-Strike 1.6 message of the day as the original example.

Building for real

• Write once, build everywhere, with the caveat that Mac and iOS builds need a Mac (or a rented one via MacInCloud at around $25/month).
• Android: creating a keystore from the Unity keystore manager, switching from Mono to IL2CPP for release, enabling both ARM architectures, producing an AAB.
• WebGL: building, disabling compression and data caching for GitHub Pages compatibility, pushing the build artifact to a public repo and deploying via Pages.
• Google Play internal testing versus closed testing versus open testing, and why bundle version code must increment every upload.
• Apple: enrolling as an individual, the $99 fee, exporting an Xcode project and running on the iOS simulator.

Timestamps

• 00:00:00 — Week 4 intro, what the final test covers and how the certificate scoring works
• 00:12:00 — The project assignment, why you shouldn’t expect 100% of the instructions, and Google being part of the job
• 00:20:00 — Where a project starts: time horizon, doubling your estimate, and the game design document
• 00:28:00 — Milestones, small tasks and the snowball effect of finishing things
• 00:36:00 — Alpha, beta, release, and how Steam boosts a first launch
• 00:44:00 — Writing a three-to-five page GDD, walked through with a slot machine example
• 00:55:00 — Project wiki, Confluence, Jira, Notion, and the “what happens if I skip this step” filter
• 01:05:00 — Building in public: Instagram versus Twitter, hashtag limits, posting under your own name
• 01:16:00 — Kickstarter and crowdfunding as validation
• 01:22:00 — Six-month roadmap for the slots game, prototype to PR to LiveOps
• 01:36:00 — LiveOps in depth: events, message-of-the-day, making a game feel alive
• 01:46:00 — Kanban versus Scrum, story points, velocity, and feature creep
• 01:54:00 — Feedback loops, GitHub Actions for CI builds, canny.io for user-driven tasks
• 02:05:00 — Store dashboards, Apple’s $99 and review strictness, individual versus company accounts, privacy policy generators
• 02:20:00 — Build targets and restrictions, why Mac and iOS need a Mac, MacInCloud
• 02:30:00 — Android build settings: keystore creation, IL2CPP, architectures, AAB output
• 02:45:00 — Player settings, icons, bundle identifiers, and fixing the Mac aspect ratio problem
• 02:58:00 — WebGL build, disabling compression, deploying to GitHub Pages so anyone can play in a browser
• 03:15:00 — Google Play Console: creating the app, internal testing track, uploading the AAB, adding testers
• 03:30:00 — Closed testing, store listing assets, tracks and the forms you have to fill in
• 03:45:00 — Apple Developer enrollment live, then exporting an Xcode project and running on the iOS simulator
• 04:05:00 — Playing the finished build on mobile, wrap-up and what the rest of week 4 covers

What you build

By the end of the session Duck Invaders exists as four separate builds. A signed Android app bundle sitting in the Google Play internal testing track, with a store listing, icon, feature graphic and screenshots attached. A WebGL build hosted for free on GitHub Pages that anyone with the URL can play in a browser. A Mac desktop build, complete with the aspect-ratio bug found and fixed on the spot. And an iOS build exported to Xcode and running in the simulator.

You also come away with a keystore of your own, a working understanding of the IL2CPP-versus-Mono trade-off (Mono for iteration speed, IL2CPP for anything you ship), and the trick of generating your Android bundle version code from a Unix timestamp via an editor menu item so you never hit the “version code already used” wall.

The planning half gives you a template for the next project: a GDD you write before you write code, a roadmap with three named milestones, a Kanban board with enough small tasks that you finish something every week, and a public feedback channel.

Who should watch this

Anyone who has a Unity project on their hard drive that nobody else has ever played. The build and publish walkthrough is the practical core — keystores, IL2CPP, WebGL on GitHub Pages, and the Play Console testing tracks — and it’s the difference between a folder of scripts and a link you can send to someone. The first half is more opinion than instruction, but it’s opinion from someone who has shipped a multiplayer game across six platforms over seven years, and it’s worth sitting through even if planning bores you.