Progress update #2.1 - Testing, Bug Fixing, Refactoring - Xmas 2017
It turns out our game concept, a networked multiplayer game with VR concepts, is quite a pain in the a** to test and debug.
To test the networking now, one needs multiple instances of the game running, before we added in VR this could be done on one machine by starting multiple instances of the built game. The problem is that SteamVR (and probably any other VR API for that matter) needs to be accessed exclusively by one application. So when we want to test VR networking, starting a new instance of the game will automatically close the other one. As a consequence we can only run one instance of the game (either editor or build) on one machine at once. Making matters worse, Unity networking seems to be pretty fragile when it comes to local differences between two client versions, differences that both Git and Collab seem to ignore, so in practice master networking testing will often be handled by building the game and sharing the build over network or portable storage with the other tester. The fact that thanks to fancy lightmaps and assets the builds can be almost a gigabyte now doesn't really make it easier on us either. But enough whining already.
We spent pretty much the entire week around the interim finding, tracking down and fixing bugs that occurred in weird or hard-to-test situations, like 5 players playing at once or players leaving and entering.
Most of December then was spent implementing the missing features for the low target (more on that in the next update) before sliding into our (well deserved?) Christmas break. :3
Progress update #2.2 - Baby Steps - Jan 9, 2018
Dev Update - Paul
Visuals have changed considerably since the last demo, plus a selection of changes to the UI and smaller fixes
Good old Kleinvieh
Among the progress on smaller issues was the addition of VR pointing, currently only used to return to the lobby after a match has ended. This required setting up a 3D pointer as a Unity GUI compatible pointing device.
The crawler camera got a small offset to achieve a sort of "over-the-shoulder" look, as well as a crosshair so players actually know where they're shooting.
What's on the menu?
One of my bigger additions besides the core mechanics that aids in making the game feel more "complete" is a main menu that extends beyond just a lobby. This main menu is relatively simple but brings all core items a player can expect. There is a main screen from which the user can pick the three different panels: lobby, settings, controls. The lobby panel is the previous lobby as it was before. The settings panel offers the player a small selection of visual settings to change if they want better visuals or better performance, including resolution and quality preset. The controls panel simply shows the control mappings for all three supported input methods: mouse and keyboard for crawlers, Rift or Vive for master.
Visual feedback
One issue we kept seeing while playing as crawlers was the lack of visual feedback when hitting an enemy or getting hit by one. To mitigate this to a degree, visual hit effects were added, simple particle effects that visualize where an entity was hit, as well as screenshake. The screenshake does exactly what the name implies, making the camera shake whenever an "event" like a shot or explosion happens close enough to the crawler. While another layer of visual feedback on the UI would be very helpful, the two additions already give a much better idea of when and why the player is losing health.
Props to the level... Well, visuals in general
Visuals were another big change for the feeling of the game. The interim demo still only had the level without any surroundings, unrefined materials and simple lighting. For the alpha, I added a more sophisticated backdrop. For one in functional nature: the backdrop would be the same for any level, so integrating it directly into the actively played level would be a waste of memory, mapping times and storage. Instead, Unity supports so-called additive loading as well as "object persistence". The idea was to load an arbitrary game scene and then additively load the backdrop scene. Turns out that additive loading breaks lightmap assignment and completely nukes lighting of the backdrop. But object persistence doesn't, so now the system is a bit more clumsy and less optimized, but works the same on a high level and lighting remains functional.
The other part of the equation is the actual backdrop. Our setting is that of an asian downtown district, so the backdrop needed skyscrapers, neon lights and a dark, broody sky. The skyscrapers were taken from a few packages in the asset store, but materials were adapted to include more emissive detail. A variety of neon signs were created, some designed from the ground up, some taken from existing logos. The skybox was changed to convey a dark night and a slowly advancing cloud layer added. While a soundscape and some ground movement for the backdrop is still missing, it already gives a much better idea of what the setting of the game is. This step also included some experimenting with lightmapping setups and emissive mapping.
Another core component to the visual style is post-processing. Using the Unity post FX stack, I added tweaked bloom, lens effects, AO, HDR mapping, filmic tonemapping, screenspace reflections and depth of field. This went a very long way in conveying a fitting look for neon signs, fire, and other bright effects as well as enhancing contrast to give a stronger darker look to the game.
Room prefabs for random map generation - inb4 wreck
To elevate the random map generation from a prototype to a usable tool, we needed prefabs for the modules that the generator uses. Rooms, corridors and junctions. The next issue that presented itself was that these rooms would need to be filled with props: furniture, lights, decorations etc. Manually placing these would be a chore, especially if we want some variety, so instead of doing that, I introduced a Random Object Instancer. It's a gameobject to be placed in a room, a certain maximum boundary volume is specified and a list of allowed objects is added. Then as an editor tool, an arbitrary number of these ROI can be selected and at the press of a button they place a random object from their assigned lists into the scene. This way the designer only needs to specify the basic layout of items in a room but visual variety can be changed with a single click. Some of the individual props for the ROI were taken from the asset store, some simpler ones were created manually.
Unfortunately, it turned out that the prefab rooms and the map generation tool in its current state are not quite compatible, and couldn't be fixed in time.
Gameplay balancing
Some changes to gameplay balancing were introduced, such as a significantly higher movement speed and somewhat higher attack rate to make crawlers feel more agile and better equipped to evade enemies if necessary, as well as increasing the level of excitement a player experiences. To mitigate the fire rate somewhat, damage numbers for the crawler weapons were tweaked. ((Artjom:)) Additionally, more enemies and a second enemy type were added so the average player would actually need the help of his fellows and the master. On top of that, the level now contains a boss with more health and more range.
Dev Update - Jonas - "They grow so quickly!"
The master has come a far way from my first concept mockups, he now is even prettier, can show crawlers de wey and burn enemies or heal the crawlers' deep wounds.
VR MASTER - NOW IN RGB!
Instead of the old additive particle material, the master now has a bunch of glossy emissive material for each usable ability that he will smoothly interpolate between.
With a new, carefully selected colour palette for abilities, this gives both the crawlers and the master an intuitive visual feedback and it looks extra sweet with Paul's new post processing effects in place. In addition, buff and debuff have been enhanced with cute little particle systems and some more smaller visual tweaks have been applied to the master. For some reason the new systems cause weird flashes when the master blinks sometimes.
DU YU NOW DE WEY????
Initially, we planned to give the the master a pair of rigged hands, that allow him to perform different gestures and postures like pointing at certain targets or flipping the bird (here at Pick One we believe in flaming).
This idea was abandoned for multiple reasons though. First and foremost, nicely rigged, low poly hand-only models that are suitable for VR are pretty hard to get your hands on (pun intended), the good ones are in the asset store with double-digit price tags and everything you can find for free is pretty much useless. With the limited artistic skills in our team, modelling and skinning a pretty hand mesh and animating nice gestures in postures was also not feasible. On the other hand, we only really need to point at stuff, hence most other postures and gestures would pretty much only be nice and funny gimmicks. In addition, the concern arose that humanoid hands would not quite fit the boxy/digital cuteness of our master. Therefore the decision was made to implement a simpler and more robust solution: A 3D ARROW!
Surprisingly, 3D arrow assets are just as hard to steal find as hands. Because of that I took on the deed of spending an afternoon teaching myself Blender and modelling this beautiful mesh. In game, the master can turn his hand into yellow glowing arrows by pressing the grip buttons. When we're adding sounds, the arrows will also emit a loud "PING" when appearing.
The idea is to use this minimalist concept to make crawler-master communication both simple and exciting.
Throwables
The big master feature for the low target was throwable abilities, more specifically fire balls and heal orbs. The idea was to give the master powerful area effects that are limited in their usefulness by low precision and the fact that they affect crawlers and enemies equally. In practice this means, fire balls will also damage crawlers and heal orbs will heal enemies. The master therefore has to decide strategically when to use these abilities and be extra careful when throwing.
To avoid spamming, throwables need to be charged before usage. Throwables with lower charge will be smaller and less powerful. When selecting a physics based ability, the master's off-hand becomes a "pool" that he needs to suck the throwable's charge out of. Visual and haptic feedback facilitate this process for the master player. The idea is that once collectibles have been implemented, the master will only have limited total charge for his abilities, intuitively represented in the pool's size.
The strength of the effect on an entity is dependent on three different factors: the aforementioned charge of the throwable, the distance to the detonation and finally the velocity of the throwable. The latter was introduced to encourage masters to throw the abilities properly instead of just dropping them right next to where they are needed. In addition to the applied effect and a badass explosion there is now some immersive screen shake thanks to Paul.
Next steps
With the alpha realease this week and about one month of developement left, focus from now on will be more on polishing and bug fixing rather than adding a bulk of new unfinished features/abilities, ending up somewhere around the desired target.
For me this means that I want to end the infinite spam of abilities for the master by adding an automatically recharging resource for buff and debuff and pick-up based resources for the throwables. Limiting the enemies' visibility for the master also seems like a doable and gameplay-relevant task. In addition, a simple off-hand-touch-pad-based teleportation solution might become important for larger dungeons. The idea is to have a less overpowered master that makes gameplay a bit more challenging for both crawlers and the master.
Dev Update - Inshal
The Sumo
A new player class was added to the game. Do you feel those enemies are too tough? Do you want extra health to be able to tank some hits for your friends as they run away and abandon you? Do you want to be able to erupt in anger and their lack of anger? INtroducing, the Sumo. The primary gameplay purpose of the Sumo is to act as the vanguard of the group and keep his allies from harm by attracting attention of the enemies. His primary attributes are:
- Extra health due to having more mass than any other entity in the game (perhaps even the master!)
- A basic attack that deals damage to everyone in front of him
- Sumo Blast! Burst forth in anger and deal distance based damage to enemies around you!
[Add images]
Randomly Generating Maps
Creating a new map layout can be tiring, stressful, boring, tedious (insert more negative adjectives here). So rather than do it ourselves, we got a Unity to do it for us. We have a simple agreement with it: We give it prefabs of the map pieces we want to use and it generates the layoutr of the map and connects those pieces together. Then we can apply some light modifications if we feel like it and play the game! If you feel like nerding out a bit and getting a sense of the algorithm, read on!
The algorithm requires map objects. There are three types of map objects at the moment: rooms, corridors and junctions. The default connection rules are as follows:
- A room may only connect to a corridor
- A corridor may only connect to a room or junction
- A junction may only connect to a corridor
These rules can be changed on a per map oject level so you can have a room that connects to other rooms if you'd like (say, a trap room connected to treasure room).
Each map object also has to have exit markers attached to it which are basically empty game objects giving the location and orientation of where to connect the next rooms. These usually come with walls that can be enabled or disabled based on whether the exit is being used or not.
Finally, map objects must also have a collider covering the entirety of their geometry for overlap checks when instantiated by the algorithm.
The algorithm itself is simple to understand. The main steps are:
- Create a list of all exits that are not in use
- Try to add a map object to that exit
- Based on allowed connections of the map object
- Randomly selects a map object from allowed list
- Connection chance
- Overlap checks
- Map boundary checks
- Rinse and repeat
We added several features on top of this simple algorithm such as chance for the algorithm to simply drop the exit and make the room a possible dead-end.
Dev Update - Artem
Classes
Inshal already told you about the sumo class, I would tell about the rest. Remember, we had adrenaline soldier class in our interim? So, now it is split in two separate classes with different roles: soldier class and adrenaline class.
Soldier inherited his glorious sniper beam that strikes through walls. What's more, he now obtained a new super-attack that fires a blossom of bullets in front of him, which makes him less vulnerable in close quarters:
Adrenaline crawler inherited, well, adrenaline! He gains adrenaline from kills. When adrenaline is enough, he can become an overpowered katana master for a while. The basic weapon of this crawler was changed to shotgun to make him more distinctive from other players and lay stress on his "rage" behaviour.
So, along with sumo and infiltrator, we now have four fully implemented and playable classes.
Enemies
Another thing necessary for a complete game is enemies. We already had a dummy enemy with a simple AI for our interim, but now we have four of them, with two unique animated models.
The most frequent enemy is small robot-soldier. It is the weakest enemy that comes close to the player and uses blunt attacks. This simple enemy has a bigger version, with more health and damage, big robot-soldier. We are probably going to make a big version of soldier more rewarding for players in the future, allowing them to drop useful collectables.
More interesting are scorpions. They look dangerous and use flamethrower as their main weapon, which inflicts serious damage. Fortunately, this attack is pretty easy to avoid.
Finally, there are scorpion-boss. Defeating the boss is the main objective of every level. It has 3 times more damage and enormous amount of health. Just look at the pic:
Next steps
We have working collectibles; however, we haven't tested and balanced them properly yet, and they won't come in the alpha version.
Also, we are almost ready to add bonus enemy that shoots from afar.
Besides that, our priority task is to balance and tweak our gameplay, fix bugs.