Finders keepers

A mysterious client has contracted you, a master thief, to infilitrate the king’s keep. Snatch arcane crystals to gain acrobatic prowess. Evade the mechanical watchers. Steal the priceless heirloom.

Genre

3D Platformer

Reference game

Pseudoregalia

Production time

15 weeks

About reference games at TGA

Games produced as part of studies at The Game Assembly are based on a reference game. This is to give students a starting point for their projects, and to speed up the inital stages of production. Genre and metrics (camera angle, character size, movement speed etc.) should adhere to the reference game. Deviations are allowed, but must be well motivated.

itch.io page here, with a downloadable version of the game.

My contributions

This was my sixth game project at TGA, and the second built in our custom engine, bean. I worked primarily on gameplay systems. A requirement unique to this project was that we use visual scripting in some way – mainly as a tool for our level designers and tech artists.

Visual Script Graph Editor

The VSGE was my chief responsibility during this project. It was built upon a minimal but functional base provided by TGA. I then expanded it with quality-of-life functionality, tons of node types, and engine integration.

In order to future-proof it for upcoming game projects, I split the editor's functionality into engine-specific vs. game-specific domains.

The visual scripting system constituting the underlying infrastructure was filed under our Engine project. Here we could also store nodes which use PhysX, basic types or engine-defined classes.

The Editor itself was instead integrated into our Application project. This allowed it access to game-specific classes - enemies, events, player controllers, etc.

During my specialization project, I added the ability to build/export dialogue trees in the Editor.

Levers & moving platforms

The first use case for our scripts (see above) was to connect levers to moving platforms and gates. The script attached to the lever was used to define the platform behavior. Can it be stopped mid-movement? Reversed? Does it go through a series of waypoints, or just back and forth between point A and point B?

In Unreal, our designers could set a number of variables: which platform(s) to link the lever to, how fast they should move, and in which direction (or to which position). We could thus define platform movement as relative (using direction vectors) or absolute (using waypoint positions by placing 3D widgets in Unreal).

All these variables would be exported from Unreal along with the level, and baked into the level description. On loading it into bean, the scripts' internal variables would be initialized with matching values.

Camera sequence system

I designed the camera sequencer to provide pre-defined control of camera movement during scripted events (e.g. cutscenes).

In order to accomodate our animators, I provided a Python script for exporting camera animations (position, rotation, and timestamp) from Maya. With this, they could either export the camera movement as-is (world transform), or in relation to a reference object. The script also applies adaptive frame reduction; if the camera is immobile for a second, only the first and last keyframe of that period is exported. All data was converted from Maya's coordinate system to bean's, then printed to a json file.

Our level designers were more experienced with Unreal Engine, so one of our tech artists coded export for level sequences. In addition, simple camera sequences could be created manually (e.g. with the use of generative AI such as ChatGPT) for quick testing or as placeholders.

Sequences with relative transform data were reference-object agnostic. This meant that the camera could take any object (or just a transform) as its reference point. The data that defined a camera orbit around the player character could equally be used to orbit an enemy, or a point in space. The same applied to "look-at" targets, i.e. where the camera would be oriented towards during the sequence.

To easily test this functionality, I built a camera sequence manager interface with ImGui, which our devs could access in-game in debug mode.

The team: Water Leaks Studio

Water Leaks consists of 20 students at The Game Assembly, Malmö. Spite is the first of three games we will be making together during our second year at TGA.

Programmers

Artists

Animators

Level Designers

Tech Artists