Friday, December 27, 2013

Week 2 Day 6 - Main Menus, Settings Menus, and Game Lobbies, Oh my!

Today we exclusively worked on menus.  We were having problems previously with how we were trying to implement our menus.  Before we were having a problem in switching how things were being drawn in our OnGui function.  This function is actually called twice, once for figuring out where everything should be drawn, and the second time for drawing it.  Originally, we were changing how things were to be drawn in that function, so that each frame it was trying to draw two different things.  We now a menu manager, which is different from our proposal.  With this new system, we are always drawing the same thing during any particular frame.

We were also encountering a problem in which the previous menu screen wasn't being cleared when switching menus.  This resulting in menu buttons and screen objects being drawn on top of one another.  This is because without a camera in the scene the screen would never be flushed.  So we added a 'dummy' camera to sit in our scene while we navigated the menus, so that we could appropriately clear previous menus and draw new ones.  This camera will allow us to provide an appropriate backdrop for the menus in the future.

After we got this system set up, and working for the main menu, we split into working on two different menus.  Jon worked on the Settings menu while Zach worked on the Game Lobby menu (we decided who would work on which with the roll of a die).

We now have a basic settings menu containing multiple sliders and toggles allowing the user to change their preferences such as inversion, sensitivity, and field of view.  We also have a basic game lobby menu that contains multiple placeholders that may or may not change as we make them actually useful.


Above is shown two clients connecting to one another in the game lobby screen.  In the bottom left you can see a text box that the user can type into.  When they press enter the message is sent to every client connected, and added to a list of messages.  That list is printed above the text box, as you can see on both clients above.  We still need to add a specific box for the messages to appear in, along with a scroll bar so that the messages do not continue off screen.

Due to more Christmas Festivities this weekend, we will not be able to work on Dias again until Monday.  We will work on the following goals starting Monday:

  1. Get Dias to the point at which we can enter a game from the game lobby.
  2. Basic HUD.
  3. Pause menu.
  4. Start working on teams.

Thursday, December 26, 2013

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.

Friday, December 20, 2013

Week 1 Day 4 - CC & Platforms

There were no posts yesterday, as we hit several roadblocks in our work.  The primary issues came about when trying to create a CharacterController (CC).  The CC can only be moved by an absolute number of units (aka, has no velocity).  It also doesn't naturally implement gravity.  So when we were able to get gravity working, it was extremely high (because we increased it, due to Rigidbodies falling very slowly), to the point where you would jump up, and immediately hit the ground again.  The jumping was also not consistent, as the character would be teleported to the jump height, rather than making a smooth jump, as the Rigidbody had.  Both of those issues could be handled better by 'faking' velocity.  So that was implemented, though the velocity needed to falloff toward zero each frame, to account for fake drag, because CCs don't have physics reactions to other objects colliding with them.  Adding this falloff caused an unknown issue with the player's view spinning around for a split second while walking forward (the problem didn't exist when walking sideways or backwards).

Due to these issues, we decided to toss out the CC option for the moment, and return to networking issues.  Also, there was a CharacterMovement abstract class defined that defined a couple abstract methods for moving a character, and setting a character's rotation (amount of rotation is always determined by look scripts/cameras).

On the networking side of things, we did implement a PlatformManagerScript that would create platforms across the network.  These platforms would be instantiated by all clients that connected to the server.  Because they are not moving yet, they remain in perfect synchronization, which can't be said for the characters.

For today's (Friday's) goals:

  • Polish character movement across network
  • Start a basic ability implementation (cone push)
    • If there is time, attempt to push this over the network
We took a while and compiled a list of all the things the game will need for Alpha 1, to be a worthwhile test:

  • Creating & Joining server
  • Characters can move & cast an ability over the network
  • Main menu, settings, basic HUD, basic lobby (possibly chat), pause menu
  • Respawning after 'death'
  • Scorekeeping, win/loss condition
  • Teams

Thursday, December 19, 2013

Week 1 Day 3 - Networking

The rest of the evening was spent playing around with networking.  This might be a good point to mention, that most of the networking model that was described in our proposal will not work as we thought.  It seems that Unity already has simple methods for synchronizing objects across the network, and we can simply do synchronization right on the object we wish to send out.  Of course, certain pieces of that model will still be present at a later date, particularly the section about getting a game started.

For now, we are going to proceed with the built-in Unity Networking.  Its model more appropriately fits our needs, and is easy enough to use.  This decision may change as we continue to work on networking this next week.  We were able to get a local server set up, and connect clients to it, and have players move around.


All players are created with the input script, movement scripts, and even the cameras.  However we disable all of these by default, only enabling them for the given client's player.

We immediately noticed the issue of using rigidbodies to control our players.  When players collide, the physics engine will begin fighting against the NetworkPlayer script that updates the player's location.  This is a serious issue, as the physics engine is still currently crucially important to how we will interact with the other game objects.  However, now that we have started to work with networking and physics together, we may need to reassess how we are controlling the player.

Goals for tomorrow:

  • Write a Movement Script with the Character Controller (as opposed to a rigidbody) and see its effect on network movement
    • Write a super class for both of these scripts, that defines an interface to move the player and rotate them
  • Write a Platform Manager that will create all the platforms at the beginning of a game (for the server), and tell all the clients where to create the platforms
    • Write a Platform script, that defines some basic platform information (this is mostly placeholder for stuff later)
  • Discuss how player interaction should work
    • What happens when players collide with each other? Going fast? Going slow?
    • What happens when players collide with a platform?

Wednesday, December 18, 2013

Week 1 Day 3 - Telescope Polish, Abilities and Networking

Not much coding has happened today.  We fixed the telescope camera, by switching it to a perspective camera, rather than orthographic, and toying with its settings a bit.  Originally we though that orthographic would be good for that long-distance view, however perspective is much easier on the eyes in practice.  So we went with that.

We sat down and starting thinking of ideas for abilities and how they would be associated with each player role.  We have (sort of) arrived at this temporary (and not even complete) table:


Light Role Support (Builder) Role Heavy Role
Attack-based Ability Push (coned area) Box Drop (from sky) Push/Slam (area around player)
Defensive-based Ability ??? Create Wall Steal Weight
Movement-based Ability Roll (possibly ignore other abilities while rolling) Grapple (like a grappling hook) Ram (run forward and push other players out of the way)
Ultimate (and probably imbalanced) Ability ??? Destroy Platform ???
Passive Ability Extra Jump ??? ???

This chart still needs a lot of work before it is ready to go.  These abilities will also not start to be implemented until after Alpha 1, according to our project schedule.  We spent a short amount of time talking about how we would handle role abilities, and movement abilities.  There is still a bit of thought that needs to be put into that before we get to the system.

We decided to delay working on the Distance Checker earlier, and decided that the basic player controls are sufficient for day 3 of development.  We want to get started on networking early, as it will be a VERY large factor in how we proceed with development.  Several hours were spent looking into different networking options for Unity.  We both arrived at the same options, their benefits and risks.

  • Built in Unity Networking
    • Player-hosted servers (like we planned, according to our proposal)
    • Questionable documentation and few available tutorials
    • Easy to implement
    • Known to be buggy (according to several forum posts)
  • Photon Unity Networking
    • "Cloud"-hosted central server only (opposite of what we planned)
    • Questionable documentation and some excellent tutorials
    • Easy to implement
    • Known to be reliable (according to tutorials and reviews)

We are playing around with a few small prototypes for each, and will use those to make our decision on which method to go with.  We are both fond of the player-hosted server model, however the benefits (mostly the ease-of-use) of the Photon network are enticing.

Questions and our Answers

We were having some problems with comments on our posts not showing up.  We disabled and re-enabled our comments and hoped that that fixed the problem.  If your comments are still not showing up, let us know and we'll find another solution.

Karl Ahrendsen asked a few good questions on our posts and I'll copy all of his comments down below.

Day 1 - Repository set up & Beginning Character Controls

Karl:  "Yes indeed. Cause physics. Make Dr. Stone proud, Zach, write those kinematic equations."

Response:  "All the physics!"

Day 1 - Camera Collision Detection

Karl:  "I really like the raycast idea, but after thinking about it for a while, I think all it comes down to is remapping the downward navigation of the camera to forward navigation (toward the player). I would be interested to hear if you tried both ways and if they feel any different."

Response: "Your method is exactly how we originally tried to solve the problem.  The problem we ran into was that we had one script detecting if we hit something to pull forward.  Another script would detect that we are not at our set distance, and it would pull back a little bit.  So we ended up with a camera that was jerking back and forth every single frame when it would collide with something.

We ended up using raycasts for a few reasons.  Firstly, it was easy.  There wasn't a lot of trig or math to crunch figuring out where to draw the camera.  The raycast gave us the position.  Secondly, raycasts are cheap.  Thirdly we could always be 100% sure that the camera would be drawn where it was supposed to be drawn.  Look at the picture below for an idea of a strange situation that we would have to move the camera appropriately.  The character is standing on the left box and the camera is sitting on the right box.  Along with the picture, another scenario is if the player is on a slope.  We need the camera to slide along the slope.  The raycast gives us an exact point, while the other method we would have to take multiple scenarios into consideration."






Day 2 - Camera Polish, Gravity, and Controls

Karl: "From a player perspective, do you think that the difficulty judging distance is something that would be solved after a few minutes of playing the game? Do you think it arises from a familiarity with jumping in other video games and your game just has different jumping mechanics?

Whatever the case, I think that the distance checker is a good thing. Experienced players probably won't have to use it because they already know whether they will be able to make the jump and beginners will be able to figure out the jumping mechanics by methods other than trial and error. Of course, it's only a good thing if the mouse button would have otherwise gone unused."

Response: "Actually it came about not because of a mouse button being used or not, but because of the controller. We didn't have anything mapped to the bumpers on our controller mapping, and so Zach was going to map the zooming controls to the bumpers. Jon felt this was wrong on moral level, and so came up with another control to map to the bumpers.

On a more serious note, our game is different in that we do not have many points of reference to judge distances. Take Halo for example. If you wish to jump to another platform above or below you, you can judge the distance based on the rest of the world. You have an entire world around and below you to determine exactly where that platform is in relation to your position, and if you can make the jump. In our game all there is to determine if you can make the jump are the platforms in open space. Nothing else is around them. Not to mention that they are moving platforms, complicating the matter even further. So we wanted to add a tool for assisting the player in judging distances."

Karl: "In Super Smash Bros. I believe you could affect the speed of your fall by pressing down on the control stick. This might be something to consider, especially with the pivoting platforms. A player could slam into one side of the platform harder and cause more platform movement if they accelerated into the platform by holding "down""

Response: "That is a good point, and something that we are actively considering.  We don't have all of the abilities figured out yet, and are still debating on which abilities are going to be included and how they are implemented into Dias."

Day 2 - Settings, Input, and Telescopes

Karl: "I think the distance checker is something that would come in later in the design. It seems like a feature that would be nice, but is far from necessary for playing the game."

Response: "That is something that we discussed earlier today, and came to a similar conclusion.  It will probably pushed back until between Alpha 1 and Alpha 2."

Tuesday, December 17, 2013

Week 1 Day 2 - Settings, Input, and Telescopes

Since the last post, we have added all the input controls that we think we will need.  We have also created two new scripts to handle player settings, and game settings.  Player settings include things like camera sensitivity and camera inversion.  Game settings include everything else, from movement speed to jump height.

We spent the vast majority of the evening working on the telescope camera.  We decided, rather than moving the main camera in front of the character to zoom in, to just create another camera.  However, once we began turning off whichever camera wasn't being used, we ran into a problem.  The problem was that once one of the cameras was activated, it jumped to where it was last looking.  So, I might be looking one way, but once I jumped into the telescope camera, I was suddenly looking behind me, because that's where the telescope was last pointing.

Our solution was to create a CameraController script, that managed both cameras.  Instead of giving one of the camera script's the input information, we gave it to the CameraController to manage it all.  The CameraController then gave whichever camera needed to be activated the appropriate information.

Below is a picture of the telescope camera working.


In the bottom right corner you can see what the player would see on screen with the telescope camera.  In the main scene, you can see the green capsule (the player) is looking off towards a distant platform.  The invisible outlined box extending from the player is the view of everything that can be seen in the telescope.  You can see how the bottom of the box skims along the distant platform, but the top misses the platform.  This is reflected in the camera preview box in the bottom right.

Tomorrow we plan on working on the distance checker that was mentioned in our previous post, along with some minor polishing of the telescope.  After that we plan on brainstorming and setting up a system for abilities, and different types of dashes and jumps.  We may implement a few abilities, and after that, networking is our next objective.

Week 1 Day 2 - Camera Polish, Gravity and Controls

We started out the day with touching up the issues of clipping with platforms, and the camera going inside the player as the camera came closer during collisions.  The player model now becomes transparent when the camera comes closer than 4 Unity units (~4 meters).

Zach started working on player settings, and I started working on getting input for the rest of our controls.  We had a debate about how to organize controls and such for all the actions a player will need to do during gameplay.  We arrived at the following table:


Player Action Mouse/KB Mapping Controller Mapping
Character Movement WASD Left Thumbstick
Camera Movement Mouse Motion Right Thumbstick
Camera Zoom Mouse Scrollwheel D-Pad up/down
Ability 1/2/3/4 Q/E/R/F Left Trigger/Right Trigger/Y/B
Jump Space A
Dash Shift X
Telescope Zoom Right Mouse Button Left Bumper
Distance Checker* Left Mouse Button Right Bumper
Score Popup Tab Back
Pause Popup Menu Esc Start

*The distance checker is a new idea we came up with during the mapping of controls.  A continuous issue with out game is the fact that it is difficult to judge distances and jumps to other platforms.  The distance checker will fire out a ray, and get a platform from where the player is aiming.  It will then use the standard jump distance and gravity to determine if the player can hit the platform.  If they can, it will provide a visual cue.  We are thinking this cue will be a glowing of the platform, but may be simply mapped to a HUD element during early development.

We talked about possibly having other views of the game, possibly a large overhead view or a side view that could be activated by buttons.  We are going to leave these out for the moment, but may come back to them at a later time.

For the rest of the day, we are going to continue working on settings, getting all this input, and possibly starting to get the Distance Checker and Telescope Zoom working.

Monday, December 16, 2013

Week 1 Day 1 - Camera Collision Detection

After getting some standard movement and camera controls set up, we started trying to handle camera collisions with objects.  Previously, and in the prototype, when the camera was moved into a solid object, it simply passed through, and we could see through the objects we were inside.

We tried a couple different solutions to this, including:

  • finding how far down the player had pulled the camera, after hitting an object.  Using that distance to find the position along the object
  • Simply pulling the camera closer, whenever we were hitting an object
When these methods proved to be unnecessarily complicated, we got the idea to use a raycast from the position the camera would be looking at, out to the desired camera position.  Using this cast, we can detect if we hit any objects in between the player and the camera, and set the camera at the position that we hit.  This way, the player's camera will never be obstructed by any objects.  This also eliminated us having to make a special case for when the camera's distance would place it on the opposite side of an object from the player (but not be hitting the object), this killing two birds with one stone.


Here's an image of the camera, as it intersects the platform below the player.  It is closer than the standard camera distance, and still clearly placed the player in an unobstructed view (as you can see from the white lines that show the camera's view).  This method is also REALLY smooth.  The previous methods were causing some large jittering as we moved the camera forward and back, trying to place it in just the right location for where we were hitting objects.  Doing the raycast gives us an exact point to place the camera (or a very close point, some optimizations will still need to be done to avoid clipping against the platform).

We have written up some goals for tomorrow:

  • Camera Polishing
    • Character Opacity - make the character become transparent as the camera get's close to it
    • Platform Clipping - place the camera slightly above the raycast hit position for collisions
  • Gravity
    • right now, it seems like the player falls too slow
    • also, listen to the John Mayer song while doing this
  • Ability Activation (basically placeholder right now)
  • Tighten character movement controls
  • Player Settings - store the data for this, don't actually make settings changeable yet

Week 1 Day 1 - Repository set up & Beginning Character Controls

Spent a few hours getting our Subversion repository working, followed by officially starting development of Dias.  Here are some photos of our code, math, and physics.  The code allows the  camera to move around the player, as far as they wish in the horizontal axis, and to a maximum and minimum degree in the vertical.  Those values are calculated based on proportions set in camLocProportion.  camLocProportion is the proportion of distanced behind and above the player model.  The trigonometry shown below is also calculating the maximum and minimum degrees the camera should be allowed to rotate.  And the kinematic equation shown in the top right calculated the initial jump velocity to be set to achieve a jump height 'd'.  Cause physics. 





~Zach Lorenzen
~Jon Kenkel