Publiser spill fra KI-appen din med PlayDrop MCP

1. Kall get_documentation({topic:"index"}) og les veiledningene for funksjonene spillet skal bruke, før du skriver kode. Når du planlegger fullskjermoppsett, lagring og kontroller fra starten, slipper du å skrive om spillet senere. For nøyaktige metodesignaturer leser du emnene sdk-types, server-sdk-types og shared-types.
2. Kall list_games. Hvis spillet allerede finnes, skal du oppdatere det og beholde name, slik at det beholder lenken og spillerne sine.
3. Velg vei. Én selvstendig HTML-fil uten PlayDrop-SDK-en bruker den enkle veien. Alt annet, inkludert enhver SDK-funksjon, oppføringsmedier eller en server, bruker en pakke.

Ta vare på skaperens kildeprosjekt selv. PlayDrop mottar bare ferdigbygde filer: det er ikke en sikkerhetskopi av kildekoden og kan ikke gi tilbake kildekode.

Send requestId, hele HTML-koden (høyst 10 MiB, 10 485 760 UTF-8-byte) og en minikatalog. Send med gameId for å oppdatere et eksisterende spill. Versjonsnumre økes automatisk. Se enkle HTML-spill for feltene.

Kall prepare_catalogue_upload med requestId, expectedCurrentVersion og én inndataform:

• Mappe: catalogue (innholdet i catalogue.json) pluss files, én beskrivelse per fil med den relative stien. En beskrivelse inneholder innebygd text, en beskrivelse av en signert opplasting, en vedleggskobling eller reuse av en fil fra en beholdt versjon.
• Lokal ZIP eller .play: pakk den ut lokalt, og send deretter catalogue.json fra roten og beskrivelsene av mappefilene. Legg aldri arkivbyte i base64 inn i et verktøykall.
• ChatGPT-vedlegg: send ZIP- eller .play-filen som vertsappen har løst opp, som archive, med den ekte download_url og file_id. Den kan være opptil 20 MiB komprimert og må ha catalogue.json i roten.

For signerte opplastinger oppgir hver beskrivelse path, contentType, sizeBytes, sha256 (64 heksadesimale tegn med små bokstaver) og md5Base64, beregnet lokalt fra de nøyaktige bytene. Send disse bytene med PUT til hver returnerte URL med alle returnerte headere, og kall deretter complete_catalogue_upload med samme requestId.

I ChatGPT kan mappefiler komme fra vedlegg som kobles etter posisjon:

attachments: [htmlFile, iconFile]
files: [{path:"index.html", attachmentIndex:0}, {path:"listing/icon.png", attachmentIndex:1, role:"LISTING", app:"my-game"}]

Hver app trenger en deklarert version, en synlighet (i forespørselen eller på appen) og en oppføring i expectedCurrentVersion med navnet som nøkkel: null for å opprette den, eller den nåværende publiserte versjonen fra list_games for å oppdatere den. En utdatert verdi avvises, slik at en annen opplasting aldri blir overskrevet ved et uhell.

Last opp med visibility: "private" når spillet bruker SDK-en eller en server, eller når brukeren din vil prøve det først. Åpne url fra kvitteringen for å spille akkurat den versjonen inne i PlayDrop med den ekte SDK-verten. Hostede serverfunksjoner kjører bare på opplastede versjoner, så test dem på denne måten.

Når det fungerer, publiserer du akkurat den versjonen med publish_game_version og sender med gameId, version, expectedCurrentVersion og, hvis brukeren din har valgt en, visibility (public eller unlisted). Den gjenbruker de testede filene, oppføringen og gjennomgangen. Ikke last opp spillet på nytt for å publisere det.

For å prøve en lokal build i PlayDrop-rammen før du laster opp, åpner du https://www.playdrop.ai/@<username>/<slug>/dev?url=<URL-encoded local address> i en vanlig nettleser på maskinen som kjører den lokale serveren.

visibility godtar public, unlisted og private. For et nytt spill uten et valg bruker du skaperens lagrede innstilling: upload_game bruker den når du utelater synlighet, og get_account viser den som publishing.defaultVisibility. For en oppdatering beholder du spillets gameVisibility fra list_games, med mindre brukeren din endrer den; upload_game gjør dette når du utelater synlighet, og en pakke oppgir den. Ikke oppført betyr at alle med lenken kan spille; det er ikke en venneliste. Gjør aldri et spill mer synlig enn brukeren din hadde tenkt. Detaljer: hvem som kan spille.

Kvitteringer for offentlige og ikke oppførte spill inneholder shareUrl, spillets varige side: gi den til brukeren din. En privat versjon returnerer url, lenken til akkurat den versjonen for eieren. Pakkekvitteringer lister hvert element; fullførte elementer forblir publisert selv om et senere element feiler.

Les list_games og den nåværende versjonen, behold name, og send et fullstendig øyeblikksbilde: alle filene og alle metadataene som skal være med, fordi felt som utelates, mangler i den nye versjonen. Katalogelementer som utelates, slettes aldri. Bruk get_game_version for å lese den nøyaktige katalogen til versjonen du endrer, inkludert Tweaks-tilstanden.

• Den enkle veien: én HTML-fil på høyst 10 MiB.
• Pakke: 512 filbeskrivelser i en mappe eller 512 arkivoppføringer (inkludert catalogue.json og mapper), 50 MiB per fil, 200 MiB utpakket totalt og 1 MiB katalog-JSON.
• Arkiver: bare trygge relative stier; dupliserte stier, symbolske lenker, krypterte arkiver, arkiver i flere deler og ZIP64-arkiver avvises.
• Forberedte opplastinger utløper etter 30 minutter.

Feil inneholder error, message, retryable, nextAction, docsUrl og documentationTopic. Følg nextAction. Etter et tapt svar prøver du identisk innhold på nytt med samme requestId; endret innhold trenger en ny. Se feil og gjenoppretting.

Bruk send_feedback til å rapportere et problem som kan gjenskapes, eller et forvirrende trinn, uten tokener eller signerte URL-er.