Stargate: VR

*
*
*
*
*

The ultimate aim is not to be a videogame developer as such but to acquire the relevant skills & pivot my way into Education-tech.

*

I want to eventually amalgamate of all my existing experience & ongoing learning into building a vr-focused education platform, aimed at helping lower-income household students climb the STEAM ladder.

*

There are a significant amount of worker 'modules' choosing what action to take on collision, performing various look-ups, or checking if a coroutine/async work is done or not.

*

To avoid the initialization/object dependency nightmare this could have been, I have leveraged a form of attribute-based Dependency Injection to hydrate classes, Prefabs & Scriptable Objects with their various components.

*

This pattern has also laid the ground for out-of-the-box easier unit test writing, which will become increasingly critical as the project continues to evolve.

*
*
*
*

This ongoing MVP covers the basics of in-game object-to-object communication. I.e., any given stargate can use an internal 'repository' GetById(<stargate address>), to find if a 'target gate' exists in the dockerized MongoDb(or in memory) and then perform a 'dial' on the returned address.

*

Once the two gates 'hand-shake' a connection is established and the player or non-player objects can be transported to a new location regardless of whether the gates are in disparate scenes or not.

Dialing to 'puddle' complete (No Kawoosh(yet..))

In this fashion, a user will be able to dial their way into their friends 'worlds' and move seamlessly from planet to planet as they play the campaign. Since this is an enormously core functionality of the whole project, a significant amount of blood sweat & tears has and continues to be poured into its design.