“Washed ashore with no rum in hand, deckhand Maruk must woozily dash, jump and traverse across a treacherous archipelago.
Strike a bargain with the ghost captain Greedy McNeedy to peer into the World Beyond. Find booty, and hopefully a way home.”
About Maruk Shipwrecked
Maruk Shipwrecked is our sixth game project and our second game as Behemoth and using our in-house LAMP Engine. This project was all about using what we learnt from Spite: Ashes of Epthael to improve our teamwork and skills.
One of the requirements for Maruk Shipwrecked was that we had to support and use visual scripting for “meaningful gameplay”. To prepare us for this we had started a visual scripting course to learn about what it is and how to make use of it. As part of that course we were given a base system to work from and it was expected that we were to implement that system into our engine.
My first job was to get the editor into our engine and be able to run the scripts. I wrapped the editor into a manager class that handles all of the input and rendering for the editor.
While the system and editor were a great starting point, there were features that were missing and or were bugged. Some of the smaller ones were support for loading and saving multiple scripts as the original system always saved to a file called “graph.data”. Zooming in and out was always centered at the origin point. But most annoyingly, each node had pins with predefined data types. Which means if I wanted to make a node that adds two numbers it would only be able to handle one data type. If I wanted to be able to add two floats and two ints I would have to make two nodes. One that takes in two floats as inputs and outputs a float, and another for ints. The solution was to implement wildcard pins where a list of allowed data types could be defined and nodes that handle multiple different data types. The base system we got already had a custom class called “Typed Data Container” that can hold any type of data and already had support for changing it’s underlying data type during runtime.
I had to update a lot of the underlying logic in the script graph editor to be able to handle the new wildcard pins. Figuring out if a connection between two pins is valid. But the biggest struggle during development was serializing and deserializing the .data files. With the addition of the new wildcard pins I had to save which pins where wildcard pins and what data type they had when they were saved as well as any default data they may have had. Because of my lack of understanding of the system it led to a lot of bugs which caused the scripts to essentially become corrupted and unreadable. The silver lining was that the group as a whole had not used the visual scripting much and the few scripts that got corrupted were small and easy to recreate, which I had to do a few times. But after a while the wildcards were working as intended.
One bug that was noticed very late in development was that a wildcard pins default data would not be the saved. After looking through the serializing and deserializing and finding that the data was saved correctly and loaded correctly I found the bug. It happened because the loading of a script happens in multiple stages, one where all the nodes and pins are created and their default data is written, and another where all the connections are set. What I had missed was that to make wildcards work I check when a new connection is made and change the pins data type to match the source. When this is done it resets the data saved, even if the data type that was switched to is the same as it was. Luckily the fix was simple, check if the type it wants to change to is the same as the current type then don’t call the function. This way the data does not get overwritten.
The visual scripting is a vital part of Maruk Shipwrecked as it handles when to play cutscenes, when to start dialog, special camera sequences and simple moving or rotating objects such as the windmills and floating platforms.
Maruk Shipwrecked
*No Trailer Yet*
“Washed ashore with no rum in hand, deckhand Maruk must woozily dash, jump and traverse across a treacherous archipelago.
Strike a bargain with the ghost captain Greedy McNeedy to peer into the World Beyond. Find booty, and hopefully a way home.”
About Maruk Shipwrecked
Maruk Shipwrecked is our sixth game project and our second game as Behemoth and using our in-house LAMP Engine. This project was all about using what we learnt from Spite: Ashes of Epthael to improve our teamwork and skills.
One of the requirements for Maruk Shipwrecked was that we had to support and use visual scripting for “meaningful gameplay”. To prepare us for this we had started a visual scripting course to learn about what it is and how to make use of it. As part of that course we were given a base system to work from and it was expected that we were to implement that system into our engine.
My first job was to get the editor into our engine and be able to run the scripts. I wrapped the editor into a manager class that handles all of the input and rendering for the editor.
While the system and editor were a great starting point, there were features that were missing and or were bugged. Some of the smaller ones were support for loading and saving multiple scripts as the original system always saved to a file called “graph.data”. Zooming in and out was always centered at the origin point. But most annoyingly, each node had pins with predefined data types. Which means if I wanted to make a node that adds two numbers it would only be able to handle one data type. If I wanted to be able to add two floats and two ints I would have to make two nodes. One that takes in two floats as inputs and outputs a float, and another for ints. The solution was to implement wildcard pins where a list of allowed data types could be defined and nodes that handle multiple different data types. The base system we got already had a custom class called “Typed Data Container” that can hold any type of data and already had support for changing it’s underlying data type during runtime.
I had to update a lot of the underlying logic in the script graph editor to be able to handle the new wildcard pins. Figuring out if a connection between two pins is valid. But the biggest struggle during development was serializing and deserializing the .data files. With the addition of the new wildcard pins I had to save which pins where wildcard pins and what data type they had when they were saved as well as any default data they may have had. Because of my lack of understanding of the system it led to a lot of bugs which caused the scripts to essentially become corrupted and unreadable. The silver lining was that the group as a whole had not used the visual scripting much and the few scripts that got corrupted were small and easy to recreate, which I had to do a few times. But after a while the wildcards were working as intended.
One bug that was noticed very late in development was that a wildcard pins default data would not be the saved. After looking through the serializing and deserializing and finding that the data was saved correctly and loaded correctly I found the bug. It happened because the loading of a script happens in multiple stages, one where all the nodes and pins are created and their default data is written, and another where all the connections are set. What I had missed was that to make wildcards work I check when a new connection is made and change the pins data type to match the source. When this is done it resets the data saved, even if the data type that was switched to is the same as it was. Luckily the fix was simple, check if the type it wants to change to is the same as the current type then don’t call the function. This way the data does not get overwritten.
The visual scripting is a vital part of Maruk Shipwrecked as it handles when to play cutscenes, when to start dialog, special camera sequences and simple moving or rotating objects such as the windmills and floating platforms.
