Prototype: Buggy Factory

Core Concept

We want to teach Modular Programming and Unit Testing using the Buggy Factory Prototype.

Why?

When it comes to programming model choices, the modular model is generally preferred over monolithic model. But for new learners, it can be hard to understand why. This prototype will teach the benefits of modular programming  and players will go through the unit testing process, which is individually testing each module to find out whether that module works or not.

The Pitch

Learn the benefit of unit testing and modular programming by debugging a car production line.

The Actual Experience

Find the problem in the car production line that is causing the car production to fail. Players can find out the problem by repetitively testing factory modules.

Key Interactions

  1. Run the car production line and find out whether production succeeded or failed.
  2. Test individual factory modules using the unit testing field to see which ones work and which don’t.
  3. Grab and replace the individual factory module using the module from the inventory.

Key Lessons

  1. The player needs to realize brute-forcing to find out which factories work is not an easy task.
  2. The player will reduce the difficulty of testing by testing individual factory modules on the unit testing field, and thus learn the benefit of unit testing.

Step-by-step Walkthrough Guide

Demo Video

Team Goals

Week 1

  • Iterate on designs, discuss with the team, faculty and client to arrive at a design that demonstrates modular programming.

Week 2

  • Finish minimal viable version of buggy factory, and get feedback from client and faculty.
  • Improve the prototype based on feedback to one that shows the benefit of modular programming over monolithic programming.

Lessons Learned

We thought creating in-game motivation to test each module would lead to people think about the benefit of doing so. However, that does not work unless we have something else as reference that can  show the potential harm of not testing modules. Since the interactions are simple and don’t actually require the player to think much,  it is possible for players to brute-force check all possible combinations modules without thinking deeply about how a modular approach would be better.

Role in a Lesson

The player is expected to develop an understanding of why unit testing is more efficient than running a complete test on a complete program, and why it is a good practice to split a complex program into several components. We intentionally created several correspondences between the game and the real concepts: 

  1. Each factory corresponds to a module. The production line setup corresponds to modular programming.
  2. The process of finding the factory problem corresponds to debugging.
  3. The process of testing each individual factory corresponds to unit testing.

If this experience were used as an introduction, the teacher could use the pseudo-code provided below to strengthen the connection between syntax and the concept.

First structure:
Func GenerateCar() {
     ProduceDoor();
     ProduceCarFrame();
     ProduceTire();

     If (TestCar() == SUCCESS) {
          return SUCCESS;
     } else {
          return FAIL;;
     }
}

Func GenerateCarDoor() {
     ProduceDoor();
     If (TestDoor() == SUCCESS) {
          return SUCCESS;
     } else {
          return FAIL;
     }
}

Func GenerateCarFrame(){
     ProduceCarFrame();
     If (TestFrame() == SUCCESS) {
          return SUCCESS;
     } else {
          return FAIL;
     }
}

Func GenerateCarTire(){
     ProduceTire();
     If (TestTire() == SUCCESS) {
          return SUCCESS;
     } else {
          return FAIL;
     }

Second Structure:

Func GenerateCar() {
     ProduceDoor();
     ProduceCarFrame();
     ProduceTire();

     If (TestCar() == SUCCESS) {
          return SUCCESS;
     } else {
          return FAIL;;
     }
}

Ideas for Future Development

We would want to shift the focus from teaching the benefits of modular programming to teaching the need for and benefits of unit testing. The player would be given the same buggy production line and need to decide where to place a testing facility. If the player chooses to build the testing facility after the car comes into shape, it will cost more to test the whole car and fix the car (both time wise and process wise). The player is then motivated to build a testing facility right after each module. In this way, the player is capable of removing unqualified components in the early stage of production, and thus ensures the efficiency and quality of production line and cars.

Teacher Reactions

The teachers we showed this prototype to thought it was a fun and interesting example of modular programming. Some were particularly excited about the potential for an experience like this one to introduce younger students to the concept of modular programming.

Several of the teachers wanted the prototype to provide more details about why a specific module failed, so the player would have more information about how to debug the production line. Some other teachers thought that players didn’t really need to think much about what they were doing to build a successful production line; they might simply brute force the combination to find the one that works. This weakens the teaching ability of this prototype.

Student Reactions

Young students liked this prototype a lot due to the music feedback on success, and the use of VR. They enjoyed the experience a lot.

Thoughts from the team

  • Zach thinks the player will enjoy the realization moment of needing to perform unit testing instead of whole car testing. But since there is no comparing between the modular and monolithic programming in this game, the benefit of unit testing can not be clearly illustrated through playing the this prototype.
  • Joe thinks buggy factory is a good way to enhance people’s understanding about the power of module programming. Maybe the one drawback is that the comparison of using module programming and not doing that is not quite obvious and people may need think further to find that out.
  • Jiawen thinks buggy factory is a good try. It started from an ambitious idea. During the developing process, the idea was kept polishing. We learnt a lot from it. And it is finally a cute demo.
  • Nick believes buggy factory demonstrates a potential way to teach about unit testing. However, this might not be the best way. To fully illustrate the benefit of modular programming and unit testing, we need to make a comparison between monolithic program and modular program. This was not possible due to the time limit, but if added, would definitely strengthen the prototype.
  • Miriam thinks this prototype is a good start on the concept, but needs a lot more work. Its main strength might actually have been point show us how concepts that we might consider simple can actually be very complex, so it’s extremely important to make sure we know exactly what about each concept we want to get across with a prototype.
  • Luna thinks it could be a decent material for explaining modular programming. However, giving users chance to random testing things out is an obstacle to make them understand the advantage of modular programming correctly. The advantage is strengthened if navigation of bug is simplified because of modular programming.

Click Here to Download the Code and Try It Out For Yourself

Further Reading

If you’d like to learn more about this prototype and its development, check out these blog posts:

  1. Week 6: Wrapping Up Solar System and Fractal Magic
  2. Week 7: Of Factories and Flags
  3. Week 8: Refining and Preparing
  4. Week 9: Halfway Through
  5. Week 10: Playtesting and More