Month: November 2018

WEEK 9

Jehan – Production:

We’re officially done with Halves! Our presentation went off without a hitch and we received some great feedback from the faculty and student body of the ETC. Based on this feedback, we’ve realized we could be clearer about a couple things in particular: why augmented reality is the ideal platform for our product, and our plan for delivery. I had a chance to discuss both of these points in our meeting with Bill after our presentation, as we have worked out the details and plan moving forward. I’ll break down some of the reasoning why:

Mobile AR is the ideal platform because..

 

• Cost/Safety Solution to Showcase the NRL:

• Real-life bots and all of the equipment, arena, and safety precautions needed to accommodate them is INCREDIBLY expensive.

• Our experience enables the NRL to showcase their brand in a safe, cost effective, and scalable manner.

 

• • • All of the fun and excitement of the NRL without any of the cost and danger.

  • Promotional Tool:

    • Our project enables the NRL to promote themselves through a new interactive medium that previously had not existed.
    • Bill is especially excited to be able to demo a battle to kids and manufacturers at youth/business conferences.

 

• Unique Demo Experience:

 

• • There are few alternative interactive ways to demo the NRL at conferences and across the nation.

Our plan for distribution is…

Our finished deliverable will be released to TestFlight, after which Bill will hire a third party to push it out on the app store. The NRL doesn’t have an online presence in the App Store, so part of this will involve the NRL being registered as a developer with said hired help. We will have to coordinate with a Bill to refer him to a viable and cost effective Third party, which I am sure that we can find within the ETC.

 

Trisha – Prototyping and Design:

 

Collaboration with the UI Designer:

This week’s prototype and testing was based on the showcase part of our experience.

 

[VIDEO]

 

As you can see from the video, it is a 3 step process:

1. Display names of individual components.
2. Open up the bot to see the individual components and insides of the bot.
3. Descriptions for these individual components.

 

This was playtested on Sunday (10/29/2018)

Playtester Name: Harrison

Gender: Male

Age: 11 years old

Comments:

• Thought it was really cool to see the bot laid out in front of him
• Wanted to be able to modify the bot he was battling with in the showcase mode (“I wish I could add components to my bot”)
• Really wanted to choose the colors of the bot and name it.
• When asked, said Height was comfortable – not an issue
• Said there was too much text on the screen

 

Based on the playtest and the design team’s observations, we are going to make a different version of this prototype with the following changes:

1. Description information will only be displayed when you’re closer to the component.
2. Height of the bot needs to be adjustable.

 

Collaboration with the Programmer:

Games like Robot Arena have been one of the games that we studied during our research phase. One thing that we thought we could improve from the battle part of that game was the feedback system.

 

[GIF]

 

As you can see from the above gif, the current feedback system that they have includes an explosion and then the component vanishes.

We wish to incorporate what actually happens in an arena. The component falls off and now becomes a hindrance as it simply lies on the arena floor.

 

Inorder to have this in the game, the following system was created:

 

Parameter values for Bot 1

 

Every component has a strong and a weak point.

 

For example, let’s take a look at the shield.

 

Strong:

• The shield is what protects the wheels. Each shield has a health bar depending on what component it’s made out of.
• Once the shield falls off, the wheels are exposed.
• If wheels (they have their own health bar) get damaged, your bot is immobilized and you lose the competition.

 

Weak:

• Depending on the material, the bot’s weight will vary.
• A heavier bot will move slower and a lighter bot will move faster.

 

Once this system has been coded, we can start testing out the values and start tweaking them to create a balanced battle.

Week 9 Example Text.

Nicole – UI & UX:

Week 9.

 

Kang – Art:

Week 9.

 

Guanghao – Programming:

This week we have nailed down the basic code framework. We are going to use component based system to construct our code. We take this for 2 reasons: 1. We can now have more combination from different components instead of being limited by the whole bots. This allows children to sort of creating their own bot. 2.we can reuse those code for different purpose, we can apply the code for both “tutorial battle” and “free battle” without changing to much. That also ensure we have a robust code base and easier for us to debug.

WEEK 8

Jehan – Producer

This week was spent refining our design and playtesting. The team has made great progress in our builds and prototypes– we are getting faster and more efficient with our prototypes. To date, our experience can be broken down into two major portions: an exciting battling portion of our game where the user can control their own bot’s movement and weapon, then attack a basic Combat robot AI… and a “Showcase” portion, in which the user can get a better sense of the inner-working of their combat robot. We had the chance to playtest an early version of the showcase for the first time with our target demographic last weekend, and it was received well.

Much of the later portion of the week was spent preparing for halves, a mid-semester review of our work and findings geared towards ETC faculty. We’ve put together a presentation outlining our overall game structure, iterative process, past and future milestones, and our plan for our delivery. Our client, Bill, will be attending our presentation on Monday of next week, and will give us his feedback on our progress.

I can’t believe we’re at the end of week 8, time is flying! We’re all looking forward to getting done with Halves… especially since we’ve worked through the entire weekend.

 

Trisha – Designer:

From the last week’s paper playtest for the resource management system, we had the following important findings:

• Self-discovery: Kids enjoyed figuring out a solution on their and were excited when they discovered why the solution worked.
• Considering the weight limitation and solving a problem got frustrating for the kids.
• When solving the problem together, we found lesser participation from the shy/quiet kid and the most loud one would be dominant.

 

We have decided to split the problem-solving and weight limitations into two different phases.

Phase 1: Find which bot would not get flipped and learn why

Phase 2: Even though your solution is correct, flipping too many times causes damage to internal components. Upgrade to a stronger armor making sure that the bot does not weigh more than 15 lbs.

 

This week, we performed rapid iterations on our prototype and integrated sound for our playtest sessions.

 

Playtest sessions: 14th, 17th and 19th of October

Playtesters Gender: 6 Males + 6 Females

Playtester Age: 10-16 years

Iterations:

 

• Virtual on Physical

 

Problem:

Players did not realise that the virtual components were rendered onto the physical world.

Changes:

We made the arena transparent.

Results:

Players started pointing that after a while, it felt like the bot existed in the same space as them.

 

• Arena too Big

 

Problem:

Originally, it felt like the arena was much above the ground. Players would stand in the middle and rotate in the same spot to find their bot.

Changes:

Lowering the arena further was not an option as the ARKit wouldn’t allow going below 0 along the y-axis. So we changed the height of the arena. The arena size (1,1,1) was reduced to half (0.5,0.3,0.5) and the height was further reduced to 0.3.

Result:

Because of the change in length and breadth of the arena, players were not standing inside of it anymore and stopped rotating around in space struggling to find their bot.

A much larger change in height made it feel like the arena was a lot lower than before.

 

• To get used to the control system before the battle, players were asked to drive the bot around in an empty arena.

 

Problem:

Players were bored and weren’t developing any skills due to mindless driving.

Changes:

Added cubes to the arena that changed color.

Result:

Players started driving much more intentionally (turn and proceed towards a cube to turn it green)

Next week, we are planning to focus and test the UI for the showcase part of our game.

Kang – Art:

Week 8.

Guanghao – Programming:

We are working hard to make the prototype which includes the whole game flow. We first anchor the world in AR and select the bot we want. We then enter the battle with the one we chose. For the first battle, there will be a movement test which you need trigger all sandbags before you encounter with a boss enemy.

Nicole – UIUX:

Week 8.

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.



 

Production:

The team made great progress with mapping out and narrowing down the specifics of scripted case scenarios in the battle portion of the game. Programming included real time drop shadows and basic animations for the player’s bot, which went a long way towards visually grounding the bot to the floor through the eyes of the user, and was well received.

As we add new features and refine/balance the movement, control, and physics systems, playtesters spend more and more time with the iPad before they decide they’re done with it. More than ever, I am seeing the real potential for us to make something great.

The most limiting constraint that we face is time… 14 total weeks of development, six of which have past already. Moving forward and for next week, we will be challenged by scoping back our idea in a manner that retains its core identity and purpose.

 

Programming:

This week we are still working on prototyping. For Wednesday, we made out a demo that uses the new version of control. We reduced the controller from 2 to 1 which allows us to put enough space to place attack UI. In the new control, we move and rotate bot in a more intuitive way. We let the bot to always move in the direction that player is facing. The reason why we made this is we found when player use the previous control they usually get lost if the camera’s facing direction is changed. This time we change the moving coordinate system from global to local so that your bot is always move in front of you. We let the EA visitors to try the two version and everyone who tried it out prefer the later one which means we are in the right track.
On Friday, we have another updated version which includes the wheel animation and realtime shadow. The wheel animation is based on the real physics, if you turn right, the right wheel will rotate backward while the left one rotate forward. And the shadow enhance the feeling that the bot is in the real world.

 

Design:

As a team, we decided to focus on the “Re-Design” (Phase 2) part of our game to be playtested in week 6.

 

The goal of this playtest was to figure out:

• how players react to problems presented to them
• how creative their solutions can get
• their understanding of a bot’s weaknesses and strengths
• which bot would they like to play as

 

As a part of our playtest, we presented players with 3 scenarios:

1. How would you redesign the robot with the hammer to make it more stable?

2) How would you redesign the silver and red robot to deal damage more effectively?

3) How would you change the two-wheeled robot so that you could recover after being flipped?

For each of these scenarios, we further asked them the following questions:

• For every problem stated, we asked them if it was something worth fixing?
• What are each bot’s weaknesses according to you?  Is this something you want to make an effort fixing?
• Which one do you prefer, offence or defence?
• Which bot would you like to play as?

 

This playtest was conducted in two separate ways,

1. We had half of our playtesters fill this survey at home to understand how much of the problem the playtesters at home were able to comprehend.
2. We had the rest of them engage in an open discussion with us to encourage them to talk about feedback that we were not necessarily looking for/didn’t foresee.

 

Our findings:

1. We were able to narrow down some of the most common but incorrect solutions for the first two scenarios.
2. We found out that players were thinking more when they reached the third scenario.
   1. This could be because of their practice with the first two scenarios
   2. Their ability to better understand the battle after going through two scenarios
   3. The problem being interesting and easy enough to encourage players to find creative solutions
   4. A much easier understanding of the problem without having to explain what was clearly wrong with the bot that was immobilized
3. Most of our players preferred to pursue an offensive approach when it came to choosing the type of bot they would like to play as. This mostly was based on the liking of the weapon the bot had. For example, players did not realise how powerful a drum bot would be because it’s impact is not visually clear.
   1. We need to have  feedback system that highlights the impact and has more clarity in terms of how effective or damaging the weapon is.
   2. A passive weapon can be a bad decision as players were constantly preferring weapons that they could trigger/activate a weapon at their own will.
4. We need to choose a scenario that is easy for a player too grasp in terms of what the current problem is. For example, players did not know what was wrong with the hammer bot unless it was explicitly mentioned to them. Whereas, a scenario like getting immobilized conveys the problem without further explanation.
5. Players loved the horizontal spinner and this is a weapon that will be introduced during customization after phase 2.

 

Our next playtest will be based on scenario 3 (being immobilized). We will be presenting players with options that they can choose from to fix this problem. Each option will have a weight and a cost associated with it.

This playtest will help us in the following way:

• further tune/balance weight vs cost
• it will give us an idea about how hard or easy is it for the players to figure out the right solution to the problem
• how many right vs wrong solutions should exists
• What are some of the aspects the player liked/hated when doing this exercise
• how to further make this scenario interesting

 

Art:

In this week, we finished the 3D models concept for our final project. We made two battlebots based on the shapes of two real famous battlebots in the show.

After the Art and Design meeting, we figured out our basic restraint relationship among different weapons. For the art, we will start to build weapon components for the game such as hammer and flipper. So in the next week, we will start to make the models of several weapons. In addition, we will begin texturing some models by Substance.

 

UI/UX Design:

In this week, we had our first formal playtest on ‘Redesign’ part which could help designers in the team to ideate more options of redesigning bots and also playtest the prototypes we made in last few weeks. We got lots of valuable input from people inside and outside ETC building. I collected the feedback of prototype playtest and delivered them to our programmer. For now, we were trying to solve the problems of control system.

 

As a part a design work, we try to review the game design we had from last week and modify a little bit to fit with our time and resource constraints and client feedback. We also generate a idea about bot gallery at the end of the whole experience to satisfy our client requirements from last client meeting that we probably need to make manufacture get more involved into the whole process.

 

I and Trisha has a clearer work division about design after faculty meeting in the middle. After the team deciding our basic flow, we will take responsibility for different parts work. I will take care of the design to user end and Trisha will take care of game level design.

 

To help the team have a better understanding of our game flow, I made the wireframes of battle phase. I believe visual elements could help our team on the same page and also help to move forward. I’m still in the process of experiments and comparison different layouts of battle phase with people’s critique around me.