Riptide Override: Sprint 2

     Sprint 2 has concluded with a total of 32 points completed. A solid 6 more then Sprint 1, giving us a velocity of 28 points. Here's the graph I made showing our current and projected progress. 

I worked in a few different categories for this sprint. Modeling, scripting, and bug fixing were the primary ones. I also quintupled (had too google that one) the backlog to ensure that my group had a plethora of cards to work with for our upcoming sprints.

The first issue I dealt with was a major bug fix. While showcasing our current prototype to my roommate, I unplugged my laptop and brought it over to him. When we hit play, the player moved in slow motion, and could not even rise. Plugging in my laptop fixed this. After a few more days of testing around this problem, It became apparent that stronger devices would have player movement speeds higher, while weaker devices made them slower. It turns out that this was because I made the movement tied to fps. when plugged in, my laptop was natively running the game at over 1200fps. This issue did not appear at first because my groupmates devices also ran the game between 800-1200fps. When my device was on lower power mode though, this dropped the game to 300dps, making the issue evident. A quick test on mobile also proved that the player would even move, while my gaming PC would cause the opposite issue, making the player phase through walls at high speeds.

95% of this issue was determining the cause, once I figured it out, I implemented a quick fps lock of 60, and changed all the movement values accordingly (a solid 20x from their base value).

I also wanted to make a higher poly version of the submarine. This was still done in unity, as we wanted to stay away from Maya. Doing this directly in Unity was done for a few reasons. One, it would cut down big time on development, as we don't want to be exporting and importing from multiple platforms, as well as making UV maps and texturing using additional software. We also just wanted a more simplistic art style in our game for props and models. This way we could have more art and props, with technically reduced quality, but significantly more variety and quantity.

Because I ended up making the glass transparent, I also needed to make a quick interior. The details wont ever be clearly presented to the player due to the size and strong tint of the glass, but they will at least be able to see that there is a interior model.

After making a more detailed model, there was a few more things I wanted to add to it to make it more immersive. That being lighting, animation, and particles. The interior uses a small area light, as well as having emissive controls to show off the inside. There's two "fake" spotlights on top of the submarine, which use emissive materials and a small halo to show the player what they are. While there is a singular true spotlight centered with the ship, which projects a cone of light about 5 submarines in length forward.

I animated a propeller on the back, as well as created a particle system to simulate bubbles and disturbance created by the movement. These particles start white/grey in color, and grow in size, transparency, and slow in speed over time. They also turn blue near the end of their cycle, and delete themselves once fully transparent.

Next I worked on something rather important, the camera system. Now this camera is rather unique and sketchy, as its multidimensional. Basically a Orthographic and Perspective camera overlaid, so we can present both 2D and 3D objects in a singular scene.

Now while attempting to make this work, a few things came to my head. This is super unique, in fact, I have never seen a camera implemented like this in any game I have ever played. Which got me thinking, there is most likely a really good reason why no one has done this before. I decided to continue on with it anyways, but make sure nothing was too directly tied with this unique camera system. Basically, if it ends up causing issues later down the line, it can be easily removed and  has nothing is entirely dependent on it to function properly.

Here is a example of the completed system. Note in scene view how everything is seen as 3D to the developers. By simply giving every other object a tag, I can make them be portrayed as 2D while in game view:

The pros of this system is that we can portray layers of depth and detail while also having strongly outlined terrain to make clear and evident hitboxes for the player to recognize. With a all 3D game, the terrain would be difficult to make rigid and detailed for a sideview camera, potentially confusing the player of where they can actually touch the terrain, and what's actually background and foreground. With 2D games, that's not a issue, but you lack a significant amount of potential detail, as everything is flat. That can be remedied of course using parallax background, but that takes a significant amount of development time to make look good and realistic. 

With this system, we can keep the player, midground, and background 3D, while only keeping the foreground (for the sake of clear hitboxes) 2D. basically everything the player can touch is 2D, and everything they can't is 3D. In theory, it should provide the best of both worlds; high level of detail and art, but also very clear hitboxes.

With that in mind, I made the blockout for Level 1:

While working on the linear blockout, I also realized that the camera needed to be locked on a axis. If we simply group it onto the player, it will also move up and down exposing parts of the level that should not be seen. So I wrote a new script with three separate public variables. Each one is tied to one of the main axis (X,Y,Z). The level featured above and below has only the Y axis locked. But in theory, this fluid system would let us create less linear levels as well, such as a dropper based one. I then filled in the foreground and background, and then added a backdrop. The level lasts approximately 50 seconds, and should be a relatively balanced in difficulty for the first level.

After filling in the terrain and creating the hitboxes, I started working on the props and environment. This level was going to be a "Coral" themed level, being placed the highest in depth relative to the rest of the game, so it was going to be one of the most colorful ones. The props I managed to complete in time before the end of the sprint, were some corals. I prefabricated them so I use them throughout the level.

This wraps up the majority of the work I conducted during this sprint. It was heavier then Sprint 1, but I don't believe I will be able to maintain such a heightened velocity for the upcoming sprint, as I begin to receive more work from other classes. The unique camera system, axis tracking, and partial construction of level 1 took up the majority of my time for this sprint.