-
Notifications
You must be signed in to change notification settings - Fork 164
Game (AY1920 Semester 2 CP3108)
This project improved the development workflow for content creators of the Source Academy's game component.
Improvements include:
- A new story testing environment for content creators to test out story scripts they have written or game assets they have created. The environment accepts story scripts from local devices instead of relying on files from the cloud.
- Drag and drop of scripts to load them has been made available so that content creators can directly see the changes they have made.
- Global mission pointer to allow content creators to test a particular mission by simply changing the mission number in the master XML file. The environment will automatically fetch mission information from master XML and load the correct mission.
- Ability to override game state through JSON.
- New snapshot tests for story scripts uploading and material uploading.
- Refactor game managers to improve readability and maintainability of code.
- New telescope/night vision filter.
Motivation: The previous version of cadet-frontend had no story testing environment. To test a story script, it must be uploaded to AWS. Also, staff were unable to replicate the student's perspective on the live system. Therefore, this new Game-dev page aims to improve the workflow for story writers to test new or edited stories.
Staff roles focus more on the development and authoring of the game system, whereas students only need to concern themselves with the gameplay experience. It is hence necessary to differentiate these two groups so that cadet-frontend displays different functionalities.
The objective is to set up and style the relevant React components that will best streamline the staff authoring experience. The uploading of story XML files re-uses the mechanism of Materials upload. This page connects to the game-state.js, which simulates the backend.
To use this feature, the back-end must be set up with an AWS S3 bucket and the cadet repo.
to set it up you need to configure secrets.exs and change the materials_bucket field under uploader to your own bucket name and add this into secrets.exs
config :ex_aws,
access_key_id: {ID}
secret_access_key:{KEY)
Currently, stories and assets for the live system are being retrieved from an AWS S3 bucket. However, there is no counterpart in place for a test environment. The backend allows staff to upload course materials. We want to extend this system such that story assets can also be uploaded by staff and retrieved by the game.
- Achieved by updating test page to automatically switch to test-stories folder.
- Follow-up: Set up a system to synchronize (push/pull) test story data between the live and test buckets.
Currently, all of the student's game completion progress (e.g. completed quests, obtained collectibles) is stored locally. This means that the game state for the student is not transferable between devices, and will reset if the student (for instance) switches browsers or clears their browsing data.
Future features such as achievements must remain consistent for the student, which is currently impossible due to the limitation described above.
- Achieved using session storage and adding back-end functionality to game-state.
To make sure that loading student's data from back end does not interfere with game testing, the game state data is stored in the session storage, which allows testers to easily change the game state via feature #6 and #7. This session storage is temporary and is limited to one browser session, hence every time the student opens the website, they will get the latest data. (Except for the save data in local storage, which has the user's current "location" in the story).
This is synchronized with the mission overview team's assessment overview. All the necessary information of what stories there are will come from this source of truth. So you will need to have some assessments that match the story files. These assessments will have to be published unless you override the game state.
- Achieved with a game state fetcher.
For staff who are testing the game, they will need to test under different conditions (e.g. custom time, custom user state).
Whatever is managed in the game state should be made customizable to support this. The functions to control which elements are overridden will come from the additions in #4.
- Achieved by adding ability to override the game state.
In the testing environment, the story writers should be able to drop a custom JSON file representing the student's current game state. The game engine will then load the game based on that data.
This JSON file will have these three things, sessionData, overrideDates, and overridePublish. A sample file will look like this.
{
"sessionData" :{
"story":{
"story": "sidequest-9.1", "playStory": false
},
"currentDate":"2020-04-12T14:22:03", //client's local time in Date() form
"gameStates":{
"collectibles":{"Best Coder": 'completed'}, //example collectibles
"completed_quests":["story-1", "story-2", "sidequest-8"] // example quests
}
},
"overrideDates":"true",
"overridePublish":"true"
}
Setting overrideDates to true means that you will view all the missions whether they have been closed or are not yet open Setting overridePublish to true means that you will be able to view unpublished missions. The underlying code is in game-state.js. Simply upload a json file containing these contents to game-dev page and it will override the sessions storage.
Page components location: cadet-frontend/src/components/game-dev The Game-dev page pulls story XML files from the Material folder, it shares the same uploading and downloading logic as the Material page. If you would like to test new stories or edit existing ones, drag and drop the relevant stories into the folder in the Game-dev page, the game will load the newly uploaded stories and run based on these stories. If no files have been uploaded, the game will automatically download story scripts from AWS. If you would like to test a particular story, make changes in the master XML file and upload. Refresh the page to test that particular story.
In the later storyline of the Source Academy game, the players will need to fix a telescope on the foreign planet together with the locals, therefore, a telescope filter will be useful to mimic the experience of using a telescope to see things.
There are 3 types of stories, one is where a story is a place you can explore (using the element), and another contains a quest which is made up of sequence of events which trigger once everything from dialogue to effects and starting of missions.
The last type is a combination of both. In this case, MAP and QUEST are siblings and A consists of a and/or . A dictates the areas the user may freely explore by default. A specifies a sequence of events that will take place. If a is present, the first one will typically be automatically loaded.
For a guide on the XML document style, please visit story xml.pdf at: https://bitbucket.org/cs1101s/cs1101s_story_1920_sem1/src/master/
Motivation: The game managers were not well-documented, there were also unnecessary or duplicated code in the system.
Contains the actual React component housing the game.
Launches the create-initializer. Called from the game's React component in index.tsx.
Contains the majority of the new changes that we implemented
- user.js contains user's role.
- hosting.js contains the necessary hosts for the user to get their stories from. Test story files are supposed to come from the material folder, and live story files will come from the standard story bucket.
- game-state.js uses session storage as it allows testers to change game state easily, while allowing students to pull data from the backend whenever they open up the website. It also handles general game state such as organisation of missions, as well as setting of the current mission pointer for students.
#614 game-display contains the stylesheets for the game engine.
Contains init function for rendering, calls PIXI.autoDetectRenderer(), which preferably calls WebGL for rendering.
renderer that appears in all other files refers to the following in story-xml-player.js:
renderer = PIXI.autoDetectRenderer(
Constants.screenWidth,
Constants.screenHeight,
{ backgroundColor: 0x000000, view: canvas }
);
stage is the root of the scene graph, all effects and objects are rendered on top of stage.
if you would like to use the renderer, call Utils.getRenderer().
Contains constants used throughout the game component, stored as a dictionary. Access the constants with Constants.key where key is the dictionary key.
To load story files from local storage, go to create-initializer.js, change the story id in the initialize function to the one you would like to test. Note that a story file has the format storyid.story.xml, the storyid will be the story id to pass in.
Fetch current location of player. Loads objects in a particular map. Manages transition from one location to another.
Render player avatar (if any). Technically a dialogue manager.
Communicates with backend to store player data.
Manages interactivity of object. Renders glow effect on objects (inside function parseInteractivity).
Load, play and unload quests.
Plays sounds from assets. The story XML dictates which sounds are to be loaded. The sounds are then loaded from the assets host and played asynchronously.
Loads story XML files from server.
Get renderer and save renderer stores the renderer to be used in different files. save renderer saves the initial renderer in init in story-manager-xml.js. get renderer is used in filter effects as well as in dialog manager (to show characters and text. story ancestor finds the story element that the current element (i.e. argument = node) is in.
Please visit https://pixijs.io/pixi-filters/tools/demo/ https://pixijs.io/examples/#/masks/filter.js for a full list of effects supported by PixiJS.
Glow effect - objects glow when the cursor hovers over.
Dark filter - transition from one location to another.
Telescope filter - only the part of the canvas within the circle can be seen, the rest are black.
Controls a black rectangle spanning the entire screen. This rectangle fades in and out to create the illusion of fading to black and back.
Clearly there is some kind of wrist device here but it is not included in the game yet.