At programmere simple retrospil er noget af en kæmpe udfordring - også for voksne!
Det starter med at være simpelt, men lige pludselig bliver avanceret.
Mens du programmerer vil du lave masser af fejl og du vil også blive frustreret. Hvorfor virker det ikke????
Selv programmører opdager fejl hele tiden. Det kan ikke lade sig gøre at programmere uden at lave fejl!
Her er 6 koderåd der kan hjælpe dig til komme i mål med din gode idé!
Start med den mest simple udgave af dit spil, så de vigtigste ting virker. Når det er på plads kan du udbygge dit program!
Det er oftest styring, kollision og variabler. Lad være med at fokusere på sværhedsgrad, levels og ekstra liv. Mangler du grafikken i starten, så bare brug noget fra biblioteket eller tegn et par streger i editoren. Skift grafikken senere. Du skal satse alt på, at få lavet en simpel "prototype" af dit spil der virker. Pyt med hvordan det ser ud og om det er kedeligt at spille.
Lad være med at hænge dig i små detaljer, før du har fået det grundlæggende til at virke. Når først det virker, kan du udbygge og forfine dit program.
Alt for mange når aldrig at blive færdig med deres projekt, fordi de har hængt sig i små detaljer frem for at starte med en helt simpel version, der trods alt virker.
Så snart du/I har lavet noget nyt i programmet der virker, skal der deles en backup af projektet i gruppen inden man går videre. Kodeprojektet er et fælles projekt alle i gruppen samarbejder om. Det dur IKKE bare at fordele arbejdet, så der er nogen i gruppen, der ikke programmerer.
Væn dig til at arbejde trin-for-trin. Kig på din kode et skridt af gangen, fra toppen og ned - og sørg for du altid forstår og kan forklare alle trin i koden!
Kør dit program efter hvert trin og tjek om det virker. Gå ikke videre med noget nyt før det gør!
Følg vejledninger et trin ad gangen. Lad være med at springe trin over.
Når du programmerer skal du arbejde sekventielt - det er et andet ord for at arbejde "trin-for-trin". Det er en måde at arbejde systematisk og analytisk på som er utrolig vigtig når man programmere.
Trin-for-trin tilgangen gælder mange steder:
NÅR DU FØLGER VEJLEDNINGER
...så lad være med at springe i rækkefølgen. Hvis du vil lave et Dungeon spil fra Masterclass under træningslejren, så lad være med at springe til det sidste eksempel. Følg og forstå eksemplerne i rækkefølge, da de bygger oven på hinanden. Ellers ryger forståelsen.
NÅR DU PROGRAMMERER
...så tag små skridt - og for hvert skridt du tager skal du teste at det virker. Hvad er det næste der skal ske i programmet? Et lille skridt ad gangen - test hele tiden - gem som ny kopi når det virker.
NÅR DU FINDER FEJL/DEBUGGER!
... så del din kode op i små dele/skridt. Skil f.eks. blokkene ad og saml det igen. Hvor er fejlen? Hav helt styr på hver enkelt lille skridt i koden. Først sker det, så det osv. osv. Indsæt f.eks. nogle "Sig" blokke, for at se om koden kører som den skal. Du kan også indsætte pauser.
NÅR DU SKAL FORKLARE KODE,
... for dig selv eller andre, så prøv at forklare koden "sekventielt". Først sker det, så det, hvis der sker så sker det osv. osv.. Fra toppen og ned. Er der noget du ikke kan forklare? Så må du få styr på det!
Det er ok at "stjæle" kodestykker, små scripts og ideer fra andres programmer. Bare du selv forstår koden!
Men lad være med at "remixe" eller arbejde videre i en kopi af et stort færdigt projekt du finder på Scratch. Det er dømt til at gå galt, fordi det nærmest er umuligt at sætte sig ind i en masse kode andre har skrevet!
Lav dit eget program - trin for trin, et lille skridt af gangen og få hver del til at virke før du går videre til næste. Hug alt det kode du vil - bare du selv forstår hvad du laver! Der er ingen genveje, når det handler om at forstå koden.
Selv om det er fristende bare at remixe/kopiere et helt projekt og skifte grafikken, så gør dig selv den tjeneste at lade være. Når man programmerer kan det ikke betale sig at være doven. Tværtimod. Jo mere du selv forstår af det du laver, des lettere og hurtigere bliver det at finde fejl og udvikle nye ting.
Inspiration, kodeeksempler og forklaringer finder du masser af her i Scratch Træningslejren.
STOP hvis du ikke kan forklare dit program. Hvis du ikke selv forstår din egen kode, har du ikke en chance. Løb din kode igennem trin for trin og forklar med dine egne ord hvad der sker.
Hvis der er noget du ikke kan forklare eller noget der ikke virker, så skil blokkene fra hinanden. Undersøg det. Saml det igen. Trin-for-trin. Find ud hvad der sker og hvorfor. Spørg andre.
En af fordelene ved at programmere er, at man kan teste sit program hele tiden. Virker det eller virker det ikke?
At finde fejl kræver, at man gør noget aktivt selv.
Skiller koden ad. Indsætter noget nyt. Samler den igen. Snakker med nogen. Eksperimenterer. Laver det forfra - på en ny måde? Laver noget helt andet eller mere simpelt. Man gør noget - og man giver ikke op.
Væn dig til at teste så ofte som muligt. Vær opmærksom på at udvikle gode måder til at teste:
... om du kan være sikker på, at det virker som det skal?
... HVORFOR noget ikke virker som det skal?
Hvis du ikke forstår hvorfor det ikke virker - så prøv at gøre noget, så du kan finde ud af hvor fejlen er.
"Sig i 2 sekunder" eller "vent i sekunder" er gode blokke til test og fejlsøgning. Med flere "vent i sekunder" blokke kan du sænke tempoet på din kode så du kan følge med 'trin-for-trin' hvad der sker og med sig blokken "Sig i 2 sekunder" kan du få dine sprites til at "sige" hvad de gør eller registrere om et kollisionsscript overhovedet kører?
Det kan også være en god idé at skille koden ad. Samle den igen. Kigge på eksemplerne i vejledningerne igen. Kigge på scripts der minder om det du vil lave. Hvad har du mon overset? Hvad kan årsagen være til det ikke virker? Hvordan kan du teste det???
Nogle gange hjælper det, at lave den del der ikke virker forfra igen. Eller lave det på en helt ny måde. Eller komme videre og lave noget helt andet i stedet for.
Bygger du videre på et program der ikke virker, går det helt sikkert galt!
Lav derfor kun en lille del af gangen og test med det samme. Gem kopier af det der virker og lad være med at lave nyt før dit program virker som det skal.