FAQ

PlayDrop is an AI gaming platform for creators. It combines a catalogue for publishing games, assets, and packs with runtime services such as identity, saves, multiplayer, monetization, AI generation, achievements, and leaderboards inside PlayDrop-hosted apps.

Because PlayDrop is not only hosting. It also gives you creator workflows, catalogue distribution, search and browse surfaces, social signals such as likes, saves, comments, and remixes, plus runtime services your game can integrate directly when it is hosted on PlayDrop.

Creators can publish apps, reusable assets, and asset packs. The catalogue model is versioned, supports remixing, and connects publishing with discovery and social signals.

Not for onboarding. The creator workflow matters first: set up the tools, choose the right content model, run locally, validate, and publish. Player-facing launch behavior is mostly obvious once the content exists.

Use both. The CLI performs the real workflows such as auth, create, remix, dev, validate, publish, browse, and comments. The public PlayDrop skill gives your coding agent the platform-specific workflow and vocabulary so it uses the CLI and runtime correctly.

Let the agent do the setup and implementation work, but keep the human request small and outcome-focused. A good creator prompt tells the agent to install the PlayDrop tooling, authenticate, inspect the workspace, and then choose the correct create, remix, or publish flow.

Yes. The CLI supports browser login by default and also supports API key login with playdrop auth login --key <api-key>. Direct username and password login is also supported when you need it.

Your workspace is the local source of truth while you are building. catalogue.json describes the publishable apps, assets, and packs in that workspace. Validation checks the local contract, and publish pushes the current workspace state into the PlayDrop catalogue.

Every catalogue object is versioned. Apps publish semantic versions, assets publish revisions, and packs publish versions. Remix flows let you scaffold local content from an exact published app, asset, or pack version instead of starting from scratch.

Yes. The creator platform includes browse and search surfaces plus comments, likes, saves, remixes, versions, and related catalogue metadata. Those signals help explain why catalogue quality and listing quality matter.

The runtime covers lifecycle, player identity, saves, room-based multiplayer, monetization, runtime asset access, AI generation jobs, shared runtime libraries, achievements, and leaderboards. Public docs now follow those surfaces directly instead of hiding them behind generic SDK language.

Assets and packs live in the catalogue as creator content, but hosted apps can also inspect, search, load, and in some cases create or update content through the runtime asset APIs. That is why the catalogue docs and runtime docs need to be read together.

PlayDrop owns the platform surfaces: host lifecycle, creator and player identity, storage hooks, room primitives, catalogue integration, commerce hooks, AI generation jobs, and player meta primitives. Your game still owns its core gameplay rules, content design, progression design, and any custom backend behavior that is outside the PlayDrop platform contract.

Usually yes. Public catalogue content is browser-first, and creators do not need to design a separate install flow for basic launch and discovery.

No. Hosted apps can choose whether auth is required, optional, or disabled. That is part of the app contract, not a universal platform rule.