Sep 1, 2021

BEPUv2 upgrade complete - improved performance, step up logic, proto-rigidbodies

Neos VR - Frooxius

Hello everyone and welcome to another of our weekly updates!

Last week we have released one of the biggest updates to Neos yet, upgrading the physics engine from BEPUv1 to BEPUv2, with a greatly improved performance and re-engineered how the integration works with Neos and has been one of the top requested changes both by GitHub and Patreon voting.

Combined this has greatly improved performance in many situations (particularly collider heavy worlds and items), improved physics behavior (e.g. when really small or going really fast) and fixed number of longstanding issues, such us users getting dropped out of fast moving vehicles or colliders lagging a frame behind.

There's a number of improvements as well, for example we implemented proper step up logic for character controller - no longer will you get stuck on small bumps in the environment - now you can walk up 2 meter tall stairs steps if you really want to!

Character controller can now also use any shape and update in realtime. With this it now respects your actual height in-game, so you can duck and walk under obstacles! Another addition lets you modify the interaction with specific colliders (or even spot on a collider using a texture), making surface sticky, slippery, bouncy and more!

And perhaps the most fun, you can now unlock rotation on character controller. As somewhat unintended side effect, this lets you create simple "proto-rigidbodies", that many of you have already been having fun with.

While we don't want to stop anyone from messing around with those (they are very fun after all!), please give the post below a read to understand their limitations and what is planned for the full rigidbody support that's coming at later point as separate major update, so you don't run into any nasty surprises!

You can read a lot more about the changes and improvements below and check out the detailed change log - we don't think that any build in the past ever had one this big!

In big part it's also thanks to our QC Team and Danger Testers, who helped catch dozens of issues and content breakages before the update went public, ensuring mostly smooth release.

There's a lot more exciting stuff to come in the future with the upgrade done, such as full rigidbody physics, culling systems for optimizations, value control volumes and more!

BEPUphysics v2 upgrade complete!

Last week we completed one of the biggest upgrades of Neos’ codebase to date - switching the physics engine from BEPUv1 to BEPUv2 and completely re-engineering how Neos integrates with a physics engine to power its interactions.

Despite the name, BEPUv1 and BEPUv2 are completely different physics engines, with BEPUv2 being written completely from scratch for greatly improved performance and flexibility of integration. Both are open-source projects by Ross Nordby.

Inside of Neos the physics engine is used to power the majority of interactions - whenever you point at something with a laser, grab an object, use a tool to interact with in-world items or move around the environment, the physics engine is used to figure out which objects in the 3D space are hit.

Because it’s the underlying layer for the majority of the core interactions with the environment, the integration with BEPUv1 has been one of the oldest parts of Neos’ codebase and it was showing its age in a number of issues that have accumulated over the years, both with glitchy behaviors and performance.

With the upgrade, we took the opportunity to completely scrap all the Neos code that integrates the physics engine as well and write a completely new one, with the latest conventions and good practices of Neos’ codebase.

In combination with BEPUv2 being a major upgrade in terms of performance and allowing better flexibility in integration thanks to its low level interface, Neos now has greatly improved performance in many areas, fixed numerous bugs and implemented a number of new features that have been requested for a while, with much more to come in the future! Let’s dive into them!

Improved world performance

Thanks to BEPUv2’s performance oriented design and our re-engineered integration, performance issues in a number of areas have been fixed, particularly with very collider heavy worlds.

The improvement will depend greatly on a world or session, depending on what particular bottleneck is. Certain worlds have seen great improvement in performance. For example Dark City 2 went from 70 FPS to around 120 FPS on the same system in the same spot. Large Minecraft import worlds have seen huge benefits thanks to their heavy use for triggers, some of the biggest ones going from 20 FPS to smooth 110 FPS and being limited by the amount of rendered geometry instead.

Many of these improvements are to improve handling of the colliders, ensuring that changes and moved colliders don’t cause unnecessary calculations (such as waking up colliders that aren’t interested in the updates) and certain parts of the update process run asynchronously from the rest of the updates.

Other worlds have seen smaller performance boosts, while other very negligible ones, due to being bottlenecked by other parts of the system, such as heavy LogiX use. This was expected, since with any complex system any part can become bottlenecked and our goal is to continually optimize all of them, with each optimization improving the general performance.

Smoother loading

The loading process should be now smoother as well. We fixed a number of issues causing extremely heavy CPU and memory usage which could lock up some systems, due to computing mesh metadata and colliders.

With BEPUv1 the acceleration structures required for mesh colliders and convex hulls were always computed on the fly as you loaded into the world, resulting in more stutters. With BEPUv2 integration the system now utilizes our asset variant system instead, computing the data only once and then loading it from the cache or the cloud.

Thanks to this the loading process should now be smoother and cause less load on the system. In our testing, computing a mesh collider for a dense mesh would take around 680 ms, while decompressing and loading a precomputed one took around 40 ms.

More efficient Raycast and Sweep queries

Thanks for BEPUv2’s low level design, we could optimize the common queries against the physics representation of the world - raycasts and convex sweeps, used to find which objects are hit in the world - e.g. when you use a tool, click on something with your laser or shoot a weapon.

If the query is interested in only one closest hit, it now uses a specialized path that adjusts the tested ray distance based on the found hits and avoids building a list of all hits to sort out later, reducing some memory usage. Both the LogiX RaycastOne and internal uses (e.g. particle system collisions) have been replaced with this variant.

More efficient dynamic bone chain collision queries

Part of our reason to upgrade to BEPUv2 was to also utilize some of its efficient data structures for our own features and various culling systems. One of the first such optimizations has been reworking the way dynamic bone chains look for potential colliders in the environment.

Previously each chain would scan all users by itself individually. With an increasing number of users (and dynamic bone chains) in the world, this would scale poorly and cost more and more CPU performance.

With the reworked system the initial intersections are now efficiently distributed using BEPUv2’s Tree structure, which should provide much better scaling and give us framework for more culling optimizations in the future.

Character Step Up logic

One of the longstanding issues in Neos reported by many users was the character controller getting stuck on small obstacles, requiring the heavy use of ramps when building worlds. We have previously deferred this issue to the BEPUv2 upgrade and with it now done, the issue has been resolved!

Thanks to the low level integration, we have implemented a proper step up logic, which will automatically walk up vertical obstacles, such as stairs, bumps and even tall vertical walls if the step height is configured so.

This should provide a lot more flexibility for creators to build the environments and make it easier for users to walk around any map, without getting stuck on small bumps and pieces of geometry. Setting up ramps might still be preferable, as it will provide a smoother movement, but is no longer necessary.

Character Controller now respects your current height and can be any shape

Another of the long requested features has been the ability for character controller to respect your current height - for example when you crouch, the shape representing you in the world gets smaller, allowing you to walk under obstacles.

With the upgrade and the logic of the character controller reworked, this is now fully supported! Rather than always being a fixed capsule shape, the collider has now been decoupled from Character Controller and is presented by a separate component on the same Slot.

As a result, you can use any convex shape - box, cylinder, sphere, even convex hull! The shape can also be updated as any other too. For Character Controller specifically there’s a new SingleShapeCharacterControllerManager component, which automatically adjusts the height of the collider based on the current position of your head.

This means in VR you can now duck and walk under obstacles! Desktop mode has a bit of extra behavior as well on top, which will prevent the character from standing up after crouching if there’s something above them.

https://www.youtube.com/watch?v=GNW59n3M8sQ

We are looking into doing more in the future as well. With planned compound collider support, it should be possible to split the character body into multiple shapes instead of a single one and provide even more precise collisions with the environment when leaning over or laying down in full-body.

Character Controller surface modifiers

To give you even more flexibility when building worlds, we introduced a new type of component - character controller modifiers! These allow you to modify the behavior of a particular collider for character collisions - dynamically changing the traction parameters, speed, jump height and more.

With this you can easily create surfaces that are sticky (like the purple goo from DOOM Eternal), slippery (like ice that makes you slide), ladders that you can climb vertically by walking into them and much more!

It’s also possible to utilize a texture to control the parameters, allowing you to vary the parameters depending on where the player is colliding. This can be very useful for terrains. We can’t wait to see what kinds of maps and cool things you’ll build with this new mechanism!

Fixed collisions being a frame behind and getting dropped out of vehicles

With previous integration users ran into a number of problems, particularly when building fast moving vehicles. Oftentimes users would end up randomly dropping out of the vehicle if it’s moving fast enough and interacting with any colliders within it would be difficult as well, as they would be lagging a frame behind from the visual.

Thanks to the whole integration being re-engineered, we put a lot more care into how the new one is designed to avoid those problems altogether, by paying more attention about the order of operations and ensuring that the physics representation is updated at the right time.

This was done by splitting movement events between general and physics, allowing the colliders to update their poses before interactions happen, without causing issues with other components that must update late.

Along with a whole number of smaller design changes, those issues are now completely gone! Vehicles and other behavior should now be reliable and easier to enjoy!

Improved interactions at small scales

One of the big changes in BEPUv2’s design is it’s auto-tuning mechanism. The previous version had a number of manual settings to make it behave well for particular use-case and scale. As a result if you scaled yourself down in Neos (or large), interactions with the environment would feel “off” and glitchy.

BEPUv2’s design however tries to avoid those manual settings whenever possible and instead the calculations are tuned automatically. As a result of the upgrade, interactions while being scaled significantly down in Neos now feel the same as at regular scale, giving users more flexibility on interacting with the environment!

Mesh Colliders can now be single sided

Previously all mesh colliders in Neos would be dual-sided - you would collide and hit the mesh from whichever side you’d come in. In a large number of cases, this was actually undesirable - you could easily get stuck in the geometry or halfway through a terrain due to colliding with both sides of it.

With the new integration, we have now exposed this as a configurable option, allowing you to set collisions to only happen from the front side of the mesh - the one that you see with a single sided-material.

On top of that we have also added heuristic that automatically converts any character colliders into Front sided only, unless some conditions are met - there’s a dual-sided material on the same slot or any negative scaling.

This technically changes behavior of existing content, but from our testing phase this seems generally beneficial in improving the behaviors of those worlds and improving performance, with the heuristics preventing the upgrade in cases where it would cause issues. If you find any more, let us know though and we can tweak them some more!

Static Trigger types

We have added some new collider types to the mix as well! In addition to Trigger and HapticTrigger, there are now static variants as well - StaticTrigger and HapticStaticTrigger. These are functionally the same, but assuming they don’t move relative to the world, will skip some of the overhead that non-static variants have.

If you’re building new content, it’s recommended to use those types whenever you know that it won’t move which can give you a bit of extra performance (especially if there’s a lot of them). If they are moving however, use the regular ones.

You’ll probably notice that there’s also “Auto” variants of these. Any existing content is automatically switched to those, so it can gain benefits of their optimizations. If any movement is detected over several frames, they will automatically be switched to the non-static version.

Main physics and Haptic colliders are now separated

Previously a single physics simulation was used to handle all the different types of colliders - both for environment collisions and triggers, as well as haptic volumes, triggering any haptic interactions in the environment.

Because those two types of interactions never interact with each other, the new integration now splits them up into two completely separate simulations. Not only does this avoid a bunch of cross testing of colliders that will never interact, but allows us to update them fully in parallel, for a bit of additional performance!

Mesh density heuristics - no more lag when laser tries to stick to dense mesh

Another of the small, but hopefully impactful performance improvements is handling of dense mesh colliders. Lasers in Neos have a “sticking” logic, which tries to stick the laser point to the last object when it goes past the edge.

Generally this works pretty well, unless the object is using a dense mesh collider. The sticking tests can be very expensive against those colliders, which would cause your framerate to randomly drop as you interact with the environment.

Neos now computes average triangle sizes and areas as part of the mesh metadata, which now allows us to estimate average density of the mesh relative to the scale it’s being tested at. If we detect that the test would be likely too expensive, we simply skip the expensive tests and just stick to the last known point.

This should help improve the general user experience with unoptimized content and avoid another case of accidental stutters that can be uncomfortable to users.

Double buffered procedural mesh collider updates

When using mesh colliders with procedural meshes, Neos would previously try to update the acceleration data in-place. In some cases this would result in glitchy behaviors, where certain colliders would seem to flicker in and out of existence or produce random ghost collisions, due to being in the middle of an update. You could particularly notice this with LogiX in some cases.

To improve this behavior and prevent potential race conditions, the new mechanism is now double buffered, simply computing a new acceleration structure in the background, while the existing one is in use and then swapping them over.

This mechanism also improves the memory management, avoiding lots of new allocations on frequently changing mesh colliders.

While this improves the behavior, generally it’s recommended to use simpler colliders instead, especially for anything that changes over time, as it will provide better performance.

Numerous other performance improvements and fixes

Apart from these notable changes, the upgrade process had many more bug fixes and small performance improvements that should overall help improve the user experience for both end users and creators.

If you’d like to see a more complete list of the changes, check out the release notes here, which go into a bit more detail.

https://steamcommunity.com/games/neos/announcements/detail/2944778418489689560

Proto-rigidbody physics - what are they?

Perhaps one of the most exciting and somewhat unintended features of the BEPUv2 upgrade is the ability to get simple rigidbody simulation, thanks to the combination of being able to use any shape with CharacterController and new ability to unlock its rotation.

With this, you can get objects that behave like rigidbodies, which can be very fun to interact and play with, but which also come with some important limitations that everyone needs to understand first.

Importantly, those are NOT what the actual planned rigidbody support entails - it is a separate body of work that will come at a later point after this upgrade and will be designed to handle the rigidbody simulation efficiently (both on system resources and network) and give you full control.

Why character controllers aren't suitable for rigidbody simulations

They're optimized for character locomotion and will have odd behavioral quirks when used otherwise, these will be addressed by the actual rigidbody support, so before that comes you'll have to deal with them
Having many of them won't perform well, both on CPU and network. They're not optimized for this use case
You have limited control. You can't control aspects like friction or create constraints (e.g. joining bodies with joints, hinges, motors etc) that actual rigidbodies support.
We STRONGLY discourage building too complex long term content with this mechanism, other than one that involves actual character control.

Now if you understand these limitations, feel free to have fun with them in the meanwhile, before the full support actually comes. Neos is all about tinkering, toying around and messing with things and it will give you a bit of a taste of what will come.

Here are some videos of our users playing with them!

What will full rigidbody support offer?

The full rigidbody support covered by this issue is a significant chunk of work that will come after the BEPUv2 upgrade completes. It will focus on following:

CPU and network efficiency - with engine optimizations, efficient handling of many bodies in the simulation and specialized network encoding will allow you to have many bodies in the world with significantly lower impact
Simple to use with less glitchiness - controlling the friction, bounciness, applying forces and impulses and more, without the extra “cruft” that character controllers have - these will be pure rigidbodies
Constraints - you will be able to connect the rigidbodies with a number of constraints - joints, springs, hinges, motors and more, to create complex setups and interactions
Smooth simulation and interaction for everyone - character controllers are simulated by a single user only and can be quite choppy and glitchy (for example when grabbing they just randomly poof off somewhere) for others if not setup properly. Full rigidbody support will be designed to not have these issues.
New features and tools - instead of having to go through convoluted process to enable the simulation, we’ll add quick tools and integrate physical interactions across Neos, to make it very easy to start playing with them and building cool content

Make sure to also check the roadmap for physics support, we'll expand it with individual tasks once work begins on this (we're still finishing BEPUv2 upgrade at the moment, so it won't happen before then): https://github.com/Neos-Metaverse/NeosPublic/projects/19

Big thanks to everyone who helped with the upgrade!

The upgrade has been a relatively long and tedious process, as we had to remove a significant chunk of Neos’ codebase and completely redesign and rework it on a new system, while making sure that existing interactions and content doesn’t break.

---

BEPUv2 integration merge request, right before public release, along with all reports by QC team and public testing (click to view full image)

Before releasing the upgrade to the public, we ran closed testing first with our new QC team in order to find out the most egregious bugs and issues, followed by public testing with our Danger Tester group afterwards, to get much broader coverage of issues and problems.

Thanks to everyone’s efforts, we found dozens of bugs, content breakages, crashes, performance issues and other issues during the testing phase and addressed them before the public release, leading to a relatively smooth release. Of course if you find any more bugs and regressions, feel free to report them on GitHub, we'll still be fixing what we can even post-release!

Here’s a huge thanks to Shifty and her QC team for helping out catch all the early bugs, as well as Danger Tester's who participated in the public testing: Shadow Panther, Beaned, ohzee, Zyzyl, Alex from Alaska, Snooper, Pat cat, LucasRo7, Turk, Enverex, MattyK, Cyro, Modern, 1amNick, Hayden, Toxic_Cookie | NTC CEO, Elizabeth Dayax, Epsilion, epicEaston197, DrFrank, TheBasementNerd (she/her), Alex rainbowdashie, Sloppy McFloppy , Ian Corvid, Kulza, Tatsu Kimiero, Sylva, Gawdl3y and everyone who tested without reports!

Another huge thanks also goes to Ross Nordby, the developer of BEPUphysics 2, for his detailed explanations and responses that helped with the integration process and quick bug fixes of issues we found in the physics engine itself!

And last but not least, there’s a huge thanks to everyone in the community and our Patreon supporters, who have enabled us to work on this large project. BEPUv2 upgrade has been one of the top requested changes, both on GitHub and Patreon and with it now complete Neos has made an important leap forward, with many great things to come in the future on top of this foundation.

There are exciting times ahead! See you next week!

Sep 1, 2021

Development Update #11

Crab Champions - Noisestorm

Work continues on every aspect of the game this month: I'm playtesting daily and making thousands of small changes that are adding up to create a satisfying game loop.

Epic MegaGrant

I'm very pleased to announce that Crab Champions has received a MegaGrant from the amazing folks at Epic Games (creators of Unreal Engine which I use to make this game). Huge thanks to them for their generosity, I'm beyond grateful for the support! Their MegaGrant initiative is helping devs finish their projects everywhere: if you are making a project in Unreal Engine it's definitely worth checking out.

Weapon Heat Mechanic

Since ammo is unlimited in Crab Champions, having a reload mechanic was a bit redundant and uses up a keybind for very little value in return. I've decided to move to a new heat based mechanic to replace traditional reloading. Before you raise your pitchforks: this will not result in your weapon doing a frustrating overheat or jammed animation where you can't fire for several seconds. Instead this heat mechanic factors deeply into the mod system as mentioned below, making it so that stacking high cost mods will mean your weapon heats quickly and will require special cooling mods or perks to circumvent, adding a new layer of strategy to builds.

This prevents any one weapon from creating a meta (this would have been the minigun in previous versions of the game as it had a huge clip, fast fire rate and no penalty for stacking the most powerful mods). Anyone not using the minigun was at a disadvantage. Now, each weapon has a different cooling speed and max heat stat, allowing for much more balance across the weapon types in this regard.

Survival Mode Weapon Mods

In Development Update #9, I shared the list of perks that were added to the game and mentioned that they would compliment the new weapon mod system. I'm happy to say that a huge amount of progress has been made on this system and it's feeling great. There was a lot of hidden complexity in getting this stable as some of the combinations can produce crazy results!

As a quick recap: weapon mods are a core focus for Survival mode, allowing players to stack powerful upgrades on stock weapons with a near infinite number of combinations. Mods can be placed on your primary and secondary weapons as well as your grenade.

These mods tie into the heat system mentioned above: each mod has a heat cost when triggered which means that players must strike a balance between raw power and being able to fire fast enough to eliminate enemies. Sure it's possible to fire a shot that spawns 12 burning blades which each spawn a black hole when exploding but it'll cost a lot of heat, meaning you won't be able to fire again until your weapon cools enough to afford the heat of another shot.

Here are some of the weapon mods added this month (many more are planned for future updates):

Common Weapon Mods

Cooling Shot: Shots that hit enemies cool your weapon
Light Shot: Projectiles are no longer affected by gravity
Bouncing Orb: Chance to fire a bouncing orb along with your normal shot
Heatsink: Cooling speed increased
Extended Mag: Max heat increased
Wind Up: Damage increased for each shot fired in a row (resets when overheating or stopping fire)
High Caliber: Damage greatly increased but max heat is reduced to 33%
Iron Sights: Damage increased when aiming
Glue Shot: Shots slow enemies
Charm Shot: Shots charm enemies (they will temporarily fight for you)
Ricochet Shot: Shots ricochet off surfaces
Snake Shot: Projectiles move in a wavy pattern
Fast Shot: Projectiles fly faster

Rare Weapon Mods

Stun Shot: Shots stun enemies
Weak Shot: Shots weaken enemies, causing them to deal less damage
FMJ: Damage increased to shots dealing more than 85 damage
Cluster Shot: Fires an inaccurate cluster of 2-8 shots
Chaotic Shot: Projectiles deal much higher damage but fly in random patterns
Big Shot: Projectiles are larger (both in terms of visuals and hitbox)
Explosive Core: Projectiles have a larger explosion radius
Ghost Shot: Chance to not heat the weapon when firing a shot
Poison Dagger: Chance for enemies to get hit with poisoned daggers when being damaged by this weapon
Iron Shot: Projectiles are far slower and heavier but deal much greater damage
Combo Counter: Deal bonus damage when hitting the same enemy multiple times in a row (resets when missing or hitting another enemy)
Precision Laser: Damage increased for each shot you hit without missing
Earthquake Shot: Shots knock enemies back
Close Shot: Large damage increase when hitting nearby enemies
Distant Shot: Large damage increase when hitting distant enemies
Afterburner: Every fifth shot is a guaranteed crit
Mace Ball: Chance to fire a heavy but damaging mace ball along with your normal shot

Epic Weapon Mods

Damage Shot: Damage greatly increased
Crit Shot: Chance to crit
Power Shot: Crit damage increased
Mega Crit Shot: Chance to megacrit (3x crit) when landing crits
Giga Crit Shot: Chance to gigacrit (10x crit) if all other mods on the weapon are crit based
Supercharger: Fire rate increased
Stacker: Elemental damage stacks increased
Heatseeker: Shots that hit enemies spawn additional shots that fire at nearby enemies
Quad Shot: Fire 4 shots with reduced damage and increased spread
Looper: Projectiles have a chance to explode multiple times
Random Shot: Every time a shot is fired, a random projectile is used
Piercing Shot: Bullets pierce through enemies
Saw Blade: Chance to fire a sharp saw blade along with your normal shot
Elemental Shot: Shots have a random elemental damage type
Crystal Blast: Chance to fire a close range AOE blast with each shot

Legendary Weapon Mods

Double Barrel: Shoot an extra shot each time you fire
Splash Shot: Shots deal splash damage to a radius around their impact point
Black Hole: Chance for a black hole to spawn at the impact point of each shot, sucking nearby enemies and projectiles in
Blade Cluster: Chance for a cluster of blades to spawn at the impact point of each shot
Homing Shot: Chance for projectiles to home to nearby enemies
Ice Shot: Chance for shots to freeze enemies
Fire Shot: Chance for shots to burn enemies
Lightning Shot: Chance for shots to shock enemies
Acid Shot: Chance for shots to poison enemies
Clone Shot: Chance for projectiles to duplicate while in the air
Fireball: Chance to fire a fireball along with your normal shot

To make the divide between weapon mods and perks more clear: weapon mods now only affect what comes out of a weapon when fired and perks can handle any other cases. Some mods have been converted to perks such as Exploding Enemies (enemies explode when eliminated) or Icebreaker (enemies take damage when thawing from ice). This allows for many more mod and perk synergies, making perks more interesting and viable rather than being purely for utility. There'll be more work done to make sure that the mod system feels easy to learn while still allowing some crazy combinations.

Here's a fun quick example: the grenade has a Black Hole mod which creates a black hole when exploding. All nearby enemies and projectiles are sucked into it. In the clip below I'm firing an orb launcher with a mod that spawns blades when exploding. You can see them being sucked into the black hole until it runs out and then the homing mod kicks in and sends all of the projectiles to the nearest enemy.

Survival Mode Challenge Modifiers

New challenge modifiers have been added to challenge islands this month, increasing the amount of potential variation across runs.

Army Of One: All enemies are of one random type
Afterlife: Enemies are invulnerable for 5 seconds after being eliminated
Friendly Fire: You can damage yourself with projectiles and explosions
Shrapnel: Enemies explode into a burst of projectiles when eliminated
Rebirth: Enemies spawn a random lesser enemy when eliminated
Ocean Of Lava: The ocean is made of lava: watch out!
Trapped: All traps and hazards on the island are enabled!
Homing Enemies: All enemies have homing projectiles
Double Edged Sword: All explosions do far more damage in a far larger radius
Randomized Mods: All weapon mods are randomized for this island
Sharpshooter: Missing shots causes you to take a small amount of damage
Elemental Enemies: Enemies explode into a random elemental damage area when eliminated

These are in addition to the challenge modifiers mentioned in a previous update such as Low Gravity or Instagib.

Controller Aim Assist

I've been doing a lot of playtesting on controller and noticed that aim assist was badly needed. I've added two settings that players using controllers can use: a Low setting that simply lowers sensitivity when near a target and a High setting that offers a subtle magnetic pull when aiming near enemies. Players can of course play without any aim assist if they wish. In Duel mode, only the Low setting will be applied for fairness.

Survival Mode Quality Of Life Improvements

New Icons: Placeholder icons are starting to get replaced: I'm going for a nice clean and simple style with these icons: aiming for them to be easy to read no matter the size on screen!
Horde + Wave Island Types Consolidated: As I want each portal type to offer a meaningfully different style of gameplay, I am merging the Horde and Wave island types as they were too similar. A similar experience to the old Horde islands can still be found when on a challenge island with the Army Of One challenge modifier active.
Pacing: Previously, all portal types had the potential to spawn after finishing the first island which meant that an underpowered player could take on an elite challenge which of course ended up feeling unfair. It also meant that it was possible to get very overpowered early on if you only chose hard portals and got Epic or Legendary rewards. I have done a lot of work to balance this out with the harder portal types slowly trickling in as you progress through each biome. The current layout is:
Island 1: Horde (1 wave)
Island 2: Horde (2 waves) OR Defense
Island 3: Horde (3 waves) OR Defense OR Challenge
Island 4: Shop
Island 5-8: Defense OR Challenge OR Elite
Island 9: Shop
Island 10: Boss
Respawn Tweaks: Downed players now respawn with only 33% health to prevent downing on purpose to regain health.

Thanks for reading!

Join the Crab Champions Discord server: https://discord.gg/crabchampions
Follow Crab Champions on Twitter: https://twitter.com/crabchampions
Join the Crab Champions subreddit: https://www.reddit.com/r/CrabChampions/