Closed nathannieuwenhuizen closed 4 years ago
is de original comment nogsteeds het soort game dat je wilt maken?
Excuses, was vergeten de comment aan te passen. De orginele comment is aangepast
UML is goed leesbaar. Ik snap alleen de double ended dependency tussen Bullet en Asteroid niet echt, want volgens mij heeft Asteroid verder geen dependency ten opzichte van Bullet. Alleen Bullet moet iets weten van Asteroid (namelijk, dat er een Split functie bestaat). In dit geval zou het ook mijn voorkeur hebben om niet direct de Asteroid aan te spreken, maar bijv. te werken met een SendMessage. Je gaat niet elk frame tegen heel veel dingen botsen, en dan verdwijnt de dependency eigenlijk volledig (dit is ook een van de redenen dat Unity met SendMessage en tags werkt over het algemeen). Een goede SendMessage zou dan gewoon zijn: "SendMessage("Hit")", en dan mag het object (Asteroid in dit geval) zelf weten of het uiteindelijk Split of niet.
Een andere mogelijkheid is om te kijken of je een bepaalde interface kunt vinden (bijvoorbeeld IHittable) als GetComponent. Dan heb je een dependency tov. die, en werk je toch direct met objecten ipv SendMessage. Ik heb dat al een tijdje niet gedaan, dus de vraag is of dat allemaal nog werkt.
Verder een helder beginpunt om op voort te bouwen. Check wel of je alles consistent in stijl hebt (afhankelijk van wat de conventies nou eigenlijk worden...)
Ik heb een interface "IDamagable" geplaatst die ik geleerd heb van de les van donderdag. Verder heb ik een object pool geïmplementeerd en de class diagram geupdate.
Welke features ik wil gaan uitwerken voor het eindopdracht:
Ik wil een een eindeloze speelveld maken dat looped over een kleine ruimte om het Asteroid spel meer te laten over komen waarin alle objecten (speler, asteroids en de bullet) als die de scherm verlaten, terugkomen vanuit het tegenovergestelde richting.
Optioneel zou ik willen dat de camera de speler volgt in deze oneindige loopable wereld, maar dat gaat meer moeite kosten en is minder relevant voor de class structuur, dus ik twijfel of deze feature er in gaat komen, maar we zullen zien
Verder een simpele UI en een wave systeem die al de asteroids spawned zou top zijn!
De mogelijkheid om met één kogel het spel te kunnen spelen. Dit wordt gedaan door de kogel niet te laten verdwijnen als het iets raakt en dat het terug gehaald kan worden met het pistool.
Hoe ver ben ik nu? Ik heb nu de basic gameplay gemaakt met de asteroids en het speler beweging. Verder heb ik één kogel mechanic geimplemnteerd waarin je maar 1 kogel kan schieten en die weer kan oppakken d.m.v. er naar toe gaan of met je pistool naar je toe trekken.
Welke dingen zou ik graag zou willen proberen? (in relatie tot OOP, patterns, language features, etc.) Ik heb al een object pooling en interfaces gebruikt, maar ik zou graag generics willen gebruiken. Ik weet nog niet waarvoor maar mischien ga ik de object pooling herschrijven maar dan meer generic. Abstract classes en functies wil ik ook graag proberen, maar die zit iets lager in mijn prioriteiten lijst.
Volgens mij is de object pool een goede kandidaat om wat met generics te spelen. Kijken hoe handig je hem krijgt zodat hij voor verschillende zaken gebruikt zou kunnen worden. Hiermee kan je ook dingen zoals de "OnObjectReuse" onderdeel maken van een interface waar de ObjectPool mee praat. Nu los je het op met een aantal lagen inheritance, terwijl het aan en uit zetten van objecten ook een responsibility van de pool class zou kunnen worden, waardoor de PoolObject een interface zou kunnen worden ipv een base class (dat heeft wel mijn voorkeur over het algemeen).
Qua die volgen in een looping wereld kan je misschien het volgende algoritme proberen: voeg de target positie aan een lijst toe. Voeg vervolgens alle "gespiegelde" varianten er van toe (links/rechts/boven/onder het scherm uit, dus gewoon de breedte en/of hoogte (in totaal zijn er dus 9 opties, maar je zou het ook kunnen beperken tot 5 als je diagonalen niet meeneemt) van het speelveld bij de target position optellen). Kijk dan welke het dichtst bij is, en beweeg die kant op. Als je dan tegen de rand van het scherm bent aangevlogen (en geteleport) zou je het even opnieuw moeten berekenen.
Gebruik in je UML voor classes die interfaces zoals IDestroyable implementeren een stippellijn met leeg driekhoekig pijltje, die vanaf de class naar de interface gaat. In veel tools wordt die "realization" genoemd.
Object pooling heb ik meer generic gemaakt door de class te verdelen in drie sub classes
Github link naar source code: https://github.com/nathannieuwenhuizen/Kernmodule1 Documentatie: https://github.com/nathannieuwenhuizen/Kernmodule1/blob/master/Documentatie.pdf
This game would be a mix of asteroids and a 2D platformer.