I finally got my first system set up and about 90% tested. Here’s a rundown of what it is, and how it works.

What it Is

As mentioned in my previous post, a game can have multiple “worlds”. In order to move between these worlds, the developer would need to provide a teleporter from one world to the other. Ideally, this is something Unit 2 would have created out of the box, but every shortcoming is an opportunity to learn something, so I set about creating this bridge myself.

Doors and Animations

Crayta provides a lot of door entities, and as far as I can see, all of them are animated. However, the animations don’t trigger out of the box, so I added a DOORCONTROLLER script which tracks the state — open or closed — and plays the opposite animation when the user interacts with the entity.

Doors as Controllers

In addition, each door has 2 surfaced properties: DESTINATION and SPAWNCODE.

DESTINATION accepts a worldasset which is the data type for another world contained within the game. SPAWNCODE is a free-text identifier that we’ll use to link the door teleport to a location in another world.

Door Trigger

If you’ve worked with the old Neverwinter Nights toolset, you’ll remember that in order to move from map to map you had to put down triggers which linked to a spawn location in another map. Using the same paradigm here, I added a trigger entity behind the door so after the user opens the door and walks through, the OnTriggerEnter event will fire.

When entered the trigger will query the parent DOORCONTROLLER script to find the DESTINATION it should send the user to. It also pulls the value of SPAWNCODE from the DOORCONTROLLER and stores it on the User object. Even if they had it, we wouldn’t want to store this info in a global sense, as we might have other players in the world using other doors. And because we don’t have a global data transport, we have to save the SPAWNCODE to the user in a custom USERDATA script, save it to the user data store, and recall it once we get to our DESTINATION world.

Locator Objects and Spawning

A locator object is invisible, but can serve as a coordinate and rotation provider for other objects. When users spawn into a world, they do so at a specially named locator. We can add additional locators to spawn our player at, but we need to know which one to choose.

When a player transitions into a new world, the USERDATA script loads the SPAWNCODE we saved when they hit the trigger in the previous world. We then loop through all locator objects in the current world and try and match the locator’s SPAWNCODE property with the one we stored on the User. If we have a match, we spawn the player at that location. If we can’t find a match, we spawn the player at the default locator location.