The fifth and final round for Building Virtual Worlds was a big one. We were given three weeks instead of the usual two and were not given a specific prompt. Rather, we were supposed to keep a few things in mind:
Design your world for the end of the year festival.
Consider how many guests can experience your world at a time.
Consider how fun it is to both play and watch.
With these constraints in mind, a scribbled some quick notes on my assignment sheet to try and get me in the optimal mindset for a project like this. In other rounds, it was a “one-and-done” situation, but now replayability was going to be a major factor considering the festival atmosphere. My notes included such insightful thoughts as:
quick + fun
small w/ polish > bigger in scope.
With this in mind, my team met to brainstorm. Usually, teams had five members, but our team was one of the four-person ones (one programmer instead of two) so we started thinking about hardware to fit this additional constraint. We ended up landing on Kinect, and got to work. Utilizing mechanics such as the movement ones associated with Kinect (gestures, poses, and overall movement) was a new area to explore for me as a designer since I have primarily worked in PC and VR up until this point.
Brainstorming ended up being slightly more difficult than in previous rounds. Our team focused primarily on the aforementioned hardware and mechanical aspects of the project this time, and couldn’t get to the “spark” of what our experience would be. Finally, I asked the group, “We all saw previous Round 5 worlds. Which one was the most interesting to you guys?” After a moment, one of my team members said, “I really liked ‘Space Bar’.” This experience involved bartenders at a weird club working together to get aliens cocktails. As it turned out, the entire group enjoyed this world for its weirdness as well as its cooperative nature. After this realization, we were firing on all cylinders.
We ended up going for a similar approach to our “Space Bar” jumping-off point in terms of bartenders working together to serve customers. Utilizing Kinect’s motion-tracking, our initial pass at the idea involved one player selecting ingredients and then combining them via magic. The combined cocktail would then drop from a portal on the ceiling to the second player, who then had to use their flat hands to juggle them over to the appropriate customer.
We felt that we captured the fantasy well, but had some initial concerns. For instance, having the selecting player do a “grab” motion with their hands, while intuitive, seemed tricky for the Kinect to register. In addition, there was a lot of waiting which is not a “mechanic” we wanted to have. While the juggling was fun, the selecting was more like work. In addition, the drink creation process involved seeing a completed drink with three colors and having the players interpret what they would have to combine to get that drink. After receiving this feedback, we decided to follow the fun and have both players work on both parts of the drink creation process. Modifying our game scene, we had a new layout to test:
With this layout, now both players had to work together to select ingredients and get them to the center of the screen. In the center, a magic circle would keep the ingredients you put there. Once three unique ingredients were in the center, it would combine into a drink which the players would then have to get to the correct customer. We attempted to have the selection process have more interactivity than before, which seemed to help. However, the flat hand juggling process, while fun, in theory, kept proving difficult. We tried numerous iterations on this layout, specifically where the ingredient buttons should be placed and where / how should the ingredients emerge. Should the buttons be on the sides? Should the ingredients emerge with some horizontal velocity to allow the player an easier time getting them moving in a horizontal fashion? What if the ingredients dropped from the ceiling? Would the flat hands be able to get them going horizontally? What if we tried hands that could rotate?
With this layout, we were clearly plagued with a lot of questions. After some time testing options and having none feel great, our team sat down in the testing room and thoroughly discussed an attack plan. While we all wanted to have the players combine ingredients to make a drink and have the player deliver said drink, we realized that perhaps this is a little too much. While these actions fit within the fantasy of what we were going for, the order of actions wasn’t fun and therefore had to be changed. This was a tough pill to swallow since we all loved the crafting aspect of this game and didn’t want to see it go. That’s when I pitched the notion of “what if we didn’t get rid of it completely? What if combining was the core loop?”
With a maelstrom of changes to make, we got to work. We realized using the flat hands was incredibly limiting, and even adding the option to rotate was not as useful as we thought considering the Kinect’s recognition limitations. We added in the forearms of the player so they can choose to use their arms as ramps or even pinball paddles. We also ditched the “combine then deliver” loop, instead opting for the players to get the ingredients directly to a bar glass itself and combine it in front of the customer.
This proved to be very effective. Players were communicating now more than ever, and it seemed like adding the forearms made getting the ingredients over that much easier and way more fun. We also implemented a solid interest curve in terms of how customers come into the bar: it will always be a customer asking for a 1 ingredient drink, with the ingredient swapping between players. Then a customer would show up asking for a 2 ingredient drink (as seen above). Finally, 2 customers would appear at once, asking for 1, 2, or even 3 ingredient drinks. As the game goes on, the chance of a customer asking for a 3 ingredient drink increases. Adding the second customer pushed communication to the forefront as well as the added challenge of getting an ingredient over one customer to the other one. This made us look at colliders extremely carefully to ensure players did not feel “cheated” if they didn’t make it over. To solve this problem, we implemented the idea that a glass’ hitbox would be slightly bigger for correct ingredients and smaller for the wrong ones. This was a great solution and brought with it amazing moments in playtesting. We also had each player only use one arm; so the player on the left would only use their left arm and vice versa. In playtesting, we realized there was a lot going on, and having the second arm seemed to only get in the way. Finally, we put in a fill bar on the ingredient buttons to allow players a moment to select their correct ingredient, coded in a point system based on correct ingredients in drinks (with ingredients in 3 ingredient drinks being worth more than 2, etc.), and a leaderboard for added competition during festival (if we got in).
Overall, Hamate & Bone was probably one of my favorite projects to work on this semester and easily my favorite world. While we were a small team, we all worked and communicated extremely well together. While the world isn’t perfect, it’s definitely fun and has a noticeable learning curve that I am proud of.
Hamate & Bone was accepted into the BVW Festival 2019
Programmer = Jianghao Hu
Artists = Yiqi Chen & Pe-Yi Yi
Sound Designer = Lawrence Plofker