Het HLO (Hybride Leer Omgeving) in Purmerend nu bekend onder de naam NeoИ Games Studio, is een Leer Omgeving voor studenten om samen meerdere periodes aan een project te werken om kennis te maken met hoe een echt bedrijf te werk gaat.

Bij het HLO heb ik als Game Developer 3 periodes meegelopen, die bestonden uit 10 weken en kan zeker zeggen dat het de meest leerzame periodes waren die ik heb gehad op school. Ik heb hier mijn Developer soft en hard skills zeer kunnen verbeteren. Op deze pagina bevinden zich wat systemen die ik heb gemaakt.

Het systeem bestond al uit een soort Factory pattern, hier moesten wij alleen de data invoer toepassen aangezien alles werd opgevraagd. Hier voor hebben wij een Mediator geschreven die de data door paast naar de ParticleManager die dan een particle uit de lijst haalt en deze opzet op basis van de ingestelde data.

Het nieuwe systeem zou een request ontvangen van een EffectsMediator en dan met de data een Effect voorbereiden, wanneer deze klaar was wordt deze geplaatst op locatie van het verzoek.

De code structuur lijkt heel dicht op een Factory design pattern. Er worden van te voren variablen ingesteld per Effect en zodra deze word gecalled word er een Effect klaargemaakt een aangepast op basis van de ingestelde variabelen.

De EffectsManager had voor het refactoren slechte instelbaarheid. Nu als Singleton kan het op 1 object bekeken en aangepast worden. Als er een Effect nodig is die er niet is kan deze makkelijk worden toegevoegd. De verzoeken worden geregeld door een mediator genaamd de EffectsMediator. Deze kan je plaatsen op een object en aansturen via Unity events om dependencies te vermijden.

Als een Effect geplaatst word blijft deze staan tot de levensduur eindigt en word vernietigt, ook kan deze blijven loopen totdat een verzoek word ingediend voor vernietiging. Een Effect kan op locatie blijven of als child worden gezet om mee te bewegen. 

Het eind product is een adaptabel Effects systeem die overal gebruikt kan worden doormiddel van een EffectsMediator script. Het herschrijven van het systeem was een groot leerprocess waar ik veel van heb overgehouden.

Bij het HLO gebruikten wij een zelf gemaakte ForceSystem, dit systeem was een stuk flexibeler en instelbaarder dan Unity's geintegreerde Physics systeem. Deze heeft Berend Weij zelf geschreven en was heel instelbaar.

Forces worden gecalled wanneer de speler slaat, de enemy krijgt een Force om weg gegooit te worden met een curve, ook krijgt de speler een kleine hoeveelheid momentum van het slaan.

Voor de game zijn combo systeem was het ideaal om Forces achter elkaar te 'queuen', als er een force klaar was word de volgende aangesloten. Tijdens het schrijven van het simpele ForceQueue systeem heb ik veel geleerd over Lambda's en Delegates.

De queue is een script wat gedeclareerd kan worden als een Class, deze bevat functies die verzoeken verwerken met de informatie die worden meegegeven aan de Queue. Na het aanmaken kan een Force worden toegevoegd, de ForceBody (de ForceSystem Physics handler) is dan een referentie van waar de force naar gedirect word. Dit zorgt ervoor dat meerdere ForceBodies gebruik kunnen maken van de ForceQueue.

De queue was in eerste instantie heel instelbaar en uitgebreid, de forces konden overschrijden worden door andere en konden ingestelde prioriteit hebben. Dit was handig maar maakte het onoverzichtelijk en de code bevond zich op een onlogische plek. Dit eindigde in het verplaatsen van de code naar de ForceSystem en instellingen toevoegen aan de Force class. 

De code is nu overzichtelijk en compact, dit zorgt er ook voor dat het niet te veel impact heeft op performance en memory usage.