`ludic build` produces a program. Double-clicked it opens a Terminal window, it wears the generic executable icon, it calls itself whatever the file is called, and it carries none of its assets. `ludic bundle` produces an application. Everything it needs is in package.ludic, so the command takes no arguments: an Info.plist and PkgInfo from `app` lines, an .icns built by sips and iconutil at all ten sizes macOS asks for from a single source PNG, the asset pack in Contents/Resources, and an ad-hoc signature - which is not optional on Apple silicon, where an unsigned binary is killed rather than warned about. The bundle identifier falls back to the package path reversed, so a project that never thinks about it still gets a defensible one instead of two apps sharing a key Launch Services hangs the Dock, saved state and permissions off. A bundled game is moved to ~/Library/Application Support/<name> before main, because Finder starts a .app with its working directory at "/" where no save could ever be written. Reads come out of the pack, writes land somewhere real and per-user, and the game's save code needs no change and no platform knowledge. The splash is the other half of looking like an application. A game that loads 165 MB spends a visible moment doing it with nothing on screen, which from the outside is indistinguishable from a launch that failed. splash_show puts a borderless window up from the same constructor that mounts the pack - before main, so it appears while the process is still starting rather than after the slow part it exists to cover - and reads the artwork out of the pack like any other asset. It turns the run loop enough times to be mapped and composited there and then; once composited the backing store survives a busy main thread, so it stays up for the whole load. Nothing hides it automatically. Only the game knows when its first real frame is ready, and a splash that vanishes before that leaves the same black gap it was covering, so the game calls App.splash_hide(). Headless there is no splash and the call lowers to nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| asset-packs.md | ||
| boot-splash.md | ||
| macos-bundle.md | ||
| README.md | ||
Changesets
A changeset is one small Markdown file describing a single user-facing change,
dropped in this directory. ludic-dev release consumes every changeset here into a new
CHANGELOG.md section, bumps VERSION, and deletes the consumed files.
Format
bump: minor
type: feat
One or more lines describing the change, in the past-agnostic imperative used in
the changelog. Markdown is fine.
bump:—major,minor, orpatch(SemVer). The release version is bumped by the highest level among the pending changesets (unlessludic-dev release <level>overrides it).type:— the Conventional Commit type (feat,fix,perf,docs, …). It decides which group the change lands in:feat→ Features,fix→ Fixes,perf→ Performance, and so on, in that order. A type with no known heading gets one named after itself.
Writing the body
The body is markdown and reaches the changelog as markdown: it becomes one list item, with continuation lines indented to stay inside it. Nested bullets, blank lines between paragraphs and inline code all survive.
bump: minor
type: feat
**Tiled map support** — load and draw Tiled maps.
- **TMX/TSX** — the XML formats, decoded to the same intermediate as JSON.
- **Collision** — the `collision` layer projects onto the engine tilemap.
Lead with the thing that changed, not with the mechanism. A reader scanning the release should be able to stop after your first clause.
Adding one
Create a file with a short, unique name, e.g. changes/regex-namespace.md. Any
filename works except this README.md, which the release step always skips.
Preview how the next release will read before cutting it — this writes nothing:
ludic-dev release --dry-run