Hogyan építettem fel egyszemélyes projektemet: Sakkmotor egy népszerű játékfejlesztő motorhoz

Nemrég fejeztem be egyik nyári projektemet: egy sakk GUI-motort, amelyet a Ren'Py Visual Novel Game Development Engine és a python-sakk könyvtár felhasználásával építettek.

Ezt a motort egy kinetikus regényjátékba, a Szél hajnalba integrálják a játék befejeztével.

Ebben a bejegyzésben néhány fontosabb technikai és nem műszaki tapasztalatot szeretnék megosztani, amelyeket azért gyűjtöttem össze, hogy ezt az egyszemélyes projektet egy hónap múlva az elejétől a végéig toltam.

Értékelje a régi kód átírásának értékét

Az iskolai CS projektek esetében ritkán van lehetőségem vagy tapasztalatom, hogy újra át kell néznem a kódomat.

Ez azonban nem így van, amikor szenvedélyprojektjeimmel dolgozom: szeretek minden lehetőséget megragadni azok használhatóságának és újrafelhasználhatóságának javításában, abban a reményben, hogy kódom értékes lesz más fejlesztők számára.

Ez a sakkmotor egy sakkmotorra épül, amelyet a Ren'Py és a vanília Pythonban hoztam létre, miközben az egyetemen tanítottam magam Pythonnak.

Ez a régi sakkmotor viszont a főiskolám egyik projektjén alapszik, a Bevezetés a CS osztályba (sakk GUI játék ütővel írva, funkcionális programozási nyelv). Vagyis kétszer is átírtam a kódomat, hogy elkészítsem ezt az utolsó sakkmotort.

Első átírásomhoz egyszerűen „lefordítottam” a sakklogikát (annak megállapítására, hogy egy lépés törvényes-e, végjátékfeltételek stb.) Racketről Pythonra. Kísérleteztem az objektumorientált programozással is, online oktatóanyagok után írtam egy minimumx sakk AI-t, és a GUI-t megvalósítottam a Ren'Py-ben.

Mivel csak a sakk alapjait ismertem, és az iskolai projekt osztályozási specifikációinak megfelelően írtam meg a sakk logikámat, az első sakkmotorom nem támogatott olyan speciális mozdulatokat, mint az en passant, a kastély vagy a promóció.

Ennek a kérdésnek a második átírása során a nyílt forráskódú Python könyvtárak után kutattam, és megtaláltam a python-sakkot, egy olyan könyvtárat, amely teljes mértékben támogatja a sakkmozgásokat és a végjátékfeltételeket, például háromszoros ismétlés esetén döntetlen igénylése.

Ráadásul a Stockfish-t, a sakk-AI-t is integrálta, és ez az integráció lehetővé teszi sakkmotorom számára, hogy konfigurálja a sakk-AI erősségét.

Ez a két funkció nagy értéket adott a sakkmotorom 2.0 verziójához, és lehetővé tette, hogy az átírásom fontosabb szempontjaira összpontosítsak, amelyeket az alábbiakban ismertetek.

Olvassa el a Dokumentációt és tartsa szem előtt a kompatibilitást

Szokássá vált, hogy áttekintem a projektemhez szükséges könyvtárak dokumentációját, mielőtt belevágnék a tervbe és a kódba. Ez segít számomra a felmerülő problémák függőséggel és kompatibilitással.

Ez a Ren'Py GitHub kérdés arra mutat, hogy a Ren'Py Python 2-t használ, és még nem került át a Python 3-ba. Tehát felismertem, hogy a Python 2-t támogató python-sakk verzióra van szükségem, mivel csak a legújabb verzió támogatja a Python 3.7+ verziót.

Szerencsére a 0.23.10 verzió támogatja a Python 2.7 és a Python 3.4+ verziókat is. Végül rátértem a 0.23.11 verzióra, mivel ez az utolsó verzió, amely még mindig támogatja a Python 2.7-et.

A függőségi és kompatibilitási problémák rendezése után készen állok a tervezés és a kódolás folytatására.

Kövesse a szoftvertervezéssel kapcsolatos legjobb gyakorlatokat

Megjegyzés: Ebben a szakaszban sok kifejezés az Agile / Scrum szóból származik.

Gyűjtse össze a projekttervezéssel kapcsolatos követelményeket

Bár csábító egyenesen a kódolásba ugrani, nem tudom eléggé hangsúlyozni a tervezés fontosságát.

Gondoljon a tervezésre, mint olyan magas szintű ütemtervre, amely egyértelműen meghatározza a projekt kiindulópontját, mérföldköveit és végpontjait. Ez lehetővé teszi a fejlesztők számára, hogy mikor derékig érik a bonyolult megvalósítási részleteket.

Ez különösen fontos a tanórán kívüli projektek esetében, mivel általában nincsenek részletes, magas technikai jellemzőik, míg az iskolai projektek többsége igen.

Sakkmotoromhoz a következő átírásokat / kiegészítő szolgáltatásokat azonosítottam:

  • Integrálja a sakk logikát a python-sakkból
  • A Ren'Py GUI kódomban cserélje ki az általam írt sakk logikát és a sakk AI-t a sakk logikára és a Stockfish API-kra a python-sakkból
  • Támogatja a különböző játékmódokat: Játékos vs Játékos, Játékos vs Számítógép (ahol a Játékos választhatja a fekete vagy fehér játékot), a sakk AI erőssége állítható a Stockfish konfigurációs paramétereinek beállításain keresztül
  • Készítsen egy Ren'Py GUI-t a gyalog promócióhoz
  • Készítsen egy Ren'Py grafikus felhasználói felületet a döntetlen igényléséhez háromszoros ismétlés vagy az ötven lépés szabály esetén

Készítsen egy igazolást a koncepció prototípusáról

A Proof of Concept (POC) prototípus segít felmérni a szükséges funkciók megvalósításához szükséges időt és erőfeszítést.

Sakkmotorom POC-jához integráltam a python-sakkot az eredeti Ren'Py GUI kódommal. Gondoskodtam arról, hogy a szolgáltatáskészlete minimális, de könnyen bővíthető legyen:

  • Integráltam a python-sakkot az eredeti Ren'Py GUI kódommal, és képes voltam darabokat mozgatni
  • Csak azért hajtottam végre a Player vs Player -t, hogy elhalasszam a Stockfish integrálását a sakk AI-re
  • Csak a nem promóciós lépéseket engedélyeztem, hogy elhalasztjam a gyalog promóció GUI fejlesztését

Határozza meg a projekt kész és definíció definícióját

A projektem definíciója a készségről (DoR) természetesen a könyvtári verziók kompatibilitására és a POC-ra vonatkozó első vizsgálatomból származik.

Ezzel párhuzamosan a projektem definíciója Kész (DoD) következik a tervezési fázisban azonosított jellemzők követelményeiből.

Szállítson minimálisan életképes terméket, vagy ami még jobb, minimálisan mozgatható terméket

Amikor a tervezési szakaszban összegyűjtöttem a követelményeket, tudtam, hogy a projektemnek nagyon sok nyújtható célja van - talán még több is, mint amit valaha is teljesíteni tudnék.

Fontos volt tehát számomra a szükséges funkciók alapvető készletének megvalósítása, egy Minimum életképes termék (MVP) kézbesítése és visszajelzések gyűjtése az ismétléshez.

Még jobb, ha az első iteráción szeretnék egy minimálisan rögzíthető terméket (MLP) szállítani. A percbeli különbség az, hogy míg egy MVP-nek semmi másra nincs szüksége, mint funkcionális jellemzőkre, az MLP-nek a kialakítása során szerethető felhasználói élménye van.

Például a gyalog promóciós lépések végrehajtásához egy MVP számára megkérhetném a felhasználókat, hogy különböző gombok megnyomásával választhassák ki azt a darabtípust, amelyiknek el akarnak lépni (például B püspöknek és K lovagnak).

Az MLP-hez olyan darabos típusú gombokkal rendelkező felhasználói felületet valósítanék meg, amely lebegve vagy kijelölve megváltoztatja a színét.

Legyen saját projektmenedzsere

Ha elsöprőnek tartja a funkciók listájának (pl. Az egyre növekvő hibák és javítások listájának) nyomon követését, akkor nem vagy egyedül. Itt az ideje, hogy saját projektmenedzser legyél.

A Trellót csodálatos eszköznek találtam mind az egyszemélyes, mind a nagy csapatú projekteknél.

Általában így szervezem a Trello táblámat egy kódolási projekthez:

Már négy lista: Backlog (a funkciókat kell osztályozzák), TODO , avagy , és a Kész.

Színkóddal ellátott címkék:

  • Készen áll a minőségbiztosításra: piros címke a csapattársaim figyelmének felkeltésére
  • Hatás: alacsony (sárga) és magas (narancssárga), amelyet egy jellemző vagy egy hibajavítás generál. Például egy kissé rosszul illesztett felhasználói felület panel alacsony hatású, ahol egy determinisztikusan összeomló hiba nagy hatású.
  • Becslés a megvalósításhoz szükséges időre: triviális (<1 óra, kékeszöld), közepes (1-2 óra, világoskék) és nehéz (2–4 óra, sötétkék).

    A másik ökölszabályom, hogy ha úgy gondolom, hogy egy kártya megvalósítása több mint 4 órát vesz igénybe, akkor valószínűleg több finomabb részű kártyára kell bontanom.

  • A szín remek vizuális jelként szolgál: mindig a narancssárga és a kékeszöld címkékkel ellátott kártyákat (nagy hatású és alacsony időigényű) kezelem, mielőtt a sárga és nehéz címkékkel (alacsony hatású, de nagy időre szóló elkötelezettséggel) foglalkoznék.

Írjon dokumentációt és gondolkodjon el a tanulásról

Miután minden egyes Trello kártyát eltolt a TODO-tól a Doing to Done-ig és kijavított minden csúnya hibát, végre eljött az ideje, hogy elkészültnek nevezzen egy projektet? Igen és nem.

Annak érdekében, hogy maximalizálhassam a projektben szerzett tanulásomat, rendkívül értékesnek tartom, hogy átgondoljam az elvihetőségeket, a technikai vagy a belső készségeket:

  1. Írjon világos, tömör README-t a GitHub projekt tárházába. Ez segít más fejlesztőknek megérteni és érdeklődni a projekt iránt.
  2. Írjon egy blogbejegyzést (mint amit most írok) a magasabb szintű szempontokról, például az architektúra áttekintéséről, a funkciók tervezéséről, a kihívásokról és a megoldásokról stb.

Hitelek és linkek

Nagyon köszönöm Tim Minnek, aki arra késztetett, hogy dolgozzak ezen a projekten, a Trello fórumon végzett közreműködéséért (új funkció ötletek + minőségbiztosítás) és felelősségre vonásáért. Tim a kinetikus regényjáték, a Szél hajnalban írója .

  • Sakkmotorom GitHub adattáram
  • A nyilvános Trello tábla ehhez a sakkmotor-projekthez
  • Ren'Py: Visual Novel Game Development Engine
  • python-sakk: tiszta Python sakk könyvtár

Maradjunk kapcsolatban! Vegye fel a kapcsolatot velem a LinkedIn, a GitHub, a Medium webhelyen, vagy nézze meg a személyes webhelyemet.