Hvordan jeg byggede mit projekt til en person: En skakmotor til en populær spiludviklingsmotor

Jeg er for nylig færdig med et af mine sommerprojekter: en skak-GUI-motor bygget med Ren'Py Visual Novel Game Development Engine og python-skakbiblioteket.

Denne motor vil blive integreret i et kinetisk roman-spil, The Wind at Dawn , når spillet er afsluttet.

I dette indlæg vil jeg gerne dele nogle vigtige læringer, tekniske og ikke-tekniske, som jeg samlede fra at skubbe dette enpersonsprojekt fra start til slut om en måned.

Værdsætter værdien af ​​at omskrive gammel kode

Til CS-projekter i skolen har jeg sjældent mulighed for eller oplever behovet for at revidere min kode.

Dette er dog ikke tilfældet, når jeg arbejder på mine passionprojekter: Jeg elsker at benytte enhver lejlighed til at forbedre deres brugervenlighed og genanvendelighed i håb om, at min kode vil være af værdi for andre udviklere.

Denne skakmotor er baseret på en skakmotor, jeg oprettede i Ren'Py og vanilje Python, mens jeg lærte mig selv Python i min første sommerferie på college.

Den gamle skakmotor er til gengæld baseret på et projekt i mit college Intro til CS-klasse (et skak-GUI-spil skrevet i Racket, et funktionelt programmeringssprog). Det vil sige, jeg har omskrevet min kode to gange for at producere denne sidste skakmotor.

Til min første omskrivning “oversatte jeg” skaklogikken (for at afgøre, om et træk er lovligt, slutspillets betingelser osv.) Fra Racket til Python. Jeg eksperimenterede også med objektorienteret programmering, skrev en minimax skak AI efter online tutorials og implementerede GUI i Ren'Py.

Da jeg kun kendte det grundlæggende i skak og skrev min skaklogik i henhold til min skoleprojekts klassificeringsspecifikationer, understøttede min første skakmotor ikke specielle træk som en passant, castling eller forfremmelse.

For at løse dette problem i min anden omskrivning undersøgte jeg open source Python-biblioteker og fandt python-skak, et bibliotek med fuld understøttelse af skakbevægelser og slutspilsforhold som at kræve uafgjort, når tredobbelt gentagelse opstår.

Derudover har den også integreret Stockfish, en skak AI, og denne integration vil gøre det muligt for min skakmotor at konfigurere styrken af ​​skak AI.

Disse to funktioner tilføjede stor værdi til min skakmotor version 2.0 og tillod mig at fokusere på de vigtigere aspekter af min omskrivning, som jeg vil beskrive nedenfor.

Læs dokumentationen og husk kompatibilitet

Det er blevet min vane at gennemse dokumentationen til de biblioteker, jeg har brug for til mit projekt, før jeg hopper ind i designet og koden. Dette hjælper mig med at evaluere ethvert problem med afhængighed og kompatibilitet, der måtte opstå.

Dette Ren'Py GitHub-problem peger på det faktum, at Ren'Py bruger Python 2 og endnu ikke er blevet porteret til Python 3. Så jeg erkendte, at jeg havde brug for en version af python-skak, der understøtter Python 2, som kun den nyeste version understøtter Python 3.7+.

Heldigvis understøtter version 0.23.10 både Python 2.7 og Python 3.4+. Jeg besluttede i sidste ende på version 0.23.11, da det er den sidste version, der stadig understøtter Python 2.7.

Efter at have sorteret efter afhængigheds- og kompatibilitetsproblemer var jeg klar til at gå videre til design og kodning.

Følg de bedste fremgangsmåder til softwareudvikling

Bemærk: Mange af de udtryk, der er nævnt i dette afsnit, er fra Agile / Scrum.

Saml funktionskrav til projektdesign

Selv om det er fristende at springe direkte ind i kodning, kan jeg ikke understrege nok vigtigheden af ​​design.

Tænk på design som en køreplan på højt niveau, der klart afgrænser projektets startpunkt, milepæle og slutpunkter. Dette lader udviklere henvise til, når de er talje dybe i indviklede detaljer om implementering.

Dette er især vigtigt for projekter uden for skolen, da de normalt ikke har en detaljeret, højteknisk specifikation, mens de fleste skoleprojekter har det.

For min skakmotor identificerede jeg følgende omskrivninger / yderligere funktioner:

  • Integrer skaklogikken fra python-skak
  • I min Ren'Py GUI-kode skal du erstatte skaklogikken og skak AI, jeg skrev med skaklogikken og Stockfish API'er fra python-skak
  • Understøtter forskellige gameplay-tilstande: Player vs. Player, Player vs. Computer (hvor Player kan vælge at spille som sort eller hvid), justerbar styrke af skak AI via justeringer af Stockfishs konfigurationsparametre
  • Udvikl en Ren'Py GUI til forfremmelse af bonde
  • Udvikle en Ren'Py GUI for at gøre krav på uafgjort i tilfælde af tredobbelt gentagelse eller reglen om halvtreds træk

Udvikle et bevis på konceptprototype

En bevis for koncept (POC) prototype hjælper mig med at måle den tid og kræfter, der er nødvendige for at implementere de krævede funktioner.

Til min skakmotor POC integrerede jeg python-skak med min originale Ren'Py GUI-kode. Jeg sørgede for, at dets sæt funktioner var minimum, men alligevel let udvideligt:

  • Jeg integrerede python-skak med min originale Ren'Py GUI-kode og var i stand til at flytte brikker rundt
  • Jeg implementerede kun Player vs. Player for at udskyde integrationen af ​​Stockfish til skak AI
  • Jeg tillod kun bevægelser, der ikke blev forfremmet, for at udsætte udviklingen af ​​GUI til forfremmelse af bonde

Identificer projektets definition af klar og definition af udført

Mit projekts Definition of Ready (DoR) følger naturligvis af min indledende undersøgelse af kompatibilitet med biblioteksversion og min POC.

Parallelt følger mit projekts Definition of Done (DoD) af funktionskravene, jeg identificerede fra min designfase.

Lever et minimum levedygtigt produkt, eller bedre endnu, et minimum elskeligt produkt

Da jeg var i designfasen for at indsamle krav, vidste jeg, at der var mange strækmål for mit projekt - måske endda mere end jeg nogensinde kunne opnå.

Så det var vigtigt for mig at implementere det meget basale sæt af nødvendige funktioner, levere et MVP (Minimum Viable Product) og indsamle feedback til at gentage det.

Bedre endnu, jeg vil gerne levere et Minimum Lovable Product (MLP) på min første iteration. Den lille forskel er, at mens en MVP kun kræver funktionelle funktioner, har en MLP en elskelig brugeroplevelse ved design.

For eksempel til at implementere bevægelsesbevægelser til en MVP kunne jeg bede brugerne om at trykke på forskellige taster for at vælge den stykke type, de vil promovere til (som B for biskop og K for ridder).

For en MLP ville jeg implementere en brugergrænseflade med stykke-formede knapper, der skifter farver, når de svæves eller vælges.

Vær din egen projektleder

Hvis du finder overvågning af listen over funktioner (plus den stadigt voksende liste over fejl og rettelser) overvældende, er du ikke alene. Det er tid til at være din egen projektleder.

Jeg fandt, at Trello var et fantastisk værktøj både til enkeltpersonprojekter og store teamprojekter.

Sådan organiserer jeg normalt mit Trello-kort til et kodningsprojekt:

Har fire lister: Backlog (for funktioner, der skal triages), TODO , Doing og Done.

Har farvekodede etiketter:

  • Klar til QA: Et rødt mærke for at få opmærksomhed fra mine holdkammerater
  • Effekt: lav (gul) versus høj (orange), bestemt af mængden af ​​påvirkning, en funktion eller en fejlrettelse vil generere. For eksempel har et let forkert justeret brugergrænseflade-panel lav effekt, hvor en deterministisk nedbrudt bug har stor indflydelse.
  • Et skøn over den tid, det tager at implementere: trivielt (<1 time, blågrøn), medium (1-2 timer, lyseblå) og vanskeligt (2-4 timer, mørkeblå).

    Min anden tommelfingerregel er, at hvis jeg skønner, at et kort vil tage mere end 4 timer at implementere, bør jeg sandsynligvis opdele det i flere finere kort.

  • Farve fungerer som en god visuel indikation: Jeg tackler altid kort med orange og blågrøn tags (høj indvirkning og lavt tidsforpligtelse), før jeg tackler dem med gule og vanskelige mærker (lav indvirkning men højtidsforpligtelse).

Skriv dokumentation og reflekter over din læring

Efter at have skubbet hvert eneste Trello-kort fra TODO til Doing to Done og løst hver ubehagelig fejl, er det endelig tid til at kalde et projekt færdigt? Ja og nej.

For at maksimere min læring fra et projekt finder jeg det umådeligt værd at reflektere over mine takeaways, tekniske eller bløde færdigheder:

  1. Skriv en klar, kortfattet README i GitHub-projektlageret. Dette hjælper andre udviklere med at forstå og blive interesseret i projektet.
  2. Skriv et blogindlæg (som det jeg skriver nu) om aspekterne på højere niveau, for eksempel arkitekturoversigt, funktionsdesign, udfordringer og løsninger osv.

Kreditter og links

Mange tak til Tim Min for at få mig til at arbejde på dette projekt, for hans bidrag (nye funktionsideer + QA) på Trello-tavlen og for at holde mig ansvarlig. Tim er forfatteren af ​​det kinetiske romanespil, The Wind at Dawn .

  • Min skakmotor GitHub repository
  • Det offentlige Trello-bord for dette skakmotorprojekt
  • Ren'Py: en visuel roman spiludviklingsmotor
  • python-skak: et rent Python-skakbibliotek

Lad os holde kontakten! Opret forbindelse til mig på LinkedIn, GitHub, Medium, eller tjek min personlige hjemmeside.