Dennis Borst - Eindopdracht

[DennisBorst]

Bomberman game in 3D, je weet niet waar de tegenstanders zijn, dat doe je op gevoel van het luisteren waar de explosies vandaan komen.

[TimPeeters1]

Impressive, most impressive.

[DennisBorst]

Dennis Borst #7, first playable + UML,

Voor mijn project ga ik een 3D first person bomberman maken. Je speelt met 4 spelers waarvan jij 1 speler bent tegen 3 AI spelers. De twist is dat je normaal in 2D de tegenstanders kan zien. Hier kan je de tegenstanders niet zien maar moet je afgaan op het geluid. Zodra je een bom dichtbij hoort weet je dat er een tegenstander in de buurt is.

Wat ik tot nu heb is dat ik met de first person controller van de unity assets store kan lopen (later wil ik een eigen controller script schrijven). Daarnaast heb ik mij gefocused om een bom te plaatsen die kan exploderen waardoor er muren naast de bom kapot zullen gaan. Ik ben niet toegekomen aan de AI.

Hier een link naar mijn branch met de scripts erin: https://github.com/aaronvark/PeerReview1819/tree/DennisBorst

Hier is mijn UML:

[aaronvark]

Je UML ziet er netjes uit. Volgens mij zijn alleen de composition (gesloten ruitjes) bij de Bomb class niet helemaal correct. Als ik het zo lees vermoed ik dat de wall door een explosie van de Bomb wordt gedestroyed. Dit zou betekenen dat de Bomb misschien iets moet weten over Walls (normale dotted arrow van Bomb naar Wall), en daarnaast dat de Actor bombs moet kunnen spawnen, oftewel zo'n zelfde pijl van Actor naar Bomb.

Uiteindelijk heeft de Actor niet eens kennis van bomb, alleen een prefab reference. Dus daar is eigenlijk geen dependency (behalve dat je ergens die prefab reference vandaan moet halen). Andersom is die er blijkbaar wel. Bomb heeft een actor ref om een enkele boolean op true te zetten. Lijkt me een beetje te veel van het goede, en een mooie kans om daar een delegate in te zetten (onExplode), waar de Actor naar luistert. Heeft Actor nog wel een dependency tov van Bomb, maar omdat die ook worden gespawned door de Actor is dat ook best logisch.

Bomb heeft wel een dependency tov IDamagable (en niet de Wall zelf), omdat je uiteindelijk via die interface damage doet. Dit is wat mij betreft ook echt the way to go. Physics overlaps, interface getcomponent, en daar mee praten. Meest flexibel wat mij betreft. Netjes!

GameManager is lekker lean zo, misschien maar zo houden ;)

[DennisBorst]

Ik heb mijn UML aangepast waardoor het de connecties meer OOP maakt. De bom script heeft nu een delegate waardoor de actor die van buitenaf kan aanroepen. De bom regelt nu zelf of er een bom in het veld gezet mag worden (ipv dat de actor dat doet, wat het dus eerst deed). Dit maakt het meer OOP.

Hier weer een linkje naar de scripts: https://github.com/aaronvark/PeerReview1819/tree/DennisBorst

De rest van de scripten die zijn toegevoegd moeten nog in de UML worden gezet.

Hierbij de aangepaste UML (een iteratie op de vorige UML):

[DennisBorst]

Dennis Borst #7, Update

Voor mijn eindopdracht wil ik graag proberen om nog 3 AI's toe te voegen die jou proberen op te zoeken en te vermoorden met bommen (dit gaat nog wel ingewikkeld worden want ik heb nog niet heel veel met AI gewerkt). Als ik dat af zie te krijgen dan wil ik graag nog power ups toevoegen die de bom die je plaats sterker maakt.

Wat ik tot nu toe heb is een first person character (van de unity standard assets), die een bom kan plaatsen die explodeert en vervolgens muren kapot kan maken. De bom doet ook damage tegen de speler zelf. Daarnaast respawned de game als de speler 3 keer geraakt is door een bom. De bom gebruikt een delegate en de muren en de spelers gebruiken interfaces dat allemaal nieuw voor mij waren dus dat heb ik er tot nu toe uit geleerd.

Wat ik nog graag zou willen proberen is een Finite State Machine gebruiken voor mijn AI (hier heb ik nog nooit mee gewerkt dus wil ik mij daar mee uitdagen).

Hier een link naar mijn branch met de scripts erin: https://github.com/aaronvark/PeerReview1819/tree/DennisBorst

Hier is mijn UML:

[aaronvark]

Netjes je UML bijgehouden! Ik zie dat er een dependency ontstaat tussen de Actor en UIManager, maar omdat de Player deze code aanroept neemt die deze dependency ook over. Misschien iets om in de baseclass te laten oplossen? Als dit niet kan ivm de gameID variabele bijv. (die nu nog volgens mij niks doet, dus waarvoor is die er?), dan zou je dat weer kunnen oplossen met een variabele van Actor die de Player class veranderd in zijn override Awake bijvoorbeeld.

De twee delegates die je nu declareert in de Bomb class zijn hetzelfde (void ...()), dus daar kan je net zo goed dezelfde voor gebruiken. Je maakt dan 2 instances van dezelfde delegate signatuur aan, en dat kan prima. Deze zou ik bijvoorbeeld gewoon "delegate void Callback();", noemen, en dan krijg je dus een "event Callback canDeploy", en een "event Callback timerCallback".

Wat nog een beetje gek aanvoelt is die tweede call naar GetComponent, want eigenlijk zou je hier gewoon de IDamagable implementatie van DestructableWall moeten veranderen zodat die wat extra's doet: namelijk zijn timer setten. Enige probleem is: die variabele staat in de Bomb... is dat nodig? Kijk of je die extra function call kunt wegwerken, want dit is redelijk hacky. Heb je ook gelijk geen Try/Catch (ignore) meer nodig omdat je zeker weet dat het een IDamagable is (tenminste, daar zou je netter op kunnen checken).

Wat gaat die WallManager eigenlijk doen met die list? Nu is het een onnodige collectie volgens mij. Is er een plan voor?

De Finite State Machine klinkt als een aardige voor de AI. De uitdaging hier wordt om de verbindingen tussen classes (en die gaan hoofdzakelijk over informatie, zoals uit de comment hierboven ook steeds blijkt) zo logisch mogelijk te krijgen. Data waar hij hoort, zodat je er geen omwegen naar hoeft te programmeren. Begin simpel. Je kan bijvoorbeeld eerst beginnen met een FSM die met functies en delegates werkt (volgens mij was het voorbeeld wat op de wiki staat ook zoiets), en dan kijken of je er eentje kunt maken met classes.

[DennisBorst]

Ik heb de feedback verwerkt in mijn scripts. De gameID zorgt ervoor dat de UI niet de verkeerde hartjes update. Anders als een AI damage krijgt dan gaat er ook een hartje van de speler af.

De WallManager heb ik eruit gedaan omdat het inderdaad geen echte functie had.

Ik denk dat het wel handig is om die 2e GetComponent te laten zitten omdat de Actor (speler + AI) ook de interface IDamagable gebruiken. Dit zou er voor zorgen dat als ik dit extra in de IDamagable zou zetten dat niet alleen voor de Wall geld maar ook voor de Actor.

Op het moment ben ik bezig met de FSM, ik had eerst alles in één script gezet (het script bestaat nog, ik heb het "PreviousEnemy" genoemd) maar Valentijn raadde mij toch aan om het met verschillende classes te doen. Echter heb ik nog niet zoveel verstand van FSM dus ik loop op het moment een beetje vast op hoe ik verder moet. Je zal zien dat mijn FSM een beetje een zooitje is. Als ik op internet opzoek naar een FSM met classes krijg ik toch meestal de FSM met functies. Nog tips waar duidelijk word uitgelegd hoe alles met elkaar verbonden zit in de FSM met classes?

Hier een link naar mijn branch met de scripts erin: https://github.com/aaronvark/PeerReview1819/tree/DennisBorst

Hier is mijn UML:

[vmuijrers]

Over FSM: Stap 1: Een monobehaviour die gebruik maakt van de FSM Stap 2: Een class genaamd FSM die gebruik maakt van States Stap 3: De States die het gedrag aangeven wat je nodig hebt voor je object. Stap 4: De monobehaviour initialiseert de FSM en roept de OnUpdate aan in de Update functie van Unity Stap 5: De FSM kijkt wel state de huidige is en roept hier vervolgends de OnUpdate Functie op aan zodat dat specifieke gedrag wordt uitgevoerd.

Het voordeel van de states is dat je niet constant hoeft te checken of bepaalde booleans true of false zijn en daarmee een soort waterval van if-statements voorkomt.

[DennisBorst]

Hierbij de repository naar mijn git: https://github.com/DennisBorst/Bomberman-3D

In de repository staat het algehele unity project en de pdf met documentatie. In de documentatie staan de twee UML's.

Dit is de link naar de zip van mijn build: https://drive.google.com/open?id=1wYAaszBb6ncbEBNXSz9zYOzTiPuy6GfT