Meeskond:Rods: Difference between revisions
(26 intermediate revisions by 2 users not shown) | |||
Line 114: | Line 114: | ||
==Koosolek II== | |||
Osalejad Den ja Oliver(Raini ja Stenniga eelnevalt põhipunktid üle käidud) | |||
===Analüüs=== | |||
Analüüs projektile Rods v.0.0.1 | |||
====Analüüs rakendusele==== | |||
'''Mis see endas sisaldab?''' | |||
Rakendus sisaldab endas ülevalt vaates 2D mängu. Mängus on peategelane rebane(esmakursuslane), kes soovib hakata õppima Eesti Infotehnoloogia Kolledžis. Mäng sisaldab traditsioonilisi elemente: menüüd, baasfunktsionaalsuse tutvustus(tutorial), süžee, maailmades ringi liikumine, ülesannete/eesmärgi täitmine jne. | |||
Põhiline eesmärk mängu arenduses on kasutada erinevaid arendusmustreid ja õppida tundma nende plusse ja miinuseid. Suur rõhk enne arendust läheb erinevate olemasolevate mustrite tudeerimisele. Sellele on pühendatud ka meeskonna Wikis eraldi peatükk, kus on tehtud lühidad kokkuvõtted erinevate mustrite kohta. Materjalide valik põhineb Bob Nystromi kirjutatud online-raamatul. Valik langes sellele materjalile, sest raamat kirjutatud spetsiifiliselt mänguarenduse mustrite jaoks. Nystrom on töötanud mänguarendusfirmas 'Electronic Arts' üle kaheksa aasta. Ta on tutvunud paljude erinevate mustritega nii teoreetiliselt, kui ka väga praktilistes olukordades. Sellest tulenevalt oskab ta lisaks nende mustrite üldisele tutvustusele jagada ka mänguarendusmaailma parimaid harjumusi('best practice'). Samuti toob ta ülipraktilisi näiteid. | |||
Tehnoloogilise osa pealt sisaldab rakendus traditsioonilisi lähenemisi. Nimelt mänguarendusesks kasutatakse tarkvara Unity 3D. Versioonihalduseks kasutab meeskond Team Foundation Server(Visual Studio Online). Programmeerimis keel on C#. Unity 3D kasutab sisemiselt MonoDevelop IDE'd C# arenduseks. Audio töötlemiseks kasutatakse vabavara Audacity. Graafika ja disaini arendus toimub ilmselt lihtsamates graafikatöötlustarkvaras nagu näiteks MS Paint, Paint.NET, Adobe PS või GIMP. Projekti juhtimise, -arengu ja dokumentatsiooni leiab meeskonna Wiki lehelt: https://wiki.itcollege.ee/index.php/Meeskond:Rods | |||
'''Mis on selle eesmärk?''' | |||
Populariseerida Eesti Infotehnoloogia Kolledžit! | |||
Rakenduse eesmärk on luua lõbus ja meeldiv(!) mäng. Mäng peab looma kasutajale hea mulje Eesti Infotehnoloogia Kolledžist. Kindlasti peavad elemendid olema kuvatud läbi eluterve huumoriprisma, samas kooli mitte halvustavalt. | |||
Põhiline eesmärk on asendada või lihtsustada sellist tutvustavat loengut nagu tuutoritund. Tutvustades mängijale EIK'i esimest semestrit. Alateadlikult õpitakse ka selgeks kooli põhiplaan(klasside asukohad jne), kuna mängu kaart vastab peaaegu 1:1'le kooli ehitusega. | |||
Lahendust pakuks see mäng ka inimestele, kes ei jõua lahtiste uste päevadele või mõnele muule Eesti Infotehnoloogia Kolledžit propageerivale üritusele. Läbi mängu saab kasutaja peamise informatsiooni kooli võimalustest ja olemusest. | |||
'''Mida tavakasutaja sellega teha saaks?''' | |||
Tavakasutaja saab ringi liikuda koolimajas. Suur rõhk mängu läbimisel on ka esimeste ainetega seotud ülesannete lahendamisel. Võimalik on ennast kurssi viia koolis toimuvaga. | |||
'''Milliste osade realiseerimine võib osutuda problemaatiliseks?''' | |||
*Ülesanded - saab olema raske täide viia, kuna iga aine vajab personaalset lähenemist. Ainetel on omad punktiarvestused ja ülesandetüübid. | |||
*Salvestamine - pole eelnevalt teinud. | |||
*Tutorial - kuidas teha kasutajale meeldivaks ehk kuidas vältida tuima teksti. | |||
*Huvigrupid - ei ole välja mõeldud lahendust probleemile. Vajab huvigruppide koostööd. | |||
*ÜE & üritused - keeruline teostada. | |||
*Aineid sissejuhatavad audio failid - õppejõududega koostöö + audio failidega töötamine. | |||
'''Algne tööjaotus''' | |||
*S - Mängu logo, bänner jne. | |||
'''Must have(tähtsuse järjekorras)''' | |||
*Peategelase ringi liikumine | |||
*Tausta kuvamine | |||
*Taustade(korruste) vaheline liikumine(trepp) | |||
*Võimalus minna neljadale ja regada ennast üliõpilaseks | |||
*Õppeainete ülesanded(suur tükk) | |||
*Salvestamine | |||
*Punktiarvestus (lihtsalt loeme mitu ülesannet tehtud on) | |||
*Menüüd | |||
'''Nice to have''' | |||
*Achviments | |||
*Lisa kohad, kus käia(suitsunurk, kohvik, WC) | |||
*Kõrvalülesanded | |||
*Lift | |||
*Tutorial | |||
*Oravad | |||
*Huvigrupid(LUG, MUG, Võrk!, Koss!, Meedia, Robootika) | |||
*ÜE | |||
*Infopunkt(TUX, kes vastab küsimustele[KKK]) | |||
*Tudengibaar | |||
*Rebastepidu(?) | |||
*Aineid tutvustavad audio failid lisada, kursuse algusesse. | |||
*Õppejõudel paluda sisse lugeda max 1min sissejuhatav jutt nende kursuse kohta: | |||
**Minu ainesse tulles peab rebane oskama... | |||
**Minu ainet lõpetades oskab tudeng... | |||
**Minuga töötamisel peab tudeng arvestama, et...(mida õppejõud sallib/ei salli, teeb omapärast) | |||
*-täiendub- | |||
//Analüüs sai valmis 29.10, aga jäi postitamata, sest leidsime, et eelmine aasta oli täide viidud täpselt samasugune idee. Projekti edasi saatus läheb arutlusse õppejõuda 31.10 | |||
==Arendusmustrid== | ==Arendusmustrid== | ||
===Command=== | Loeme mustreid ja kirjutame kokkuvõtteid, et teaksime, mida oma mängus kasutada. | ||
Mustrid on võetud leheküljelt: www.gameprogrammingpatterns.com | |||
Mustri nime taga olev täht viitab meeskonna liikmele, kes seda mustrit luges ja kokkuvõtet kirjutas. | |||
===Tuntud mustrid=== | |||
Siin on välja toodud põhilised mustrid raamatust "Design Patterns: Elements of Reusable Object-Oriented Software" - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. | |||
====Command(R)==== | |||
Saab kasutada lugemaks kasutaja poolt sisestatut (nupuvajutused) | Saab kasutada lugemaks kasutaja poolt sisestatut (nupuvajutused) | ||
Line 134: | Line 232: | ||
- allows the parameterization of clients with different requests | - allows the parameterization of clients with different requests | ||
- allows saving the requests in a queue | - allows saving the requests in a queue | ||
Undo and redo actions | Undo and redo actions | ||
Line 140: | Line 237: | ||
http://sourcemaking.com/design_patterns/command/c-sharp-dot-net | http://sourcemaking.com/design_patterns/command/c-sharp-dot-net | ||
===Flyweight=== | ====Flyweight(R)==== | ||
- hea kasutada graafika kujutamiseks kus on väga palju objekte, nagu näiteks mets, sest mets sisaldab sadu eraldiseisvaid osakesi (puid) ja terve metsa korraga kuvamine on liiga suur koormus graafikakaardile. | - hea kasutada graafika kujutamiseks kus on väga palju objekte, nagu näiteks mets, sest mets sisaldab sadu eraldiseisvaid osakesi (puid) ja terve metsa korraga kuvamine on liiga suur koormus graafikakaardile. | ||
- andmed objektide kohta jagatakse kaheks: esimene osa on ühine kõigile.. näiteks puudele (tekstuur, geomeetria), teine osa käib iga puu kohta eraldi (jämedus, värv jne) | - andmed objektide kohta jagatakse kaheks: esimene osa on ühine kõigile.. näiteks puudele (tekstuur, geomeetria), teine osa käib iga puu kohta eraldi (jämedus, värv jne) | ||
- kasutab enumeid | - kasutab enumeid | ||
- kasutab switch/case | - kasutab switch/case | ||
- mõeldud rohkem „heavy graphics“ mängude jaoks | - mõeldud rohkem „heavy graphics“ mängude jaoks | ||
http://en.wikipedia.org/wiki/Flyweight_pattern | http://en.wikipedia.org/wiki/Flyweight_pattern | ||
===Observer=== | ====Observer(R)==== | ||
- üks enimkasutatavaid mustreid | |||
- achievement unlocked näide: | |||
Kontrollime millal toimub meid huvitav sündmus: sillalt alla kukkumine. Selleks ei tuleks teha eraldi meetodit "unlockFalloffBridge()" vaid erinevad aspektid mängus väljendavad sündmusi. | |||
Näiteks: meil on meetod mis tegeleb füüsikaga (keha kukkumine nt.) siis kui see meetod tuvastab keha kiire liikumise (kukkumise), saadab välja sellekohase teate (füüsika meetodit ei huvita, kas keegi loeb seda teadet või mitte): “Uh, I don’t know if anyone cares, but this thing just fell. Do with that as you will.” | |||
Antud juhul võtab selle teate vastu achievement süsteem, mis kontrollib kas kukkuv keha oli peategelane ja kas see oli sild kust ta alla kukkus. | |||
Siin näites ei pidanud füüsikaga tegelev kood achievementidega tegelema üldse, saatis ainult teate välja. Niimoodi on lihtne achievement süsteemi muuta või üldse eemaldada, ilma, et füüsika meetodit tuleks muuta. Selles näites on achievement süsteem "observer" | |||
switch (event) { | |||
case EVENT_ENTITY_FELL: | |||
if (entity.isHero() && heroIsOnBridge_) { | |||
unlock(ACHIEVEMENT_FELL_OFF_BRIDGE); | |||
Antud muster nõuab palju klasse | |||
Muster on „heavyweight“ | |||
Lihtne ja töötab | |||
====Prototype(D)==== | |||
Väga hea sarnaste objektide varieerimiseks. | |||
Defineerid ühe alus objekti e. prototüübi ja varieerivatel objektidel delegeerid nad protüübini. | |||
Hea koodi näide: | |||
{ | |||
"name": "goblin grunt", | |||
"minHealth": 20, | |||
"maxHealth": 30, | |||
"resists": ["cold", "poison"], | |||
"weaknesses": ["fire", "light"] | |||
} | |||
{ | |||
"name": "goblin wizard", | |||
"prototype": "goblin grunt", | |||
"spells": ["fire ball", "lightning bolt"] | |||
} | |||
{ | |||
"name": "goblin archer", | |||
"prototype": "goblin grunt", | |||
"attacks": ["short bow"] | |||
} | |||
Samas, kui alternatiiv(vale) oleks kaks viimast objekti nii defineerida: | |||
{ | |||
"name": "goblin wizard", | |||
"minHealth": 20, | |||
"maxHealth": 30, | |||
"resists": ["cold", "poison"], | |||
"weaknesses": ["fire", "light"], | |||
"spells": ["fire ball", "lightning bolt"] | |||
} | |||
{ | |||
"name": "goblin archer", | |||
"minHealth": 20, | |||
"maxHealth": 30, | |||
"resists": ["cold", "poison"], | |||
"weaknesses": ["fire", "light"], | |||
"attacks": ["short bow"] | |||
} | |||
See the difference huh? | |||
====Singleton(D)==== | |||
Pointless. | |||
Omab kahte põhilist eesmärki: omada teatud klassist ainult ühte eksemplari & globaalsed muutujad, millele saab kõikjalt ligi. | |||
Mõlemat põhimõtet annab hõlpsasti asendada alternatiividega. Asendama peaks, sest Singeltonil on palju probleeme. | |||
Ühte eksemplari saab tagada näiteks ühe booliga "käivitatud". | |||
Vältimaks globaalseid muutujaid ja hoida ühe muutuja skoopi võimalikult väiksena saab kasutada mitmeid alternatiive, nt. get'ers jne. | |||
====State(D)==== | |||
==Prototüüp== | |||
Hetkel on prototüüp olemas ainult Unity projektina. Projekt on pakitud .zip failiks ja laetud ülesse. | |||
Link: http://www.upload.ee/files/4385641/kool.zip.html | |||
Nautimust ! | |||
==Lõpptoode== | |||
Lõpptoode .exe failina. | |||
Link: http://www.upload.ee/files/4472357/lopptoode.zip.html | |||
Go nuts! |
Latest revision as of 14:05, 19 January 2015
Rods
Meeskonna liikmed
- Rain Mäsak
- Oliver Armväärt (Osales ACM ICPC ja IEEEXTREME 8.0 programmeerimise võistlusel)
- Den-Daniel Dobrus - Projekti juht (Osales ACM ICPC ja IEEEXTREME 8.0 programmeerimise võistlusel)
- Sten Saliste (Osales ACM ICPC ja IEEEXTREME 8.0 programmeerimise võistlusel)
Projekti idee
Teha 2D mäng kasutades Unityt.
Mängu idee on teha rebastele selgeks kooli plaan ja üldine toimimine esimese semestri jooksul.
To-do
- Teha
- Tegemisel
- Tehtud
Idee [25.10.2014]
- DONE - Idee kirja panna
- DONE - Mängutüüp
- DONE - Baasfunktsionaalsus
- DONE - Mänguidee
- DONE - Esmane tööjaotus
- //Lükkub edasi 'Analüüsi' faasi// Valida välja õiged arendusmustrid (materjal: Game programming patterns)
- Töötada läbi erinevad mustrid
- Leida plusse ja miinuseid
- Valida sobivaimad mustrid
- Põhjendada valikuid
- DONE - Seadistada üles TFS
- DONE - Teha selgeks
- DONE - Kõik meeskonnaliikmed ühendada
- DONE - Õppejõud ühendada
Analüüs [01.11.2014]
- Rakenduse eesmärk
- Mida tavakasutaja sellega teha saab
- Problemaatilised kohad realiseerimisel
- Tööjaotus
- Nimekiri funktsionaalsusest - must have
- Nimekiri funktsionaalsusest - nice to have
Retsensioon[8.11.2014]
Koosolekud
I
Kõik kohal.
Rods v.0.0.1 Nimi tuleb arenduse käigus
2D - Pealtvaade, Unity, C#, TFS, MonoDevelop
Mänguidee:
- Mängu idee on teha rebastele selgeks kooli plaan ja üldine toimimine esimese semestri jooksul.
Baasfunktsionaalsus:
- Ringi liikumine
- Ülesannete lahendamine
- Maailmade(korruste) vahetamine
- Menüü, pausmenüü jne
- Punktiarvestus
- Achivments
- Auto salvestamine peale edukat sooritamist
Ained ja ülesanded:
- Java(Pöidla dialoog) - Nii, paar ülesannet.
- Füüsika(hahahaha) - Jukul on kahe kilone pomm, arvuta päikese mass.. eiei Jukul on kolme kilone pomm. Kas Juku ema oli brünett või blond? Panna haigelt raske ülesanne sinna vms.
- ITSPEA - Esimene viktoriin
- Matemaatiline analüüs - Kas käia kontsultatsioonis jne minigame'idega
- Makro - SKP arvutamise valem
- Sissejuhatus informaatikasse - Kes oli Turing
- Erialatutvustus - Vali välja IT firma.
Esmane tööjaotus
- Andmebaasid ja Unity - sõbraks - Sten 24.10
- Unity ja TFS + siis kõik liikmed TFSi - Oliver 24.10
- Arendusmustrid - Rain & Den - 24.10
Märksõnad, mis käisid läbi:
Kooli mäng , saad korruseid vahetada , siseneda klassidesse , lahendada ülesandeid , suitsetada , WC asukohad , söömine , pesemine , kapid , garderoob , akvaarium , lift , trepid , vending machine , küsimuse puhul saad pöörduda tuutor Tuxi poole, kes kooli peal ringi patseerib , Tux-mail ja ajaga tundidesse jõudmine , "Theres a cookie for you in the cafeteera" , "Theres a smart physics guy in the smoking area. Go find him!" , seda võib veel kasutada.
Koosolek II
Osalejad Den ja Oliver(Raini ja Stenniga eelnevalt põhipunktid üle käidud)
Analüüs
Analüüs projektile Rods v.0.0.1
Analüüs rakendusele
Mis see endas sisaldab?
Rakendus sisaldab endas ülevalt vaates 2D mängu. Mängus on peategelane rebane(esmakursuslane), kes soovib hakata õppima Eesti Infotehnoloogia Kolledžis. Mäng sisaldab traditsioonilisi elemente: menüüd, baasfunktsionaalsuse tutvustus(tutorial), süžee, maailmades ringi liikumine, ülesannete/eesmärgi täitmine jne.
Põhiline eesmärk mängu arenduses on kasutada erinevaid arendusmustreid ja õppida tundma nende plusse ja miinuseid. Suur rõhk enne arendust läheb erinevate olemasolevate mustrite tudeerimisele. Sellele on pühendatud ka meeskonna Wikis eraldi peatükk, kus on tehtud lühidad kokkuvõtted erinevate mustrite kohta. Materjalide valik põhineb Bob Nystromi kirjutatud online-raamatul. Valik langes sellele materjalile, sest raamat kirjutatud spetsiifiliselt mänguarenduse mustrite jaoks. Nystrom on töötanud mänguarendusfirmas 'Electronic Arts' üle kaheksa aasta. Ta on tutvunud paljude erinevate mustritega nii teoreetiliselt, kui ka väga praktilistes olukordades. Sellest tulenevalt oskab ta lisaks nende mustrite üldisele tutvustusele jagada ka mänguarendusmaailma parimaid harjumusi('best practice'). Samuti toob ta ülipraktilisi näiteid.
Tehnoloogilise osa pealt sisaldab rakendus traditsioonilisi lähenemisi. Nimelt mänguarendusesks kasutatakse tarkvara Unity 3D. Versioonihalduseks kasutab meeskond Team Foundation Server(Visual Studio Online). Programmeerimis keel on C#. Unity 3D kasutab sisemiselt MonoDevelop IDE'd C# arenduseks. Audio töötlemiseks kasutatakse vabavara Audacity. Graafika ja disaini arendus toimub ilmselt lihtsamates graafikatöötlustarkvaras nagu näiteks MS Paint, Paint.NET, Adobe PS või GIMP. Projekti juhtimise, -arengu ja dokumentatsiooni leiab meeskonna Wiki lehelt: https://wiki.itcollege.ee/index.php/Meeskond:Rods
Mis on selle eesmärk?
Populariseerida Eesti Infotehnoloogia Kolledžit!
Rakenduse eesmärk on luua lõbus ja meeldiv(!) mäng. Mäng peab looma kasutajale hea mulje Eesti Infotehnoloogia Kolledžist. Kindlasti peavad elemendid olema kuvatud läbi eluterve huumoriprisma, samas kooli mitte halvustavalt.
Põhiline eesmärk on asendada või lihtsustada sellist tutvustavat loengut nagu tuutoritund. Tutvustades mängijale EIK'i esimest semestrit. Alateadlikult õpitakse ka selgeks kooli põhiplaan(klasside asukohad jne), kuna mängu kaart vastab peaaegu 1:1'le kooli ehitusega.
Lahendust pakuks see mäng ka inimestele, kes ei jõua lahtiste uste päevadele või mõnele muule Eesti Infotehnoloogia Kolledžit propageerivale üritusele. Läbi mängu saab kasutaja peamise informatsiooni kooli võimalustest ja olemusest.
Mida tavakasutaja sellega teha saaks?
Tavakasutaja saab ringi liikuda koolimajas. Suur rõhk mängu läbimisel on ka esimeste ainetega seotud ülesannete lahendamisel. Võimalik on ennast kurssi viia koolis toimuvaga.
Milliste osade realiseerimine võib osutuda problemaatiliseks?
- Ülesanded - saab olema raske täide viia, kuna iga aine vajab personaalset lähenemist. Ainetel on omad punktiarvestused ja ülesandetüübid.
- Salvestamine - pole eelnevalt teinud.
- Tutorial - kuidas teha kasutajale meeldivaks ehk kuidas vältida tuima teksti.
- Huvigrupid - ei ole välja mõeldud lahendust probleemile. Vajab huvigruppide koostööd.
- ÜE & üritused - keeruline teostada.
- Aineid sissejuhatavad audio failid - õppejõududega koostöö + audio failidega töötamine.
Algne tööjaotus
- S - Mängu logo, bänner jne.
Must have(tähtsuse järjekorras)
- Peategelase ringi liikumine
- Tausta kuvamine
- Taustade(korruste) vaheline liikumine(trepp)
- Võimalus minna neljadale ja regada ennast üliõpilaseks
- Õppeainete ülesanded(suur tükk)
- Salvestamine
- Punktiarvestus (lihtsalt loeme mitu ülesannet tehtud on)
- Menüüd
Nice to have
- Achviments
- Lisa kohad, kus käia(suitsunurk, kohvik, WC)
- Kõrvalülesanded
- Lift
- Tutorial
- Oravad
- Huvigrupid(LUG, MUG, Võrk!, Koss!, Meedia, Robootika)
- ÜE
- Infopunkt(TUX, kes vastab küsimustele[KKK])
- Tudengibaar
- Rebastepidu(?)
- Aineid tutvustavad audio failid lisada, kursuse algusesse.
- Õppejõudel paluda sisse lugeda max 1min sissejuhatav jutt nende kursuse kohta:
- Minu ainesse tulles peab rebane oskama...
- Minu ainet lõpetades oskab tudeng...
- Minuga töötamisel peab tudeng arvestama, et...(mida õppejõud sallib/ei salli, teeb omapärast)
- -täiendub-
//Analüüs sai valmis 29.10, aga jäi postitamata, sest leidsime, et eelmine aasta oli täide viidud täpselt samasugune idee. Projekti edasi saatus läheb arutlusse õppejõuda 31.10
Arendusmustrid
Loeme mustreid ja kirjutame kokkuvõtteid, et teaksime, mida oma mängus kasutada.
Mustrid on võetud leheküljelt: www.gameprogrammingpatterns.com
Mustri nime taga olev täht viitab meeskonna liikmele, kes seda mustrit luges ja kokkuvõtet kirjutas.
Tuntud mustrid
Siin on välja toodud põhilised mustrid raamatust "Design Patterns: Elements of Reusable Object-Oriented Software" - by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Command(R)
Saab kasutada lugemaks kasutaja poolt sisestatut (nupuvajutused)
void InputHandler::handleInput() { if (isPressed(BUTTON_X)) jump(); else if (isPressed(BUTTON_Y)) fireGun(); else if (isPressed(BUTTON_A)) swapWeapon(); else if (isPressed(BUTTON_B)) lurchIneffectively(); }
Võimaldab lasta kasutajal muuta nuppude funktsiooni
- encapsulate a request in an object
- allows the parameterization of clients with different requests
- allows saving the requests in a queue
Undo and redo actions
http://sourcemaking.com/design_patterns/command/c-sharp-dot-net
Flyweight(R)
- hea kasutada graafika kujutamiseks kus on väga palju objekte, nagu näiteks mets, sest mets sisaldab sadu eraldiseisvaid osakesi (puid) ja terve metsa korraga kuvamine on liiga suur koormus graafikakaardile.
- andmed objektide kohta jagatakse kaheks: esimene osa on ühine kõigile.. näiteks puudele (tekstuur, geomeetria), teine osa käib iga puu kohta eraldi (jämedus, värv jne)
- kasutab enumeid
- kasutab switch/case
- mõeldud rohkem „heavy graphics“ mängude jaoks
http://en.wikipedia.org/wiki/Flyweight_pattern
Observer(R)
- üks enimkasutatavaid mustreid
- achievement unlocked näide:
Kontrollime millal toimub meid huvitav sündmus: sillalt alla kukkumine. Selleks ei tuleks teha eraldi meetodit "unlockFalloffBridge()" vaid erinevad aspektid mängus väljendavad sündmusi.
Näiteks: meil on meetod mis tegeleb füüsikaga (keha kukkumine nt.) siis kui see meetod tuvastab keha kiire liikumise (kukkumise), saadab välja sellekohase teate (füüsika meetodit ei huvita, kas keegi loeb seda teadet või mitte): “Uh, I don’t know if anyone cares, but this thing just fell. Do with that as you will.”
Antud juhul võtab selle teate vastu achievement süsteem, mis kontrollib kas kukkuv keha oli peategelane ja kas see oli sild kust ta alla kukkus.
Siin näites ei pidanud füüsikaga tegelev kood achievementidega tegelema üldse, saatis ainult teate välja. Niimoodi on lihtne achievement süsteemi muuta või üldse eemaldada, ilma, et füüsika meetodit tuleks muuta. Selles näites on achievement süsteem "observer"
switch (event) { case EVENT_ENTITY_FELL: if (entity.isHero() && heroIsOnBridge_) { unlock(ACHIEVEMENT_FELL_OFF_BRIDGE);
Antud muster nõuab palju klasse
Muster on „heavyweight“
Lihtne ja töötab
Prototype(D)
Väga hea sarnaste objektide varieerimiseks.
Defineerid ühe alus objekti e. prototüübi ja varieerivatel objektidel delegeerid nad protüübini.
Hea koodi näide:
{ "name": "goblin grunt", "minHealth": 20, "maxHealth": 30, "resists": ["cold", "poison"], "weaknesses": ["fire", "light"] }
{ "name": "goblin wizard", "prototype": "goblin grunt", "spells": ["fire ball", "lightning bolt"] }
{ "name": "goblin archer", "prototype": "goblin grunt", "attacks": ["short bow"] }
Samas, kui alternatiiv(vale) oleks kaks viimast objekti nii defineerida:
{ "name": "goblin wizard", "minHealth": 20, "maxHealth": 30, "resists": ["cold", "poison"], "weaknesses": ["fire", "light"], "spells": ["fire ball", "lightning bolt"] }
{ "name": "goblin archer", "minHealth": 20, "maxHealth": 30, "resists": ["cold", "poison"], "weaknesses": ["fire", "light"], "attacks": ["short bow"] }
See the difference huh?
Singleton(D)
Pointless.
Omab kahte põhilist eesmärki: omada teatud klassist ainult ühte eksemplari & globaalsed muutujad, millele saab kõikjalt ligi.
Mõlemat põhimõtet annab hõlpsasti asendada alternatiividega. Asendama peaks, sest Singeltonil on palju probleeme.
Ühte eksemplari saab tagada näiteks ühe booliga "käivitatud".
Vältimaks globaalseid muutujaid ja hoida ühe muutuja skoopi võimalikult väiksena saab kasutada mitmeid alternatiive, nt. get'ers jne.
State(D)
Prototüüp
Hetkel on prototüüp olemas ainult Unity projektina. Projekt on pakitud .zip failiks ja laetud ülesse.
Link: http://www.upload.ee/files/4385641/kool.zip.html
Nautimust !
Lõpptoode
Lõpptoode .exe failina.
Link: http://www.upload.ee/files/4472357/lopptoode.zip.html
Go nuts!