Dirk de Kok
Quick Info
-
Duration: 1 year
-
Team Size: 22 ~ 25
-
Engine: Unity
-
Role: Lead Programmer / Gameplay Programmer
-
Platform: Windows (Steam), SteamVR
My work
More detail regarding my contributions I made to this project, as well as the biggest challenges I faced.
Gravity Hand
One of the main mechanics is the Anti-Gravity Hand. With this mechanic, you can make objects fly in zero gravity, and make them fall again at will.
I prototyped this in Unity and then implemented it in the build. I simply started with detecting collision with the player's hands, waiting for an input and then to turn off the gravity in the rigidbody of the held object. Seeing as we also wanted the player to be able to enable the gravity again, I had to have a way of keeping track of the objects currently in zero gravity. Thus every "interactable object" (objects you can pick up) had to have a specific component, which I will keep track of in the hand that activated anti-gravity.
I worked closely with the designers to get the details correct: Are objects bound to one hand? What happens if I activate the anti-gravity twice with different hands? Do I need to hold an object before I can activate it or is just touching it enough? I was able to create quick iterations on it until we settled on a final version.
Prototype
Alpha Build
Seamless Level transitioning
An essential part of our game is to be able to move from one scene to the other, without causing too much stuttering or frame drops. This is especially important for Virtual Reality as bad performance can cause nausea.
There are two parts to this feature, the performance and the logic. The former, is simply going through Unity's async performance settings and tweaking that. The performance is also kept high by enforcing strict rules on level designers to not clutter the scenes too much, by for example having few root objects.
The scene alignment logic was a bit tricky. Our game is a non-euclidean roomscale only experience. Meaning that the scenes need to be aligned in such a way that the player can just walk from one scene to another. I decided to solve this by aligning 2 "puzzle" pieces together, each in a different scene. I can take advantage of our portals to make sure the player ends up where they need to be. Then I can make those 2 pieces overlap on runtime, as the scenes are being loaded additively and asynchronously.
One of the hurdles that I encountered is teaching level designers how to use this system to their advantage. In the end, it was easiest to just sit down together with them, in a peer programming fashion.
Video showcasing seamless level transitioning. The player moves from one scene to another without them knowing. The next scene is also being loaded in the background.
Rough visualization of how it combines the level pieces
Team management
For the entire duration of the project, I was the lead programmer. I was responsible for making sure the tech side of the projects was faring well. My main tasks included:
-
Ensuring project direction
-
Prioritization of tasks and features
-
Encourage and facilitate collaboration between disciplines
-
Update the producer and other leads on the tech side of the project
-
Pitch the tech side of the project to the stakeholders (teachers)
-
Oversee the programmers and facilitate anything they need
In the end, what this meant was that a lot of my time is now taken by lead (and other) meetings. In those meetings I would give a technical perspective to whatever we were talking about.
The feedback my peers give my has been positive throughout the project duration, indicating that I am taking up this role well. I made sure that the project was on the right track and that we wouldn't over scope our concept.
Can't really show an example, so here is a team management stock image