top of page
Wondercade_Arcade_Logo_edited.png

Engine: Unity 2019.2.2f

Language Used: C#

Primary Roles: AI, Building System, Mini-Games, Game Saves

Platforms: Windows PC, PS4

Additional Roles: PS4 Port, Post Processing Effects, Progression

bitbucket-icon-8.jpg
app-icon.png

Wondercade Arcade is a multi-perspective management simulator where players have to manage and restore an old arcade that is inherited from you're grandfather, back to its former glory. It was a project I developed in sixteen weeks as part of my second year major production while studying at the Academy of Interactive Entertainment and was the first multi-platform project I developed for both PC and Playstation 4. Additionally, this project heavily utilized my Visual AI behaviour system i developed in my spare time at the start of the year to create the customer and mini game AI while also heavily utilizing JSON formatting for game saves.

*Trailer made by Adam Klappers

+.png

Customer AI

With this project I wanted deploy my visual AI system I developed earlier this year as a test case for seeing if the system works in large scale projects and to see how far I can push it. This project was the perfect case as the customers are meant to make logical decisions based of their current needs while navigating the arcade during opening hours. There decisions are determined based of their current stats such as hunger, thirst and boredom which are returned as a weight scores in each behaviour that are connected to a roulette selector node which determines whether to play an arcade or to find a vendor. Both behaviours determine which arcade or vendor to navigate to and utilize by finding all placed items of the desired type and choose the closet and cheapest one based on their current desire (i.e. wants to play pong or wants a drink). However, when not currently acting upon one of these behaviours, the customer is either patrolling outside to predefined patrol points if they haven't entered the arcade yet or they are wandering inside by sampling a random position from the arcade's navigational mesh and navigating to it. If the AI's needs isn't satisfied which is determined by a morale meter which decreases if their hunger, thirst or boredom crosses a particular threshold, the customer leaves the store in frustration and never return which negatively impacts your analytics.  

+.png

Code Sample - Customer Behaviours

To make the customers appear more human they had to act more naturally upon their current moods which is why their stats such as hunger, thirst, boredom and morale are constantly fluctuating while navigating the arcade. This is why over periods of times their needs are constantly increasing and changing as they must be met in order to prevent their morale from crossing the minimum threshold that causes them to be frustrated and have a negative impact on the arcade. All this human like behaviour is achieved via the AI stats system that keeps track of its current needs by checking and setting the required parameters on the behaviour tree for executing the required actions. Additionally, this system also checks its environmental surroundings to see if its not in a run downed room by constantly casting a ray downwards to check if the floor has a dirty tag, if so the customer will lose morale at a faster rate due to be dissatisfied with how the player is maintaining their store. The whole system is dependent on whether the player has placed the necessary items in the arcade to keep the customer fulfilled.

+.png

Code Sample - AI Stats

stats.png
+.png

Game Saves

Similar to my work on the Tiki Trials level editor, I again decided on utilizing the stream writer and stream reader classes to read and write game data to a file via a JSON string. However, unlike the system in Tiki Trials where only level data had to saved, this system had to save and load the exact state the player was in when saving such as what items have been placed, their positions, what the customers were doing, where the player is, what time of day it is, etc. This task was without a doubt a challenge, as I'd never taken on game saving system of this scale. Despite the difficulty, I overcame this challenge by placing data structs above their respective classes that hold the require data to be serialized while also placing a main data struct above the serialization class that contains references to these data structs. Additionally, every class that contained a serialization data struct contained a save and load function that gets called every time the game saves and loads. Essentially, I utilized a factory pattern that manufactures a game state based on the data fed to it when loading in.

Yet while this game utilizes an auto save system, the serialization of the current game is vital for when playing a mini game as the main scene is unloaded. There was no exception for not allowing the player to seamlessly transition to and back from the mini games, immersion needs to be maintained. Furthermore, a current save system was created that persists between scenes to keep reference to the current save file that is loaded but additionally also holds a game data data struct for holding save data when playing on the Playstation 4. Due to the limitations of time and not having access to the Playstation developer forums I couldn't figure out how to write to and read from the PS4 and it's supported file types. I had to utilize this approach as it was the only solution for preserving data between scenes without writing to disk. While not happy with this downgrade, it's the only main done I had to for for PS4 other than a few quality elements as game data will be lost when exiting the application or returning to the main menu.

+.png

Code Sample - Serialization & Save Example

Example: Saving AI Behaviour (Choose Arcade Behaviour)

+.png

Building System

After reflecting on the experiences I gained following the completion of the Tiki Trials level editor, I decided upon making a system that improves upon the mistakes I made with Tiki Trials. For instance, this time around I decided upon generating a grid on start up instead of manually creating one in the editor in order to save unnecessary setup time. This is accomplished through placing generation points in the editor which generates a grid of 1 by 1 cubes with no mesh in rows and columns of specified size on start up. Additionally, I didn't want to have to keep track of a list of generated cells and figure out which ones I can navigate to, instead I just wanted to keep track of which cell my cursor was over in order to snap the preview item to the currently highlighted cell. Had this approach been taken for Tiki Trials it would have saved enormous amounts of set up time as complete grids can be generated within seconds of any desired size.

+.png

Code Sample - Grid Generation & Navigation

I wanted to resolve the pain of the placing and editing system I made for Tiki Trials as it required me to take into consideration the various ways the designers setup prefabs prior to my involvement on the project. This is why I decide upon every placeable item being setup the same way to avoid having this unnecessary headaches. Each place-able items model is attached as a child to generic cube with the model's bottom being flush with the primitive with any scripts that holds the items traits is attached to the parent. Once setup the cubes mesh is disabled and the cubes collider is adjusted to fit the model's. With this approach i can now simply snap and connect items perfectly to cells like Lego bricks by simply applying an offset of one on the y axis as everything is technically a cube. The same apply's for wall items except making it flush with the right side of the cube and applying a point six offset and changing its forward vector to match the direction of the normal of the side of the wall the cursor is on and applying the offset in its new forward direction.

 

Furthermore, a manager script was developed to hold references of every script in the building system which allowed me simply reference the building manager in any other system if I need to access a particular section of the system. Additionally, the main functionality of the building manager is to deal with entering and leaving certain edit modes such as purchase mode (buying and placing items), edit mode (moving or selling placed items), destroy wall mode (destroy walls to open up more space) and cleaning mode (restore damaged rooms). Everyone of these modes are turned on via their set mode function (i.e. SetEditMode(true)) which exits the office computer (where these modes are accessible) while switching to edit view and disabling the default control map. Depending on the mode a few different functionality are enabled, for instance a preview of the item you wish to place will appear in the cell the player is currently highlighting during purchase mode or destruction UI will be enabled if entering destroy wall mode.

+.png

Code Samples - Building Manager & Placement System

+.png

Playstation 4 Porting Process

The Playstation 4 was always a platform considered from the beginning of development which is why we used the Rewired Control Mapper asset to bind our controls as it saved a considerable amount of time as we didn't have to write our own control map classes that supports various types of controllers on different platforms. It wasn't until about four weeks into production that I first got access to the PS4 dev kit in which the core game didn't have a game play loop going yet but nevertheless I spent a good few days learning and experimenting with the hardware and figuring out its limitations and the optimization settings that Unity offer for PS4. In the end i manage to get the game running constantly between fifty-sixty frames per second and was the only student in my cohort to successfully port a project to the console with very little assistance from teachers. The most assistance I got was setting up the software to deploy and remote view to the kit and any additional trouble shooting with connecting to it over the network. In the end after getting a feel and basic understanding for how to deploy projects to the PS4, I was very surprised at how little code I had to write to get it working as at most I did was adding preprocessor checks (i.e. #if UNITY_PS4) for the game save system and a controls display handler to work properly on their respective platforms. However, I mostly got it to work by tuning some of the player settings, specifically by enabling Unity's new graphics jobs system which spreads the rendering load across multiple threads and turning down some quality settings such as textures and shadow resolutions. Additionally, performance saw some incredible boosts on both platforms by baking the occlusion culling.  While this process helped me achieve the goal of getting the project running at a reasonable frame rate on the PS4, I imagine this process will vary from project to project depending on graphics intensity and background processes intensity

+.png

PS4 Gameplay

bottom of page