We designed the track fully and did the final testing in this week.
The track is designed that there are 3 different coloured tracks of differing widths depending on the difficulty. The narrower the track, (as defined by the colour), the higher the multiplier that is applied to the points that are gained per balloon popped.
This is also when we planned our testing. We decided upon a cut down version of what we needed to test, (i.e. the sensors and ease of control). The would be completed in the next week.
Week 9 is the point where we considered the feedback that we received from the group demo and considered how we would be able to implement it.
The piece of feedback that we received most was that we should implement an automated function that would allow for players to compete against a CPU alongside another player. However, this idea did not fit within the specification that we had for the game. We felt that, as we designed it as a player vs player game, the automated function would compromise that. Also, we lacked the time to fully implement and test such functionality to the point that it worked as we intended every time that we ran the program.
Otherwise, we were pleased with the feedback that we received as it was mostly positive.
We also shifted our focus towards the presentation to the rest of the class in the following week.
This was the week that we demoed our robot to the rest of the group. Our demo involved a simplified version of the track and a few balloons along the path. We used this as a proof of concept test as we lacked the time to properly produce a full sized and correctly proportioned track.
The demo showed each part of our game functioned properly and also allowed us to gain some feedback as to what we could possibly implement to improve it.
This week is where we did the final preparations for our presentation to the rest of the groups and lecturers.
This presentation covers the entirety of the process of building the robot and developing the game. We presented this to the rest of the class.
Week 6 is where the whole group collaborated on the final ideas and the actual logistical planning of the track.
The main track idea is that there are 3 colours of track that the robot can detect, with balloons along each path. The 3 colours show a different level of difficulty, with higher difficulties having a higher multiplier to the points scored from bursting balloons, (i.e. harder track = more points). If the user directs the robot off-track, there is a points penalty. The main difference between the tracks is that the more difficult the track, the more complex and narrow the coloured strip becomes.
The layout would be based around a simple oval track, (the easiest track to follow), with harder tracks coming off the sides, (similar to how a real racetrack is laid out), making the user choose which track to take and making the game more varied.
We also decided upon the materials that would be required for producing such a track. This will be collected and built in the coming weeks.
This was the week that the final finishing touches were added to both the hardware and software elements of the robot. The major change was adding a touch sensor on the top to allow us to implement a feature where the game would start after the sensor is tripped and resets if the game is already running.. This was a useful addition as it means that the user has full control of when the game starts and feels as though they have some input.
This week also featured the start of the planning involved in building a suitably sized and laid out track for our robot to interact with. I was part of this. We decided upon the basic ideas behind the layout and the surface area that the track would need to cover to make it an engaging and interesting game experience for the player. With this in mind, I came up with the ideas behind the surface area of the tracks and the actual size required to fit the robot on it and allow the game to proceed for a full minute.
Week 4 was the start of the group producing the game. We all had a hand in adding to the code and producing different algorithms for the robot. I, (alongside a teammate), produced the countdown timer and the basic movement loops
Loops that I worked on:.
(Above) This loop is the countdown timer. It runs before anything else and tells the user when they can start the game. It also triggers the start of the game, (as the movement loops run afterwards, preventing users from starting too early and cheating)
(Below) The image below shows how the countdown loop links to the movement. The countdown runs beforehand. Once the countdown has finished and the sound stating so has played, the user is allowed to move using the Bluetooth controller. There are multiple options for the controller buttons and the various associated movements, (be it the hammer or the main motors).