How to Be A
Course: Design Educational Games (CMU 05-418).
Instructor: Erik Harpstead
Teammate: @Christina(Qianou) Ma
Project category: Game Design and Research
Pitch 1: Project Pitch.pdf
Checkpoint 1: Check#1.pdf
Final Writeup: DEG_Final_Report.pdf
Game Executables (Updating):
05/24/2021: Version 3.1 (en_US/zh_CN)
To Be Updated
YouTube Demo Video (one complete branch):
In my fourth year, I took Design Educational Games (CMU 05-418/818) with Professor Erik Harpstead.
For this project, we were grouped in teams of 2-3 people. We were supposed to design an educational game -- there were not so many restrictions: as long as we do not implement 3D games everything should be good (though if you were capable enough to make one, you could talk to Erik). Thus, the project required the teammates to co-operate well through a valid game design industrial process: brainstorming, researching, implementing, prototyping, script writing, and iterating. We have only less than a month to finish an MVP of a game -- therefore, we were recommended NOT to make a digital game, because programming can be really time-consuming.
However, as my team were really confident of ourselves, we still decided not to ban digital games from our brainstorm selections. Well, this paved the bedrock for us to finally make a game, which is praised as "the most impressive digital game that was ever made in the history of this course".
In the preparation stage, we set up our roles in this team. Since I have most game design experience, I was responsible for the majority of gameplay design, programming and game arts, and my teammate Christina was responsible for doing game research, poll & survey distribution and story script writing. Here I will write more about my part, and if you are interested in Christina's job, you can refer to her page here.
The first job for us is to decide what to make. We used a Miro board to brainstorm about the topic of the game.
And we decided to make a parent education game very soon. This is likely to be a relatively novel topic to this course, as many people would choose topics like finance, environment, or programming, etc.
After we decided the topic, we started to make the early brainstorm. The following diagrams were the early proposals of this project.
* Project visuals by Tony
Integrating with the feedback from the peer review, we finally chose the second proposal -- the chat simulator as our final project topic.
As we decided that the game form is a chat simulator, we could not escape from the responsibility to write a decent story. This story should support branching, because parents, the players, will learn from different ending of the story. On the other hands, we only have about a month, so we can't make the story extremely long.
Initially we wanted the story to be passing through a lifespan of a certain character, but we quickly noticed that this is too ambitious. Therefore, we decided to only make a part of a character's lifespan. During this selected part, the players should experience a relatively complicated parent-children interaction. Also, we need to consider about the group of parents we are focusing at, for example American parents may be totally different from Chinese parents.
Our final scenario decision was something like:
Children is preparing for an important exam. During this mentally pressured time period, the interaction between children and parents can be difficult and complicated.
And we start our prototyping from here. The process of making story is too wordy to speak here, so please refer to the game document if you want to take a look at how the story is iterated.
If you are interested in reading the story iterations in Chinese, here's the first two iterations.
Iteration 1 (Traditional Chinese).pdf
We followed the generic UI design process. The game process is relatively simple, so there shouldn't be too many UI elements to draw.
The following list shows all of the required scenes.
The connection logic is decided by the game process. A game day of our chat simulator starts with the player (as parent) goes to the office. In the office, the player may respond to messages on the computer screen via some software, or initiate some conversation to some NPC. Once they finished the conversation for that day, they may return home; if it is Friday, the child will also return home (otherwise the child is in a boarding school). The player may go from living room to bedroom and end the day from there. The second day will start by loading page from home to office.
Thus, the following pages are the first lo-fi versions of the page layouts. We tested them and they were proved to be intuitive through our playtestings.
Later we start to polish the interface, adding some visual art elements. At first we decided to make Persona 5 as our style reference, because it is relatively relaxing and easy to make within a month. And this is our second UI version.
As time is really limited, some of the background illustrations are not completed in this iteration; I used photos from google instead. However, even though this iteration received some good comments from my playtesters, many of them also reflected that the UI style looks somewhat irrelavant to the game style. The game does not look like some game that requires a pop-style UI; the story happens in the school, and many playtesters (around 40-50 years old) are not fans of this style. Therefore, we made the third iteration of UI style, and this time it really took me a lot of time to draw.
Here's the game closed loop and game system diagram.
And I think they explain how the game system works well. If you want to read the entire process of how we added the supplementary systems into the system, please refer to the game document as this could be too lengthy for this website.
Finally, the programming stage. The programming part comes to a higher-level subtlety. The first challenge, also the major significant challenges we met, is how should we store the branching of the story. Initially we thought about using a tree structure as the data structure, for the sake of convenience, because we don’t want to manually input the story line by line into Unity3D. At first we thought about writing in a txt file and writing a parse() function to automatically turn the txt file into tree nodes. It looks something like this:
Using & as delimiter and each node stores message groups and response groups along with the children indices. However, this soon went to failure, because the story branching is actually not a tree!
Many of the nodes converge, which means several parents may share the same child. Also, this simple parser makes incorporating game values extremely difficult: if we want to set up the threshold values for each selection, and the bonus we get from choosing the choices, the node could be very hard to read.
Finally we implemented the story nodes by constructing data structures that are specified as TextGroups in Unity. A TextGroup looks as follows:
Each TextGroup knows the incoming messages
specified by the IncomingMessages Texts, and each IncomingMessages knows its WaitTime (the time lapse between receiving players’ reply and starting to type) and TypingTime (the time spent on typing the incoming message). These variables allow a high-fidelity simulation of instant messaging. Also, each TextGroup knows the player choices specified by the Answer Answers, and each Answer knows a bunch of information: its min_mh, min_int (the minimum mental health
intimacy ) and MH_buff, Int_buff (the bonus received by making the choice). It also knows tip and warn, for giving the players hints and tips after making the choices. Most importantly, the NextGroup and NextAvailable allow the node recognizing its unique child. The linearity underlying is the basis for the tree story storage; these text groups work pretty robustly.
The second challenges appear to be similar, but also fundamentally different. The face-to-face chat-simulator: the basic logic is similar, but this time a single dialog may involve more than 2 talkers. Therefore, we need to pay additional attention to how characters are switching. Also, notice that characters will not be “typing”, neither “waiting”, therefore, the basic logic on instant message simulators is actually not applicable here. It seems that a completely different data structure will be more helpful. Due to time-limit, this part is not fully implemented on our own -- we are building the face-to-face chat-simulator using the $4.99 Unity Asset, DDSystem24.
In particular, we made the adaption to automatically create and assign characters. For example, in the original asset, we must create the characters in the inspector, but this will create a problem, for example, if the player defined the kid to be a son, not a daughter, then we cannot use the daughter character showing up as the kids. Compared to other significant challenges, the challenges here are easier to solve.
Some other challenges appear at the scene management. We determined at the beginning of the project the game scene flow should be as following:
1. Monday to Thursday: Office -> Load (Office to Home) -> Bedroom -> Load(Sleep) -> Load(Home to Office) -> Office;
2. Friday: Office -> Load(Office to Home) -> Face Chat -> Bedroom -> Load(Sleep) -> Face Chat
3. Saturday: Face Chat -> Bedroom -> Load (Sleep) -> Face Chat
4. Sunday: Face Chat -> Bedroom -> Load (Sleep) -> Load (Home to Office) -> Office
So keeping track of the calendar could be important, and turning the date to a weekday will be required. However, by just making sure the mathematical relationship, this challenge is also solved quickly.
The remaining challenges are all subtle debugs and implementations, such as player customized variable substitution, render pipeline optimization, font shaders and button/toggle/InputField renderings. There are almost, certainly, surely, implicit bugs still remaining in this game, but considering the limited time, the challenges have already been handled smoothly, which meets our expectation.