Gravity

Ruckus

MMP2b Rosenberger, Welsch,

Wimmer

Concept

Local, Splitscreen, 4 Player Deathmatch

Take cues from other arena shooters (UT, Quake, Tribes, Nexuiz)

Add our own twist by allowing gravity to be changed

No regenerating health

Start with basic weapon, acquire others via pickups on the map

Health packs and seperate ammo packs for weapons

Make it go fast

You'll never be killed by a pack of attack dogs

What we "borrowed"

Increase the freedom of movement by allowing gravity switches

What we added

Tweak and fuse classic weapons to make them play better with the increased freedom of movement

Design a map with a completely different flow

Reduce the cognitive load of other elements to make movement less confusing

Challenges

Design a map that still works when players are allowed to go anywhere

Simplify a lot of things while still making them fun and interesting

Things we learned.

Isolate challenges early and solve them in a useful way.

Good 

The pooling system.

Most weapons are projectile based -> Lots of GameObjects in play at once. 

Continously deleting and allocating projectiles would be terrible for performance.

GC considered harmful. 

Alternative: Allocate all memory upfront and only reuse.

Good 

The pooling system.

{
  "Prefabs": [
    [ "Prefab/BounceProjectile", 180 ],
    [ "Prefab/GravityProjectile", 60],
    [ "Prefab/BlobProjectile", 60 ],
    [ "Prefab/UltimateProjectile", 4 ] ]
}

Based on some JSON, objects are allocated on start-up

Request -> Use -> Release -> Reset -> Request...

Works in every case where lots of GameObjects are needed.

Even works in completely seperate Unity projects.

Bad

The ICanShoot Interface.

One of the oldest parts of the code base. 

"Oh it's C#, lets use an Interface."

Resulted from over-simplifying the problem of designing weapons with some common behaviour (Ammo, cooldown). 

public interface ICanShoot
{
    float Cooldown { get; set; }
    bool Available { get; set; }
    void Shoot();
    void Enable();
    void Disable();
    void GetAmmoState(out int currentAmmo, out int maxAmmo);
}

Bad

The ICanShoot Interface.

With time more and more logic was implemented in seperate GameObjects. 

However, the common access point for weapons was ICanShoot.

Everytime another GameObject wanted to use weapon components, a workaround was needed.

Putting an Interface between GameObjects can really slow you down  (Over-zealous information hiding).

Build systems with native simplicity or your devs are gonna have a bad time.

Putting the gravity in Gravity Ruckus

Bad

The first approach to gravity

>>"Let's calculate gravity dynamically, based on real life but exaggerated a bit."

<<"Huh, where did my performance go? Where am I? Why am I floating?"

Creating an additional model for realistic gravity on top of Unitys physics system turns out to be pretty computationally expensive.

Makes calculating proper player orientation an absolute nightmare.

Don't even think about switching gravity with this approach.

Neutral

The second approach to gravity

A better system, involving the player looking at a wall and then pressing a button to switch gravity in that direction.

Gives player proper control over gravity.

Bad, because you have to look away from enemies to switch your gravity.

Good 

The third approach to gravity.

By splitting up gravity switching from one key to the whole D-Pad, the player gains much better control, without having to readjust their aim.

Takes a bit of time to get used to, but works amazingly afterwards.

Handling weapons and gravity.

It is really hard to hit people that can move quickly in every possible direction.

-> AimAssist

-> HomingComponent

Designing a map with our particular mechanics in mind

Bad

"Let's base our map on those arena shooter maps we all know and love!"

While this sounds like an excellent approach in theory, it quickly became apparent that it wouldn't work very well with our gravity mechanics.

Standard map designs tend not to work well if the players can move freely in all three dimensions.

Using a standard map design for FPS

Good

Our new approach was to create a series of rooms, each designed to allow every surface to be used as a floor.

To keep things interesting every room was given it's own theme, with fitting cover and obstacles.

Rooms designed for 3D movement