Author: iamsuigeneris

EA OCCO: JPiS

iamsuigeneris

For the intro animatic, I composed original music alongside the video that coincides with the key points of emotional expression. I calculated what BPM would match these points and then created the song in Propellerheads Reason (version 7). I also designed sound effects to act as stingers for the moments of communication that tell players the story of the game they are about to play.

I made this teaser video for a student game project I developed under the direction of the Office of the Chief Creative Officer at Electronic Arts. For the project I served as a game designer, audio artist/engineer, and producer. This video showcases some of the music and sound effects I did for the game.

For the first 3 stages of gameplay I defined an intensity variable that is passed into Wwise for RTPC. The intensity settings of 1, 2 and 3 correspond to low, medium and high, respectively, as seen in this video. Once the players reach the boss, the music transitions to a new song, and again if they manage to defeat the boss. Not depicted in the video is the increase in pitch, tempo, and HPF as the players’ ship takes more and more damage, followed by an immediate drop in pitch accompanied by a LPF when the players take a final life-ending hit.

Advertisement

Planetside 2: First Impression

iamsuigeneris Leave a comment

I recently tried out the Planetside 2 beta on PlayStation™ 4. My first impression was surprisingly disappointing. I was visually underwhelmed, though I qualified that with the knowledge that it is still in beta and not everything is indicative of the final product. But more importantly, I was dropped into a massive new world with absolutely no idea what to do. The first instructions I receive are simple enough to follow, teaching me what each button my controller does. But after that, I’m given a jolly sendoff into battle… a battle with a location I don’t know and no clear method of transportation other than sprinting by foot, which in fact I proceeded to do. I ran and ran and ran… and ran through a sparsely populated environment filled with dirt, the occasional shrub, and rolling hills, never seeming to get any closer to what I believed to be a target beacon on my HUD. Within 20 minutes of starting I decided to close the game and play something else.

In contrast to this experience I recall the first time I played Titanfall, also in beta at the time. Not only was it a new control scheme to learn but on a rather new platform for me: PC as opposed to my preference of consoles. And yet, since Titanfall was a new IP, it approached its players with the expectation that they would need a solid understanding of how to play in order to enjoy the game. They expertly crafted a tutorial level broken up into pieces in which a control mechanic is first explained, followed by a simulated situation in which to enact it. Should you fail, you can instantly retry. By the time I completed the tutorial, I was able to get my first kill in my first online match against other players, even though I’m not a PC gamer and had never before played a game with the same movement dynamics. This stands in stark contrast to my experience with Planetside 2 where I couldn’t even find the battle.

Planetside 2 is not the only FPS in which I had this experience. Some years ago CCP Games launched Dust: 514 on the PlayStation™ 3. While I did have the benefit of being at home on my input device, I was new to the EVE universe as well as the particular way that battles play out in the game. My first time dropping into a match involved a lot of sprinting and dying. While text explanations of every single object in the game were plentiful, understanding it all was not a task that the uninitiated would find accessible. Lackluster gameplay and the prevalence of nigh-indestructible veterans inspired sporadic gameplay and eventual abandonment of that game for me and I fear that Planetside 2 will share the same fate.

EA OCCO: Jelly Pirates in Space

iamsuigeneris Leave a comment

Team Legato & ThunderEgg (Collectively The Vanguards)

Collaborators: Sudhanshu Aggarwal, Chih-Wei (Jerry) Chen, Chong Hu, Christian Karrs, Michael Lee, Rahul Nagarkar, Xin (Zinc) Ning, Xinyu (Lillian) Qian, Akshay Ramesh, Jimin Song, Goksu Ugur, Meng-Hua (Julia) Wu, Wanyan (Aurora) Zheng

Timeframe: January 2015 – May 2015

As my final semester project at the Entertainment Technology Center, I worked with Electonic Arts’ Office of the Chief Creative Officer under the direction of Richard Hilleman. Working as two remote teams, we created a cooperative, a-synchronous, shoot-em-up for players who don’t fall in the category of “core gamers”. Using simple mechanics that allow for an easy-to-learn and fun experience, we designed the game to appeal to children ages 8-12, as well as their parents. Through this approach we created a game that offers fun for the whole family! For more information, please visit our website.

Roles: Game Designer, Sound Designer, Producer

My contributions:
– Designed game with 3 others (including creation and maintenance of design documents)
– Design document can be viewed HERE
– Composed original soundtrack
– Created and curated all sound effects
– Integrated all audio assets into Unity3D using Audiokinetic Wwise™
– Production, e.g., tasking, scheduling, support, communications (internal/external), etc.
– Remote team management
– Wrote and published weekly newsletters, as well as maintained a team blog
– Created promotional video content
– Created and maintained project website

Project allo – Entry 9

iamsuigeneris

This week we focused on improving our game experience based on the feedback and observations from our playtest last weekend. We have another playtest scheduled for this Saturday so that we can test out the mechanical changes that we made. Our semester is approaching its end so we have accelerated production to reach our goal of a complete game experience by our soft opening.

We conducted a playtest last weekend to assess our current game design. The playtest showed us that players liked the team shooting experience we offered them. They really liked the visual theming. With regard to the 3 control interfaces we had them try, the majority of players liked being able to independently rotate their cannons around the entire ship as opposed to being dependent on the captain for positioning (as was the case in the other 2 control schemes). They really liked the surprise of the special ‘danger’ event that happened at the end of the test level. Criticism centered around the insufficient responsiveness of the controls. We had incorporated friction and inertia into the movement of the captain’s shield and crew’s cannons in order to give the cannons more weight and make the game a bit more challenging; however, we observed that we set those parameters too high so we will be reducing them for our next playtest, in addition to the other mechanics changes.

Our challenge this week was for our design team to lock down the intended game experience. So far we have been creating an experience intended to be cooperative; however, the shooting mechanics and current enemy designs do not require or encourage the players to work together. In the playtest, we observed that each player’s role is so intuitive that they don’t need to communicate more than once or twice during the game. We had a long discussion on whether we wanted to continue with this shooting gallery approach or stick to our original intention of tower defense. We chose to stick with the simple basic shooting mechanics; however, we will be adding unique special abilities to each player role, as well as enemies that can only be damaged by specific players in order to increase the cooperation requirements of the game. We believe this will make gameplay have more meaningful choices on strategy and we will test the theory in our playtest this week.

Project allo – Entry 8

iamsuigeneris

So far we have been working to design the roles of captain, navigator of the ship, and crew, players who man the cannons of the ship. We have iterated on mechanics that allow the captain to move the ship up and down, as well as crew mates to move their cannons around the ship in order to aim. We are anticipating our second playtest and wish to lock down these two roles in order to consider a third role to provide more variety and selection for the players.

Our designers came up with a third interaction scheme for the game based on feedback we received from clients and faculty. The captain can move the ship up and down onscreen, as well as rotate a barrier that can protect parts of the ship from enemy impacts. The gunners are able to rotate the cannons around the ship’s entire 360-degree range (though they cannot occupy the same space/overlap). We wanted to try a version with these mechanics in order to give the shooters more independence from the navigator, as well as to give the navigator a more clear and meaningful interaction.

Captain and Crew

Project allo – Entry 7

iamsuigeneris

In the time since we decided on moving forward with our fourth prototype idea, we have been designing and building elements to turn it into a comprehensive experience that appeals to both children and their parents. We have designed and are building a cooperative, space-themed, tower defense/shooter hybrid game that drops players into the role of space pirates trying to survive perilous locations in search of treasure.

We have been building our final product design for the last few weeks leading up to our halfway milestone. This is a short peak at our progress.

Project allo – Entry 6

iamsuigeneris

This is our fourth design idea. We designed and built it in tandem with Dynamic Defenders as an alternative interpretation of the original allo idea: all players control part of one object. In this game, players each man one of three cannons and try to protect their ship from incoming enemies. They can also collect power-ups that change the nature of the shots their cannons produce. For this prototype, players must try to survive for as long as possible before their health bar reaches 0.

Jellies in Space

The idea of this design was to encourage player cooperation by binding them to one in-game object and tasking them with protecting the object (and themselves by extension). Faculty and client response was positive, particularly with regard to its potential for expansion. They found the controller, a rough implementation of the Dynamic Defenders controller, unintuitive and they felt that having the spaceship rotate automatically was more of a hindrance than a help. Based on our client feedback we decided to move forward with this premise, and create a design for a full game around it.

Project allo – Entry 5

iamsuigeneris

This is our third design idea. Since faculty responded positively to being able to freely bounce around, we decided to change the design to resurrect our initial goal of a cooperative experience while maintaining the player agency they liked. In this game, players must work together to protect a constantly-changing VIP player from hazards coming at them from offscreen. If a VIP is hit, they lose their status and the title shifts to another player. Players must try to survive for as long as possible; once all players have been hit as VIP, the game is over.

Dyanmic Defenders

This prototype was designed in response to positive feedback from our previous Bouncing Billiards prototype. We wanted to test a mechanic of giving players full agency in determining what they do, while incorporating game mechanics that require them to work together and help each other. Responses were positive, with the biggest issues being the learning difficulty and the incomplete quick-time interaction events. We ultimately discarded this idea in favor of our fourth prototype because we could not justify how the game could be expanded into a more comprehensive final product that required 14 people to make.

Project allo – Entry 4

iamsuigeneris

This is our second design idea. Using the basic mechanics of pool and applying our multi-player bouncing jellies, 2-4 players engage in a chaotic race to get the most balls into the pockets. After pocketing all of the regular balls, The Crazy Eight ball will appear and begin chasing the nearest player. All of the players must work together to pocket The Crazy Eight; however, they can only hit it safely from behind, lest they be consumed. If the players successfully pocket The Crazy Eight, the players who remain alive get bonus points. If they all get eaten, then the winner is determined by his/her score from pocketing the normal balls.

Bouncing Billiards

This prototype was designed in response to the failures of our first prototype. Though the implementation of that prototype was flawed, the idea of bouncing around as jelly elicited numerous positive responses. As a result we made a simple game that gives players the full freedom to bounce around. Though they each share the same objective, they can go about achieving it in different ways: skill shots of knocking balls into pockets, getting last touches on balls that have been hit by other players, or just launching themselves into other players to prevent them from scoring. Several faculty particularly enjoyed bouncing into and knocking each other around. The feedback from this prototype inspired our third prototype.

Project allo – Entry 3

iamsuigeneris

This is our first design idea. Players each control a portion of the gelatinous creature onscreen in order to generate force that makes it move. Each component of the creature operates like a slingshot, players can pull on their portion, release, and apply a force in the opposite direction of their stretch. They need to coordinate their efforts in order to make the creature move in the net direction they desire. The prototype includes 3 demo levels with collectible items, as well as blocks that need to be smashed into before reaching the level end.

allo

This design idea was an experiment to see if players could coordinate their collective movement by applying forces to their in-game avatar, essentially if they could work together to control one body, and have fun doing it. Unfortunately, this design did not prove successful. Faculty players found the controls unintuitive and movement stilted, as well as lacking a clear objective and a compelling reason to engage with the game at all. This was due in part to an incomplete control interface; however, the design implementation was fundamentally flawed in that it didn’t allow players enough control over what they were supposed to be doing. The amount of force generated by one player slingshotting barely moved the body, and even then it didn’t usually behave in the manner they intended. We discarded this idea after receiving feedback during our quarter milestone presentation.