As state before I had a few goals in mind for today. These goals were to offer some visual feedback to the client that they died, implement a better smooth follow camera, and begin drafting out tables for the game database.
Player Death Changes
To change how the game handles a player death, I did several things. These were to implement a new script for player death (short and sweet) and add a prefab of an 'explosion'. The prefab for the explosion is nothing special, just a sphere growing in size with a basic Bubble material pulled from the standard assets. The script itself is similar to the Explosion script I have for hitting remote players. The only difference is that after this is played, it request for the player to go back to the lobby. Also, because of how I have my cameras set up, it gets a new handle to a new camera. I will explain this below.
The entire script that handles the room transition and prefab creation is show below:
using UnityEngine;
using System.Collections;
public class PlayerDeath : MonoBehaviour {
public float effectLength;
public Camera camera;
// Use this for initialization
void Start () {
Destroy ( gameObject, effectLength );
camera = (Camera)Instantiate ( camera, transform.position, transform.rotation );
camera.GetComponent<SASmoothFollowLook> ().target = transform;
}
void OnDestroy ( ) {
GameManager.gameManager.ClientController.Send ( DataType.JOINGAME, "lobby" );
}
// Update is called once per frame
void Update () {
transform.localScale += new Vector3 ( transform.localScale.x + 1.0f * Time.deltaTime,
transform.localScale.y + 1.0f * Time.deltaTime,
transform.localScale.z + 1.0f * Time.deltaTime );
}
}
Camera Follow Script Changes
Long story short, the changes to my camera following script were extremely simple. The Unity one is nice, as I stated before, but does not meet my needs. My needs being full camera movement in a 3D environment with objects that have the same capabilities of movement. I also kept the smooth following and smooth look at components, but all in one script. Finally, I also attached the camera with the script to the player as a child object. This made the camera following smoother, and tighter. It fit our needs perfectly.
The script is as follows:
using UnityEngine;
using System.Collections;
//Script for a smooth follow and lookat that is more appropiate for our game
public class SASmoothFollowLook : MonoBehaviour {
public Transform target;
public float distance;
public float height;
public float damping;
public bool smoothRotation;
public float rotationDamping;
// Use this for initialization
void Start () {
if ( target == null ) {
Debug.LogError ( "SASmoothFollowLook Script on " +
gameObject.name + " has no associated target reference." );
}
}
// Update is called once per frame
void FixedUpdate () {
Vector3 position = target.TransformPoint ( 0, height, -distance );
transform.position = Vector3.Lerp ( transform.position,
position,
Time.deltaTime * damping);
if ( smoothRotation ) {
Quaternion rotation = Quaternion.LookRotation (
target.position - transform.position,
target.up );
transform.rotation = Quaternion.Slerp (
transform.rotation,
rotation,
Time.deltaTime * rotationDamping );
} else {
transform.LookAt ( target, target.up );
}
}
}
However, one thing that happens is that on the players death, the camera is destroyed too, since it is a child object. So, I simply create the camera as its own prefab, attach it to the player death script, and create a new instance when needed. It works perfectly. I may even consider make a new camera script to make a more cinematic effect.
Database Schemas
In order to create a database that was going to be worth it and done in a timely manner, I needed to consider what was vitally needed. After doing some consideration and the features in the game, I have come down to implementing four tables for our game as it stands right now. This database will support the features listed: persistent user login data, a scoring system, and maintaining game data.
The first feature we want to complete is having our own login setup so that players can have a personal account on the system. Right now, all users log in as a guest with a server supplied name. This ruins the fun. So, creating an account will allow players to pick their own names. It will also allow players to have an entry in the scoring system to keep track of their career scores.
This brings us to the next table. The scoring table. This table is simple and only has an id, a foreign key to the user whose score it maintains, and the player's score itself. That is pretty much it. The score is on a career (lifetime) basis, not per game.
Finally, we have a table containing a list of all games, past and present. The table also maintains the state of these games, active, inactive, or queuing. Right now, when a player logs in, they will only be able to join games created after the fact. This is how registering with the SmartFox Client works, they only get events after the fact. So, the table will maintain all queuing games, and when a player logs in, the server will update the client based on the games in the table that are in a queuing status.
The database is a relational database and uses SQL for queries and what not.
That is everything I have accomplished so far today, meeting my goals. If I decide to, I may start testing working with the database and server for a custom login.
No comments:
Post a Comment