千山萬水：A THOUSAND MILES AND TEN THOUSAND WATERS
3D Video Game
Worked for:
5 weeks, Apr - May 2023
Created by:
Rachel Wu and Erika Sampson
Music composed by:
Nan Jiang
Individual Responsibilities:
5 weeks, Apr - May 2023
Created by:
Rachel Wu and Erika Sampson
Music composed by:
Nan Jiang
Individual Responsibilities:
- game design
- mechanic design
- programming
- shaders
A Thousand Miles and Ten Thousand Waters was the final project for my CS 221: Digital Worlds for Gaming course. It is a 3D third-person puzzle game where the player plays as Xiao-mei, one of the many attendants of Xiwangmu (the Queen Mother of the West), who has been tasked with finding the peaches of immortality. In the section of this game that we developed, Xiao-mei has fallen into a cave and must find a way out. The purpose of this project was to practice using Unity and C# for third-person 3D game development, as well as introduce us to developing games for controllers.
Development Process:
My partner and I both wanted to explore representation with games and agreed that we wanted a game that explored our shared heritage. We were initially inspired by titles such as Nine Sols and 8 Doors: Arum’s Afterlife Adventure, games developed by Taiwanese and Korean game developers, respectively, that are influenced by each country’s mythologies. Our brainstorming process started with researching Chinese / Taiwanese mythology and folklore, until we finally determined that our game would incorporate elements from the story of Xiwangmu, the Queen Mother of the West. Afterwards, we worked on a one-page design document for the entire game, despite only working on a small section of the game, so we could understand how the section would fit into a larger game. Once we had a general idea of the game, we worked on creating a map of the physical layout of our smaller section, to make sure the section we were developing was manageable in the amount of time and manpower we had. Next, we greyboxed our scene out and planned out details like the scripts, game assets, dialogue, puzzles, and visual style.
While my partner worked on gathering assets and building out the physical scene, I worked on scripting all the gameplay elements. The very first mechanic I worked on was the sliding puzzle, where players moved shuffled tiles around until they created a complete image, a mechanic central to this section’s gameplay. This mechanic involved a script that would switch the camera to an overhead view and the controller to the puzzle controls when the player entered “puzzle mode”, as well as a script that slid the in-game blocks around by keeping track of the empty space within an array of arrays and checked if the blocks created the solution image. For the camerawork, I learned how to use Unity’s Cinemachine system to switch between cameras, create cutscenes, and use dolly cameras on tracks.
For our first playtesting session, we created one complete puzzle with simple UI instructions on the controls for people to test. The objective of this playtest was to determine the difficulty of the puzzle, whether more instructions were necessary, and if the image used for the puzzle was too confusing. Having this playtest was important for us because as the person who created the puzzle I knew how to solve it in five steps, and therefore couldn’t be objective on the true difficulty of the puzzle. During the playtest, we timed our players to give them an equal amount of time and we had a set of prewritten questions for our playtesters to answer once they were finished. The feedback that our five playtesters gave us helped us determine that while our instructions were clear and players had no problem figuring out how to play, the difficulty of the puzzle was a little high, mostly because people could not figure out what the final image was supposed to look like. Some people remarked that seeing the solution image would have helped, while others expressed that the difficulty of the puzzle was what drove them to keep playing.
After playtesting, I created a hint system to work alongside the puzzle mechanic. Taking into account the different opinions of our playtesters, I designed the hint system so players could choose whether they wanted to see the final image and how much of the final image they wanted to see. This meant that players who only wanted a little nudge in the right direction could choose to see the placement of two tiles, while players who wanted an easier experience could choose to see the entire image. The hint system scripts allowed players to navigate the hint UI and pulled up the appropriate level of hint according to player selection and the current puzzle.
Once my partner finished building out the tunnel systems at the very beginning of the game section, we realized that the environment was dark and players might get confused, potentially never entering the final cave area containing the bulk of the gameplay. To solve this problem, I designed a guidance system where players would follow a floating entity that emitted light toward the tunnel exit. The script for this mechanic was partially inspired by my train movement script from my previous VR project, Alien on a Train. It involved the floating entity, visually represented by a particle system, moving towards the next waypoint once players had arrived at the trigger area around the current waypoint. I also wrote some scripts for a narration system that operated in a similar fashion, typing out the current narration text if the trigger area was entered while keeping track of the next text object from an array of text objects.
Since our game was using Chinese paintings as the images for our puzzles, I wanted to incorporate a painted aesthetic into the visuals of our game. Taking inspiration from the visuals of Okami, I learned how to use Unity’s shader graph to produce an inverted hull outline shader to replicate Okami’s ink wash painting aesthetic, and overlaid a simple parchment texture over the camera to make the game feel more like a painting.
Challenges Faced:
During this project, we decided to explore a new approach by collaborating with a student from the MUS 213 - Video Games: Composition & Criticism class to create music for a specific part of our project. For the collaboration, we had to be mindful that our project's progress relied on our collaborator's progress with her own final project—the music for our game. As a result, we made sure to provide timely updates of our own project by providing her with detailed descriptions and screenshots of the game, and later providing a recorded playthrough of the finished tunnel sequence she could use for her final presentation. The result was a captivating and haunting piece inspired by traditional Chinese music, which effectively enhanced the initial sense of unease in the tunnels. This collaboration tested our ability to coordinate effectively, meet multiple different deadlines, and maintain clear communication.
Another challenge we faced was with the narrative portion of the project. In every video game related project I’ve done, some part of the original plan has had to be cut out, and this project was no exception. As we neared the deadline for our project, it became apparent that we would not have time to implement the narration system, despite already having the dialogue written out and a script to trigger the narration text. Had we pushed ourselves to simply stay up and dedicate all of our free time to this project we might have been able to implement it, but my previous experience with another project had taught me otherwise. The possibility of running into unforeseen errors was too high, and in our opinion, having no narration system was preferable to having a sloppily implemented and bug-riddled narration system. Instead, we dedicated our remaining time to polishing the features already present in our project, and using the environment to invoke the senses of uncertainty and awe we were originally using the narration for.
Lessons Learned:
While developing A Thousand Miles and Ten Thousand Waters, I learned the importance of planning and once again experienced the value of playtesting your game. Having a detailed understanding of everything we would need for our game and staying with our plan made the development process smoother. After developing our previous project, Fish Simulator, my partner and I decided that we wanted to continue exploring game and level design for a confined space, which is where the idea for a tunnel system leading into a larger cave came in. Rather than feeling restrictive, having a defined area for our game challenged us to smartly make use of the space and prevented us from expanding the project to an unmanageable size. Bigger isn’t always better!
Working on A Thousand Miles and Ten Thousand Waters also allowed me to further my skills with Unity and C#, as well as learn about shaders, how to make shaders, and how to create games meant for a controller. If given more time to work on this project, I would finally implement the narration system to fulfill our original vision for the project. I would also make the controls smoother, and have a better transition in and out of “puzzle mode”.
Development Process:
My partner and I both wanted to explore representation with games and agreed that we wanted a game that explored our shared heritage. We were initially inspired by titles such as Nine Sols and 8 Doors: Arum’s Afterlife Adventure, games developed by Taiwanese and Korean game developers, respectively, that are influenced by each country’s mythologies. Our brainstorming process started with researching Chinese / Taiwanese mythology and folklore, until we finally determined that our game would incorporate elements from the story of Xiwangmu, the Queen Mother of the West. Afterwards, we worked on a one-page design document for the entire game, despite only working on a small section of the game, so we could understand how the section would fit into a larger game. Once we had a general idea of the game, we worked on creating a map of the physical layout of our smaller section, to make sure the section we were developing was manageable in the amount of time and manpower we had. Next, we greyboxed our scene out and planned out details like the scripts, game assets, dialogue, puzzles, and visual style.
While my partner worked on gathering assets and building out the physical scene, I worked on scripting all the gameplay elements. The very first mechanic I worked on was the sliding puzzle, where players moved shuffled tiles around until they created a complete image, a mechanic central to this section’s gameplay. This mechanic involved a script that would switch the camera to an overhead view and the controller to the puzzle controls when the player entered “puzzle mode”, as well as a script that slid the in-game blocks around by keeping track of the empty space within an array of arrays and checked if the blocks created the solution image. For the camerawork, I learned how to use Unity’s Cinemachine system to switch between cameras, create cutscenes, and use dolly cameras on tracks.
For our first playtesting session, we created one complete puzzle with simple UI instructions on the controls for people to test. The objective of this playtest was to determine the difficulty of the puzzle, whether more instructions were necessary, and if the image used for the puzzle was too confusing. Having this playtest was important for us because as the person who created the puzzle I knew how to solve it in five steps, and therefore couldn’t be objective on the true difficulty of the puzzle. During the playtest, we timed our players to give them an equal amount of time and we had a set of prewritten questions for our playtesters to answer once they were finished. The feedback that our five playtesters gave us helped us determine that while our instructions were clear and players had no problem figuring out how to play, the difficulty of the puzzle was a little high, mostly because people could not figure out what the final image was supposed to look like. Some people remarked that seeing the solution image would have helped, while others expressed that the difficulty of the puzzle was what drove them to keep playing.
After playtesting, I created a hint system to work alongside the puzzle mechanic. Taking into account the different opinions of our playtesters, I designed the hint system so players could choose whether they wanted to see the final image and how much of the final image they wanted to see. This meant that players who only wanted a little nudge in the right direction could choose to see the placement of two tiles, while players who wanted an easier experience could choose to see the entire image. The hint system scripts allowed players to navigate the hint UI and pulled up the appropriate level of hint according to player selection and the current puzzle.
Once my partner finished building out the tunnel systems at the very beginning of the game section, we realized that the environment was dark and players might get confused, potentially never entering the final cave area containing the bulk of the gameplay. To solve this problem, I designed a guidance system where players would follow a floating entity that emitted light toward the tunnel exit. The script for this mechanic was partially inspired by my train movement script from my previous VR project, Alien on a Train. It involved the floating entity, visually represented by a particle system, moving towards the next waypoint once players had arrived at the trigger area around the current waypoint. I also wrote some scripts for a narration system that operated in a similar fashion, typing out the current narration text if the trigger area was entered while keeping track of the next text object from an array of text objects.
Since our game was using Chinese paintings as the images for our puzzles, I wanted to incorporate a painted aesthetic into the visuals of our game. Taking inspiration from the visuals of Okami, I learned how to use Unity’s shader graph to produce an inverted hull outline shader to replicate Okami’s ink wash painting aesthetic, and overlaid a simple parchment texture over the camera to make the game feel more like a painting.
Challenges Faced:
During this project, we decided to explore a new approach by collaborating with a student from the MUS 213 - Video Games: Composition & Criticism class to create music for a specific part of our project. For the collaboration, we had to be mindful that our project's progress relied on our collaborator's progress with her own final project—the music for our game. As a result, we made sure to provide timely updates of our own project by providing her with detailed descriptions and screenshots of the game, and later providing a recorded playthrough of the finished tunnel sequence she could use for her final presentation. The result was a captivating and haunting piece inspired by traditional Chinese music, which effectively enhanced the initial sense of unease in the tunnels. This collaboration tested our ability to coordinate effectively, meet multiple different deadlines, and maintain clear communication.
Another challenge we faced was with the narrative portion of the project. In every video game related project I’ve done, some part of the original plan has had to be cut out, and this project was no exception. As we neared the deadline for our project, it became apparent that we would not have time to implement the narration system, despite already having the dialogue written out and a script to trigger the narration text. Had we pushed ourselves to simply stay up and dedicate all of our free time to this project we might have been able to implement it, but my previous experience with another project had taught me otherwise. The possibility of running into unforeseen errors was too high, and in our opinion, having no narration system was preferable to having a sloppily implemented and bug-riddled narration system. Instead, we dedicated our remaining time to polishing the features already present in our project, and using the environment to invoke the senses of uncertainty and awe we were originally using the narration for.
Lessons Learned:
While developing A Thousand Miles and Ten Thousand Waters, I learned the importance of planning and once again experienced the value of playtesting your game. Having a detailed understanding of everything we would need for our game and staying with our plan made the development process smoother. After developing our previous project, Fish Simulator, my partner and I decided that we wanted to continue exploring game and level design for a confined space, which is where the idea for a tunnel system leading into a larger cave came in. Rather than feeling restrictive, having a defined area for our game challenged us to smartly make use of the space and prevented us from expanding the project to an unmanageable size. Bigger isn’t always better!
Working on A Thousand Miles and Ten Thousand Waters also allowed me to further my skills with Unity and C#, as well as learn about shaders, how to make shaders, and how to create games meant for a controller. If given more time to work on this project, I would finally implement the narration system to fulfill our original vision for the project. I would also make the controls smoother, and have a better transition in and out of “puzzle mode”.
