Booyah! Etter 39 timer med omtrent konstant arbeid..

..er innlevering i boks! Jul nærmer seg, før nok en rekke med oppgaver følger (;

Prøv resultatet av case 1-6 her =D (Trykk F5 straks du er dævv)

Jepp, jeg er fullstendig klar over at dette innlegget kommer i siste liten før den endelige rapporten skal leveres inn! Heldigvis(?) har jeg ikke så alt for mye å si om Case #6.

Les hele casen her

Case #6 dreide seg om å lage en eller flere nye karakterer, som hadde i oppgave å kverke protagonisten. Kravene for denne fienden var at den skulle befinne seg i en seperat klasse, den skulle oppføre seg «intelligent» og statig bevege seg mot protagonisten, og til slutt skape en reaksjon i det den koliderte med protagonisten. I utgangspunktet var planen min å lage en svart klone av Gray som med 5 sekunders mellomrom klonet hver enkelt bevegelse spilleren gjennomførte (Inspirert av en identisk fiende i Rayman).

Rayman bædass!

Dette ble det ikke noe av, ettersom det å kopiere hver handling protagonisten utfører (vel og merke med et 5 sekunds intervall), viste seg å være en smule tidskrevende. Jeg bestemte meg derfor heller for å skape en fiende som kunne bevege seg uavhengig av omgivelsene! Ikke ulikt spøkelset på Sega’s Alex the Kid, som velger å hjemsøke deg for resten av nivået, straks du slipper det ut av den lille boksen det oppholder seg i.

Grays midlertidige nemesis har jeg valgt å kalle for en floater, enkelt å greit fordi den flyter over nivået, i håp om å sluke den stakkars protagonisten. Floateren tar form av et sort hull, som straks det får kontakt med spilleren, slenger ut fangarmer og imploderer med spilleren i sluket. Jeg ga floateren attributter som lar den akselerere i retning av karakteren, uavhengig av bakker og fjell. Med høy maksfart og lav friksjon, blir det alikevel vanskelig for floateren å fange spilleren, ettersom den fort kan ende opp med å gli et godt stykke unna før den får akselerert i riktig retning igjen. Et problem jeg støtte på underveis var situasjonen hvor spilleren møter på TO floaters samtidig. I dette tilfellet har de to lett for å ende opp på nøyaktig samme reise, ettersom de over tid tilpasser seg spillerens posisjon. Jeg prøvde diverse metoder for å hindre dette, deriblandt å gi hver floater en maksfart mellom 6-8, beregnet fra tilfeldighet. Men resultatene ble for tilfeldige; spillets vanskelighetsgrad ville på denne måten ende opp som ekstremt uforutsigbar! Jeg endte derimot opp med å gjøre noe så lett som å lage to ulike floaters: en med høy maksfart og den andre med lavere.

Straks jeg får levert inn rapporten, laster jeg opp resultatet, hvor floaters inkluderes (:

Case #5, gjennomført i frustrasjon, er ferdig! Etter å ha lest en god del om hittesting mot arrays(et array er en type oppbevaringsstruktur for data; i mitt tilfelle en haug av objekter), og oppsett av tile-baserte spill, har jeg endelig fullført selve «motoren» for spillet. Skal innrømme at jeg har hatt noen helt geniale moments hvor jeg enkelte ganger ikke forsto hva jeg selv hadde skrevet, men var fornøyd med resultatet. Andre timer endte kaffen i taket og jeg på gulvet. Alt i alt har det vært en både frustrerende, opplysende og lærerik arbeidsfase!

Slik ser nivået ut før det havner på skjermen

Til å begynne med hadde jeg som sagt planlagt å finne en metode for å skape min egen hittest-funksjon(hittesting er kort fortalt en kollisjonskontroll som ser om to objekter overlapper hverandre), ettersom jeg ville unngå å måtte kollidere mot hver eneste forbanna tile i hele spillet. «Planen» gikk ikke superbra, og jeg  endte heller opp med det dobbelte av det jeg ville unngå… hah!

Men! Det var for det beste. Takket være min mega-funky-dobbel-hitbokstestingsmetode skal resten av programmeringen nå være ganske kontrollerbar. En av mine største frustrasjoner under arbeidet var nemlig det at karakteren faktisk måtte TREFFE veggen for at hele situasjonen skulle bli registrert som en kollisjon. Deretter måtte figuren skyves ut av veggen igjen før noe annet kunne skje! I håp om å komme opp med en bedre type kollisjonstesting leste jeg på tidligerenevnte linker i håp  om å finne noe bedre. Her fikk jeg vite at det visstnok var ganske normalt å teste hvert enkelt hjørne av figuren mot objektet man skal kollidere med. Men etter flere håplese forsøk på å få dette til, ga jeg opp. I kommende timer ble jeg sittende i sofaen og stirret på skriptet i håp om en form for åpenbaring på hvordan problemet kunne løses. Og pow, plutselig fikk jeg en idé!

Kort fortalt gikk idéen ut på å oppdage veggen før karakteren treffer den. For å få dette til måtte jeg med andre ord hitteste med et annet objekt en karakteren. Prosessen foregår følgende:

1. En gjennomsiktig boks(mindre en karakteren), forflyttes fra karakterens utgangspunkt til karakterens neste destinasjon(bestemt av fart og retning).

2. Hvis boksen ikke kolliderer med noe, kan karakteren fint flyttes frem til objektets posisjon, og prosessen starter på ny.

3. Kolliderer boksen med veggen, flyttes boksen tilbake til karakterens posisjon og bevegelsesfarten settes til null.

I ekstase satte jeg idéen til verks, og endte opp med… mer irritasjon.  Joda, metoden fungerte ypperlig, men stadig nye problemer dukket opp. Det problemet som drepte mest av motivasjonen besto av at karakteren nektet å bevege seg helt inntil veggen i de tilfeller farten var høy. Dette var selvfølgelig fordi hitboksen kolliderte med veggen før karakteren hadde nådd helt bort, og stoppet dermed hele prosessen. Etter en dag eller to med mye kladding i paint kom jeg endelig frem til en funksjon som ordnet opp i dette! Ved å benytte meg av operatøren %(rest) som foreleser Dag Nylund forklarte oss under en forelesning, klarte jeg å forflytte karakteren helt bort til veggen, straks kollisjonen tok plass.

Noen av skissene fra arbeidet (inkludert er en fin tegning av Gisles bie-prosjekt)

Jeg prøvde også å bruke den samme boksen for å kollisjonsteste med både x- og y-akse. Resultatet var så skremmende at jeg aldri prøvde noe lignende i ettertid! Det som fungerte derimot, var å bruke en boks for hver akse; aka. mega-funky-dobbel-hitbokstestingsmetode! C;

Utgangspunktet for Case #5 var som jeg forsto det å beherske hittesting. Vi skulle i denne sammenheng også lage objekter som karakteren kunne plukke opp. Ettersom «motoren» så å si var ferdig, kunne jeg på samme måte som jeg la inn en veggtile(veggbrikke), legge inn en tile som inneholdt en gjenstand og deretter si at brikken skulle reagere ved kollisjon. Helt til slutt la jeg på en interface som lot meg stille på alle variabler mens flash-filen spilles av, slik at jeg slipper å gå inn i selvet scriptet hver gang jeg vil endre forholdene.

Resultatet så langt la jeg ut på newgrounds, for å se hvilke innstillinger folk flest foretrekker. Prøv det her! [:

Veldig kort om Case #5:

Nok en scripte-oppgave (: Oppgaven er flerdelt, og innebærer blandt annet bruk av Hit Test(nevnt i forrige innlegg), og å putte animasjonene i en sprite(en samling av karakterens animasjoner i ett symbol). Noe av oppgaven har jeg fått gjort, men har nylig lært at Hit Test vil vise seg som upraktisk om jeg jobber med tiles(grafiske objekter delt opp i en form for rutenett). Derfor prøver jeg nå å lære alt jeg kan om hvordan jeg kan skape min egen kollisjonstesting med tiles.

Her er et par av sidene jeg leser på for øyeblikket:
tbg.tonypa.pri.ee
active.tutsplus.com

Les hele casen her

Yeah! THE moment er her; vi har begynnt å lære Actionscript 3.0(programmeringsspråket brukt i Flash)!

I forbindelse med forelesningen, følger selvfølgelig en case av samme slag. Case #4 går ut på å ta i bruk tidligere grafikk og animasjon, og gi protagonisten noen enkle funksjoner. Kravene for oppgaven er følgende:

  • Karakteren skal kunne styres mot venstre.
  • Karakteren skal også kunne styres mot HØYRE!
  • Karakteren får ikke forlate skjermen.

Les hele casen her

Scriptet jeg brukte i forbindelse med den tidligere simulatoren er et eneste kaos, og vil i min mening ikke ha noen praktisk egenskap for de foreliggende oppgavene. Jeg har derfor startet med blanke ark, og prøvd å bygge opp scriptet fra starten av. Under arbeidet med oppgaven har jeg prøvd å sette meg inn i konseptet bak Hit Test-metoden. Etter å ha fått forklaringer fra flere kanter, både huskamerater og studieveiledere, føler jeg at jeg har fått en viss forståelse for hvordan metoden tas i bruk, men sliter fortsatt med å få stakkaren til å hoppe.

Oppdateringer siden simulator:

  • Foreløpig fjernet krash- og walk-animasjon, for å gjøre bevegelsene glattere.
  • Raskere akselerasjon, for en mer tilfredsstillende styring (kjedelig å vente to minutter før karakteren begynner å dra på beina).
  • Bruker Hit Test-metode fremfor å kontrollere mot X- og Y-akse som jeg gjorde tidligere. Dette er mer praktisk for senere arbeid.
  • Har lagt til en skli-animasjon for å skape variasjon i bildet.

Det endelige resultatet for case # 4 kan du se her(ved å trikse med høyre- og venstretast får du kanskje et glimt av glitch: en heftig moonwalk!)

Klokka er 06:21 og jeg har lyst på mat. Har jobbet i natt, samt en god dose de siste dagene, men til tross for dette er tredje og siste caseinnlevering før høstferie studieuke endelig ferdig!

Som tidligere nevnt, gikk Case #3 ut på å skape en sammenheng mellom historie og animasjon, gjennom tre scener. I alle disse skulle multilayer-metoden bli tatt i bruk. Multilayer-metoden innebærer at to eller flere lag skal beveges i ulik hastighet for å skape dybdeeffekt. Er utrolig glad for å ha lært om dette, ettersom det er superkult og skaper [10*antall layers\2] ganger så mye innlevelse!

Mine tre scener er smidd fra dysterhet. Triste blå fjell, ekkel mosegrønn grotte, mystisk lilla skog! Etter å ha spilt en god del platformspill innså jeg ut at dette virkelig er tre standard arenaer som gjentagelig skaper skumle vibrasjoner. Fant det noe vanskelig å integrere viktige milepæler i historien på tre scener, men tok utgangspunkt i starten av historien, hvor vår stakkarslige protagonist sørger over gudvethvem(dette blir det ikke gitt noe svar på i historien… foreløpig), og en tilfeldig hendelse midt i spillet, hvor Gray møter på en potensiell fiende(?).

Marshmellows?

Triste greier ):

Når det gjelder utfordringer, føler jeg at denne oppgaven var vanskelig og tidskrevende å gjennomføre. Å skape en realistisk og nøyaktig multilayer-effekt gjennom standard animering viste seg å være vanskeligere en jeg hadde  trodd. En fordel jeg tok meg nytte av, var å regne ut gå- og løpehastighet på forhånd. Etter å ha dette under kontroll skapte jeg og animerte laget protagonisten skulle gå på. Når hele sekvensen var ferdig, la jeg på lag for lag, fra lengst borte til fremst.

Tok også i bruk blur-effekt på alle lag og objekter for å gi mer fokus til hovedlaget, hvor Gray beveger seg(følte ofte enkelte av objektene kunne stjele for mye fokus). Dette hjalp også på å dybdeeffekten i multilayer metoden. Fikk idéen fra foredraget Tina hadde på multilayers. Takk :]

Se resultatet fra Case #3 her (helst mens du hører på litt dyster pianomusikk, innpakket i et ekkelt, gammelt teppe)

Nå er klokka 07:31 og jeg nyter soloppgangen i Hamars tåkedis… (Dette er intet håpløst forsøk på halvhjertet poesi! Rommet er bokstaveligtalt blusset opp i sjokkgul!)

I tredje case av dette prosjektarbeidet skal vi sette animasjon og historie inn i konteks. Målet for oppgaven er å skape tre sammenhengende scener, hvor det blir tatt i bruk flere lag med omgivelser.  Har så vidt startet på den ene scenen, men bestemte meg nettopp for å fullføre selve historien, samt spillets plott, før jeg fortsetter på selve casen.

Les hele casen her

I forbindelse med casen(og kjedsomhet), kjøpte jeg også Playdead’s Limbo, et platformspill med helt rå multilayerbruk!

Scene fra Playdeads platform-puzzle "Limbo"

Limbo – Mørkt, dystert, trist og supersweeeet!

Men på tide å gå inn i jedimodus og finpusse på story. Mer på Case #3 senere!