- ❓ What is SMART SANDBOX (SS) (as of 2023/05/22)
- 📖 Frequently Used Terminology
- 📝 Technologies and libraries used
- 🎲 Central Logics
- 📝 Extra notes and recommendations (last updated: 2023/05/22):
SS is a platform in which the BCIT SMART team will be using to communicate the deliverables of the team to client in an easy and fun ways.
The host can create games by uploading grids of game items (e.g. cards, tokens, etc.) and generate a room from the game data in which others can join and interact with the generated items.
If you are starting to work on SS, please check the 👉 setup guide 👈
- Card: A card has two sides, front and back. Each side can use a different image. Card can also be flipped and piled.
Not to be confused with the poorly named 'cards' zone.
- Token: Similar to card except that tokens from the same deck are all identical.
- Piece: A piece has one side and a singular image. Pieces cannot be flipped and cannot be piled.
Create piles by dragging game objects of the same kind on top of another homogeneously-typed game object or pile.
Separate the pile by right-clicking and choosing Disassemble.
Piles are automatically disassembled when they are moved into a deck or hand.
- Hand: Game objects that are currently in a player's hand. These objects are hidden from and inaccessible by other participants while they exist in this zone.
- Deck: Game objects that have either not been dealt from their original deck or have been since them moved back into. Every Card should have a reference to their original deck such that they can be recalled back into it. Game objects that did not start in a deck should never have access to that deck (ie: card from the 'red' deck should never find its way into the 'blue' deck). A pile (ie: 'discard' pile) can however mix and match cards from different decks.
- Cards: Game objects that are not in any hand or deck belongs in this zone. Poorly named due to cards being the only game object type back in time. A more accurate name would be table or free.
Store information about that game, such as the name and decks that exist within it.
Store information about a deck of homogeneously-typed game objects (ie: deck of exclusively tokens).
allows a Game to be hosted and for other players to join.
stores information about the room, such as the players participating and the state of the Game.
- MERN Stack: This game is built with React.js on the front end, Express.js and Node.js on the back end, with MongDB being used as our database option.
- Socket.io: We use Socket.io for sending and receiving data between the client side and server side.
- Konva: A Canvas JavaScript framework that allows animations, transitions, layering and event handling etc. We use react-konva to handle the layering and the interactions among various game components.
- multer: A module which is primarily used for uploading images and files. It enables users to upload their own images and create customized games.
- sharp: A module that allows users to convert large images in common formats to smaller images of different dimensions.
- Axios: Axios is used for sending GET and POST requests and receiving response between client and server side.
- bcryptjs: A JavaScript library for password salting and hashing. It generates a 'salt' (a piece of randomly generated data) and combines it with the original password to perform password hashing for additional security.
- Dotenv: A node.js module that loads environment variables from a ".env" file into "process.env".
- Heroku: A cloud application platform for the deployment of our application.
overview of the build game process in /buildgame page
- image is uploaded by the user using the image upload form.
- if image size too big, the image is resized in client side to reduce server burden.
- The number of item in grid is specified in the form.
e.g. in the case of image below
There are 9 cards across and 3 cards down, in total 27 cards.
- The image and the rest of the formdata is sent to the server to slice image appropriately and create game objects.
- The generated item is sent back to client and displayed once user click on the location for the item.
- Once all items are added, click save game.
- Each items that were added are stored in database as Grid.
- A Game data is created from the ids of Grid objects and stored in database.
- Once a game object is successfully created, user is redirected to the dashboard.
overview of the play game process (initialization) in /room?=id page
- in the host Room page (/games), choose a game created by the user.
- Clicking the game will generate the room data in the server-side, and the room id is sent back to the client side to redirect the user to "/room?=
roomID" - Once redirected, room ID and username is used to add the user to the roomData stored in server.
- Once added, the server will emit the roomData to client.
- The data is received by the table of client and items are displayed.
- User action (drag, drop, flip, etc.) will send data to server to update the roomData.
- Once updated, server will emit the change to all users.
- Client will received the update data from server and update the local representation to match the most recent server data.
- The side bar has no function except for log out. discuss with Alan for it's purpose, and if it is deemed unnecessary, do remove.
- The zoom function for cards (e.g. zooming into card when hover) is a necessity, as some cards have texts in them and is illegible when they are at comfortable playing size (65px wide 91px high)
- It is recommended that your code follows the functional paradigm.
- Game Actions such as drag, move, flip, rotate, or whatever may be implemented should exist in the gameaction.jsx module.
- Game objects such as card, token, piece, or whatever may be implemented should exist in the gameRoomComponents directory.
- The heroku server will be slower than most client-side machine, so try to optimize the server performance by implementing uWebsocket.js or other server-side module.
- Read module-specific comments for further explanation.