Plan your first AfricaOne experience
This is a planning guide. It does not create an app or connect to player accounts. A sandbox console exists at africaone.io/developers and is switched off in production.
1. Choose one player task
Write a sentence that describes the benefit and the action: "A player discovers a reviewed city story and can return to the world when finished." Keep the first version small enough that its behavior and permissions can be understood in one sitting.
Avoid promising earnings, professional certification, guaranteed work or rewards that have not been approved.
2. Sketch the complete journey
Describe the entry point, the main action and the way back. Include the states a player will encounter:
| State | What the player needs |
|---|---|
| Loading | Honest progress and a way to recover from a delay |
| Empty | A useful explanation without fabricated activity |
| Consent or access denied | A clear choice and a safe way to leave |
| Offline or failed | Preserved input where supported and an explicit retry |
| Success | A truthful confirmation and a next action |
| Return | The expected place in AfricaOne, with identity and progress intact |
3. Minimize permissions
List the information and actions your experience would need. Remove anything unrelated to the player's task. Do not design around access to emails, birth dates, private messages, exact locations, balances or other players' private records.
The proposed platform will require approval for each capability. Writing a requested capability in a plan does not grant access to it. Plan for a declined permission and for permission being withdrawn later.
4. Prototype with fictional data
An independent interface sketch can use clearly fictional examples. Keep them separate from real player records. Show which values are examples, avoid invented user counts or endorsements, and make no network request to a proposed AfricaOne endpoint.
Use the Experience Kit guidance for responsive layout, controls and accessible states. A prototype is not an approved app or a production integration.
5. Prepare review evidence
Describe your intended audience, requested capabilities, data use, error recovery and content rights. Record keyboard behavior and small-screen layouts. Keep proposed purchases, rewards or professional verification disabled until their separate approvals and interfaces exist.
Return to the overview for the current scope: the API reference and the sandbox console exist; SDKs and submission tools will be documented when they are genuinely available.