This week we had to set up our build for both our final build for the class, as well as for showing off at the RPI game-fest. This comes with several challenges, firstly while our build is in a good spot we made the decision to use the high definition pipeline from unity. Firstly this change made the build too intensive for my laptop to run, so I was confined to the computer labs to finish the build. While this was not a huge issue as I don’t mind working in the labs, it definitely made scheduling my work hours more difficult. Now I had to schedule around not being home to make food or take breaks, which made time more of a vital resource than it already was. Between this and jumping between other class work I had to make sure that everything was all set on time, which included getting a backup build set up Wednesday, and a fully lighting baked build done for Friday. This wasn’t too bad of a feat since the two other programmers were also there to help, unfortunately due to other classwork more of the work had to fall onto one of the other programmers for this, however as soon as I was caught up I spent as much time as I could helping him finish up and get the build sent out!

As our game starts to grow bigger and bigger we started to notice that we needed to have some form of save / load system, as well as a way to jump to a level that the player desires. So to do this I was tasked at creating a Checkpoint system. When planning out this system I wanted it to be a simple for our design team to use as possible, to do this I decided that if possible just allowing them to drop the Checkpoints into the scene and assigning a position for the two players to spawn at would be the easiest to implement.

 

To do this, I would need to make the system as simple as possible but be flexible enough that the designers could do what they needed. First the prefab itself, all it is is a trigger and two empty game objects to represent points in space, these two empty game objects will be the spawn point of both players (allowing the designers to have a visual reference of where they will be) and the trigger is what will set the player’s spawn point to the current one.

 

The checkpoints work quite simply, when a checkpoint is triggered the checkpoint will record it’s name into playerprefs, then when the game loads (on start for the scene) it will find and move both player’s to the correct spaces on the spawn point based on the name saved in playerprefs. This allows the game to be loaded simply without any major new architectural changes to the game.

 

There are however some issues with this method, firstly name matters a lot. Since the name is the only thing that is recorded externally, the naming convention of this needs to be distinguished enough to not have issues. Secondly, it doesn’t take into account any previously triggered events or inventory. However due to the layout of the game this isn’t a needed aspect, checkpoints are going to be at the beginning of puzzles where previous keys aren’t needed, and events gets wiped, making recording these aspects worthless. However, if we decided that we want a puzzle that takes advantage of either of these things the architecture for the checkpoint system allows for the easy expansion of the system, enabling further use of the previous code.

 

This also doubles as a level select system for the game, as all we need to do is assign the name of the gameobject to player prefs in the menu when a level is selected, and it takes care of the rest automatically.

 

I’m generally pretty proud of this system, it’s simple to use, dynamic, and set up easily enough that expansion is possible if need be! Hopefully it comes in use and no bugs come out of it, but if they do I feel fully confident in my abilities to fix them!

With Game-fest being over and done with, I can certainly say that the experience was well worth it! Despite the crunch the week before, going to the festival and seeing people who have never heard of the game before sit down and love the experience was incredible! The thing that surprised me the most was how into it some people got, us being a niche game I wasn’t expecting people to be as into it as they did. Especially the younger folks.

 

Also being around that many other developers was amazing, seeing everyone’s hard work being appreciated by the public was an amazing experience, as well as talking to other devs about what they were doing was awesome! Surprisingly the build itself didn’t have any major bugs in it either, considering the current milestone of the game I was expecting at least a few un-noticed bugs to pop up during the showing, but no! All in all, it was a great experience, and I’d do it again in a heartbeat.

Next weekend we’re going to attending the Champlain Game Festival, there we will be showing off Gaze of the abyss to the public. To prep for this we have a couple of hurdles to pass, firstly we’ve been having issues with building our main scene when incorporating the menu screen into it. Secondly we need to make sure we have a build done 4 days beforehand in order to have a buffer time in case things go wrongly. We borrowed equipment from the school to use, printed out a banner, and printed out flyers to organize ourselves for the event.

 

So testing and building, for this event I put myself though some crunch in order to get everything up to par with what you would expect at a game festival. I spent the entire week doing various polish, fixing bugs, and testing the levels we were showing off over and over again to make sure everything  was polished and ready to go. While the week was tougher than it needed to be, it still got done and we are now fully prepared for game-fest!

In the last part of this I talked about how I set up the API to handle multiple control schemes and how I set them up to be able to swap at run-time, here I will talk about the actual control schemes and their implementations!

So you may be wondering, what were the three control schemes? The first one is a basic tank controls, forward / backwards is on one stick and rotation on another. The second is similar to the first however all directional were on the left stick, but the right stick could be used to override the rotation if needed. Finally the third was having everything on one stick, however movement was relevant to the camera’s position instead of the players.

Previously we have been using the first layout, so I was tasked at implementing the two new ones for QA this week. Firstly lets look at layout B, this was a relatively easy fix, all I had to do was implement an override for rotation if input was detected on the right stick.

Here you can see the starting section of our move player movement, with the xAxis variable in this case handling our rotations. xAxisMove is the first rewired axis input, this being bound to the right-stick in this setup, xAxisAim is the rewired axis input being got from the left stick (the override) in this case. Simply put if there is any input at all the variable is then set to the second input, replacing the first. Then this is passed along to the rotation function and everything acts the same.

Unfortunately layout C required it’s own function to work, as it is fundamentally different from the other two control schemes.

Here you can see the override for the function, since layouts A & B use the same functions we only care if the map is set to C, if it is then we use the new function.

This is a fairly simple movement algorithm, with the main difference being that the player’s movement direction is based on the camera’s rotation, so forward will correspond with the camera’s forward direction. The main challenge with this was that our current animation controller didn’t have functionality with this new movement scheme, we decided that it wasn’t a priority for this sprint and if we continued with this scheme we would polish the issues that it had. So the fix is to manually swap the diver’s direction into the direction of the velocity. This creates an issue where the diver’s rotation snapped to wherever they were looking and caused immersion issues. However this wasn’t a concern for now as we weren’t sure that it would feel good in the first place. That being said if we do go forward the fix would be to rotate the player towards the desired rotation instead of simply snapping to that rotation, a simple fix but not necessary for now.

All that considered… the third option was the winner for QA! Testers found that moving relative to the camera was the most conformable and felt the best. So going forward we are going to fix the weirdness and get it feeling fantastic, then hopefully I can move onto other systems to work on and have the diver feel good!

 

Thanks for reading!

-Alex Hubble