Game

AY1920 Semester 2 CP3108: Team Game Development (cadet)

In coordination with https://github.com/source-academy/cadet-frontend/pull/1058, this project aims to extend the cadet backend to allow storage of game data in backend.

Improvement: Previously the user's game data (story to play, collectibles, status of game inside a story...) is stored in local storage, making it troublesome for user to change another device to play the game. Now the cadet backend is enabled to store user's game data.

Achieved by:

1. Studying the structure of the database. Found out that the story to play for a user is bound with the table "assessments" and the relevant data can be retrieved from the index.json file. To keep track of the user's current story, we only need to make relevant modifications in the frontend. More details can be found in the url above.
2. Using migration to extend the field of table "user" by one additional column. Namely "game_states".
   • game_states, being a new attribute of the table "user", is a map. Inside the map, there are another map called "collectibles" and an array of strings called completed_quests.
   • collectibles is a map, this is for the convenience of frontend. A collectible is a picture in frontend. The picture has a nick_name, which we would like to call in the process of game developing. The nick_name is the key of the map. The picture has a real name, which is the name of the picture source file in the assets server. The real name is the value of the map.
   • completed_quests is an array of strings. The purpose of this is to better fit the game process. When the user plays the game, an action_sequence, which is an array of strings, is generated to represent the user's state inside the game. To save users' game states by generalising this idea, we call this array by the name "completed_quests" and save it in backend along with the user.
3. Added functionality for the backend to retrieve, update, reset users' game_states.
   • To make whole structure more modular, a new module called Cadet.GameStates is created. Inside this module, several functions regarding game data are included.
   • Retrieving functions: currently, the game_states, collectibles and completed_quests can all be retrieved individually.
   • Update functions: currently, the game_states can be updated as a whole. Individual update functions were once implemented, but they were excluded afterawards because of redundency.
   • Reset functions: currently, the game_states can be reset to default status, in case of unwanted updates. In this development, this functionality serves as a helper in testing. In future development, more functions can be specified, such as reseting collectibles, reseting completed_quests or deleting one particular collectible.
4. Properly adjust other parts of the backend to fit the new functionality.
   • The router file is updated with added routes to the newly implemented functions.
   • The user_controller file is modified to serves as bridge between the router.ex and game_states.ex.
   • The user_view file is updated so that the rendering of index.json file can now include the user's game_states.

To do:

• Since this development is driven by the need of 19/20 cp3108 game team, it is not clear whether the functions added in current implementation are enough to satisfy all the need of game development in the future. In other words, more functionalities need to be further specified later on.
• Due to constraint of knowledge, exception handling part of newly added functions is to be implemented (in elixir).