Ceramic Serenity
An interactive game intended for stroke survivors to play as a form of physical therapy. This game offers a low stress, low pressure experience for patients practicing movement in the lower half of their body. Players can select which pot they would like to create and fully customize the aesthetic afterwards!
Demo playthrough
How to play
Our game includes a variety of exercises including side abductions, balancing, and forward leaning movements.
When the player is interacting with the UI elements on the screen (i.e. selecting the settings button and game modes) the player uses front leaning as a way to control the buttons.
Once the chosen vase shape is chosen, the player can begin molding the pot by balancing on one foot. The pot will progress in its shape during the time the player is actively balancing.
After the pot is created, the player will be taken to a customization screen, where they can decorate their pot. In order to select a color or patter, the player must do hip abductions.
At the end of the player’s experience, they will be prompted whether they want to complete their pot or continue editing. If the player chooses to mark their pot as finished, they will be asked on the next screen whether they would like to view the gallery — a documentation folder of every pot they have made — or return to the home screen.
Target Audience
Our target audience is people who have suffered a stroke and are now disabled in the lower half of their body. Stroke survivors often have challenges with their balance and coordinated movement, due to this, specific exercises are necessary for relearning functional skills. Ceramic Serenity incorporates common rehabilitation movements with the relaxing act of sculpting pottery. We incorporated the exercises of hip abductions, balancing, and forward leaning movements to target stability, leg coordination, weight distributiong. These exercises connect directly to practices in physical therapy and ultimately aim to help improve activities like standing, walking, and balancing. By turning these movements into a game, it encourages, motivates, and provides researchers with consistent, meaningful tasks to use with their patients.
Milestone 1 - moodboard to mockup
Tech Progression:
- As we worked on the visual design aspects of our game, part of our team simultaneously worked on the programming aspects of the game. A brief outline of their planning goes as follows:
- Tech and tools utilized:
- Unity Capture plugin
- Unity UI Builder
- Blender/ Maya
- Substance painter
- Photoshop/Graphic design software
- Premiere Pro
- How will these tools be utilized:
- The Unity capture plugin will be used to allow live movement to be captured and utilized for player controls in the prototype
- Unity UI tools will be used to implement the menus, buttons, and icons that will guide and enhance the user experience.
- Blender and other 3D software will be used to create 3D assets and UV maps for the models. Those models will then be taken into Substance Painter to create texture maps that can then be applied to Unity materials.
- Photoshop/other graphic design software will be used to design any 2D visuals necessary for the experience.
- Premiere Pro will be used to create and edit the in-game sound effects.
- Implementation pipeline
- Asset creation will be done in their respective software such as Premiere Pro, Blender, or Substance Painter. Where assets will undergo their process to be finalized and possibly change based on feedback from playtesting or other circumstances.
- Mechanics, buttons, etc., will be made with placeholders to ensure functionality in the game first. As assets are finished, they will be implemented over these placeholders.
- Once functionality of mechanics is working and the assets are finalized. They can be fully implemented into the game as their systems will be working before their assets are completed.
- Tech and tools utilized:
Milestone 2 - finalizing the mockup
Tech Progression:
- Revising scene transition
- Change the system for scene transitions. Everything for the game stays in one scene instead of loading different scenes each time we want to load different UI.
- Gallery scene coding
- The game needed multiples scripts to make a gallery system work. The idea is to allow the user to “take a screenshot” of their finished creation, which they can view in the gallery screen accessed through the main menu or finishing the minigame.
- This system was achieved with three scripts:
- Script that renders the screenshot and manages the screenshots in memory.
- Script that tells the game how to load screenshots on the gallery screen.
- Script that activates the other script that renders the screenshot.
- Implementing movement mechanics and visuals
Milestone 3 - Completing visual assets & Implementation
Milestone 4 - final assets & Implementation
Tech Progression:
- 2D Art Implementation Pipeline
- We first created placeholders before implementing any visual assets. This was to ensure functionality before working with any visuals. Once functionality was fully ensured, we would parent an “image UI object” to anything that needed a visual, such as a button. Within the Image UI object, you can load any image file.
- This process wasn't needed for every object. As some objects, like the “Canvas,” already have functionality to load image files for backgrounds. So, parenting an image object like the canvas wasn't necessary.
- 3D Model Implementation Pipeline
- We implemented the models using the mesh render and some scripting. Adding a model is a simple click and drag into the scene, but for the gameplay, Unity tracks how long the player performs the required action, such as hip abductions and updates their progress. As their progress increases past certain thresholds, the script updates the mesh in the mesh render. resulting in the mesh switching with the scene.
- Overlay Bug Fix
- There was issues with the pattern and color selection gameplay. After the pot was customized, it would keep the same design, even if the user went back and made changes. This was fixed by creating a pot mesh that’s no longer a child of the canvas panel specific to gameplay phase 2 and the confirmation menu. The pot essentially exists between gameplay phase 2 and the confirmation screen; it’s the same pot mesh but at two different stages.
- Gallery Bug Fix
- The first issue encountered with the gallery was that the screenshot rendered on the same frame switching the scenes. Thus, it was taking a screenshot of both the pot and the gallery screen. This was fixed by adding a delay, or coroutine, of 2 frames to the UI switcher script.
- The issue that was never fully resolved was the gallery updating after the confirmation screen. For the user to see an updated gallery, they would need to go to it from the Home Screen.
- Sound Implementation
- A sound script was created with arrays of Music and SFX. The script was then connected to the buttons in the game with different play and functions to officially create a soundscape for the gameplay.
This website uses cookies.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.