To start our project, we summarised our literature review findings through our proposal, which received some feedback from the teaching team. The feedback mostly talks about our initial idea of addressing two different problems, unsafe crossing and smartphone addiction, at the same time.

To answer the feedback, we conducted user research using several methods, including a survey, an interview, direct observation, and placing a physical probe. The details of each method and its results can be seen in more detail here. The user research gave some important insight:

• People cross more and use their smartphones more on signalised crosswalks
• People mostly use their smartphone to browse social media when walking on the street, less on playing games or watching videos
• People understand the risk of using a smartphone while crossing the street
• Observation reveals that most people have a common behaviour when using their smartphone while walking, which is looking down

To answer these insights, we want to distract them from their smartphones before they cross.

• The duration can be set because most of our target users cross on a signalised crosswalk, so there is a duration for when to cross and when not to.
• Because people mostly use their phones to browse social media, we can distract them by providing a more appealing activity. This is easier than distracting people who are playing a game or watching a video that requires more focus, while browsing social media is more like micro-activities that are easier to disturb.
• Intervention will be placed on the ground because our target users mostly look down when they arrive in the space.

• Our solution is designed to enhance pedestrian safety by encouraging greater attention to road conditions at intersections. The system integrates an interactive game placed on both sides of the street, where pedestrians can engage with one another while waiting to cross.
• The game involves two pedestrians collaborating to complete a recipe by kicking virtual ingredients to one another across the intersection. However, the gameplay is time-limited. Once the allotted time is up—typically when the signal changes—the game will automatically stop, prompting pedestrians to focus on the road and safely navigate the crossing.

1. Each side of the intersection has its own recipe task. To complete the task, players need to collect different ingredients.

User 1 initial screen	User 2 initial screen

2. By kicking ingredients to the other player on the opposite side of the intersection, both players can receive the ingredients they need. Completing the task requires collaboration between the two players.

After user 1 get the tomato from User 2	After user 2 give the ingredient to User 1	Both players complete the task

3. If the task is completed, the screen will show a "yummy" text on the screen.

Task completed screen

In the first iteration, we figured out what the requirements needed to build a single piece of a process flow, which means a board and a sensor. This iteration resulted in a simple connection between an ultrasonic sensor and an Arduino Uno board (Access the commit here).

#define TRIG_PIN_1 4
#define ECHO_PIN_1 3
#define TRIG_PIN_2 13
#define ECHO_PIN_2 12
void setup() {
  Serial.begin(9600);
  
  // Sensor 1 pins
  pinMode(TRIG_PIN_1, OUTPUT);
  pinMode(ECHO_PIN_1, INPUT);
  // Sensor 2 pins
  pinMode(TRIG_PIN_2, OUTPUT);
  pinMode(ECHO_PIN_2, INPUT);
}
long getDistance(int trigPin, int echoPin) {
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  long duration = pulseIn(echoPin, HIGH);
  long distance = duration * 0.034 / 2;
  return distance;
}
void loop() {
  long distance1 = getDistance(TRIG_PIN_1, ECHO_PIN_1);
  long distance2 = getDistance(TRIG_PIN_2, ECHO_PIN_2);
  
  // Send the distances in the format: distance1,distance2
  Serial.print(distance1);
  Serial.print(",");
  Serial.println(distance2);
  delay(1000);
}

Before connecting Arduino to Unity, it is important to ensure that the game system works first, at least by using a keyboard press. So, for the first iteration, our Unity focused more on the developing environment, assets (such as icons and background), and the initial state of starting the game, which is to randomise the ingredient spawns. Then, we added the keypress and finished the overall game system, which checks the state whether the recipe has been finished or not.

Detail of our second stand up can be seen here

Figure 1. First Prototype

We presented our first prototype on Stand-Up Two. At this stage, we had already connected the game system with our simple Arduino scheme, consisting of only three sensors for each player, as seen in Figure 1 below. It was still very clunky control because we used three sensors to move four ingredients. So, what happened was one ingredient needed to be moved by using a combination of detection from two different sensors, as seen in Table 1 below.

Table 1. Prototype 1 sensor detection

If this worked fine, we actually planned to use five ingredients, with one more ingredient controlled between Sensor I and Sensor II. However, since the reading was messed up too badly, we decided to proceed with one sensor per ingredient.

While the simple flow mentioned in Iteration 1 works, the developer just needs to replicate it several times to achieve eight sensors working in the same system. So, in Iteration 2, the developer focused more on how to connect two Arduino boards to accommodate eight different ultrasonic sensors. This iteration ended with the successful connection between two Arduino boards:

• Connect Arduino 1's pin 0 to Arduino 2's pin 1
• Connect Arduino 1's pin 1 to Arduino 2's pin 0
• Connect Arduino 1's GND to Arduino 2's GND

For the Unity, we added more interactions in the UI side, such as game completion screen and time up screen. We also added some more ingredients to increase playability.

More on our User Evaluation here

When we did our user evaluation, we wanted to know if the game system had reached the expected usability level, as stated in our non-functional requirements. Our prototype is already functioning at this stage, so we want to gather more insight into the user experience side.

• It does not have the function to adapt when only one person is present, so we suggest a single-player mode with presence detection as one of the future iterations.
• Understanding the average sensor reach for our user, we should then adjust the parameter of function triggering, as stated in Iteration 3 below.
• It is harder to understand which sensor controls which ingredient, so we adapt the game system to include background colours and add matching colours to the environment as well, so we addressed it through our Iteration 3 below.

The last iteration of the Arduino revolves around tuning the parameters to trigger functions in Unity's game system. This iteration is strongly connected to the user evaluation because we want to know if the current parameter is enough to trigger the function or not so we can adjust the value more and create a more seamless experience.

Through evaluation, our users also said that it is hard to know which sensor to trigger to move a certain ingredient, as our ingredient works based on its position against other ingredients. Therefore, through this iteration, we decided that we should have an indicator in the physical environment and in the game system to indicate which sensor moves which ingredient. The indicators are in the form of colours.

We want to enact the environment as well as possible so that we can deliver the experience as close as possible to the real world. Therefore, we use a wooden pallet as our floor and tape the sensor facing upwards through the space between each wood platform. We also created a zebra cross in the middle where people can walk on top of it, creating a real sense of crossing after playing the game.

Figure 2. Final look of our physical environment

In the final stage of our prototype, we also incorporated a timer in our game screen, simulating what it would feel like to wait until the right time to cross the street. We also added some sound to start the game and when the users finish a recipe to ensure continuous engagement throughout the game until the time runs out.

More images of our final Tradeshow here.

Through feedback and testing, we conclude that in the future, the project should implement the following:

• Single-player mode. By detecting whether more than one person is present or not, the game can change mode by itself, allowing the person to play by themselves against a computer or even adding a new game variation that can be played alone but still controlled with the reading provided by the Arduino sensors.
• On-ground display. The initial product design is to have the display available on the ground, relating to our simulated aspect of the current prototype. We believe that achieving this will help the product gain more attention from target users in a real-world environment.
• Adding animation to the game. Similar to the on-ground display, adding slight animation to the game objects could attract more target users to interact with our product as it becomes more visually appealing.
• Connection to a real-world crossing signal. This is a crucial aspect when the product is about to be implemented in a real-world environment, as the game should be able to start and end based on the traffic light.

Meanwhile, these could be implemented as nice-to-have:

• Change sensor type. While an ultrasonic sensor fits the purpose for this stage of the prototype, there is a possibility that using another kind of sensor would benefit more and provide a more accurate reading. We recommend an infrared (IR) sensor due to its robustness detecting presence in a straight line. It can be covered with a transparent material on top of it to cover the sensor surface. However, the implementation would require a more thorough consideration of placement so that the sensor can read movement more sensitively.
• Updating the Game. Although we did not explicitly test the fun aspect of the game, we recommend that Chef Cross be updated over time to provide more novelty and a fun feeling to its users. Some parts that can be considered are new recipe combinations and adding more ingredients.