Manual
Scope: game · language: en
Game administration
admin
Each game runs its own database and admin. Manage catalog, trials, environments, packs, campaigns, abilities and quiz content from the panel.
Feature settings, Mechanics, Test lab and the Anti-cheat page control runtime behavior for that game only.
Feature settings, Mechanics, Test lab and the Anti-cheat page control runtime behavior for that game only.
Mechanics profile
admin
The Mechanics page defines the race shape, scoring, win condition, variance, environment cap, fusion and ability/quiz rules.
Saves create a version; activation is atomic and audited.
Saves create a version; activation is atomic and audited.
Content rules
admin
Use additive content, versioned keys and translations for every visible string. Quiz answer specs are validated on save and import.
Never paste secrets into content fields.
Never paste secrets into content fields.
Command reference
admin
The Command reference page lists every project command, what it does, its usage and where it is exposed in the admin.
Read-only checks can be run there and are recorded in the test-run history; commands that write data stay deliberate operator actions. Use it before running anything from a terminal.
Read-only checks can be run there and are recorded in the test-run history; commands that write data stay deliberate operator actions. Use it before running anything from a terminal.
Encyclopedia import
admin
On Collectibles or Collectible profiles use **Import from sources** to fetch taxonomy, overview, habitat and conservation from GBIF, Wikipedia and Wikidata for one animal; enable **Force refresh** to import again.
For batches use Test lab → Scenarios → Encyclopedia import (limit/offset; preview unless execute). The import only writes content and source/license records; it never changes gameplay stats. Review the result before publishing.
For batches use Test lab → Scenarios → Encyclopedia import (limit/offset; preview unless execute). The import only writes content and source/license records; it never changes gameplay stats. Review the result before publishing.
Email & push
admin
The **Email & push** page (Growth) lists the EN/IT templates for marketing email and push, with a safe test send and a delivery log. **Seed default templates** adds the neutral welcome, comeback, milestone, reward, event, invite and digest emails and the reminder/event/reward pushes; it never overwrites admin edits. Edit a template's name, subject/title, body and active flag; saving bumps its version. Tokens `{name}`, `{app}`, `{url}` and `{unsubscribe}` are replaced at send time.
**Growth settings → Email, push, social, ASO** controls the switches, provider, daily caps (`email_daily_cap`, `push_daily_cap`), sender name and reply-to. Marketing messages are sent only to opted-in players and within the cap; transactional mail is untouched. Operators can send a test email to an explicit address from the page.
Commands: `php artisan growth:messages:seed`, `php artisan growth:messages:send welcome --player=ID|UUID|EMAIL` (or `--channel=push`), `php artisan growth:messages:send welcome --email=you@example.com`, and `php artisan growth:messages:digest --limit=200 [--dry-run]`. The digest is scheduled weekly (Monday 09:00) and daily (09:05); each run targets only players who selected that cadence and opted in. Push delivery requires `ONESIGNAL_APP_ID` + `ONESIGNAL_REST_API_KEY` or `FCM_SERVER_KEY` in the environment and the provider selected in Growth settings; with no credentials the send is logged as skipped, never failed silently. The **messaging_preferences** client screen (Command Center → Account, editable component `messaging_preferences_form`) lets the player toggle email/push opt-in and the digest frequency; device-token registration for push is handled by the push SDK integration.
**Growth settings → Email, push, social, ASO** controls the switches, provider, daily caps (`email_daily_cap`, `push_daily_cap`), sender name and reply-to. Marketing messages are sent only to opted-in players and within the cap; transactional mail is untouched. Operators can send a test email to an explicit address from the page.
Commands: `php artisan growth:messages:seed`, `php artisan growth:messages:send welcome --player=ID|UUID|EMAIL` (or `--channel=push`), `php artisan growth:messages:send welcome --email=you@example.com`, and `php artisan growth:messages:digest --limit=200 [--dry-run]`. The digest is scheduled weekly (Monday 09:00) and daily (09:05); each run targets only players who selected that cadence and opted in. Push delivery requires `ONESIGNAL_APP_ID` + `ONESIGNAL_REST_API_KEY` or `FCM_SERVER_KEY` in the environment and the provider selected in Growth settings; with no credentials the send is logged as skipped, never failed silently. The **messaging_preferences** client screen (Command Center → Account, editable component `messaging_preferences_form`) lets the player toggle email/push opt-in and the digest frequency; device-token registration for push is handled by the push SDK integration.
Growth campaigns
admin
The **Campaigns** page (Growth) creates scheduled email/push campaigns from the existing templates. Choose the channel, template, segment (`all_opted_in`, `new`, `active`, `dormant`, `never_active`), an optional locale (blank = each player's locale) and an optional schedule time; saving without a time creates a draft. **Schedule now** makes it due, **Run now** queues it immediately, **Cancel** stops a draft/scheduled/running campaign. The page shows the estimated recipients, the per-segment counts and sent/skipped/failed counters.
Every send goes through the opt-in, per-channel daily cap and EN/IT template fallback; a segment can never widen consent. Delivery is chunked and queued (`RunGrowthCampaign`), so the queue worker must run. `php artisan growth:campaigns:due` queues due campaigns and is scheduled every five minutes; `php artisan growth:campaigns:run {id}` queues one campaign now. A completed campaign is not sent again. The demo deployment must block campaign creation and delivery via the demo read-only rules.
Every send goes through the opt-in, per-channel daily cap and EN/IT template fallback; a segment can never widen consent. Delivery is chunked and queued (`RunGrowthCampaign`), so the queue worker must run. `php artisan growth:campaigns:due` queues due campaigns and is scheduled every five minutes; `php artisan growth:campaigns:run {id}` queues one campaign now. A completed campaign is not sent again. The demo deployment must block campaign creation and delivery via the demo read-only rules.
Growth reports
admin
The **Reports** page (Growth) shows aggregate email/push metrics for the last 7, 30 or 90 days: players, email opt-in, push opt-in, active push tokens, messages sent/skipped/failed, a per-channel breakdown, the top templates, the top skip reasons (not opted in, frequency cap, template missing, no email, push disabled, provider unavailable, no tokens) and campaign totals.
Reporting is privacy-first: no player rows, message bodies, open/click identifiers, IP addresses or device details are shown. Counts exclude bots and anonymized accounts. The page is read-only and does not send anything.
Reporting is privacy-first: no player rows, message bodies, open/click identifiers, IP addresses or device details are shown. Counts exclude bots and anonymized accounts. The page is read-only and does not send anything.
Referral program
admin
Referral settings live in **Growth settings → Referrals**: enable the program, code prefix/length, attribution model/window, hold hours, qualification rule (verified / first race / verified+first race+24h), double-sided gold/gems, premium switch, daily/lifetime/pending caps, auto-flag score, manual review, disposable-email blocking and the public page. The kit config also lists public and disposable email domains.
Each player gets a stable code on demand (`/r/{code}` sets the attribution cookie and redirects to registration; `?ref=CODE` and the API `POST /referrals/apply` are also accepted). A referral is pending during the hold; `referrals:qualify` (scheduled every 10 minutes) checks the rule and grants the rewards idempotently through the ledger. The **Referrals** admin page shows aggregate statuses and the recent list; flagged referrals need **Approve** or **Reject**. Approving re-checks qualification. Rewards are in-game only; no cash payouts. The public demo must block approval/rejection with the read-only admin rules.
**Milestones** (Growth settings → Referrals) grant extra rewards when a referrer reaches 3, 10, 25 and 50 qualified friends. Each milestone is a reward spec: `<N> gold`, `<N> gems` or `<N> premium` (for example `50 gems`); `pack` or `pack:<key>` delivers the pack contents without charge (bare `pack` uses `basic`); `cosmetic` or `cosmetic:<key>` grants a cosmetic (bare `cosmetic` uses the cheapest active one); `park_slot` grants one park slot. Each threshold is granted once per player and is written to the referral reward ledger as `milestone:<n>`.
**Season leaderboard** is shown on the public `/referrals` page and in this admin page; it lists the top referrers by qualified friends inside `referral_season_days`, aliases only. **Vanity/partner codes** can be assigned in the player ID + code form on this page when `referral_vanity_codes` is on; the new code replaces the generated one and the old link stops working. The **referrals** client screen is registered in the Screen Designer and the Command Center; its components (`referrals_code`, `referrals_stats`, `referrals_leaderboard`, `referrals_invited`) are editable.
Each player gets a stable code on demand (`/r/{code}` sets the attribution cookie and redirects to registration; `?ref=CODE` and the API `POST /referrals/apply` are also accepted). A referral is pending during the hold; `referrals:qualify` (scheduled every 10 minutes) checks the rule and grants the rewards idempotently through the ledger. The **Referrals** admin page shows aggregate statuses and the recent list; flagged referrals need **Approve** or **Reject**. Approving re-checks qualification. Rewards are in-game only; no cash payouts. The public demo must block approval/rejection with the read-only admin rules.
**Milestones** (Growth settings → Referrals) grant extra rewards when a referrer reaches 3, 10, 25 and 50 qualified friends. Each milestone is a reward spec: `<N> gold`, `<N> gems` or `<N> premium` (for example `50 gems`); `pack` or `pack:<key>` delivers the pack contents without charge (bare `pack` uses `basic`); `cosmetic` or `cosmetic:<key>` grants a cosmetic (bare `cosmetic` uses the cheapest active one); `park_slot` grants one park slot. Each threshold is granted once per player and is written to the referral reward ledger as `milestone:<n>`.
**Season leaderboard** is shown on the public `/referrals` page and in this admin page; it lists the top referrers by qualified friends inside `referral_season_days`, aliases only. **Vanity/partner codes** can be assigned in the player ID + code form on this page when `referral_vanity_codes` is on; the new code replaces the generated one and the old link stops working. The **referrals** client screen is registered in the Screen Designer and the Command Center; its components (`referrals_code`, `referrals_stats`, `referrals_leaderboard`, `referrals_invited`) are editable.
Social & ASO assets
admin
CLI: `php artisan animalia:social:assets {id} --zip` or `php artisan animalia:social:assets --all --limit=25 --zip`; add `--preset=square` (repeatable) to limit the presets. Use the generated URLs in the ASO/social fields and for posts; set the app icon and feature graphic in the store listing.