Babel: Beta

______________________________

|| THE GAME ||

______________________________

Babel is a networked multiplayer platformer game, with cooperative puzzle elements. Play together and explore the rich environment of the ancient floating islands, left in ruins after civilizations of the past but now re-discovered. With Oculus Rift compatibility, you can truly immerse yourself in this stunning expedition.

Use the unique Frequency abilities that your character can control to help one another by boost jumping to greater heights, creating and connecting portals to teleport around the level, manipulating platforms using switches and buttons that may need power from more than one source, and calling others to assist if you get lost. Seek out and collect the ancient treasures to increase your score, with the more valuable crystals requiring cooperation from other player(s). You can use character animations, such as waving, to communicate with other characters.

Babel is a game that is suitable for all ages. Since the player can only interact with other players using non-verbal communication as a design choice, and would not have access to verbal communication means within the game such as built in chat, it should be widely accessible to people who have difficulties speaking to other people or players that don't speak the same language. Babel was designed to be a virtual space where everyone can experience and partake in the benefits of cooperative play, especially those affected by problems such as social anxiety and mutism.

______________________________

|| THE TEAM ||

______________________________

Whoaful People

Stephen Fleming: Stephen was the team leader for the project, and took charge on some of the decisions that were made over the course of development. He also used the Kinect motion sensor to capture animation data, that he later edited to be useable for the game. Another area he worked on was 3d modelling, focusing mainly on the environments, and ultimately building all of the levels in the Unity game engine.

Patrick O'Halloran: Patrick performed a variety of programming tasks on the team. His works included network, animation and gameplay programming as well as performing other general programming tasks.

Senyee Lee: 2D Artist and 3D Modeller. She designed and modelled the character. She also created the decals based on Aztec/Mayan research.Her other tasks included modelling extraneous objects, unwrapping and texturing various models. 

Cian McCormack: Cian was in charge of the UI designand implementation in the game, along with being the lead on the Level design. He was also the Sound Designer, as well as taking on various programming tasks.

Lee Byrne: Programmer and sound engineer. He worked on the implementation of some of the core game mechanics, and was the main contributor to the puzzle system including the Trigger ability, buttons / switches and platform control. He worked on general backend mechanics such as character movement and physics. He was in charge of implementing all the local and networked sound cues in the game, and also designed / sources many of the sound effects in the game.

______________________________

|| LEVEL DESIGN AND ENVIRONMENT ||

______________________________

With the environment design we had a very specific idea in our head; floating islands. The floating islands would provide the perfect opportunity for us to delve into building a hugely creative environment, as well as create interesting puzzle sequences.

The games style has retained the idea that it is a mysterious world, with some Aztec design to it, but also combining more futuristic equipment to it, such as the platforms, and buttons. The mystery comes from the ruined walls, and pillars which give an impression of some long lost civilisation, and pushes the narrative we wanted build up throughout the game world.

In terms of overall level design, we wanted something that had a very natural flow to it, where the player could explore where they wanted, but without them being overwhelmed by having too large an area to explore. To cope with these we decided to have 3 main islands, which would act as hubs for the puzzles that the players would have to solve to get the gems scattered through the area.

The puzzles would appear simple in nature, requiring the players to actually co-operate to get the gems. However, we wanted to avoid forcing players who wanted to play alone, to have nothing to do, so through skilful use of the mechanics and environment, a player could in theory get almost every gem alone.

The sparse placement of objects was important to the design, as it made the level more focused, with areas of interest highlighted by these objects being there.

______________________________

|| CHARACTER ANIMATION ||

______________________________

The character animation is driven by the new state machine animation system Mecanim. Blend trees are used to naturally blend between running, walking, idling, jumping and falling! This makes the platforming portion of our game feel very responsive. 

As well as movement animations, we also have special emotes that the player can perform. All the animations in the game are networked for other players to see. The player can wave to others or perform a variety of dances to express themselves. The layered system in Mecanim allows you to wave while walking for example. 

______________________________

|| USER TESTING AND FEEDBACK ||

______________________________

Online Testing: We were in a lucky position that we could essentially hand out to anyone online to test, and this was one of the major areas we focused on when getting feedback to work from.

This method of testing was extremely beneficial because it let us see the capabilities of the server we were using, and how many people it could cope with, but also let us get some interesting insights from the players we gave it too. Stephen would give a build of the game out to people who didn’t know each other, let them play together for about 30 minutes, before talking to them individually and getting their opinions on what they had played.

Their feedback led to several changes; namely, what were you really getting by collecting the gems. The idea of getting something abstract like points was redundant, and so the diegetic UI that allows you to see another players progress, gives players something to work towards.

Another area that changed, came from a technique that players discovered. This was using the ability to make portals to let a player jump higher, when they exited the second portal they created. This portal jumping technique requires a certain level of skill to actually pull off, but in this sense, we discovered that if a player had enough skill, they would be able to basically get any crystal in the game, on their own.

One other area the feedback we recieved, that influenced our focus from having multiple hand gestures/animations to tell players how to place, was to move to a version where the auras would be better indicators of allowing the players to achieve what they wanted. What we saw, and what we learned was that players didn't want to stop and select a new animation, or stop to try and use this technique to explain to a player what they should do. Instead what players wanted was too keep moving, and figure the puzzles out through sheer problem solving. 

Offline Testing: One issue we ran into with the online user testing, was the fact we didn’t actually get to see players go through the game, and watch how they found using the user interface was. As well as that, the online testers were generally seasoned gamers and knew what to do in the game.

In our offline user testing session, we finally got to see how players used these various elements, and we noticed two very big things. One was that the user interface wasn’t being fully utilised, and that people found it slow and cumbersome to use, and that players were struggling with the mechanics of changing between frequencies.

This led to some radical, but simple changes to the game. We ended up removing the user interface entirely, and moving all of the buttons to the controller, as well as removing the idea of having to select a particular frequency to use it. What we ended up doing was using a single, context sensitive frequency.

In our testing of these more refined mechanics, we found that players instantly had a better understanding of what was going as they played. They didn’t have to stop and slowly move between the boost jump, and the portal, but had a smoother experience in doing what they wanted.