Max Willekes - Eind Opdracht blok 1

[MaxWillekes]

Asteroids but you play as the asteroid and you have to ram ships to score points.

[MaxWillekes]

Eerste versie van de UML voor een first playable van het concept.

[aaronvark]

Aardige setup. Wat wel opvalt is dat de actor baseclass gedrag uitvoert wat eigenlijk alleen voor de enemy is ("als je tegen de speler aankomt"), dus misschien is die niet eens nodig op dat punt. De InputManager is handig in gebruik tov de Player. Hier kan je mooi een interface van maken met de theorie van vandaag. Ook is hier nog wel een kans om de keybindings variabel te maken. Welke knoppen aan welke events gekoppeld zijn zou je bijvoorbeeld in een Dictionary<string, UnityEvent> opslaan, zodat je dit korter (in een loop) kan afhandelen, en makkelijker op een overzichtelijke manier kan editen.

Verder zie ik ook dat je gameObject.transform.position gebruikt, doe dat op z'n minst direct via de transform (want die gameObject is overbodig), maar sla het liefst ook de referenties naar components even op in een member variable (zoals in mijn voorbeeld myTransform, omdat dit echt kan schelen als je dit heel vaak doet).

[MaxWillekes]

Genoemde feedback ( op de variabele keybindings na (al ben ik van plan dat dit weekend te maken )) verwerkt.

Al weet ik niet zeker of dit is wat er werd bedoelt met een interface van InputManager maken. En ik weet ook niet zeker of ik de juiste pijlen/lijnen heb gebruikt in de UML voor de relaties tussen InputManager - GameManager - Player.

Versie 0.0.2 van de UML

[MaxWillekes]

Op het moment heb ik nog geen updated pull-request. Aangezien ik nog bezig ben met werken aan code en deze nog niet functioneel is. De meest recente veranderingen kunnen worden gevonden in #48 .

Wat ik graag zou willen hebben als het gaat om features zijn:

1. Basic hoofdmenu met credits.
2. Bewegende en continue spawnende enemy's
3. Een score counter tijdens het spelen
4. Enemys die kunnen schieten.*

*zou ik graag willen maar is in verband met tijd mogelijk niet mogelijk.

Wat ik nu heb is player movement, de classes voor de player en de enemy en de mogelijkheid voor de speler om de enemy te vernietigen.

Wat ik graag zou willen proberen zijn een statemachine voor de menu's. Meer gebruik van delegets, events en interfaces. Mogelijk verandert dit nog op basis van wat we in de aankomende lessen gaan behandelen.

[aaronvark]

Volgens mij heb je realistische doelen. Wel zie ik dat je in het toepassen van een aantal zaken, de GameManager te veel macht hebt gegeven. Nu luistert de speler gewoon naar wat er gevraagd wordt, en gebeurt alles eigenlijk in de manager. Probeer na te denken over wat de verantwoordelijkheid van elke class is, en dat een speler bijvoorbeeld zijn eigen zaakjes zou kunnen regelen, ipv vanuit updates steeds verteld worden wat er moet gebeuren. Kijk dus of je minder vaak de communicatielijnen tussen classes kunt laten lopen, zeker tussen classes die wat meer los staan in termen van naam (game manager en player bijv., Player & PlayerInput classes zouden bijv. vaker met elkaar te maken kunnen krijgen, zeker als de input class bezit is van de player class).

De statemachine is een class waar je dat goed kunt uitproberen. Als je er morgen bent kunnen we wel sparren over de responsibilities die classes hebben, en hoe je die kunt verdelen.

[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.

[MaxWillekes]

Link naar de personal repository van mijn eindopdracht https://github.com/MaxWillekes/EindOpdracht