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:
- Í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.
- Í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.