MMP2b Rosenberger, Welsch,



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


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.


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.


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.


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);


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


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.


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.


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


"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


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


By Philipp Welsch