Operation StarFall
Operation StarFall
Dit is een nieuw project op mijn school, het doel van dit project is om een professionele game te maken. Voor dit project gaan we dus samen werken met onze docenten maar niet als docent leerling maar collega met collega. Dit om te zien hoe het is om in een game studio te werken.
Game
Rider, Unity
C#
Lead programmer
Deze mechanic maakt gebruik van het select systeem, als je meer wilt weten over dit systeem klik hier Als het select systeem een target heeft geselecteerd en de speler de ability button indrukt Wordt er een force gegeven in de richting van de target, de speed van de ability kan worden veranderd in de inspector
Voor deze mechanic zat ik te pair programmen met een andere developer. Ik legde uit hoe het mij logisch leek om te programmeren terwijl de andere developer de code typde. Het idee dat ik bedacht voor dit systeem is dat de speler en een grabable allebij een trigger collider hebben, wanneer deze colliden en de speler de "grab" button drukt, dan teleport de speler naar de closest point die is ingesteld. We teleporen de speler en lerpen hem niet, dit omdat het dan "snappier" aanvoeld
Selecting targets is een los en herbruikbaar systeem. Het systeem werkt met de muis maar ook met controller input. Dit door de richting te pakken van de joy stick of de positie van de muis. In deze richting wordt de beste Selectable object gezocht doormiddel van het dot product. Wanneer je een object hebt geselecteerd kijkt hij of er een route is naar het object doormiddel van een raycast. Terwijl je iets geselecteert heb blijft het systeem zorgen dat er een path naar de target is. Als er geen rechte lijn naar de target is deselecteert hij de target.
Tijdens het project was ik heel erg veel betrokken bij het controlleren van de code in de pull requests en het implementeren van de gemaakte mechanics. Later in het project kreeg ik ook de rechten om pull requests te merge. Dit zorgde dat ik niet steeds moet vragen of iets gemerged kon worden. En aangezien de andere developers ook steeds meer implementatie deden had ik meer tijd om vragen te beantwoorden en mijn eigen todo's te maken.
Ik heb samen met een andere developer lopen kijken naar hoe we een goed sound systeem konden maken, Hier hadden we meerdere ideeën voor maar ze waren niet zo fijn. Uiteindelijk heb ik iets bedacht wat best wel redelijk zou werken. Ik ben dit toen gaan uitwerken door een prototype te maken zodat de andere developer kon zien hoe ik dit systeem in mijn hoofd had. Daarna heeft hij dit systeem uitgebreid met verschillende opties en settings per audio.
In de tweede sprint van het project gingen we bezig met het camera systeem. Er was besloten om met cinamachine te gaan werken. Ik en 3 andere gingen hier gezamelijk onderzoek naar doen en de camera controller op te zetten. We gebruiken Cinamachine om de camera de spelers te laten volgen, dit door de transposer te gebruiken. De camera zoom hebben we zelf geschreven aangezien we ook met points of intrest wouden werken. Voor de camera zoom gebruiken wij de Z axis en geen fov aangezien alles streched out wordt wanneer je fov gebruikt. voor de zoom gebruiken wij de distance van de camera en de verste target. en dit wordt de nieuwe z axis van de camera. Hier waren nog wel wat problemen mee, zoals de y axis die sneller moet uitzoemen dan de x axis. Hier moesten wij rekening mee houden
De basis van de animator stond er al, maar aangezien de developer die ermee bezig was een beetje vast liep besloot ik het over te nemen, zodat hij op iets anders kon focussen. Er waren veel dingen die nog moesten gebeuren met de animator, Waaronder veel polish, wanneer je bijvoorbeeld geen movement input meer geeft maar wel nog iets geweegd moet je een animation afspelen, wanneer je van een platform afloopt moet je een animation af spelen. En voor de verschillende characters moesten we ook andere attack animations afspelen. Dit heb ik uiteindelijk gemaakt doormiddel van sub-statemachines and animation layers.
Ik heb samen met 2 andere developers de player state machine designed. We hebben samen overlegd over hoe het moet werken en hebben daarna alle 3 aparte state machine prototypes gemaakt. Hierdoor konde we kijken wat fijn was een welk systeem en deze hebben we later uitgewerkt en gepresenteert aan de andere developers. Uiteindelijk is deze state machine nog iets aangepast en hebben wij besloten een meer generic state machine te maken. klik hier voor meer informatie over de generic state machine. Deze generic statemachine is daarna uitgewerkt en toegepast voor de player. Omdat het ongeveer als de animator werkt is het maken van states veel makkelijker en de transitions zijn ook sneller duidelijk.
Het doel van de state machine is om makkelijk enemy states te kunnen instellen en veranderen, met verschillende condities. De state machine werkt ongeveer hetzelfde als de animator alleen is nu custom geschreven wat ons veel meer controllen geeft. De state machine werkt door het vinden van de huidige state en door alle mogelijk transities te kijken welke hij kan nemen. Als er een goed is gaat hij naar die state. Voor de editor window heb ik UI builder gebruikt zodat ik de layout niet hoefte te programmeren. Dit is de eerste keer dat ik een Editor window heb gemaakt en heb er veel van geleerd.
2 andere develoeprs waren samen bezig met het zorgen dat de spelers door elkaar konden lopen maar wel op elkaar konden staan. Op een gegeven moment hadden zij een probeel dat speler 1 op niemand kon staan, speler 2 alleen op speler 1 kon staan en speler 3 alleen op speler 1/2 kon staan etc, toen ze er niet achter kwamen besloot ik te helpen. na wat debugging en uitzoeken wat er mis kon zijn kwam ik erachter. Het wat de volgorde van de speler in de hierarchy. De eerste speler kon er wel opstaan, maar de 2de speler niet. En aangezien ze Physics.IgnoreCollsion gebruikte zette de volgende speler weer de collision uit. De oplossing was simpel. Hou de collision aan als er 1 van de 2 spelers boven de andere zit.
