Huvudinnehåll
Course: Dataprogrammering > Enhet 1
Lektion 17: Att bli en bättre programmerarePlanera ett programmeringsprojekt
Att bli programmerare handlar inte bara om att lära sig syntaxen och begreppen för ett programmeringsspråk: det handlar också om att lista ut hur man använder den kunskapen för att skapa program. Vi har gjort en massa program i den här kursen, i utmaningarna och projekten, men nu är det dags för dig hitta på egna idéer för nya program - idéer som du själv verkligen tycker skulle vara kul - och försöka att göra de idéerna till riktiga program .
Du kan antagligen inte allt som behövs för ditt program när du påbörjar det, och det är helt okej - du kommer att vara motiverad att lära dig de nya sakerna eftersom du kommer vilja skapa ditt eget program på riktigt. Programmerare lär sig ständigt nya saker för nya projekt, och det är en del av varför vi älskar programmerandet så mycket.
Vi går stegvis igenom planerandet av ett programprojekt:
1 . Vad vill du göra?
När jag började programmera, kom jag hela tiden på nya program att bygga och skrev alltid ner dem på en lista. Jag var överförtjust i att kunna skapa nytt, och det var så väldigt mycket min hjärna ville göra. Om du känner likadant så har du förmodligen redan en uppfattning om vad du vill göra, och kanske har du redan en egen lista.
Om du inte redan har en idé, har vi här några frågor som hjälper din brainstorming:
- Vad är ditt favoritspel - arkadspel, brädspel, sportspel? Kan du göra en förenklad digital version av det? Kan du ändra det lite, som att ge det ett annat tema eller andra huvudpersoner?
- Vad är gillar du mer? Om du gillar konst, kan du göra ett konstprogram? Om du gillar historia, kanske en interaktiv tidslinje vore något? Om du gillar vetenskap, vad sägs om en vetenskaplig simulering?
- Vilken är din favoritfilm eller tv-serie? Kan du göra en digital version av en scen eller en karaktär från den? Kanske ett spel baserat på den?
- Finns det någon pryl eller uppfinning du gillar? Kan du göra en simulering av den?
När du väl har valt en idé bör du skriva en beskrivning av den. Om jag t.ex. bestämde mig för att göra en klon av "Breakout", det är mitt favorit-retro-arkadspel, kanske jag skriver:
Breakout: ett spel där man styr en bricka längst ner på skärmen, och man använder den för att studsa en boll uppåt och i vinklar för att förstöra klossar. Målet är att förstöra alla klossar och inte låta bollen nå marken för många gånger.
Du ska förfina beskrivningen senare, men för tillfället ger det dig en bra utgångspunkt för resten av planeringsarbetet.
2 . Vilken teknik kommer du att använda?
I det här steget måste du överväga om du ska använda den teknik (språk / bibliotek / miljöer) du är bekant med sedan tidigare eller enkelt kan lära dig och vilka av dem som passar bäst för jobbet. För många är listan ett objekt långt, "1 . JS + ProcessingJS", och det gör beslutet enkelt.
Vår JS + ProcessingJS miljö fungerar bra för att göra animeringar, spel, visualiseringar och simuleringar. Kolla bara på gemenskapsprogram för att se det breda utbudet av program som alla gör här.
Vår miljö fungerar inte för andra saker som multiplayer-spel, mobilappar eller tung data-bearbetning. Om du känner till andra språk/miljöer (som JS + HTML, Python, SCRATCH, Swift, etc.) och du tänker bygga något som inte funkar så bra med ProcessingJS, fundera då på vilken av dessa tekniker som bäst passar för ditt program. Om du vill bygga något i den här stilen men inte kan teknikerna, så kanske du komma på en ny programidé. Du kan lära dig en ny teknik för ett nytt projekt, men om du just börjat programmera är det en bra idé att bli riktigt bra på ditt första språk först.
Om jag bestämde mig för att göra ett spel som Breakout, skulle jag välja JS + ProcessingJS, eftersom jag redan kan den tekniken och den fungerar dessutom bra för 2D-spel.
3 . Vilka funktioner kommer programmet att ha?
Nu kommer vi in i den riktiga planeringen, och här (tror jag) börjar det roliga. Målet i detta steg är att ta reda på vad du faktiskt ska bygga - hur kommer programmet se ut, vilka features det kommer innehålla, vilka features kommer det inte innehålla .
Det första du kan göra är "mock-ups" - skisser som ser ut som det du vill bygga, men utan detaljer som färg eller exakta dimensioner. Du kan göra mock-ups på papper eller med online-program:
För att ge dig en uppfattning om hur mock-ups kan se ut, har jag lagt till mockups till min Breakout-klon. Jag skissade varje scen separat och ritade pilar mellan dem för att visa hur en scen leder till en annan. Pilarna hjälper mig att förstå vilken logik jag behöver i mitt program för att gå mellan de olika tillstånden i programmet.
Nu kan du använda mock-upsen som underlag för att skapa en featurelista, där du tänker tänker genom vilka features ditt program behöver och skriver ned dem.
För min Breakout-klon kan det här vara min featurelista, uppdelad efter
de olika scenerna:
Spelscen
- Användarstyrd paddel
- Brickor i olika färger
- Vinkla bollens rörelse
- Kollisionsdetektering
- Panel som visar liv
- Panel som visar poäng
- Ljudeffekter
Huvudscen
- Spelaknapp
- Hjälpknapp
Hjälpbild
- Text
- Tillbaka-knapp
Vinst scen
- Rubrik
- Fyrverkeri-animering
Förlustscen
- Text
- Starta-om-knapp
4 . Men vilka funktioner (features) måste vi ha?
Om vi hade oändligt med tid att skapa alla program vi har i huvudet, så skulle de allihopa inkludera alla features i vår lista. Men det har vi inte, så i det här steget måste du bestämma vilka features som är viktigast och vilka features du bara gör om du har tid. Det kommer att hjälpa dig att räkna ut i vilken ordning du ska implementera dina features i, från mest till minst viktiga.
För att hjälpa dig att räkna ut hur viktig varje feature är, fråga dig själv de här frågorna:
- Om jag delade det med en kompis, vilka features skulle jag vilja vara säker på fungerade?
- Vilka features tycker jag är roligast att bygga?
- Vilka features är mest speciella för mitt program?
- Vilka features lär jag mig mest av att implementera?
- Finns det några features som verkar vara för svåra att bygga med tanke på vad jag lärt mig såhär långt?
Gå sedan igenom din featurelista som du har nu och sortera den eller lägg till siffra som visar hur viktig varje feature är.
För min Breakout-klons featurelista har jag satt "P1", "P2" och "P3" bredvid funktionerna, vilket visar högsta prioritet (P1), mellanprioritet (P2) och lägsta prioritet (P3). Jag bestämde mig för att prioritera den unika spelmekaniken över allmänna spelfunktioner som scener, för jag tycker att det är mest spännande i projektet:
(P1) Spelplats
- (P1) Användarstyrd paddel
- (P1) Flerfärgade brickor
- (P1) Vinkla bollens rörelse
- (P1) Kollisionsdetektering
- (P2) Panel för liv
- (P2) Panel för poäng
- (P3) Ljudeffekter
(P2) Huvudscen
- (P2) Spelaknapp
- (P3) Hjälpknapp
(P3) Hjälpbild
- (P3) Text
- (P3) Bakåtknapp
(P2) Segerscen
- (P2) Rubrik
- (P3) Fyrverkeri animering
(P2) Förlorarscen
- (P2) Text
- (P3) Starta om knapp
Som ett generellt tips för dig som bygger spel, här är några features som jag rekommenderar att nedprioritera: menyer, flera nivåer, 3D-grafik. Fokusera på vad som är unikt och roligt med ditt spel, lägg sedan till extrafunktionerna.
Du kan också förvandla din prioriterade lista till projektversioner, så att du enkelt kan se vad du behöver implementera i varje version, och du kan alltid stanna efter en viss version och vara nöjd med det du har gjort.
Så här ser versionerna ut för min Breakout-klon:
V1
- Användarstyrd paddel
- Flerfärgade brickor
- Vinkla bollens rörelse
- Kollisionsdetektering
V2
- Panel för liv
- Panel för poäng
- Starta scen / spela-knapp
- Vinnarscen med rubrik
V3
- Ljudeffekter
- Hjälpknapp
- Fyrverkerier
- Förlora scen w / Starta om knappen
5 . Hur ska du implementera det?
Nu har du en uppfattning om vilka features du ska bygga först i ditt program - men om du börjar nu kommer du få stirra på ett helt tomt program utan någon kod skriven, vilket kan vara skrämmande. Vilka variabler ska du skriva först? Vilka funktioner?
Ett sätt som du kan räkna ut det på är genom att tänka på "hög-nivå-arkitekturen" i ditt program - bryta den in i kategorier som "objekt", "logik", "användar-interaktion", "användardata" och "scener" - och Tänk sedan på hur du kan implementera dem, som objektorienterade objekttyper, funktioner eller variabler.
Till exempel, här är en arkitektur för min Breakout klon:
Objekt
Brick(.isHit())Paddle(.move())Ball(.move())
Scener
- Start
- Spel
- Slut
Logik
- Boll-bricka-kollision (
funktion, använd avgränsningsbox) - Paddel-Boll-Vinkling (
funktion, inverterad vinkel)
Användarinteraktion
- Tangentbord-paddel-styrning (
keyPressed) - Knappar för scenändringar (
mouseClicked)
Användardata
- Missade bollar (
array) - Boll träffar (
array)
När du väl har tänkt på arkitekturen på hög nivå bör det bli tydligare vad som är enklast att börja koda.
Du kanske bestämmer dig för att skriva hela ditt program i pseudokod först, vilket vi pratar om senare i denna genomgång. I grund och botten skulle det innebära att hela programmet skrivs i vanlig svensk(nåja "svengelsk" kanske) text i kommentarer och sedan sakta allteftersom byta ut kommentarerna mot kod.
6 . Vad är din tidslinje?
Hur mycket tid har du på dig att bygga programmet? Hur många veckor och hur mycket tid varje dag? Vilka funktioner skriver du varje vecka? Ditt mål i detta steg är att räkna ut en tidslinje för ditt projekt - vilket är särskilt viktigt om du har en deadline men är också användbart så du börjar se hur mycket tid det tar att skriva ett program.
Här är en tidslinje för min Breakout-klon, med 2-4 timmars arbete varje vecka:
- Vecka 1: Design och pseudo-kod
- Vecka 2: Det grundläggande visuella
- Vecka 3: Boll som rör sig / kollisionsmekanik
- Vecka 4: Poäng och liv mekanik
- Vecka 5: Motiv (Start / vinna / förlora)
- Vecka 6 : Finjusteringar, manuella tester (QA), förberedelser för demo
Att räkna ut tidslinjer för programprojekt är svårt. Några saker som verkar lätta tar längre tid än vad man förväntar sig (som en konstig bugg som dyker upp och tar timmar att felsöka), vissa saker som verkar svåra tar mindre tid än man förväntar sig. Som en allmän regel kan man anta att det att längre tid än man tror, och man får justera planeringen allteftersom.
Är du redo!?
Förhoppningsvis ger detta dig en uppfattning om hur planeringen av ett programprojekt går till och inspirerar dig att starta ett projekt nu. Beroende på vad du vill bygga kanske du också bestämmer dig för att gå igenom andra kurser först, som Avancerad JS: Spel och visualiseringar eller Avancerad JS: Naturliga simuleringar, för att få fler idéer om vad eller hur du ska bygga.
Det viktiga är att se till att du börjar skapa egna program på något vis, för det är då du lär dig mest, och också då du får mest nöje av programmeringen, eftersom du gör dina idéer, tankar och drömmar till verklighet.
