Week 2 Day 5 - Basic Ability, Network Abilities, Spawn Manager and GUI Basics

So, quick recap on the last week, as we haven't had many opportunities to post recently.

Friday/Monday were spent working on the Cone Push Ability.  On Friday, we spent more time than we intended working with Blender to create a basic cone, that was centered at the point on the cone, rather than the middle of the cone and getting that properly imported into Unity.  We now have that figured out, and will be able to any shape/model importing much faster in the future.  Here's a size comparison of the current cone push area:

When trying to create the cone relative to their character we also had to take into account the third person point of view, take the following example:

The orange line represents where the player is aiming when they are activating an ability.  The red line represents the actual direction where the ability will be cast from.  As you can see, when the player aims at something in the center of their screen, the ability is not cast from the direction they are looking, but rather out of  their character.  This new direction can be calculated simply with some vector math, but it was interesting enough that we thought we would include it in here.

It wasn't until Monday that we really got started on applying the ability over the network.  We put some thought into how to implement this, and had to choose how we wanted to handle player collisions over the network.  Our original model was a very authoritative server model, however Unity's networking is much simpler with a more distributed approach.  We concluded that there were a few basic ways to approach this ability over the network:

1. Player activates ability, tells server that he activated, server tells all clients to display cone, server tells certain clients that they need to apply a force to themselves.
• Authoritative to server
• Some instances of others being pushed by this ability, even though they feel that they dodged it
• Some instances of this client feeling like he hit someone, and not hitting them
2. Player activates ability, tells all clients to display cone, caster client finds people he hit, telling those clients that they need to apply a force to themselves.
• Authoritative to caster's client
• Some instances of others being pushed by this ability, even though they feel that they dodged it
• Almost never instances of this client feeling like he hit someone, and not hitting them
3. Player activates ability, tells all clients to display cone, those clients determine if they are hit, applying forces to themselves.
• Distributed to all clients
• Almost never instances of others being pushed by this ability, even though they feel that they dodged it
• Some instances of this client feeling like he hit someone, and not hitting them

As it currently stands, we decided to go with implementation #3.  This method does limit the amount of data sent over the network, as it only forwards the position, rotation, and the ability cast.  Whereas other methods would require to additionally tell other clients if they needed to apply a force, and by how much.  We also decided that it would reduce the number of discrepancies clients have while playing the game.  The authoritative server, and authoritative caster methods would lend to more clients having discrepancies with the ability, while #3 seemed to provide the fastest feedback, and a majority of players would feel better if what happened to them reflected what they saw on their client.

Once we were able to use this ability over the network, we began experimenting with how it affected other players.  The idea was that it would nearly push them off of any platform they are standing on, and a couple pushes would definitely push them off.  We soon realized that we do not have nearly enough experience with Unity's physics engine, as we were plunged into resources on Physics materials and their effect on friction, applying the force against gravity, and a number of other issues directly related to our inexperience.  Fine-tuning the numbers and methods of applying this force will need more work to proceed.

Today, we implemented a spawn manager.  There are a number of spawn points located on each of the platforms.  When the platforms are created on each client, they register themselves with the Spawn Manager.  This manager currently only keeps a list of spawn points, and gives one to the player when they are first joining the game.  In the future, we will have it give spawn points based on what team the player is on, where their teammates are, and other game objectives.

We are approaching the point at which we need to start taking into account how teams are going to work, and when a player is beyond the bounds of the game.  We feel that it is about time that we work on some GUI elements, and get the basics of creating a server/client and modifying our game variables are just as easily implemented with a GUI as without right now.  Also, we are lacking any experience with Unity's GUI and want to get a feel for what we are getting ourselves into with that.