Responsive Web Design

The Objective of this month long project was to create value for in the electronic waste recycling process by identifying problems and solving them by designing web pages for both desktop and mobile screens.

Created as part of the Interaction Design Studio course, the techniques used were guerrilla research, story-boarding, personas, wire-framing and visual interface design. The tools used were Figma, Invision, Sketch, Illustrator and Photoshop.

Take a look at the process book on the right.

Themed Experience on the Oculus

Togo: The Trail of Mercy is a fully fledged theme park experience complete with ride queue, virtual reality, media, and an automated ride. This experience followed the true untold story of Togo- The unsung hero of the “Nome Serum Run” dog sled journey that took place in Alaska in the winter of 1925. The VR experience was done by a team of 5 which I was a part of. As this was part of a scripted experience made by the Carnegie Mellon School of Drama, we were aware of what exactly we were supposed to do and what feelings to invoke while experiencing this.

I worked on the world and environment design, mechanics and VFX. The platform used for VR was the Oculus Rift.

Angry Chicken is a Virtual Reality experience built for the HTC Vive. This was built by a five person team in a period of two weeks. I was in charge of production, level design and programming.

Goal and Design Process

The theme of the round was a naive guest round, so the success of our work depended on how intuitive and comfortable our game was to play for someone who had minimal to no experience in Virtual Reality games. Since our platform was the HTC Vive, we decided to make full use of the room-space playing area the  device affords. But this was a tricky challenge because a naive guest may not recognize the freedom of movement, or any interaction for that matter. We eventually settled on a destruction game where you take the role of a godzilla chicken destroying a city in search of eggs.

Once the theme and setting were in place, we had identified the direction that we wanted to go with the project and we were wary of possible pitfalls that could pull us back.  The core mechanism of the experience was the fun felt destroying world objects and the freedom to do so, and we picked up that as long as we did that right the quirkiness in the story and the world can be overlooked. Since our world had a city setting for the chicken to rampage in, our art assets were all models of actual entities you were likely to find around a city: buildings, houses, cars, trucks, helicopters, street lamps, etc. To maximize the feeling of fun, we had to make the destruction of buildings realistic; i.e. only those parts/chunks of the building which have been hit by the wing should have its respective physics acting on it. This could not be achieved by having complete models of the edifice, so the artists made houses and buildings piece by piece which we put together on Unity. This put us in a good spot for the interim review by the instructors.

Challenges

There were two main challenges that we faced in principle game design and this is how we solved them:

1. Getting the guest to know where to go and if they're doing the right thing This was a major issue as in VR, players sometime tend to have no idea what to do, even when the solution is as simple as just looking behind you. In the intro of our game, we emphasized on the need for the chicken(guest) to find the eggs.  If the guests misses it (and usually they do) they realize it when they start the game, in the first zone of the city.  This zone contains limited amount of objects to destroy and it is impossible to miss destroying the house in front, which incidentally holds the first egg. The guest learns that on touching it they enter a new zone with a new egg, and so on. This serves as an indirect control as the guest starts looking for the eggs while also wreaking havoc
2. Moving the guest around in a city-sized area As large as we wanted the city to be, brimming with stuff to destroy, the area couldn't possibly be accommodated in the Vive space.  This would result in either the buildings being too small or the number of buildings be too less. As a temporary measure we used teleportation as a means to transport yourself through the city, but after interim we received not-so-positive feedback on that feature. Then we replaced it with the enlarging of the chicken itself, so after getting the egg of a zone, the chicken grows in size and gets access to an even wider area of the city which could only be seen and not touched previously. It could also be justified in the narrative since it was after all a chicken that survived a nuclear attack. Eventually, we were highly commended for implementing this idea.

Angry Chicken was deemed by peers, instructors and alumni as ETC Festival worthy, so we went about theming a room allotted to us in a way that shows the setting of the game. We went for a nuclear lab environment with the backdrop of buildings and skyscrapers, and used black light and glow paint to good effect. We also gave extra space around the edges of the Vive area to account for people wildly swinging around their controllers, but despite all there was plenty of spillage (and paint scrapes off walls) on the day of the festival.

The following projects were created for Visual Story course at the Entertainment Technology Center. I performed various roles and duties in each assignment and learnt about the film production process while doing so.

Global Game Jam 2018

CosmoSwing is a 2 player experience built for the PC for the Global Game Jam 2018 under the theme “Transmission”. This was built by a 4 person team in a period of 2 days. I did level design and gameplay programming and made a prototypes for the team to iterate upon.

Brainstorming and Ideation

When we received the theme of what we’re going to make, we spent a while brainstorming on ideas that would make sense with “Transmission”. After we bounced around a few ideas, we liked the concept of carrying a message in space. But along with that, we also were looking for a fun game mechanic to go along with it and we discussed several ideas that could blend both with the theme and a good game mechanic. We settled on the player being able to control a rocket in space, jumping across planets.

The idea was that the rocket continuously rotates a planet and to jump correctly, the player should aim the rocket towards the edges of the orbits of the destination planet. If they aim towards the center of the planet, the rocket does not catch the orbit and crashes into the planet. This was kinda based on real rockets using planets’ rotation to gain velocity and achieve efficient landing, like in the movie “The Martian”.

It was a unique mechanic, but we weren’t quite convinced how fun it would be. The only way to find out was by prototyping the simplest planetary jump quickly, and working upwards from there or getting rid of it entirely. We set to work and I used Unity’s in-built functions and a bit of math to get a prototype so that we could start testing as a team.

Process

After adjusting interplanetary distance, rotational speed and translational speed, we found that it was indeed fun and kinda tricky to jump planets.  You had to have very sharp timing and notice the angles to pull of the jump. We decided to go ahead with the game, which was the rocket would serially go into a randomly highlighted planet, collect an alphabet from there and go to the next one. At the end, we would have to unscramble the group of letters that we found to find the code,or transmission.
But after we integrated the blasts when the rocket hit the planet, the gameplay became so fun that we decide to pivot the game and just make the gameplay all about the jumping planets, with blasts and all. So we decided to add another rocket, and make the game a two-player race where the winner is the first person who can maneuver past all the planets and reach Earth.
The rest of the game was all about level design and testing it out. It was hard to get the game balance, because if interplanetary distance was too little then it became easy, but we also wanted the player to get across the screen.So after multiple iterations, we decided to have a U-shaped layout, which gives the player the freedom to risk it all by making a big jump directly to Earth, or play it relatively safer but planet hopping. After a long night, we finally got the game balance to just right, after multiple external playtests. Our hard-work was rewarded, as we were chosen as the game with  the Best Game Mechanic!

Play the Game

You can download and play the game here:
https://globalgamejam.org/2018/games/cosmoswing

About

It all started when…

The following is placeholder text known as “lorem ipsum,” which is scrambled Latin used by designers to mimic real copy. Sed a ligula quis sapien lacinia egestas. Vivamus sit amet semper lacus, in mollis libero. Nullam sit amet nisi condimentum erat iaculis auctor. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae.

Aliquam bibendum, turpis eu mattis iaculis, ex lorem mollis sem, ut sollicitudin risus orci quis tellus. Mauris id fermentum nulla. Nullam sit amet nisi condimentum erat iaculis auctor. Suspendisse nec congue purus. Mauris egestas at nibh nec finibus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae.

About

BUILDING VIRTUAL WORLDS ROUND 1

Mabel is an Augmented Reality experience built for the Microsoft Hololens with the clicker. This project was built by a five person team in two weeks time. I was the designer, writer, programmer and producer on this project.

The theme given to us was that character A is scared of an entity or character B, and the guest has to help A get past that obstacle or fear. We decided on a fantasy setting where you take control of the deer and explore the castle in search of a potion that can transform the deer back into a princess and end the game. We initially tried to design a maze puzzle, where the guest has to move walls to make a path and get to the desired destination. This then was adapted with a fantasy story such that you have to help a transformed princess navigate a castle while watching out for guards.

Implementation and Challenges

Implementing this was not as easy as initially planned, as we had a few technical hiccups. Since we had all levels piled one on top of the other in the castle, the Hololens clipping plane was causing part of the design to be invisible to the guest view. Also, input to give directions as to where exactly the deer has to go was difficult to work with the 'Pinch' interaction on the Hololens as it was causing inaccuracies in location of pinch. I then simplified the design so that the castle itself doesn't change, but the mazes are replaced by patrolling guards so that you have to time your movement to avoid being captured by the guard.

The clipping problem had to also be dealt with efficiently. If you get the Hololens camera too close to a model, the model gets clipped. So basically if we created one joint castle on Maya it would completely vanish if a guest brings their head close to it. So we constructed the castle from individual bricks, using a script to set dimensions of a particular wall and then putting up the wall in the desired location of the castle, all in Unity. This turned the tide completely, because now we were using the clipping plane to our advantage. A player can now look into any enclosed rooms through multiple tiers and irrespective of which floor the deer is on. This feature eventually turned out to be the most notable and attractive one in our game.

After this, the remaining part of the development was just fine tuning the location of the collectibles and the position and routes of the guards.  The design was in such a way that to finish the game, the guest must explore all parts of the castle, in the process getting past all the guards at least once. Once we integrated the Hololens clicker, target accuracy improved drastically and the experience ran smoothly. After several playtests we felt that we needed to add in a mini-tutorial to familiarize guests with rules of the world. Player experience remarkably improved after that.

Personal Space Invaders is a Virtual Reality experience built for the Eye-tracking VR headset Fove. This project was built by a five person team in a period of one week. I did game-play programming and UI design.

Personal Space Invaders is a level based game in which the target of the player is to outlast the timer of each level without being caught by the naked musclemen. We made full use of the eye-tracking technology in the Fove as the player has to look directly at the musclemen for them to stop coming towards the player. If the player blinks at any point in the game, all the musclemen in the scene leap towards the camera (the player). The principle objective of this game is to have a fun experience, which was the theme of the lightning round.

We intended on having the experience incline from easy to hard, and by the time the player reaches the final level they have a good understanding of how the weird world works, and what they should and should not do to get their personal space invaded. Most brainstorming sessions were spent figuring out the configuration of musclemen placement across each levels.  We initially started out with a 360 degrees placement (all around the player) but during initial playtest we realized that it just led to players wildly swinging around back and forth and straining their necks in the process. We made several prototypes and finally settled on an arc, gradually extending in angle and number of musclemen through the levels. Difficulty of each level was set using the speed of the approaching musclemen, which was also gradually ramped up for each level.

Several indications were used to give feedback to the player, as we learnt in playtest that without feedback it was not obvious if they were staring at the right place and whether or not they were blinking. We kept an Eye Open/Close sprite in the center of the camera view, which tells you exactly where you're looking at. When you look at a muscleman they not only move backwards but they also turn red which reinforces the fact that you're looking at the right place. We gave plenty of auditory indicators for when they're close by, spawning or moving away

About

Deep Trouble is an asymmetric multi-player game built for the Jam-O-Drum platform. Deep Trouble was built by a four person team in a period of two weeks. I worked on general programming and designing for the game which includes assigning player roles, environment mechanics, User Interfaces and systems design.

The Jam-O-Drum is a table-sized platform onto which a projector maps the game from a  computer, while up-to  4 guests can play a game on one of the 4 controllers placed on the edge of the table. Guests can give inputs either on the drum (by banging it) or on the spinner (by rotating it). This game was designed for 3 player controls while the fourth corner was used as a fuel meter.

We took inspiration for our game theme from another game which was developed on the Unity Engine, Sunless Sea. But our experience was a co-op game, with three distinct roles for all three players. The three roles decided upon were:

1.  The captain, who's in charge of piloting the submarine around and provide speed boosts
2.  The helmsman, who has to use the sub's light beam to look for fuel but also be careful not to attract sharks
3. The mechanic , who has to fix the damaged navigation and light mechanic

This conclusion however was only arrived after much deliberation. We faced a lot of dilemma over how many players should be allowed, whether they should be playing cooperatively or facing each other and what roles they should have.

Since our game involves navigating a boat only in one direction, that meant that for one player (the player whose side the ship is moving towards) will have his spinner direction inverted, which may be confusing while playing. So that's why we came to the conclusion of having 3 players, in directions left, right and behind the boat, and all playing for the same side.

We also spent a lot of time trying to figure out mechanics & Interface for each role. Our initial build had cannons attached to a boat, but it got called off as a shooting game, which is against BVW rules. So we had to come up with new meaningful roles to replace the cannon-guy, and we arrived at the mechanic/repairman of the sub. Their job entitled spinning their pointer towards the teammate who needed help and banging on the drum to boost up health. As they had to switch between fixing the light and the navigation instinctively, the UI had to be clear and easy enough to allow it to do so. I came up with this flow of display for the mechanic's drum

We implemented this and playtested it out. The design was not only intuitive but it was pretty fun to bang on the drum, helping out your teammates. So we decided to stick with this feature. Obviously the aesthetics of it were improved upon.