Progress update #3.1 - Last Tweaks for Playtesting - Jan 17, 2018

Dev Update - Jonas - Finishing Touches

Over the last week, the master received his last finishing touches: teleportation, ability resources, bug fixes and further visual upgrades.

Teleportation

One major design question was how to deal with varying map sizes as well as different VR room sizes (steam VR play area). The idea was to encourage the master player to walk (actually walking, taking advantage of the large HTC Vive play space) around on the map and support crawlers in different corners of the dungeon. In order to preserve a consistent master player scale, some form of teleportation needed to be implemented. There are many existing solutions to teleportation in VR, most famous the Steam VR pointing based teleportation, which will teleport the player to the exact position that he points to. As this would allow the player to simply spam teleportation instead of actually moving in VR space, this didn't seem like a suitable solution for us.

So finally, we came up with a tile-based teleportation system. It allows the master to teleport to adjacent tiles of the size of his play area. In order to be effective, the master still needs to move around within the tile.

Selection of the teleportation target is done with the radial menu of the off-hand, in order to keep teleportations globally aligned, the radial menu was modified to a "compass radial menu". In addition, radial menus now also support the "no selection" if the selection (either trackpad or analogue stick) is too centred, this is needed to stay in the current tile. The current target tile selection is also visualised by a marking on the floor.

Ability Resources

As the master player was way overpowered before, usage of abilities is now limited by sparse resources. Both buff/debuff rays and physics-based abilities now use resources that are either regenerated over time or are picked up by crawlers. As of now, this means that a fully charged master can buff and debuff for 5 seconds and throw 3 heal orbs and fire balls before needing to recharge. The amount of available resources is intuitively represented in the size of the ability pool or the casting hand.

Bug fixes and further tweaks

Over are the days of the exploding eyes, turns out that any mesh scaled down to 0 will cause weird lighting bugs. Also gone is the "infinite buff" bug, that caused buff effects to stack and not be removed, making the affected crawler an invincible one-hit kill machine. In addition, quite a few non-master related bugs that bugged us for months got fixed.

Further improving master visuals and following the style set with the new particle systems last week, buff and debuff rays now glow more neon-like, the casting hand emits fancy particles as well and the entire master starts glowing when applying a buff or debuff. In addition, there is now a helper ray indicating the aiming direction of the rays in case the player fails to aim at crawlers/enemies properly. Some less visible changes and tweaks have been applied to the radial menus, hand visualisations, particle systems and materials in general.

Next Steps

All in all, i'm pretty happy with how the master turned out so far, but of course there's always room for improvement. Early playtesting this week revealed, that the crawlers are often having a hard time finding the master and grabbing the master's attention is not really supported at all as of now, and vice versa. To solve this, we are planning to add a 3D arrow to the crawlers UI, that always points to the master that makes a ping noise and lights up yellow when the master is pointing somewhere and takes the master's color otherwise. A key to point the crawler camera at the master as well as one for pinging the master back seem like valuable features to implement. 

In addition, the master seems a bit mute as of now, with first sounds in the game. Adding some idle, ability and ping sounds will definitely boost immersiveness and localization for both crawlers and the master.

Of course, it goes without saying that there never is too much eye candy. Adding in ground effects for crawlers affected by abilities, more particle systems, more light sources, nicer and more polished, textless radial menus are currently not too high up in the priorities though. 

Dev Update - Paul - Touching finishes

Over the last week the menu, visuals and crawler also received some finishing touches.

The days between the Alpha presentation and now consisted mostly of bugfixes, first playtesting and loads and loads of tweaking.

Visual tweaks revision 209124683 'n' a half

I mostly tweaked visuals and kept playing over and over again to find bugs and issues. One of the most prominent topics were visual tweaks. For one doing a new lightmapping pass, but this time with the backdrop loaded additively as well as using reflection probes, which also fixed the additive scene loading. This brought with it the possibility to bake occlusion culling into both levels, which helps improve performance. 
Other than that, many particle effects and materials were tweaked or redone to increase visual fidelity, such as a sizzling effect for the laser beam or sparks flying when an enemy is hit. Post-processing effects were also tweaked to tone down brightness overshoot. 

UI tweaks

Changes to the UI were made as well.

First, in the main menu, the settings section was expanded to offer audio volume control, the option to show a VR controls reminder when playing VR and a - admittedly gimmicky - system info, which really only shows your machine's core specifications as an orientation.
On top of that, the lobby screen now provides a brief rundown of a class' abilities and statistics when moving the mouse over the class icons and a loading screen after the match start countdown has reached 0, as the previous barebones loading could be mistaken for the game freezing.

Second, the crawler UI was revised, moving the ability status icons to the center of the screen and increasing the visibility of the attribute bars.
The crosshair was fixed to show up in the correct position and was changed to a dot instead of a cross since we noticed that the cross suggested to players that this was a gun spread indicator when really it is just an indicator of gun direction.
The cursor was fixed in that it is now hidden while playing and only shows up in menus.
One noteworthy addition was an arrow at the top of the screen that always shows where the master is, as playtesters complained it was hard to figure out where the master is at all times.
I also introduced a death screen, since up until now dying as a crawler simply meant your control over the character would stop and a single nametag change would appear. Now, a message about your death is displayed on the screen and the camera zooms out into a total overview of the level.
At the start of a game, each crawler gets a short notification on what the objective of the game is and a brief hint on how to achieve it.
The master now sees a large circle around each crawler and their nametags and healthbar are enlarged, making it easier to spot them in a crowd.

Additionally, there is now rudimentary UI handling of disconnects. Our game, unfortunately, cannot gracefully handle mid-match dropouts, so up until now if someone disconnected from an ongoing game, no one else would notice until AI or statistics eventually broke and the game couldn't be finished. With this change, if a player disconnects during the match, all other players are notified about this event and informed that the current match cannot be finished and they would need to return to the lobby. If the server disconnects during the match, players are put back into the lobby and shown an error notification telling them that the connection was lost. 

Scene adjustments

What we noticed when playing the Alpha version was that, for more than two players, the existing level was definitely too small, so it was expanded by one row of rooms in each direction, this time even using the updated room prefabs. A simple VR controls reminder was added to the backdrop level which, when enabled, simply shows the VR controls inside the game view, useful for novice players. 

Audio, at least halfway there

One important addition was sound effects (all lifted under various licenses from online sample databases). The game already had simple background audio for a while, but no sound effects for anything else. This milestone sees the addition of ambient sound for the backdrop: traffic jams and some howling wind, and some sizzling of neon lights in the main scene. Every crawler attack now also has a sound effect, from gunfire sounds of the soldier, over supercharged laser effects, singing lightsaber hum of the infiltrator to the satisfying pellet spit and reload of the berserker's shotgun. Similar goes for enemy hit effects, which now randomly fire off one of several damage sounds. 

A caveat to sounds is that not all things have one. For example, enemies are still completely silent, not even their attacks give off the slightest note. Neither are there any sounds to specific match-specific events such as starting or winning, nor for the clicks in the menu. This is unfortunate but is unlikely to change drastically. 

Player balance

A few tweaks to player balancing were made, including a change in camera offset and distance as well as some weapon statistic changes and movement speed. 

Network performance

This is a tricky and nerve-racking topic. Here's some necessary background on networking as we use it: The Unity UNET framework uses relay servers to transmit data between clients and servers. These relay servers have a bandwidth limit imposed on user traffic, likely to avoid abuse. This bandwidth limit is realized as a "pool". The added bandwidth limit is 4KByte per second per connected client. So every second, 4KByte of "data volume" per player are added to the pool. Additionally at the start of a session, the pool is initialized with roughly 2 minutes worth of limit. If at any point the growing pool is exceeded, all clients are disconnected from the relay server. This means that a UNET enabled game usually needs to keep their traffic at or below 4KByte per second per client.
Obviously where I am going with this is that it turned out we were not within that limit. We don't have precise numbers, but our traffic exceeded the limit so much that, with a full match of 5 players, we would see reproducable relay disconnects after less than 4 minutes. Ironically enough, in our first attempt to lower bandwidth usage, we instead increased traffic tenfold and disconnected after 25 seconds. The second attempt actually saw reduced traffic. Now we still don't know precise numbers, but we believe we are close enough to the limit to not see disconnects during an average match. These attempts consisted of reducing synchronization rate for certain network elements, reducing the amount of data sent (for example only synchronizing the Y axis rotation instead of all three axes), compressing some of the data and more. 
One experimental attempt - that is not actually deployed in the current release - sees a more compute-heavy approach of selecting the bare minimum of necessary position and rotation data, converting it to "smaller" data types, synchronizing, and then reverting the process on the other end. In theory, this could reduce minimal message content size per transform update from 16 Bytes to 3 Bytes. However, the message headers still remain as they were and actually represent an even larger fraction of traffic. We have no solutions currently in development for this issue, we basically simply hope that our efforts so far suffice. 

Performance testing

Lastly, a lot of performance testing and analysis was done. The game was tested on a wide range of hardware (from an Atom x5-8350 + HD Graphics up to a Ryzen 7 1700 + GTX1080Ti) to see how well it would perform and how well it scales. A number of performance issues were encountered, analysed and mitigated to varying degree, in certain cases improving performance by up to 60%. Unity's built-in profiler proved to be a very valuable tool for this purpose. 

At this point I would classify the system requirements of the game as follows:

Minimum (1024x768, Low, 30fps, some stutter):
- AMD Phenom X3, Intel Core 2 Duo E8400 or equivalent
- 4GB RAM
- ATi Radeon HD5570, Nvidia GT440 or equivalent DX11-capable GPU with at least 512MB of VRAM
- Windows 7 x64

Recommended (1920x1080, High, 60fps, mostly smooth):
- AMD FX4300, Intel Core i5 670 or equivalent
- 8GB RAM
- AMD Radeon HD7850, Nvidia GTX660 or equivalent DX11-capable GPU with at least 2GB of VRAM
- Windows 10 x64

Serious business (2560x1440, Very High, 60fps, very smooth): 
- AMD Ryzen 5 1500X, Intel Core i5 3570 or equivalent
- 12GB RAM
- AMD Radeon R9 290, Nvidia GTX780Ti or equivalent DX11-capable GPU with at least 3GB of VRAM
- Windows 10 x64

Overkill (3840x2160, Ultra, 60fps, very smooth):
- AMD Ryzen 7 1700, Intel Core i5 7600k or equivalent
- 16GB RAM
- AMD Radeon R9 Fury X, Nvidia GTX980Ti or equivalent DX11-capable GPU with at least 4GB of VRAM
- Windows 10 x64

Dev Update - Inshal - Touches Finishing

I'll just nerf this character so it will not be overpowered... Aaaaaaaand now it's useless.

Balancing

The initial design of the game was that crawlers would tend to avoid enemies and look to gathering their strength before taking head-on fights. However, for testing purposes, we had "artificially inflated" the damage and health values of crawlers so it would be easier to test their abilities and attacks. This led to single crawlers going through the entire level, killing all enemies and the boss without so much as a scratch in some cases. It was high time to fix that!

The S0ld13r with his rifle and laser abilities could easily take down all enemies in his path before they could even get to him. He was rebalanced to be a long distance fighter. The overall damage of his class was reduced so enemies could still reach him and deal damage before getting annihilated.

• Low bullet damage
• Fire rate set to 5 shots/second
• Scattershot ability per bullet damage reduced
• Laser damage per second reduced

The 1nf1ltrat0r was able to stay invisible for a duration and get backstabs on enemies for as long as his invisibility lasted. This was a problem as all enemies ignored him while he dealt quite a lot of damage to them, leading the class to easily kill even the boss. By removing invisibility, however, he quickly got overwhelmed and killed at the start of the game. A balance has been achieved in the current state. The 1nf1ltrat0r still needs to be careful about avoiding combat but whenever possible but now he is able to hold his own in a fight.

• Above average sword damage
• Backstab yields x2 base damage
• Additionally, going invisible and backstabbing deals x4 base damage
• Attacks no longer break invisibility
• Invisibility lasts 8 seconds
• Health reduced so as to encourage stealthier play

The Sum0 was always a simple character balance-wise. He'd deal slightly more damage than everyone else and take more damage as well.

• Increased basic attack damage
• Large, distance-based Sumo Blast ability damage
• Twice as much health as average (as getting close to deal damage leads him to get hurt quite often)

Finally, the B3rs3rk3r had been a bit underwhelming despite his ability to switch weapons. A bit of playtesting revealed that his ability was like a double-edged sword (pun intended). He dealt more damage in his enraged state but also took quite a lot, leading to the ability as a whole to be risky. To counteract that, during the rage state, his armour was increased so he takes less damage from enemy attacks.

• Average shotgun damage
• Significant sword damage in rage state
• Increased armour in rage state
• Rage adrenaline requirement set proportional to circa. 5 kills.
• Health set to 1.2 times that of other classes (due to shotgun usually leading to close quarter encounters)

Loading Screen

A loading screen was added to the game with an animation so as to hide the game stuttering for a few seconds when loading in the level. This helped transition to the game easier and was later "prettified" by Paul so as to have a fade in!

Ability Notifier

A common annoyance was that when a crawler used an ability, it was always a guess as to when that ability would be available again. We had timers in working in the background to make the ability available again after X seconds but it was never ready when one would think it was (and really needed it). Well, now we can proudly say: "Despair no longer beloved playtesters! We, your humble developers, have added a UI element with pretty icons to display when an ability is on cooldown and when it is ready to rumble. So now you can go into that fight knowing your invisibility is there to help you run away! "

Bug Fixes

• Fixed the Sumo simply obliterating an enemy with his basic attack because it registered multiple times
• Fixed Berserker rage issue where the katana would get stuck to his side if the ability ended during a swing

Dev Update - Artem - NullReferenceException

Collectibles

While our main goal were to playtest the game, fix bugs and tweak balance, we still managed to add one essential feature that makes our game complete: collectibles. From now on, not only crawlers depend on master, but also master depends on crawlers in a way, since crawlers now need to collect items in order to restore master's strengths.

There are two types of collectibles: green and orange, where the first one corresponds to master's ability to heal characters, and the second one stands for his... fireballiness! Yes, that's how we call it among our team _{(no we don't...)}

Final placement of enemies, players and collectibles

After the collectibles are added to the game, and the demo level was significantly expanded by Paul, we had to prepare it for the final series of playtesting. My work was to arrange a proper placement for all in-game stuff to our level: player spawn points, collectibles and enemies. Finally, our level meets the conditions we outlined in the very beginning of our game practicum:

• It has lower number of weaker enemies closer to the edges of map, especially where the players spawn. This allows the crawlers to slowly get used to the game before they might be accidentally killed.
• It has stronger enemies in the center of the map, which increases the importance of cooperation on a later stage of the playthrough.
• It has 'bad' dead ends full of enemies and 'good' dead ends with collectibles. Therefore, the crawlers have to obey their master's guidance if they want to avoid troubles and play their round smoothly!
• BOSS in the middle of our level. Make him angry and enjoy running from him across the entire map!

New enemy detection shader

After a lot more details were added to the level, making the final picture contrast and complex, visibility of certain things became significantly lower. For instance, it was almost impossible to use Enemy Detection ability of our glorious infiltrator, since the highlights were hardly visible. For the sake of a better visibility, a new shader is introduced! It also looks more visually appealing and... highights the boss with a menacing red color.

Performance optimization and profiling

Another thing that had to be done to establish smooth gameplay even on middle-range laptops is a performance optimization. After a deep dive into Unity profiler and examining every called function, we detected several performance issues and fixed them. The results much cooler than we could've expected and merely overwhelming: overall FPS increased more than by 50%! What's more, we managed to get rid of performance spikes that tend to occasionally slow down our game to few FPS.

Thanks to Paul, who tested the game after the performance tweaks, we now can be sure that everything runs smoothly on a wide specter of machines.

Additionally, we tweaked network performance by significantly reducing the synchronization burden for syncing animations of players and enemies.

Bugs, bugs, bugs...

As everyone I our team fixed numerous amount of bugs and polished a lot of small features, I also want to expand this list:

• Fix bug when berserker cannot shoot after his RRRAGE fades.
• Fix bug that player spawn positions were corrupted (so that they could've even appeared in neighboring room).
• Provide missing icons for some of the active and passive abilities.

Experimental: manually sync movements

After researching what is still the most unpleasant part of our game in terms of visuals, we came to conclusion that it is a laggy movement of enemies on client. Unity does not interpolate synchronized positions and orientations of objects and it is clearly visible that update happens only 10 times per second! To solve this, we tried replacing the vanilla Unity NetworkTransform by our own sync framework. As a result... BOOM! Thee game breaks in the beginning of our playtesting! Invited testers waiting 10 minutes until we run an older version is a certainly not the best experience for us, and despite the fact that at the moment the framework is fixed and gives pleasant results, we are still thoroughly testing it and the feature is excluded from the current release.

 Progress update #3.2 - Playtesting! - Jan 22, 2018

And yet again, our game concept turns out to be a huge pain in the a$$. Having a 5-player global multiplayer that includes one VR player, just grabbing one of your friends and placing him infront of your laptop for a couple of minutes doesn't quite do the trick, so we had to get creative. 

We decided to split up the playtesting, starting with the crawlers, as they have the largest part in the game.

Early Small-Scale Crawler Testing

To get a first impression of what's fundamentally wrong with the game in general, Paul and Jonas recruited a gamer friend to test the game with them in a late-Wednesday-night TS session.
The participant was sent our latest build version of the game and only told to start the game, have a look around and get familiar with the controls before joining our server. During the hour-long playtesting session, Paul and Jonas would take turns hosting servers and be playing as the VR master, giving us a solid 3 player setup. The participant was asked to think out loud and describe things he liked and disliked during the game and finally to fill out the following questionnaire.

The playtesting session not only revealed quite a few previously unknown bugs but also gave us an unbiased opinion on design choices and implementations. In the following, you will find a list of the worst critique points: 

• The music is horrible, sounds, in general, are too loud, making things worse, there is no volume slider in our settings menu
• The particle effects and the light on the crawler are too bright, quite blinding actually, in addition to the excessive amount of bloom
• The camera is too far away, camera controls feel both raw and sluggish, the crosshairs are off-centre
• The different crawler classes are poorly balanced, due to the nature of the gameplay some classes don't make sense
• On a dual-monitor setup, the mouse pointer would leave the screen leading to loss of focus when clicking
• Quite a few game-breaking bugs that drastically reduce fun (infinite buff, friendly fire, random deaths)

In the following day, quite a few of the bugs and short-comings were addressed and resolved.

Large-Scale Crawler Stress Testing

"Hey, let's just broadcast the download link for the game in a populated Teamspeak server, what could go wrong?" 

Ok, to be fair, it was a bit more thought through though. After having addressed the most obvious flaws of our game, we wanted to get some more feedback from other people, test how the game would perform in the unforgiving environment of real-world gamers and test the game's performance under previously untested player counts. We ended up having two new testers, that went through the official playtesting process, got a warmup, minimal instructions and were asked to fill out the questionnaire.

The other ~5 participants had a less formal, but yet not less helpful, process, they literally just downloaded the game because they found it in the chat, did neither know that they were supposed to playtest it nor that Paul and I were involved in the development. As a consequence, we expected the most unfiltered form of direct feedback, and yes, they tore the game into pieces.

Again, we told our official participants to join our servers after having a look around, while the rest of the Teamspeak server just basically did whatever they wanted. As a consequence a bunch of servers were hosted simultaneously, our server was also fully populated for the first time with distinct, real people, putting the entire networking architecture to a good test, revealing new bugs and flaws.

From playing more ourselves, testers' comments during the hour-long playtesting and filled questionnaires, we could identify quite a few more bugs and poor design choices (incomplete list):

• The lobby and the main menu are bugged, Ability to duplicate oneself in the lobby, Mouse pointer disappears after unplanned disconnect
• Weird disconnects, Win/lose conditions not triggering
• Gameplay boring when dead, No death effect on crawlers, No revivability, Master or player spectator desired
• Crawlers have no indication of Master's position, No ability to communicate with master, Not aware of master's abilities, Sometimes master too high => Indication arrow and button to focus on master desirable
• Class 2 (Infiltrator) useless, Friendly fire is still in for some crawler attacks, General bugs for crawlers (Berserk can't shoot anymore after going rogue)
• Class 1 (Soldier) overpowered
• Buff kind of equal to Debuff, Crawler names not readable for master
• Update rate of master visuals too low
• Annoying SFX (too much honking, "neon tube sounds"), extreme bypass effect, poor mastering
• Camera still janky
• UI scaling issues on 4K monitors
• Game objective unclear, Running around looking for the last enemies unsatisfying, More linear map desired
• Visual Indicators of low hp desirable

Some of these issues were addressed, some are still unchanged.

Master Testing

This part turned out to be the trickiest. VR setups are still quite rare, generally quite cumbersome to set up and due to its performance-hungry nature anything but portable. In addition, useful testing of the master requires four other crawler players to take part in the session.

We decided to conduct the playtesting session in the GamesLab because it provides one working Oculus Rift based Steam VR Setup during our weekly team meeting. We had two participants (one gamer, one non-gamer) come in and test the master player while the team was playing as crawlers. The first thing to become pretty obvious was how uncommon VR still is, most people have probably never had a VR experience and therefore are unfamiliar with basically everything, including the controllers, their buttons and standard control schemes. As a consequence, both our participant had no idea what they were doing or how the controls worked (they also ended up getting stuck in the Steam VR and Oculus home screens), despite the existence of a control screen in the main menu and the VR controls being displayed in the game scene as a billboard. In addition, despite the "Please take off the HMD" screen in the main menu, it was confusing to players when to use VR or the standard Monitor/Mouse/Keyboard setup. 

To tackle this, we will need to think about implementing a full VR main menu and an extensive master tutorial including tool tips in the later game. In addition, it might be useful to reintroduce the visual representations of the controllers to give new players the ability to inspect different controller and button layouts. Whether or not all of these changes can be realistically implemented before the final release is questionable, since some of them will require substantial changes to the project structure. 

After the players had figured out the controls (~10 mins), they actually started to play around with the game and interact with crawlers. Generally the testers were quite happy with the gameplay, nonetheless, some bugs and suggestions for improvement made were reported:

• Resource levels of abilities not always clear, size-based approximation not too intuitive
• Movement with the Oculus restricted (Occlusion)
• Teleportation unaware of play area size, Teleport Text not visible over fire hand, Teleport text unintuitive
• Some kind of screen with condensed crawler statuses desirable
• "Please take off the Headset" screen creepy