Posted on by jsandhu

Week 7

WEEK 7

 

Production:

This week, we coordinated with our out-of-house sound designer (a colleague at the ETC), and catalogued the portions of our experience that require specific SFX. We don’t have a sounds designer on the team, so I will be responsible for coordinating with him I outlined the table below as a reference for him:

 

Design:

This week, we tested out the resource management system for the redesign phase of our game.

Our redesign phase will accommodate the scenario in which the player’s bot is flipped and the player has to find ways to get around it.

What a redesign session would look like in the game:

  1. Players will enter a battle
  2. They will be playing against an AI bot (flipper)
  3. After a good few seconds (20 – 30 seconds depending on what players prefer) into the battle, the AI bot will flip the player which will lead to the player’s bot being immobilized (the player’s bot will land on its back and cannot move anymore similar to scenario 3 gif)

  1. The player will lose this battle as their bot cannot move anymore
  2. Players will get the opportunity to go back in time and make changes to their bot to avoid being flipped on their back that lead to immobilisation
  3. Players will be provided a range of options (Self-righting mechanism, heavier chassis etc.)
  4. These options will have at least 2 acceptable solutions and the rest will be right answers but not acceptable and also wrong answers (Example: Players will suggest increasing the weight of the bot, which is currently 14 lbs,  to avoid getting flipped. Unfortunately, this answer despite having a possibility of being correct goes against the weight restrictions (15 lbs))
  5. Players will choose their option, they will then be shown the outcome of their choice in the form of an animation or by battling with the AI bot again.
  6. To avoid monotonicity, some options like increase weight, will not allow the players to move to the outcome phase (the battle or the animation part) and players will be told the outcome in the form of visual/textual feedback immediately after choosing that option.
  7. If the outcome is such that their bot doesn’t get flipped, they have successfully redesigned their bot.

 

Note: The redesign phase is not about fixing/repairing your bot before the next battle. It’s about rethinking the design to solve a particular problem. Think of it as, “If I could go back in time, what would I do differently to avoid this from happening”. It’s catered towards encouraging the players to solve challenges from past battles that the bot must have faced. We want to players to get into a problem-solving mindset. We want the players to understand that NRL focuses on learning from a particular bot’s past shortcomings and “iterating” on its existing design.

 

We are currently making a list of right and wrong options that will be provided to the player at step 6. Based on Table 1, we made a list of options for when a bot is flipped and immobilized. Each of those options have problems listed next to them that can be presented to the players when they chose them to let them know why that was a wrong choice. We would like to know if we are on the right track in terms of categorising these problems as right/wrong.

 

So the problem statement is:

Your bot gets flipped and lands on it’s back that leads to it getting immobilized and you lose the match. How will you redesign it such that you can either recover from being flipped or avoid getting flipped?

For now, the right solutions include:

  1. Self-righting mechanism
  2. Invertible bot
  3. Weapons that also self-right

The most obvious wrong solution is: increasing the weight (goes beyond competition weight limit)

This is what the distribution for our redesign phase would look like:

Based on some of our playtest feedback, it went through several changes in terms of balance and the way the information was presented to the players.

The final iteration looked like this:

This iteration will be tested with school kids (10-14 years of age) to test the following things:

  1. What is their thought process when solving this problem?
  2. Do they solve this any differently when paired with a buddy?
  3. Which weapon did they want to equip their bot with and why?
  4. Their reason for the solution that they provide.
  5. Is the moment of self-discovery fun?

 

We will also playtest the current bot movement system in AR with the kids this weekend. Based on my past experience, I added a developer mode to our build to tweak all the juice parameters (force, friction, rotation). This will help us  lock down on what parameter values feel “fun” to the kids.

 

The design team and the programmer sat down together to create a better work ethic that involves much more transparency from both disciplines.

This meeting helped us better understand each other and develop a terminology that both disciplines will be able to use in the future. All ideas will now follow this format and the programmer will create a framework that will accommodate these ideas.

 

Programming:

We made a new version of control in which the movement of bot is based on physics. Which helps us gain a much smoother rotation. Though it might not that easy to control, it also gives kid a chance to chase their bot.
We also add a dummy AI which could only randomly move to a target point. It gives us a sense of how we can interact with enemy.