Gameplay Camera
-The gameplay camera will settle above the currently selected playable character and smoothly follow his/her movement.
-The gameplay camera will be cardinal with a fixed rotation. North will always be up on the screen and South will always be down.
(Note: The smooth camera script I am currently using introduces a degree of camera rotation which might sometimes seem disorienting, but the effect is nice and for the most part, North is still fairly consistent. Need to decide how much rotation should be allowed)
-The gameplay camera will allow the player to zoom in and out, but should be fairly limited to prevent the player from seeing too much of the map.
(Note: In addition to preventing too much visibility, having a cropped camera adds to the fear/anxiety of the player. a closer camera gives zombies/marauders a better chance to sneak up on players and scare them. A good example of this is the Dead Space series where the camera is uncomfortably close for a TPS)
-The gameplay camera will NOT have a free fly mode, players will only be allowed to see what their selected character can see.
(Note: Originally, I thought a free fly camera would be advantageous as I thought this might be similar to an RTS giving the players a chance to make strategic decisions based on their surroundings. The more I think about this, the more I feel having a free fly camera would rob the player of exploring on their own. Even a "fog of war" mechanic that obscures unexplored portions of the map like in Warcraft removes the player from feeling like they are in the character's shoes. The focus of the game would too quickly turn into a "commander" chair overlooking the whole map and I feel this would create a disconnect from the characters and make the environment seem less threatening.)
-The gameplay camera will fly across the map when a new character is selected. The camera position "jump" will be quick, but the player will maintain a sense of location and never lose track of where they are.
(Note: This should help the player from feeling too claustrophobic and allowing them to "cheat" a little and get short glimpses of areas they may not have yet discovered. It won't really be enough to give the player an unfair advantage, but they might feel like it does. Hopefully this will make players a little less dependent on the minimap.)
(Note: I am a little concerned with how the jump will react when players become incredibly far away from each other. A slight full screen motion blur during the transition should help this.
-Buildings. Building models will be broken into parts so that when the selected playable character enters, the roof renderer can be disabled so we can see inside. This will allow us to explore the insides of structures as well as prevent players from seeing what is inside a door before actually entering. (nobody is going to charge into a room if they know it is full of zombies). I am playing with the idea of "darkening" the outside when the player is indoors to disconnect them from the outdoors and make them feel more inside.
-Stairs and floors. If a building has more than one story, the disabling of renderers should be handled to ensure that the character is visible and that the floors beneath him are not. Stairs might need to be automated (Think zelda) as you would be unable to tap on a hidden floor to go up or down. The player should be able to tap on an interactive icon to indicate that they want to go up or down a stairwell.
Cinematic Camera
-During dialogue and scripted storyline moments, the main camera can switch into cinematic mode and get more artistic/closer angles. The camera might zoom down to a player's face or off to the side of two characters having a conversation. This might also be a way to point out important items or objectives. Normal gameplay will be paused during cinematic events and the players will not be controllable.
Player Movement
-We need to decide between 2 possible implementations for player movement:
- On-screen analog stick (Steered movement) - hopefully we can avoid this, but it would be possible to implement. I hate to give screen real estate to a stick if we can avoid it as it seems like it would interfere with other interface interactions.
- Move-To (path-finding movement) - This is our best option as far as touch screens go. Each character simply acts as an agent to the navmesh and a touch tot he screen indicates where the player should travel too. Holding your finger on the screen will continuously update the character's destination hopefully creating smooth movement. [The example game displayed by Havok at GDC does this perfectly, so the tutorials should helps us implement this even better Youtube Video 1, Youtube Video 2] My only concern is that a touch might be on the other side of a wall or obstacle causing the character to change his route dramatically to make his way outside for example when really the play was just trying to walk close to the inside of the wall. I believe this issue can be solved by checking the player's line of sight.
Unity Prototype 1
-I altered one of the Unity tutorials to create a crude example of what gameplay might be like. The selected player can be moved around with ASDW and SPACE BAR will switch between the two players.
-The camera here is just what is used in the tutorial, adjusted to have a higher offset so we are looking down on the player from a higher angle. I really like how the camera adjust to see the player when you stand on the other side of a wall and the camera's view is obstructed. A big part of scavenging will be inside of buildings and we don't want to lose our player behind the set.
-NOTE: The web build might take a while to load because there are still a lot of assets in there from the tutorial. It has not been optimized at all.
-----------------------------------------------------------
