Kuidas teha playable-reklaami ilma arendajata

Peamised järeldused - Playable-reklaami tegemine on suuresti disainiotsus: vali üks mehaanika, üks eesmärk ja üks lõpp, enne kui ühtegi tööriista puudutad. - Kirjuta esimesed paar sekundit paberil ette. Kui võõras ei saa ilma tekstita aru, mida teha, lihtsusta mehaanikat. - Arendajata saab ehitada playable-reklaami tööriistaga või visuaalse mootori ekspordiga, kuid lõplikku faili tuleb ikkagi päris telefonides testida. - Lõppkaart ja poe nupp on reklaami osa, mitte järelmõte. Kontrolli neid enne iga üleslaadimist. - Pea iga võrgu kehtivat spetsifikatsiooni pakendamise puhul tõe allikaks ning tee kvaliteedikontroll täpselt sellele failile, mille välja saadad.

Mis playable-reklaam tegelikult on

Playable-reklaam on väike interaktiivne kogemus, tavaliselt HTML5, mis töötab reklaamikohas. Inimene näeb lühikest lõiku sinu mängust või rakendusest, suhtleb sellega ja jõuab siis lõppkaardile, mis suunab ta poodi.

See ei ole demoversioon ega treiler puudutuskutsega. See on spetsiaalselt loodud tsükkel, mis paneb inimese sinu toodet puudutades mõistma. See raamistus on oluline, sest ütleb, mida välja lõigata: peaaegu kõik.

Tehniliselt on playable veebileht. See koosneb HTML-ist, JavaScriptist, piltidest ja vahel helist ning joonistatakse canvasele või DOM-i. Kui huvitab, mis kapoti all toimub, on heaks sissejuhatuseks Canvas API dokumentatsioon MDN-is. Selle lugemine ei ole playable'i tegemiseks vajalik, kuid see selgitab, miks playable võib olla väike ja kiire, kui seda lihtsana hoida.

1. samm: vali üks mängimist väärt mehaanika

Ava oma mäng või rakendus ja küsi: milline on see üks tegevus, mis paneb inimesed ütlema "ahaa, saan aru"?

• Match-3 mängus on selleks kahe elemendi vahetamine ja kaskaadi vaatamine.
• Hüperkergemängu (hyper-casual) jooksjas on selleks vasakule ja paremale suunamine takistustest möödahiilimiseks.
• Merge-mängus on selleks kahe identse eseme kokku lohistamine.
• Finants- või treeningrakenduses võib see olla üks interaktsioon, mis näitab tulemust, näiteks liuguri liigutamine ja numbri muutumise vaatamine.

Vali see, millest on kõige lihtsam aru saada ilma sõnadeta ja mis annab tagasisidet kohe. Ära anna järele kiusatusele näidata progressiooni, poode või sotsiaalseid funktsioone. Need on põhjused mängida edasi, mitte põhjused alustada.

Kasulik test: kirjelda playable'i ühe lausega. "Lohista sobivad plokid, et laud puhtaks teha" sobib. "Ehita oma baas, siis võitle, siis uuenda" ei sobi.

2. samm: kirjuta seanss paberil ette

Enne ehitamist kirjuta playable üles lühikese taktide jadana. Disainid väga väikest lugu.

1. Konks (hook). Mida mängija esimesel hetkel näeb? See peaks näitama sinu mängu põhivisuaali ja tegema selgeks, et midagi on interaktiivne.
2. Esimene sisend. Mida ta esimesena teeb? Suuna seda käekursori, esiletõstmise või pulseeriva sihtmärgiga. Ära toetu tekstilõigule.
3. Tasu. Mis juhtub, kui ta seda teeb? Lisa liikumine, heli (kui võrk seda lubab) ja selge edasiliikumise tunne.
4. Eskalatsioon. Anna talle üks või kaks tegevust juurde, mis tunduvad esimesest veidi suuremad.
5. Lõpp. Otsusta, kuidas see lõpeb: võit, napp läbikukkumine, mis kutsub uuesti proovima, või ajapõhine katkestus. Seejärel näita lõppkaarti.

Visanda iga takt jämeda kaadrina. Kui seda ei saa paari kastiga joonistada, on see selle formaadi jaoks liiga keeruline.

Otsusta, kuidas saab läbi kukkuda

Playable, mida ei saa kaotada, võib tunduda mõttetu, ja see, mida kaotatakse liiga kiiresti, tundub ebaõiglane. Levinud muster on juhitud võit, millele järgneb raskem teine samm, kus läbikukkumine on võimalik, kuid andestav. Uuesti proovimine peaks olema silmapilkne.

3. samm: vali, kuidas ehitad

Ilma pühendatud arendajata on kolm realistlikku teed.

A-tee: playable-reklaami tööriist

Playable-reklaami tööriist genereerib sinu sisendi põhjal HTML5. PlayableRun näiteks alustab sinu App Store'i või Google Play lehest ja loob playable'i, mida saad täpsustada, seejärel ekspordib Google Adsi jaoks valmis ZIP-faili. See tee sobib väikestele tiimidele, kes peavad variatsioone välja andma ilma tootmisliini ehitamata.

Kompromiss on kontroll. Töötad olemasolevate mallide ja interaktsioonidega, seega vali 1. sammu mehaanika seda silmas pidades.

B-tee: mängumootori playable-eksport

Kui sinu mäng on ehitatud mootoris, millel on playable'i või HTML5 eksport, saab tehniline disainer mängu sageli ühele tasemele kokku kärpida ja selle eksportida. See säilitab sinu päris visuaalid ja tunnetuse, kuid failimahtu ja võrgupõhiseid ümbriseid pead ise haldama.

C-tee: vabakutseline või stuudio

Allhange on mõistlik, kui vajad ainulaadset mehaanikat, mida ükski tööriist ei toeta. Anna neile 2. sammu stsenaarium, mitte ebamäärane brief. Küsi, mida tarnitud fail sisaldab ja kuidas see poelinki käsitleb.

Ükskõik millise tee valid, stsenaarium ja materjalid on sinu töö. Tööriist ei saa otsustada, mis su mängu juures lõbus on.

4. samm: valmista ette materjalid ja ehita

Kogu enne ehitamist kokku see, mida playable vajab:

• Põhigraafika. Tegelased, esemed, taustad ja kasutajaliidese osad, puhtalt eksporditud, vajadusel läbipaistva taustaga.
• Tagasisideelemendid. Osakesed, punktide hüpikud, esiletõstmised ja käekursor.
• Heli. Valikuline, ja hea playable peaks olema mõistetav ka vaikse heliga.
• Lõppkaart. Sinu ikoon, lühike tekstirida ja selge installinupp.
• Poelink. Täpne App Store'i või Google Play leht, mille reklaam peab avama.

Ehitamisel pea meeles kolme põhimõtet.

Tee puudutus andestavaks. Inimesed mängivad väikestel ekraanidel ebatäpsete pöidlatega. Suured puutealad ja andestav lohistamine on parem kui täpsed juhtnupud. Kui ehitad enda sisendikäsitlust, selgitab Pointer Events dokumentatsioon MDN-is, kuidas üks koodirada saab käsitleda nii puudutust kui hiirt.

Reageeri koheselt. Iga puudutus peab tekitama nähtava reaktsiooni. Isegi hetkeline viivitus tundub nagu reklaam oleks katki ja inimesed lahkuvad.

Hoia see kerge. Rasked materjalid aeglustavad laadimist ja playable, mis laeb aeglaselt, kaotab inimesed enne, kui nad seda üldse näevad. Tihenda pilte, väldi tarbetut heli ja lõika välja iga funktsioon, mida sinu stsenaariumis pole. Iga võrk seab oma failipiirangud, seega kontrolli sihitava võrgu kehtivat spetsifikatsiooni, mitte ära looda mälule.

5. samm: testi päris seadmetes

Arvuti eelvaated peidavad probleeme. Enne üleslaadimist ava fail vähemalt paaris päris telefonis, ideaalis ühes vanemas ja ühes uuemas, ning kontrolli järgmist.

• Kas see laeb mobiilses ühenduses kiiresti?
• Kas puutesisend käitub samamoodi nagu sinu eelvaates?
• Kas paigutus sobib nii püst- kui rõhtpaigutuses, kui võrk mõlemat toetab?
• Kas lõppkaart ilmub iga kord, ka pärast läbikukkumist või ajalõppu?
• Kas installinupp avab õige poelehe, mitte kohahoidja?
• Kas midagi läheb katki, kui mängija puudutab suvaliselt, kiiresti või ei tee üldse midagi?

Viimane küsimus tabab palju. Päris inimesed ei järgi sinu stsenaariumi. Nad puudutavad animatsioonide ajal, ignoreerivad käekursorit ja proovivad kerida. Sinu playable peaks sellele vastu pidama.

Põhjalikuma nimekirja jaoks kasuta enne iga väljalaset playable'i HTML5 kvaliteedikontrolli kontrollnimekirja.

6. samm: ekspordi ja lae üles

Pakendamise juures lükatakse muidu head playable'id tagasi. Võrgud erinevad selle poolest, kuidas poelinki tuleb käivitada, millised failid on lubatud ja milline peab pakett välja nägema.

Eriti Google Adsi puhul on ZIP-i struktuuri ja poliitikakontrollide üksikasjad kirjas artiklis Kuidas laadida HTML5 ZIP Google Adsi. Kui käitad App-kampaaniaid, loe artiklit ExitApi App-kampaaniates, et mõista, kuidas väljaklõps tuleb ühendada.

Tee lõplik kontroll täpselt sellele failile, mida üles laadid, mitte varasemale versioonile. On üllatavalt tavaline testida ühte versiooni ja välja anda teist.

Levinud vead, mida vältida

• Liiga palju näitamine. Playable ei ole õpetus. Kui see vajab pikka selgitust, kärbi mehaanikat.
• Võlts mäng. Kui playable ei sarnane päris tootega, tunnevad inimesed end eksitatuna ja mõni desinstalleerib kohe. Näita seda, mida tegelikult pakud.
• Üleskutse peitmine. Lõppkaart peaks olema ilmne. Ära pane inimesi nuppu otsima.
• Läbikukkumise oleku vahelejätmine. Stsenaariumijärgne võit tundub igav. Väike võimalus kaotada, millele järgneb lihtne uuesti proovimine, kipub tähelepanu hoidma.
• Testimine ainult brauseris. Päris seadmed paljastavad puute-, heli- ja paigutusprobleeme, mida arvuti kunagi ei näita.
• Ainult ühe versiooni väljastamine. Kui esimene playable töötab, muuda korraga ühte asja, näiteks konksu, esimest sisendit või lõppkaarti, et õppida, mis loeb.

Realistlik esimene projekt

Kui see on sinu esimene playable, hoia ulatus väike. Vali üks mehaanika, ehita sellest üks tase, lisa selge lõppkaart, testi seda mõnes telefonis ja lae see üles ühte võrku. Õpid ühest päris kampaaniast rohkem kui täiusliku variatsioonikomplekti planeerimisest.

Kui oled valmis proovima, vaata PlayableRuni demode lehel näiteid, et näha, milline näeb välja valmis playable, või loo tasuta konto ja ehita oma esimene oma poelehe põhjal.