Friday, March 07, 2014

Atelier II Game: Lost in Transit

Alas, the final is completed! The prototype anyways.
The following game will be featured in Level Up! Showcase 2014 on April 4th. Come check out the game and many other games done by my fellow colleagues and various universities.
Click here for the GDD. Click here for Art & Code, Alpha and Beta presentations.

Lost in Transit 

 Amongst the colossal city-scape, the enamoured heights and beauty of the magnificent metropolis distracts you, causing you to lose the one you love most dearly, and traversing analogous paths to reach the apex of the city to find them, before it’s too late. Lost in Transit is a dramatic, panic and sympathy-driven, 3D sandbox-style first person labyrinth where the player controls a parent and a child separately who are stuck in opposite ends of a city and trying to re-unite.


The full detailed description of the game can be found on the Game Design Document for Lost in Transit, which is found here.
Alternative: (Dropboxfile)
Lost in Transit stemmed from Alexandra’s proposal from last semester’s course, Atelier I: Discovery. Alexandra and I (Marishka) both wanted to do a first person 3D game. Alexandra’s proposal was based off a parent and child lost in a city and trying to find each other. The concept was open enough to discover what mechanics we wanted to implement, as well as level design and various other components that bring a game to fruition. One could easily compare this to one of the main plots of Heavy Rain. Furthermore, we did not want to create a super intense-driven game as our main focus demographic were casual gamers and eliminate enemies but rather have obstacles like language barriers or crowded streets (think of the game as the child spawn of Scarlett Johansson in Lost in Translation and Heavy Rain)

It initially commenced as a world, which was very sandbox-based like the GTA series. However, based on time limitation, we decided to create a labyrinth game, where the player would switch back and forth between two characters where on top of their obstacles (NPCs, dizziness, etc.) the player would be in a 1st person perspective, making it more challenging for the player to figure out where they are in the game and reuniting with their second counterpart.
When we placed two FPCs in Unity however, we noticed that both the characters moved at the same time. As we found this challenging, we decided to use this issue and form a sort of 3D version of a former game created by two students called Reflection, where one player controls two characters at the same time. That game was 2D and had a birds-eye view so you knew where both players were going. Our gameplay would involve the player switching back and forth between the parent and child, making it challenging still but luckily have no enemies.

Level Design
We initially designed it considering both characters move at the same time during a labyrinth. From sketching it in a bird’s eye view, I, Marishka, used Chrome Build by Lego to design a 3D sketch-up of the level using digital Lego.

From there Alexandra created the basic form of the city following the sketch-up, including roads, sidewalks, a skybox and sound.
However, the challenge came up where the characters could not be controlled in the sense that when one moves south, the other moves north and vice versa. We seemed stuck there as we tried to figure out how to program it correctly. Eventually I programmed it so that the characters don’t move at the same time by hardcoding the controller script instead of using the unity assets. Alexandra programmed the switching between characters. Thus, the game reverted back to its original idea sans Reflection mechanics.
Art, Texture and Music Assets
As explained in the GDD, we created more of a bleak city of sorts, and more or less stressed less on art and more on mechanics.
I programmed the particle effect for the child so no matter where it went, a particle effect would follow. I also created the NPC. Which at first one was more or less a placeholder using Sculptris to model and Photoshop CS6 to texture the model.

Thereon, I wanted to update the model by implementing a walk cycle or a dance of sorts. Rigging the model proved highly difficult when the skeleton would not apply to the mesh. Furthermore, figuring out Blender felt like half the battle when I semi-modeled, rigged, animated and textured solely with Blender. I also created some simple textures for the buildings using Photoshop as well the instructions and title screen. That time my tablet broke which caused major pandemonium to produce a better quality asset for the beta. However, for Level UP!, expect an update on the art assets.

Alexandra created the win/lose states as well as the camera effects for both characters. She implemented the city sounds as well to give it more of am ambient feeling of walking through city streets. Furthermore, she produced the win/lose state and mini maps.
win state (rough)

Playtesting alpha results
It was highly suggested that we added a map to give the player some notion of their location by having a close-up mini-map and a full view mini-map at the bottom of the screen to indicate the player’s location for each character. Another suggestion was having the characters to spawn at different locations each time to increase playability and implement a landmark of sorts to give the player a goal to reach (or in this case, a place that the player needs both characters to reach in order to be reunited).
Alexandra focused on getting both maps with their locations and had it so every time the player switches characters you would see the location of the active character only. At first, the full-view mini map was a greyscale map that showed the outline of the city but it was suggested to add the player’s location to that one too. She implemented a big tower located in the centre of the city as the landmark both players need to get to in order to find each other.
I focused on changing the spawn points for the player so that every time the game restarted, the spawn point would change. By creating an empty game object and instantiating it using the FPC as a prefab that is dragged when the empty game object is instantiated, the spawn location changes. The main issue wit this is that it only worked for one player so we needed to create multiple prefabs for multiple spawn locations for both characters.
Minor changes to the visual effects of players which required some debugging for the cameras but became more effective and showed improvement.
Playtesting beta results
The game plateaued, as it became more of a simulation than an actual game. The mini showing the entire city easily gave the location to the other player so we removed that. The buildings were too tall to locate the landmark so we shortened it and made it so that it would look more iconic and bold and “in-your-face” to the player (similar to Journey). The city would be better detailed which we look more into for future directions. In order to make the game less boring and give more challenge to the player to complete and replay the game (if they lose) by implementing a timer. For visual assets, it was suggested to add specific detail as players would base location on certain buildings (aka implementing more visual cues and clues).
Lastly, we decided to add unique music to each character so that the characters would know they are close to one another when two different tones they emit chime together. Furthermore, if the player goes too far off-course, an irritating sound would play, indicating that the player is too far. 
For the full list of future directions of Lost in Transit, click here (The GDD).
Alexandra Lau & Marishka Zachariah were both involved in creating 3D assets, mechanics, level design and programming. Alexandra composed all the music assets and I was involved with more of the art assets and animation.

No comments:

Post a Comment