Din angrebsplan
Hvis du udvikler for en kunde, skal du få en stram specifikation. Jeg anbefaler generelt ikke dette til webapps, som ofte nyder godt af organiske forbedringer, men et spil har brug for et sæt klart definerede regler, som er etableret før produktionen påbegyndes. Beslutninger om, hvordan man scorer, hvad der udgør et korrekt svar, og hvordan man indsamler data er grundlæggende for kodestruktur, så få dem skrevet ned og underskrevet (og jo kortere deadline du har, jo vigtigere er dette er).
Programmering af spil er helt anderledes end at udvikle standard webapplikationer, hvoraf de fleste består af flere skærme, visning af information eller beder om input, der kan oprettes på forhånd i Flash Builders træk-og-slip GUI og gemt som MXML synspunkter.
Programmering af spil er helt anderledes end at udvikle standard webapplikationer
Spil vil sandsynligvis være langt mere dynamiske, så jeg genererer de fleste af deres visuelle elementer fra kode i stedet for via træk og slip. Ved at placere sådanne elementer inde i containere såsom lodrette kasser (VBox), horisontale kasser (HBox) eller lærreder er det muligt at skabe, vise, skjule eller ødelægge dem i farten. Hold hele tiden dit spils design i dit hoved, eller tegn endda wireframe guides – Flash Builder er lidt klodset håndtering af udstillingsobjekter er ofte en hindring, men slutresultatet bliver dynamisk, fleksibelt og læne.
Version 4 af Flex SDK introducerede "Spark"-komponenter sammen med "Halo"-sættet. Spark-komponenter har næsten ingen standardstyling og blev skabt af Adobe for at komme væk fra standardudseendet og -følelsen af så mange Flex-apps. Det lyder måske som en god idé, men er det?
Ifølge Adobe var mindre end halvdelen af alle Flex-applikationer blevet "drastisk flået", hvilket det ser ud til er en dårlig ting, men jeg er ikke så sikker - trods alt deler Windows-applikationer alle et fælles udseende baseret på det underliggende .NET rammer. Du kan altid genkende en Flex-applikation inden for millisekunder efter den starter, men det generer mig ikke, så Spark er en løsning på et ikke-eksisterende problem.
Endnu værre er det, at Spark tager længere tid at bygge en applikation, fordi du er tvunget til at skinke hver komponent på ny, mens du med Halo kan ændre et eksisterende skin. Hvad mere er, betyder huller i Spark-implementeringen, at det er umuligt at udvikle en kompleks RIA uden at bruge nogle Halo-komponenter under alle omstændigheder.
Flex 4 SDK føles derfor som en midlertidig udgivelse, der forhåbentlig vil blive forbedret og afsluttet med den næste version. Med en deadline på kun et par uger valgte jeg at bruge Halo, og faktisk falde tilbage på 3.5 SDK for at gøre det endelige spil kompatibelt med Flash Player 9+.
Jeg baserede spillets design på selve atlasset ved at bruge lignende skrifttyper, farver og designelementer for at give den slags konsistens, der forstærker branding. Fireworks er mit foretrukne billedredigeringsprogram, og ved fornuftig brug af lag og gruppering var det let nok at isolere grafikken, så de kunne eksporteres separat til inkorporering i de forskellige containere i Flash Builder. For eksempel indlæses den generelle baggrund ved opstart, men kortbeholderen, kortdata, statustavler og spilgrafik indlæses dynamisk. Dette gør det langt nemmere at skabe nye versioner af spillet uden omfattende omkodning.
