Koodikatselmointi

[ElectricShakuhachi]

Latasin koodin 12.12.2021 klo 20.21

1. Koodin laatu, rakenne, ym. :

• Luokkien / metodien / muuttujien ym. nimeäminen on projektissa erittäin selkeää.

• jotkin funktiot koodissa on mahdollista lyhentää jos ei käsiteltäisi jokaista suuntaa omana tapauksenaan vaan esimerkiksi mäpättäisiin jossakin että K_LEFT -suunta vastaa aina suhteellisia koordinaatteja (-CELL_SIZE, 0) jne ja sitten voitaisiin aina käydä kaikki suunnat läpi luupissa joka syöttää esm. funktiokutsulle aina ko. koordinaatit, sen sijaan että käytettäisiin neljää if-haarautumaa.

• Luokkien velvollisuuksien jaottelu on kurssilla kenties yksi vaikeimmista asioista, eikä sen toteutus tässä projektissa ollut missään nimessä huono, mutta joitakin mahdollisesti parannettavia asioita löytyy. esim. auttaisi ehkä jos olisi joku selkeä yksi user interface -luokka, joka omistaisi ja käsittelisi kaikki ui:ta toteuttavat alaluokat. Funktioiden velvollisuudet olivat pääosin selkeitä ja yksiselitteisiä.

• hakemistorakenne oli pääosin selkeä, mutta käyttöliittymää ei ollut jaoteltu omaksi hakemistoksi ja muutenkin suoraan src-hakemistosta löytyi tiedostoja, jotka liittyivät erinäisiin ohjelman osiin, jotka voisi olla selkeämmin hakemistoissa

• peliympäristöön ym. vaikuttavien variaabeleiden säilyttäminen omassa tiedostossaan oli kätevän oloista, koska muutoksia näihin voi sitten tehdä yhdessä paikassa. Voisi olla kätevää ohjelman muokattavuuden kannalta jos sinne pyrittäisiin siirtämään vielä enemmänkin kaikki sellainen konfiguraatio, johon voidaan ajatella tulevan muutoksia -> esimerkiksi vihollisten liikkumanopeus ym. muidenkin peliin liittyvien kellottimien pyörähdysnopeudet. Näin olisi todella nopea sitten pelikokemusta tweekatessa jos olisivat siellä nekin muokattavissa.

-Variaabeleiden suhtautuminen toisiinsa on myös tärkeä asia, niin että jotain muokatessa ei käy niin että täytyy koskea useisiin osaan koodeja. Tässä asiassa hyvää oli esm. että pelikartan (MAP) koko ja (CELL_SIZE) määrittävät toiset variaabelit, joiden mukaan ruudun koko renderöidään -> tällainen koheesio on hyvä asia. Yksi mihin sitä voisi lisätä, on se, että myös pelivihollisen kuvaa ladattaessa ei olisi kovakoodattu spriten kooksi (50, 50), vaan voisi käyttää tässäkin variaabelia CELL_SIZE. Näin jos pelin kokoa muutetaan muuttuisi automaattisesti mukana sitten vihollisten koko.

• Projektin testit oli toteutettu järkevästi ja vaatimuksia repositorion siisteyden osalta ym. oli seurattu hyvin.

2. Huomioita pelikokemuksesta ja siihen liittyvästä koodista:

• Peli olisi paljon mukavamman näköinen jos hahmot liikkuisivat liukumalla tasaisemmin eikä nykien paikasta seuraavaan, eli ne eivät liikkuisikaan yhtä CELL_SIZE:ä kerrallaan vaan tasaisesti, käytännössä siis liikutettavaa etäisyyttä pienennettäisiin huomattavasti ja sen liikuttamiseen liittyvää kellotusta nopeutettaisiin vastaavasti.

• Joskus hahmo ei tottele komentoja niin kuin luulisi. Tarkemmin sanoen, jokaista nuolinäppäintä on painettava erikseen toisen näppäimen vapauttamisen jälkeen, että liikkuminen tapahtuisi oletetusti. Tyypillisesti kuitenkin käyttäjä painaa uutta suuntaa siten että toisen napin vapauttaminen tapahtuu vasta tämän jälkeen. Toisen napin vapauttaminen aiheuttaa pygame.KEYUP -eventin, jonka takia toisella näppäimellä valittu liike pysähtyy, koska MainLoop -luokan _handle_events -metodissa on kirjoitettu liikkeen pysäyttäminen KEYUP:illa huolimatta siitä mille näppäimelle KEYUP -tapahtuu. Tämä voidaan korjata esimerkiksi testaamalla KEYUP-eventin käsittelykohdassa, onko KEYUPIN event.key sama kuin tämänhetkinen direction ja muuttamalla direction = None vain jos näin on. Kokeilin, ja se tuntui mukavoittavan pelikokemusta selkeästi.

3. Vaatimusmäärittelyyn ehdotuksia:

• Koska uusi käyttäjä voi tietämättään käyttää jo olemassaolevaa käyttäjätunnusta sekoittaen omat tuloksensa jo olemassaolevan toisen käyttäjän kanssa, olisi mielestäni hyvä lisätä kirjautumisnäkymään esimerkiksi varoitusviesti, jos käyttäjä on jo olemassa.

• Jos kurssin puitteissa saisi lisättyä jo jatkokehitysidoihin listatun toiminnallisuuden siitä, että pelissä olisi useita tasoja (eli peli loppuisikin aina vasta sitten kun pelaaja häviää ja tasot vaikeutuisivat jollain lailla), olisi pelin hauskuus välittömästi paljon korkeampi (ja kurssin kannalta mahdollisesti lisäpisteitä projektin laajuudesta). Tällöin olisi myös sqlite-tietokannan ja leaderboardin toiminnallisuuksien mielekkyys korkeampi, koska pisteillä ei olisi triviaalin helposti saavutettavaa ylärajaa. Tämän voisi toteuttaa nopeiten ehkä siten että aina nugettien loputtua luotaisiin vaikka vaan ihan samakin alkutilanne uudelleen ja lisättäisiin vihollisten määrää tms.

[JHNUL]

Kiitoksia hyvistä kommenteista, otinkin heti käyttöön tuon KEYUP-mäppäyksen senhetkiseen suuntaan.