With our Half Presentation coming up on Monday, the team spent a majority of our time this week prepping by making slides and rehearsing. This involved creating several powerpoint iterations, practice presentations with professors, practice on our own, and practice in the RPIS space over the weekend. While iterating our presentation, we ran into two main problems:
- Timing the presentation so that it was close to 15 minutes.
- Communicating what our tool actually does.
For problem one, we fluctuate between having way too little to say and way too much. This was generally helped with plenty of practice and clarifying problem two. Problem two was much more difficult to solve because it involved us asking and answering a lot of design questions about our project that we had yet to confront. We decided to address a lot of these design questions in a design meeting with Dave.
During our design meeting with Dave, we needed to meditate on how our tool is supplementary to classrooms and what branching narrative means for an educational tool. To begin this process, we transitioned from thinking of our tool as a branching narrative tool to thinking of it as a choice-based learning tool focused on choice-consequence balance. We also began defining what a narrative tool “looks like” as a cohesive collection of features and what the practical limitations implementing those features are. To give us a sense of what an educational programming tool has done to address these questions, we looked at Alice3. This gave us some direction in how to categorize assets in an asset gallery and helped us zero in on the problems of defining interior and exterior spaces that students can create. Generally, we have decided on an asset categorization method and the need for prebuilt scenes in our tool.
In addition to continuing to create more environment assets, Anlan and Lyn laid out an example scene in Maya for our presentation and to inspire Rohit’s scene template building later.
Rohit updated our current asset inventory/gallery to include the assets that Anlan and Lyn have made. He also began looking into how to implement saving and loading in the Roblox experience. Chenguang continued to work on the dialogue system, which he expects will take a bulk of the rest of the semester to implement. For now, we’re still relying on hardcoding dialogue. Using what exists of Chenguang’s dialogue system, Xiao was able to make a brief demo featuring a player, her narrative, and two NPCs.
On Friday, Gillian and Rohit visited Cornell HS to playtest a paper prototype and survey students about how they would use a Roblox narrative design tool for their classes. We asked students to fill out surveys outlining how they would approach a theoretical history assignment using Roblox and what classes they would be most interested in using our tool for. We then had students create their own dialogue trees with a conversation between some characters from their favorite piece of media. Afterwards, we asked students about the difficulty of creating the dialogue tree. What we generally found was that students highly valued being able to customize scenes and add their own characters. Additionally, they were all inclined to plan things on paper before writing dialogue in Roblox. The students we surveyed showed a moderately strong preference for potentially using this tool in science and foreign language classes.
