This week we started development on our next two prototypes: a modifiable chain of flags to demonstrate linked lists and a car factory to illustrate the benefits of modular programming. We also did some post-mortem documentation and final tweaks on the last two prototypes, keeping track of what the strengths and weaknesses of each are and what we would do next. Jiawen also improved the fractal algorithm and replaced the wand in that prototype with a particle effect, which improved the look of the game and made the order of execution of the functions clearer.
Designing this prototype was tough. Nick’s idea of skyscraper building focused on modular programming while Zach’s focused on debugging. Our original thought was that these two ideas might work together quite well, but the truth was they did not. Why? We had too many focuses in one prototype, and consequently, there was too much to implement, too many designs to figure out. We failed to deliver the final design on Monday, but on Tuesday it occurred to us that it was probably not wise to focus on two topics in one prototype. Instead, Nick came up with the suggestion that we focus on just modular programming. Specifically, we intended to teach the advantages of modular programming: the capability of replacing and unit testing modules, which makes the program easier to debug and increases the reliability of the program. In the end, we decided to implement a prototype that asks guests to debug a buggy production line for cars. The player is expected to reach a certain kind of quality rate for the cars, but the buggy production line does not reach this rate. So the player is expected to unit test each module, and find the right combination of modules that will meet the quality rate requirement.
With the flag prototype, we aim to illustrate traversal, insertion, and deletion for linked lists. The appropriate steps to inserting or deleting nodes from a linked list can be difficult to conceptualize when looking at a 2D version of the list written out in front of you. We hope to solve that by having guests traverse the list manually, one node at a time, as if they were the pointer to the current node.
Within the experience, guests will be attempting to add a letter to a flag banner so that it matches their diagram. For example, the diagram may say “welcome” but the banner may say “welome,” so they need to add a “c.” The banner is attached to a winch, but the tail end is blowing in the wind, so the guest needs to get to the place the “c” belongs by turning the winch past each flag. If they go too far, they can get back to the beginning by releasing the winch. When they get to the correct spot, they can add the new flag by tying it to the one that should come after it (in this case, the “o”) and moving the tie from the flag coming before it (the “l”) from it’s original placement (connected to the “o”) to the new flag (the “c”). If they untie the far side of the banner without attaching it to anything, the loose flags will fly away in the wind. Similarly, in the next level they will need to remove a letter from the banner in order to correct it.
From a computer science standpoint, guests will be getting practice working with linked lists and a more concrete understanding of why insertions and deletions work the way they do. The flags represent nodes of the list, the letters represent the data the nodes contain, and the ties between each flag represent the pointers from one node to the next. There is no way to go backwards along the list, only to get back to the beginning. The guest’s hands represent the temporary variables necessary for insertion and deletion.
This week, Miriam finalized the design of this prototype with Jiawen and Luna, who then set up the basic environment. Jiawen also wrote the basic classes and the operations for the left hand. Luna has been away at the Game Developer’s Conference, and will continue working on it next week when she returns.
In addition to starting designing and starting to develop our next pair of prototypes, we have been informally playtesting our Cute Fractal and Solar System prototypes. Throughout the week we have invited other students here at the Entertainment Technology Center, with and without programming experience, to try them out. Overall, the results have been quite encouraging.
We’ve seen again and again that the controls of both are quite rough and not as intuitive as we would like, but we knew that was likely to happen. The exciting part was that the playtesters with programming backgrounds were able to guess the topic of each prototype and make sense of the content, and the playtesters without programming backgrounds were generally able to understand and use the prototypes. For the playtesters without programming backgrounds, we found that they were able to explain why events in the experience happened the way they did, even if they did not yet know exactly how that would translate to programming.
In future prototypes, we want to try to find ways to make the gap between these experiences and real code smaller, perhaps by adding ways to see labels or pseudo code for each object or event.
We’re also looking forward to having local teachers try out these experiences and give us their feedback starting after spring break.
Even though our development cycles are two weeks long, we are still developing and pitching new ideas each week so that we can continue to gain experience and improve our brainstorming and presentation skills. We hope that this will also result in more viable ideas than we can actually build this semester, so that we can give our client both the prototypes and a set of additional things to try.
This week Miriam, Jiawen, and Nick pitched four ideas to our client:
- A pirate treasure storage service to illustrate hash tables and chaining to deal with hash collisions.
- A Jack and the Beanstalk inspired experience about growing grapes to demonstrate insertion into binary search trees.
- A sculpting experience with a machine that can modify your building materials to show parameter passing.
- A challenge of searching through a gradient cube to match a particular color to practice binary searching.
After pitching, we think that the color cube idea is our strongest, and will likely build it next round. However, we realized that each of these ideas still has some space for improvement. For instance, the metaphor is too hard-coded to the game in the grape one. For the hash bank one, the player lacks the capability to make decisions, which reduces the “fun” level of the whole game, and is also detrimental to the learning moments. How do we give the player capability to make decision while making sure that it does not break our design will be the core question to discuss next week.