Challenges
Billy Saves the World
All difficulties encountered while working with the proprietary Action Manager language and the methods used to overcome them.
Communicating with Back-End
Challenge
The Action Manager visual coding language had limitations in its capabilities. Completing certain tasks that required more complex logic proved difficult to achieve solely through the front-end.Action
Collaboration with the programmers responsible for maintaining and updating the Action Manager was essential for completing tasks such as implementing a more dynamic fast travel system. A fully functional prototype was personally created, after which the work progressed to the next stage of development. The task was divided into individual components and placed into two categories, with one focusing on front-end logic and the other on back-end logic. This categorization is illustrated above in a timeline format, showing the approximate order of code execution. Blue text represents work handled by the front-end, while red text indicates elements requiring back-end assistance, which primarily focused on making a map selection screen.Result
Through multiple meetings with back-end programmers, a clear understanding was established of the requirements needed to complete the task. Additional nodes were provided that enabled the front-end to control destination unlocking, player icon positioning, and the opening of the map selection screen. These contributions allowed for the successful completion of the more dynamic fast travel system.
Finding Uses for Actions
Challenge
Documentation on how actions functioned within the proprietary visual code was minimal, and few team members understood their operation. Actions existed as nodes of various types, each designed to execute specific logic. This lack of clarity made large-scale implementation difficult, particularly for programming remaining sections of the game in this language.Action
Completed areas of the game were analysed to determine practical uses for specific Actions.DoIf and Do were frequently observed in situations where a variable’s state required evaluation. These closely resembled C# if and else conditional statements.
Result
Clearer understanding of action functions improved efficiency in selecting the appropriate node for a given scenario. TheDoIf and Do Actions proved especially effective for branching dialogue, such as purchase interactions where the system verifies whether the player has sufficient protons and returns an outcome based on the detected amount.
In-Game Timers
Challenge
Several missions required timers. One example involved a non-playable character requesting a return visit at a later time to receive the next portion of a quest. A counter was created within a level, but leaving the level caused the timer to stop.Action
Through exploration it was discovered that the character, Billy, could have logic attached. As an experiment, the timer was moved to this asset to prevent the counter from stopping when exiting a level.Result
The above image demonstrates the outcome after the logic was moved from the level to the player’s character. It shows that wherever Billy travels, the timer continues counting because it is linked to an asset that always remains present during gameplay, rather than a specific location that may be absent if not loaded.
Organization
Challenge
Understanding the Action Manager visual programming language independently was challenging, requiring the creation of test levels and extensive debugging to grasp how specific nodes functioned. The next hurdle was devising a method to organize the game logic effectively.Action
A consistent system was developed to organize each mission into structured logic groups. Each corresponded to a unique mission, labelled accordingly. For instance,SnowmanQuest is shown in the flow chart above. These contained sequences, or scripts, which consistently began with Always to mark the starting point of execution. From there, various custom-named variations were triggered, such as CheckMission. Within them, conditions referenced variables named similarly to their related quests to maintain clarity. A period was used to separate descriptions, such as SnowmanQuest.MissionProgression. Additionally, player notifications for tracking progression utilised specifications of a different category, labelled as Mission. An example is Mission.SnowmanQuest.
