Refleksion: Corona Dag II

Refleksion over undervisningen 20140403:

I faget interaktion bruges Corona SDK til udvikling af mobile apps. Via Corona SDK kan vi udvikle apps til fx:

• Android
• iOs (= iPhone, iPad)
• Kindle
• Ouya

Corona SDK består af en device-emulator, der på udviklerens PC viser et skæmbillede af, hvordan appen vil se ud på en mobil enhed. Programmeringen foregår via Coronas API, der skrives i Lua. Koden compiles i skyen, og resultatet sendes tilbage til programmørens PC i form af en fil.

Hvis der er tale om en Android telefon, så returneres en .apk fil.

Dag II var interessant, fordi den ikke gik helt som forventet. Inden undervisningens start annoncerede jeg dagens lektie på Facebook. I løbet af forrige semester udførte jeg research i Corona. En bog så lovende ud:

Umiddelbart så koden lovende ud. Programmøren præsenterede et puslespil. Det lignede gefundenes Fressen. Men i løbet af weekenden ville jeg lige afprøve øvelsen, for at se, hvordan dagen skulle tilrettelægges tidsmæssigt.

Som regel bruger studerende længere tid på en øvelse end jeg selv ville gøre. Det viste sig desværre, at teksten ikke kunne holde det den lovede. Uanset hvilken mobil device jeg valgte i emulatoren var resultatet det samme: indholdet viste sig ikke på skærmen. Der var sære fejlmeddelelser. Og jeg kom til at bruge ca. 4 timer en søndag med debugging af en anden mands ikkefungerende kode.

O … K … hvad gør man så?

Jeg havde allerede bygget nogle pædagogiske prototyper, der eksperimenterede med Coronas Physics Engine:

• SceneAndButton – et eksempel på en kode, hvor kasser falder ned, og hopper som gummibolde, når de rammer “jorden” (en grøn firkant), et tilfældigt placeret kvadrat eller en grøn cirkel, som brugeren kan trække rundt med (drag & drop).
• Storyboard – hvor man ved hjælp af et klik skifter scenen ud.

Men min målgruppe er multimediedesignere. Jeg holder selv meget af koder, der får kasser til at hoppe rundt – eller at skabe sære geometriske mønstre ved hjælp af loops. I løbet af weekenden slog det mig, at det nok var bedre at arbejde med en lille animation, som brugeren kan styre ved hjælp af knapper eller kode.

Appen er i princippet meget simpel. To figurer myldrer ned over skærmen. En knap gør opmærksom på at man kan klikke dér. Når man klikker, så løber en sprite hen over skærmen.

Det var min opfattelse, at denne kode nok var lidt for enkel til seks lektioner; men omvendt så kunne jeg supplere med de to foregående kodeeksempler.

Jeg præsenterede spritesheets, der både anvendes i animation på mobile devices. Jeg brugte eventyret om Rapunzel, (Klokkeblomst) som udgangspunkt.

Eventyret kan animeres sådan:

1. Scene: Helten står ved slottets fod. Brugeren ser de lange fletninger, der udgår fra prinsessen højt oppe i tårnet. Jeg tegnede dette på tavlen (i en bevidst grov skitseform).
2. Brugeren klikker på fletningerne, der er en knap.
3. Knappen fyrer en animation af ved hjælp af en eventlistener, der reagerer på en berøring (touch). Når touch = true afspilles …
4. animaitonen af prinsen som klatrer op ad fletningerne og ind til den søde prinsesse ved hjælp af Coronas API transition.to

Eventyret er et visuelt eksempel på, hvordan knapper fungerer i computerspil. Og dermed har vi forbindelsen til årets semestercase, der handler om serious games eller gamification. (Emnet er i øvrigt et kompromis mellem to undervisere, der er tilknyttet projekterne “serious games” og “gamification”.)

Plan og successudfaldsrum

Som altid indledte jeg timen med en beskrivelse af dagens program – og en introducerende snak om det som vi skulle lave i dag. Successkriteriet (eller rettere: det didaktiske læringsmål) var at den studerende skulle kunne udvikle et spritesheet og skrive en kode, der kunne afvikle spritesheetet inden vi gik hjem den dag.

Et spritesheet kan principielt tegnes på flere måder:

• Man kan åbne et tegneprogram (fx Gimp, Inkscape, Photoshop eller Illustrator). En fil på fx 2048×2048 inddeles i ensartede fliser ved hjælp af linealer. Herefter tegnes de ønskede figurer animationens positurer.
• Man kan tegne i hånden og indscanne billederne. En enkelt studerende valgte denne fremgangsmåde. Jeg foreslog, at han kunne vektorisere sine tegninger i Illustrator og arbejde videre i Flash.
• Animationen kan udvikles i flash – og herfra kan man eksportere et spritesheet. Teknikken beskrives i en kort artikel af Avinash.

Fremstilling af spritesheets

Klokken var nu 10. Klassen mente, at de ville kunne have et spritesheet klar på en times tid. Tegning tager altid længere tid end man regner med. 11:30 havde de fleste studerende produceret spritesheets.

Flere studerende havde ikke brugt Flash siden introduktionen på 1. semester. Det er således  ikke mærkeligt, at viden om Flash var lidt rusten. Derfor skulle der bruges mere energi på at forklare, hvordan man animerer i Flash end jeg havde forventet. I næste iteration vil jeg derfor tilføje afsnit om animation i Flash – og hvordan man arbejder med symbolerne library.

 

Efter frokostpausen kunne vi prøve at animere vores spritesheets. Der skulle kæmpes lidt med Coronakoden, der ikke opførte sig som forventet. Jeg havde en ide om at man kunne nøjes med koden i main.lua – og glemte at konfigurationsfilen var vigtig.

Her skal det siges at klassen var meget tålmodig. De kæmpede for at få koden til at virke. Det lykkedes ikke for alle; men jeg vil gætt på at ca. halvdelen fik liv i deres sprite.

Facebook efter lektionen

Derfor valgte jeg at give en antydning af en løsning på Facebook.

Eksemplet viser noget om blogs og sociale mediers styrke i undervisningen. Bloggen og dens kodeeksempler kan anvendes af de studerende efter at lektionen er afsluttet.