Tim Peeters -Eindopdracht 1 'Space Invaders 3D'

[TimPeeters1]

_EINDOPDRACHT: https://github.com/TimPeeters1/KernGameDev1_TimPeeters_

re #11 voor vorige issue :)

Note to self, bij pull request maken eerst master pullen, commiten en dan mergen met master (door branch cleanup).

[aaronvark]

Voor de volgbaarheid nog even een re #11 van je vorige issue...

Wat vooral in je UML opvalt is dat de "aggregation" pijl nog incorrect wordt toegepast. IDamagable is geen aggregation (onlosmakelijke samenkomst) van Bullets, maar Bullet heeft waarschijnlijk een dependency t.o.v. IDamagable (dus dan zou het een normale dotten arrow moeten zijn). Ook inherit Enemy niet van Bullet. Dus waarschijnlijk is hier nog wat verwarring over de arrow types ;)

Verder is de inzet van de interfaces in je code vrij netjes aangepakt (dependencies tov interfaces is een prima oplossing om classes gesplitst te houden). Ik ben wel nog benieuwd waarom private serializefield zo populair is, want in principe is het gewoon een "public voor designers, maar niet programmers". Komt het zo vaak voor dat developers zomaar aan je variabelen zitten? Zijn daar mogelijk andere oplossingen voor? Wel is het natuurlijk nuttig als je private variabelen in de context van bijv. ScriptableObjects ook opgeslagen wilt hebben, maar dan heeft toegang er niet zoveel mee te maken (en dan nog kan je je afvragen of het niet gewoon public moet zijn).

Je houd je nog niet aan de conventies qua haakjes.

Je ObjectPoolManager class is misschien (ben benieuwd naar de keuze die je hierin maakt) een onnodige ophoping van code wat ook opgelost kan worden als je ObjectPools simpelweg opslaat waar ze nodig zijn (bijv. Player beheert een pool van bullets, evt. een BulletPool (die de interface implementeerd)), en ze niet allemaal op 1 plek hoeven samengevoegd te worden. Dat voorkomt ook het opslaan / zoeken per tag e.d., en maakt het waarschijnlijk wat compacter. Verder is de implementatie best netjes!

Goed werk verder, en netjes op tijd ingeleverd!

[TimPeeters1]

Voor de deadline van vandaag 5 uur heb ik mijn ObjectPoolManager 'gerefactored'. Het is meer een toevoeging dan een refactor omdat ik er namelijk voor gezorgd heb dat objectpools nu vanuit scriptable objects werken. Dit voorkomt namelijk het moeten zoeken naar tags/strings vanuit de classes die de poolmanager gebruiken. Als voorbeeld: de player gebruikt nu een scriptable object voor zijn bullets, en de bullet hoeft slechts een keer geassigned te worden in het scriptable object en daarna in de player class. Hierna wordt de scriptable pool toegevoegd aan de manager en hoeft er niet meer geassigned te worden.

Verder wilde ik ook nog events toe voegen voor de player, alleen had ik hier geen tijd meer voor. Dit ga ik dit weekend nog doen samen met het fixen van mijn UML. Daarnaast ben ik er niet zeker van of de methode van de scriptable objects nou daadwerkelijk zo performant is voor de poolmanager... hier zou ik graag nog wat feedback over willen.

[TimPeeters1]

Wat kan mijn spel nu? Ik ben op het moment bezig met een 3d versie van space invaders. Op het moment kan je als speler schieten, naar links en rechts bewegen en rondkijken in de ruimte. Daarbij zijn er ook vijanden die je kan hitten en killen, dit werkt dmv. een interface en physics bullets (rigidbodies). Het spel bevat verder ook een spawn mechanic dat rijen met aliens spawnt, en de aliens schieten terug van tijd tot tijd (zoals het klassieke spel). Hierbij worden ook alle bullets, enemies en particles gepooled in een objectpool (die op het moment niet generic is).

Wat wil ik dat mijn spel kan? Ik wil nog aardig wat functies gaan toevoegen. Zo wil ik nog een player death toevoegen, een systeem waardoor aliens sneller gaan vliegen als je een hogere score hebt, een highscore systeem, en natuurlijk beter werkende enemies. Als ik nog tijd over heb wil ik ook nog wat leuke art toevoegen :) Qua programmering wil ik ook nog een generic object pool maken, een finite state machine toevoegen en meerdere enemies laten inheritten van een abstract enemy class (deze zijn op het moment allemaal dezelfde enemy class).

[aaronvark]

Lekker bezig! Goed om te zien dat je actief met de //TODO's bezig bent, en dat de object pool nu al een aantal iteraties heeft gekregen. Ik ben benieuwd naar je ervaringen met de ScriptableObjects (laat die ook aan Valentijn zien!), want het klinkt als een goede oplossing.

Wat ook nog een leuke kans is nu je toch met ScriptableObjects werkt is om ze niet public in te stellen op de pool manager, maar in te laden via Resources.Load<...> vanuit een vaste folder. Dan kan je ze toevoegen aan de folder, en worden ze automatisch geladen. Ook heb je dan misschien niet eens meer een MonoBehaviour nodig voor de pool, omdat je resources ook via "lazy initialization" kunt inladen zodra de pools nodig zijn.

Ik zie ook dat je overal private hebt weg gehaald, maar impliciet is het dan nog steeds private (just so you know).

De state machine zou je waarschijnlijk kunnen gebruiken voor de speler (powered up, dead, normal, ligt er uiteraard aan wat je gaat doen). De enemies lijken vooral een erg lineair pad af te lopen en nooit een state terug te gaan, dus misschien is het daar wat minder nodig.

[TimPeeters1]

Een kleine voortgangsupdate Deze week heb ik voornamelijk gewerkt aan het uitwerken van de all established mechanics. Zo heb ik de spawner uitgewerkt om daadwerkelijk rijen te spawnen ipv random in een box. Daarbij ben ik ook nog de player verder aan het uitwerken om nu vanaf een third person perspectief te kunnen spelen. Ik wil dit weekend de rest van de mechanics uitwerken en afmaken zodat ik volgende week makkelijk kan afronden. Ook heb ik om niet gek te worden van het programmeren wat simpele art toegevoegd :)

[TimPeeters1]

De link naar de repo van mijn eindopdracht:

https://github.com/TimPeeters1/KernGameDev1_TimPeeters