Sådan laver du en playable ad uden en udvikler

Key takeaways - At lave en playable ad er mest en designbeslutning: vælg én mekanik, ét mål og én afslutning, før du rører et værktøj. - Planlæg de første par sekunder på papir. Hvis en fremmed ikke kan se, hvad han eller hun skal gøre uden tekst, så forenkl mekanikken. - Du kan bygge uden en udvikler ved at bruge en playable ad maker eller en eksport fra en visuel engine, men du skal stadig teste den endelige fil på rigtige telefoner. - Slutkortet og store-knappen er en del af annoncen, ikke noget, der kommer bagefter. Verificér dem før hver upload. - Behandl hvert netværks aktuelle specifikation som den endelige autoritet for pakning, og lav en QA-gennemgang af den præcise fil, du sender afsted.

Hvad en playable ad egentlig er

En playable ad er en lille interaktiv oplevelse, normalt i HTML5, der kører i en annonceplads. Brugeren ser et kort udsnit af dit spil eller din app, interagerer med det og lander derefter på et slutkort, der sender vedkommende videre til store'en.

Det er hverken en demobuild eller en trailer med en opfordring til at trykke. Det er en målrettet loop, der får folk til at forstå dit produkt ved at røre ved det. Den vinkel er vigtig, fordi den fortæller dig, hvad du skal skære væk: næsten alt.

Teknisk set er en playable en webside. Den består af HTML, JavaScript, billeder og nogle gange lyd, tegnet til et canvas eller til DOM'en. Hvis du er nysgerrig efter, hvad der foregår under motorhjelmen, er Canvas API-dokumentationen på MDN en god introduktion. Du behøver ikke læse den for at lave en, men den forklarer, hvorfor en playable kan være lille og hurtig, når den holdes enkel.

Trin 1: Vælg én mekanik, der er værd at spille

Åbn dit spil eller din app og spørg: Hvad er den ene handling, der får folk til at sige "nå, jeg fatter det"?

• I et match-3-spil er det at bytte to brikker og se en kaskade.
• I en hyper-casual runner er det at styre til venstre og højre for at undvige forhindringer.
• I et merge-spil er det at trække to identiske genstande sammen.
• I en finans- eller fitnessapp kan det være én interaktion, der viser resultatet, for eksempel at flytte en skyder og se et tal ændre sig.

Vælg den, der er nemmest at forstå uden ord, og som giver feedback med det samme. Modstå trangen til at vise progression, shops eller sociale funktioner. Det er grunde til at blive ved med at spille, ikke grunde til at begynde.

En nyttig test: Beskriv playable'en i én sætning. "Træk de ens blokke sammen for at rydde brættet" duer. "Byg din base, kæmp, og opgradér derefter" gør ikke.

Trin 2: Planlæg forløbet på papir

Før du bygger, skal du skrive playable'en ned som en kort række af beats. Du designer en meget lille historie.

1. Hook. Hvad ser spilleren i det allerførste øjeblik? Det bør vise spillets centrale visuelle udtryk og gøre det tydeligt, at noget er interaktivt.
2. Første input. Hvad er det første, spilleren gør? Led vedkommende med en hånd-cursor, en fremhævning eller et pulserende mål. Stol ikke på et afsnit tekst.
3. Belønning. Hvad sker der, når spilleren gør det? Tilføj bevægelse, lyd hvis netværket tillader det, og en tydelig fornemmelse af fremskridt.
4. Optrapning. Giv spilleren en eller to handlinger mere, som føles lidt større end den første.
5. Afslutning. Beslut, hvordan det ender: en sejr, et næsten-nederlag, der inviterer til et nyt forsøg, eller et tidsbaseret stop. Vis derefter slutkortet.

Skitsér hvert beat som en grov ramme. Hvis du ikke kan tegne det i få bokse, er det for kompliceret til dette format.

Beslut, hvordan man kan fejle

En playable, der ikke kan tabes, kan føles meningsløs, og en, der tabes for hurtigt, føles uretfærdig. Et almindeligt mønster er en guidet sejr efterfulgt af et sværere andet trin, hvor det er muligt at fejle, men uden store konsekvenser. Nyt forsøg bør være øjeblikkeligt.

Trin 3: Vælg, hvordan du vil bygge den

Der er tre realistiske veje uden en dedikeret udvikler.

Vej A: En playable ad maker

En playable ad maker genererer HTML5 for dig ud fra dine input. PlayableRun tager for eksempel udgangspunkt i din App Store- eller Google Play-side og producerer en playable, du kan finpudse, og eksporterer derefter en ZIP klar til Google Ads. Denne vej passer til små teams, der skal levere variationer uden at opbygge en pipeline.

Afvejningen er kontrol. Du arbejder inden for de skabeloner og interaktioner, der findes, så vælg mekanikken fra trin 1 med det in mente.

Vej B: En game engines playable-eksport

Hvis dit spil er bygget i en engine med playable- eller HTML5-eksport, kan en teknisk designer ofte skære spillet ned til én bane og eksportere den. Det bevarer dine rigtige visuals og din fornemmelse, men du skal selv håndtere filvægt og netværksspecifikke wrappers.

Vej C: En freelancer eller et studie

Outsourcing er rimeligt, hvis du har brug for en unik mekanik, som intet værktøj understøtter. Giv dem dit manuskript fra trin 2, ikke et upræcist brief. Spørg, hvad den leverede fil indeholder, og hvordan den håndterer store-linket.

Uanset hvilken vej du vælger, er manuskriptet og materialerne dit ansvar. Et værktøj kan ikke afgøre, hvad der er sjovt ved dit spil.

Trin 4: Forbered materialer og byg

Saml, hvad playable'en har brug for, før du går i gang med at bygge:

• Kernegrafik. Figurer, genstande, baggrunde og UI-elementer, eksporteret rent og med transparente baggrunde, hvor det er nødvendigt.
• Feedback-elementer. Partikler, score-pops, fremhævninger og en hånd-cursor.
• Lyd. Valgfrit, og en god playable bør stadig give mening uden lyd.
• Slutkort. Dit ikon, en kort tekstlinje og en tydelig installationsknap.
• Store-link. Den præcise App Store- eller Google Play-side, som annoncen skal åbne.

Mens du bygger, bør du huske tre principper.

Gør touch generøst. Folk spiller på små skærme med upræcise tommelfingre. Store trykområder og tilgivende træk-adfærd slår præcise kontroller. Hvis du bygger eget input, forklarer Pointer Events-dokumentationen på MDN, hvordan én kodesti kan håndtere både touch og mus.

Reagér øjeblikkeligt. Hvert tryk skal give en synlig reaktion. En forsinkelse på blot et øjeblik får annoncen til at virke ødelagt, og folk forlader den.

Hold den let. Tunge materialer gør indlæsningen langsom, og en playable, der indlæses langsomt, mister folk, før de overhovedet har set den. Komprimér billeder, undgå unødvendig lyd, og skær enhver funktion væk, som ikke står i dit manuskript. Hvert netværk har sine egne filgrænser, så tjek den aktuelle specifikation for det netværk, du målretter, i stedet for at stole på hukommelsen.

Trin 5: Test på rigtige enheder

Preview på computeren skjuler problemer. Før du uploader, skal du åbne filen på mindst et par rigtige telefoner, gerne én ældre og én nyere, og tjekke følgende.

• Indlæses den hurtigt på en mobilforbindelse?
• Opfører touch-input sig på samme måde som i dit preview?
• Passer layoutet i både portræt og landskab, hvis netværket understøtter begge dele?
• Vises slutkortet hver gang, også efter et nederlag eller en timeout?
• Åbner installationsknappen den rigtige store-side og ikke en pladsholder?
• Går noget i stykker, hvis spilleren trykker tilfældigt, hurtigt eller slet ikke gør noget?

Det sidste spørgsmål fanger meget. Rigtige mennesker følger ikke dit manuskript. De trykker under animationer, ignorerer hånd-cursoren og prøver at scrolle. Din playable bør kunne klare det.

Brug QA-tjeklisten for playable HTML5 før hver udgivelse, hvis du vil have en mere fuldstændig liste.

Trin 6: Eksportér og upload

Pakningen er det sted, hvor ellers gode playables bliver afvist. Netværkene adskiller sig i, hvordan store-linket skal udløses, hvilke filer der er tilladt, og hvordan en pakke skal se ud.

For Google Ads i særdeleshed er detaljerne om ZIP-strukturen og policy-tjek beskrevet i Sådan uploader du en HTML5 ZIP til Google Ads. Hvis du kører App-kampagner, så læs ExitApi i App-kampagner for at forstå, hvordan klik-ud'et skal sættes op.

Lav et sidste tjek af den præcise fil, du er ved at uploade, ikke af et tidligere build. Det er overraskende almindeligt at teste én version og sende en anden afsted.

Almindelige fejl, du bør undgå

• At vise for meget. En playable er ikke en tutorial. Hvis den kræver en lang forklaring, så skær mekanikken ned.
• Falsk gameplay. Hvis playable'en ikke ligner det rigtige produkt, føler folk sig vildledt, og nogle afinstallerer med det samme. Vis noget, du rent faktisk leverer.
• At skjule call to action. Slutkortet bør være tydeligt. Lad ikke folk lede efter knappen.
• At springe fejltilstanden over. En scriptet sejr føles kedelig. En lille chance for at tabe, efterfulgt af et nemt nyt forsøg, har tendens til at fastholde opmærksomheden.
• Kun at teste i en browser. Rigtige enheder afslører problemer med touch, lyd og layout, som computeren aldrig vil.
• Kun at sende én version afsted. Når den første playable virker, så ændr én ting ad gangen, for eksempel hook, første input eller slutkort, så du lærer, hvad der betyder noget.

Et realistisk første projekt

Hvis det er din første playable, så hold omfanget småt. Vælg én mekanik, byg én bane af den, tilføj et tydeligt slutkort, test den på et par telefoner, og upload den til ét netværk. Du lærer mere af én rigtig kampagne end af at planlægge et perfekt sæt variationer.

Når du er klar til at prøve, kan du se eksempler på PlayableRun-demosiden for at se, hvordan en færdig playable ser ud, eller oprette en gratis konto og bygge din første ud fra din egen store-side.