Talk:TikTokTek: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Tkruglov (talk | contribs)
Created page with "Projekti analüüsi retsenseerib OnTime, Tatjana Kruglova."
 
Pploom (talk | contribs)
No edit summary
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
Projekti analüüsi retsenseerib OnTime, Tatjana Kruglova.
=Retsensioon projekti analüüsile=
Koostanud: [[OnTime]]
 
 
==Sissejuhatus==
Rakenduse ideeks on laialdaselt levinud mäng, mis oma kirjeldusega paelub juba nii mõnegi kasutaja. Rakenduse analüüsist saab välja lugeda mängude variatsioone ning ka mängu põhimõtted uutele kasutajatele. Analüüs on väga sisurikas ning kirjeldab kõiki mängu aspekte. Lisaks klassikalise mängu realisatsioonile on juurde plaanitud ka omapoolsed laiendused.
 
==Märkmed ja omapoolsed soovitused==
Rakenduse analüüsis on välja toodud neli erinevat mängu variatsiooni, mida kasutaja saab mängu alustades valida. Samas jääb ebaselgeks mõningate mängu tüüpide erinevused, näiteks Renju, Gomoku ja Gobang, kas need on kõik üks ja sama mäng ning on lihtsalt mängu nimetamisel välja toodud selgituseks või need on samuti mängu variatsioonid? Pente puhul on hästi väljatoodud, et selle puhul on erinevuseks mängulaua suurus.
 
Menüüde ülesehitus on põhjalikult läbi mõeldud ning ülesehitatud. Kahjuks aga pole lähemalt seletatud mis andmed ning mis viisil salvestatakse andmebaasi. Kindlasti tuleb mõelda andmebaasi ehituse peale ning juhul kui realiseeritakse ka üle võrgu mängimise mis viisil plaanitakse mänguandmeid edasi-tagasi edastada.
 
Samuti võib keeruliseks osutuda terve "quality-of-life" funktsionaalsuse realiseerimine ning võimalike sätete variatsioonide testimine. Siinpuhul tuleks endale ning kasutajatele põhjalikumalt lahti kirjutada, mis on need eriparameetrid, mida lubatakse kasutaja poolt muuta ja mis viisil. Näiteks kui lasta kasutajal valida isa endale laua suurus, siis pigem võiks kasutajale pakkumises olla vähene hulk staatilisi väärtusi, mitte lasta kasutajal ise numbreid kusagile väljale sisestada.
Lisaks tuleks läbi mõelda, kuidas hinnatakse selliseid parameetreid nagu intuitiivne, hõlbus, utilitaarne vs seksikas. Kas on plaanis viia läbi kasutajamugavuse hindamine mõningate kasutajate uuringute näol?
 
Väga hästi on arvestatud võimalike probleemi allikaid ning hinnatud tiimi oskusi. Ning keerulisemad ning ajamahukamad osad on ilusasti jäetud "Nice to have" funktsionaalsuse alla.
 
==Kokkuvõte==
Klassikalise kaasahaarava mängu arendus omapoolsete täiendustega. Mängu sisu on põhjalikult lahti kirjutatud ning võimalikud mängu funktsionaalsused on kasutajale võimalikult arusaadavaks tehtud. Soovitaksin tiimil lisaks mõelda läbi andmete edastuse ning salvestuse ning samuti ka sättete muutmise/lisamise võimalused. Arendamisel peaksid kõigil tiimiliikmetel olema ühine arusaam sellest, mida arendatakse, mistõttu peaks kõik punktid võimalikult selgelt välja kirjutatud olema.
 
=Retsensioon lõpptootele=
Koostanud: [[FoodCab]]
 
Projekti tutvustuse ning analüüsi põhjal on tegu väga huvitava ja palju erinevaid võimalusi pakkuva mänguga. On selge, et projekti arendusega tekkis probleeme. Lõpptoode valmis vähendatud koosseisus ning paljude kompromissidega, sest esialgsest must have funktsionaalsusest on implementeeritud ainult põhiosa, see tähendab ühte mängustiili üksikmängus arvuti vastu ning mitmikmängus teise inimese vastu sama seadmega.
 
Hinnates olemasolevat, siis töötab mäng korralikult ja on mängitav. Üksikmängus arvuti vastu on algoritmi valitud käigud sageli küsitavad. Näiteks jätab AI kasutamata võimalusi viienda nupu ritta seadmiseks isegi siis, kui mänguväljal on mitu 4 nupulist rida. Selle saab lahendada lihtsa muudatusega AIPlayer.cs failis ridadel  36 ja 38:
 
for (int rowOffsetSign = -1; rowOffsetSign <= 1; rowOffsetSign += 3)
 
Samas võib seda lugeda ka lihtsa raskusastme tunnusjooneks. Ilmselt algoritmi tõttu on ka arvuti vastu mängus mänguvälja tagasiside mitmikmänguga võrreldes aeglasem. See kõik mõistetav, sest mängualgoritm tundubki antud rakenduse üks keerulisematest osadest olevat.
 
Positiivsena võib välja tuua mitmikmängu, mis toimib veatult ja kiirelt ning on samuti mängitav.
 
Koodi üldise osa kohta võib puudusena nimetada vähest MVVM kasutamist, kus vaatemudel on keskne element.

Latest revision as of 23:59, 1 February 2017

Retsensioon projekti analüüsile

Koostanud: OnTime


Sissejuhatus

Rakenduse ideeks on laialdaselt levinud mäng, mis oma kirjeldusega paelub juba nii mõnegi kasutaja. Rakenduse analüüsist saab välja lugeda mängude variatsioone ning ka mängu põhimõtted uutele kasutajatele. Analüüs on väga sisurikas ning kirjeldab kõiki mängu aspekte. Lisaks klassikalise mängu realisatsioonile on juurde plaanitud ka omapoolsed laiendused.

Märkmed ja omapoolsed soovitused

Rakenduse analüüsis on välja toodud neli erinevat mängu variatsiooni, mida kasutaja saab mängu alustades valida. Samas jääb ebaselgeks mõningate mängu tüüpide erinevused, näiteks Renju, Gomoku ja Gobang, kas need on kõik üks ja sama mäng ning on lihtsalt mängu nimetamisel välja toodud selgituseks või need on samuti mängu variatsioonid? Pente puhul on hästi väljatoodud, et selle puhul on erinevuseks mängulaua suurus.

Menüüde ülesehitus on põhjalikult läbi mõeldud ning ülesehitatud. Kahjuks aga pole lähemalt seletatud mis andmed ning mis viisil salvestatakse andmebaasi. Kindlasti tuleb mõelda andmebaasi ehituse peale ning juhul kui realiseeritakse ka üle võrgu mängimise mis viisil plaanitakse mänguandmeid edasi-tagasi edastada.

Samuti võib keeruliseks osutuda terve "quality-of-life" funktsionaalsuse realiseerimine ning võimalike sätete variatsioonide testimine. Siinpuhul tuleks endale ning kasutajatele põhjalikumalt lahti kirjutada, mis on need eriparameetrid, mida lubatakse kasutaja poolt muuta ja mis viisil. Näiteks kui lasta kasutajal valida isa endale laua suurus, siis pigem võiks kasutajale pakkumises olla vähene hulk staatilisi väärtusi, mitte lasta kasutajal ise numbreid kusagile väljale sisestada. Lisaks tuleks läbi mõelda, kuidas hinnatakse selliseid parameetreid nagu intuitiivne, hõlbus, utilitaarne vs seksikas. Kas on plaanis viia läbi kasutajamugavuse hindamine mõningate kasutajate uuringute näol?

Väga hästi on arvestatud võimalike probleemi allikaid ning hinnatud tiimi oskusi. Ning keerulisemad ning ajamahukamad osad on ilusasti jäetud "Nice to have" funktsionaalsuse alla.

Kokkuvõte

Klassikalise kaasahaarava mängu arendus omapoolsete täiendustega. Mängu sisu on põhjalikult lahti kirjutatud ning võimalikud mängu funktsionaalsused on kasutajale võimalikult arusaadavaks tehtud. Soovitaksin tiimil lisaks mõelda läbi andmete edastuse ning salvestuse ning samuti ka sättete muutmise/lisamise võimalused. Arendamisel peaksid kõigil tiimiliikmetel olema ühine arusaam sellest, mida arendatakse, mistõttu peaks kõik punktid võimalikult selgelt välja kirjutatud olema.

Retsensioon lõpptootele

Koostanud: FoodCab

Projekti tutvustuse ning analüüsi põhjal on tegu väga huvitava ja palju erinevaid võimalusi pakkuva mänguga. On selge, et projekti arendusega tekkis probleeme. Lõpptoode valmis vähendatud koosseisus ning paljude kompromissidega, sest esialgsest must have funktsionaalsusest on implementeeritud ainult põhiosa, see tähendab ühte mängustiili üksikmängus arvuti vastu ning mitmikmängus teise inimese vastu sama seadmega.

Hinnates olemasolevat, siis töötab mäng korralikult ja on mängitav. Üksikmängus arvuti vastu on algoritmi valitud käigud sageli küsitavad. Näiteks jätab AI kasutamata võimalusi viienda nupu ritta seadmiseks isegi siis, kui mänguväljal on mitu 4 nupulist rida. Selle saab lahendada lihtsa muudatusega AIPlayer.cs failis ridadel 36 ja 38:

for (int rowOffsetSign = -1; rowOffsetSign <= 1; rowOffsetSign += 3)

Samas võib seda lugeda ka lihtsa raskusastme tunnusjooneks. Ilmselt algoritmi tõttu on ka arvuti vastu mängus mänguvälja tagasiside mitmikmänguga võrreldes aeglasem. See kõik mõistetav, sest mängualgoritm tundubki antud rakenduse üks keerulisematest osadest olevat.

Positiivsena võib välja tuua mitmikmängu, mis toimib veatult ja kiirelt ning on samuti mängitav.

Koodi üldise osa kohta võib puudusena nimetada vähest MVVM kasutamist, kus vaatemudel on keskne element.