aaronvark / PeerReview1819

Repo for peer review assignments for year 2 development class of 18/19
0 stars 0 forks source link

Geoffrey Hendrikx - Blok 1 #8

Closed GHendrikx closed 4 years ago

GHendrikx commented 5 years ago

Tetris met verschillende weersomstandigheden. Physics Based blokken die vallen en die via de weersomstandigheden anders reageren.

denk aan wind effecten.

GHendrikx commented 5 years ago

Toelichting Documentatie.

GHendrikx commented 5 years ago

All the scripts Block BlockGenerator InputManager Singleton Also UML is added as a PNG image

aaronvark commented 5 years ago

UML is overzichtelijk genoeg. Zorg er wel voor dat de volgorde van items binnen een groep (var/func) altijd public/protected/private is (dus +/#/-). Bij de InputManager is dat nu bijv. niet zo. Je was hier volgens mij vandaag ook al mee bezig, maar het is in deze opzet wel get geval dat de InputManager te veel dingen aan het regelen is. Het is eigenlijk meer een game manager, omdat het ook game events (zoals block spawning) beheert, en niet alleen de input afhandelt. Uiteindelijk is het even de vraag hoe je dat opgelost hebt, maar ik ben benieuwd waar je op uitkomt.

Over het algemeen is het fijn om je dependencies meer in elkaar te stapelen, en te denken vanuit iets dat in termen van het spel het meest logisch is. Als ik hardop nadenk: Ik denk dat je in jou situatie een controller zou kunnen hebben, die input opvraagt (evt. van een input class die de keybindings weer beheert), en deze toepast op een blokje. Zodra dit blokje vervolgens de grond raakt zou het kunnen vragen om een nieuwe, of vanaf buiten een nieuwe toegekend krijgen (meer een dependency injection). In het tweede geval kan block spawning & assigning volledig los van controls gedaan worden. En heeft alleen de class die dit regelt (bijv. een game manager) referenties naar beide dingen. Hier zijn een miljoen oplossingen voor, maar het idee is om het simpel te houden (zowel in begrijpbare structuur, als in gebruik).

Code is verder prima leesbaar en goed te begrijpen.

GHendrikx commented 5 years ago

Added:

Edited: Block.cs Does work with events now and setting the damage of the block. BlockGenerator.cs Generating his own block at the beginning and setting the block his event. InputManager only provide the Game with input now and it's not dependent on the block class Singleton.cs

Edited UML

image

Slight Change in my Game Design. I want the blocks to get damage for how many blocks its on top. This is why i got a interface called IDamagable in the game.

GHendrikx commented 5 years ago

8

image

image

Wat wil ik er nog bij toevoegen: Blocks die kapot gaan door destructionBlocks die bestuurd worden door een AI. Verschillende blocken bijvoorbeeld een physics material block.

Waar ben ik nu. De destructable blocks worden gespawned samen met de gewone blocks. een main menu, option menu, etc. pool die objects teleporteer en terug haalt destructable blocks werken al kwa damage eraf doen etc.

aaronvark commented 5 years ago

Interessant gebruik enums in arrays. Je bent hier wel volledig afhankelijk van dat alles in de juiste volgorde staat, dus je zou zelfs nog kunnen overwegen om met dictionaries te werken. Dan wordt de enum je key, en is de instance je value. Zelfs als iemand alles omgooit en dingen in de verkeerde volgorde worden toegevoegd, kom je nog steeds bij de juiste objecten uit.

Klein details: ik zou de laatste regel van die switch state gewoon currentState.Enter() doen. Leest beter, en je assigned hem daarvoor toch. Ook heeft je StateMachine een dependency (stippels met normale pijl) naar IState, geen implementation/realization.

Wel fijn om te zien dat je de UML actief onderhoudt!

Ik ben ook benieuwd naar wat er gebeurt met de onClick listeners van je MainMenu buttons als je vaker het MainMenu in gaat. Klopt het dat hij ze nu steeds toevoegd, en er na 2x dus meerdere referenties in staan? Dan ga je uiteindelijk opstapelende SwitchState() calls krijgen, des te meer je naar MainMenu terugkeert. Zo mogelijk misschien eerst de listeners clearen voordat je nieuwe toevoegt.

In de interactie tussen je Pool en BlockGenerator kan ik nog nergens een plek vinden dat er daadwerkelijk blocks worden aangemaakt. Ik zie wel een aantal private SerializeField lists. Hebben die nog een functie? Aan de naamgeving zou je verwachten dat BlockGenerator echt blocks maakt, maar uiteindelijk is het meer een doorgeef luik naar een pool. Als je hem wel meer responsibilities zou willen geven zou je het spawnen en in de pool voegen aan deze class kunnen overlaten.

GHendrikx commented 4 years ago

Game: https://github.com/GHendrikx/Wheatris PDF Documentatie: https://github.com/GHendrikx/Wheatris/blob/master/Wheatris%20Geoffrey%20Hendrikx%203028316.pdf

vmuijrers commented 4 years ago

Geoffrey, je links gaan naar een 404 pagina, staat je github misschien nog op private?

GHendrikx commented 4 years ago

Hey Valentijn, sorry hij moet nu public staan als het goed is.