Nifty Island

Website

Overview

Nifty Island is a UGC (User Generated Content) MMO where players build islands with custom assets and gameplay experiences. All creation happens in game using the Nifty Island Engine. Creators are paid based on the amount of foot traffic their islands recieve.

Players level up their account/recieve rewards by performing a variety of activites: fishing, playing UGC experiences/minigames, completing challenges, and participating in UGC quests.

My Role

Technical Team lead.

I lead a team of 10+ developers in building a MMO from the ground up. I am responsible for game architecture, gameplay implementation (PVP combat), and engine level systems (Custom Netcode, Visual Scripting Language, Entity Component System, World Streaming, Custom Assets).

Outcome

My team delivered a publicly available MVP in 8 months and a public beta release in 3 years. At its peak Nifty Island attracted over 20,000 monthly active users.

Featured Work

PVP projectile/melee combat

I designed and implemented the combat for Nifty Island. Players create minigames on their islands that allow for combat (Deathmatch, CTF, Custom Scripts). Players are equipped with a sword and a gun in a unique blend of melee/ranged combat.

Designing Combat

One Nifty Island's greatest strengths is it's character controller. When I designed the combat I wanted to make sure it would amplify the strengths of the 3d platformer movement. This led me to a couple design tenets:

1. attacks should be dodgeable (no hitscan)
2. obtaining more powerful weapons should require platforming (old school shooter pickups)

Another unique constraint to Nifty Island is that as a dev team we have no control over the design of the maps (all maps are UGC). This game me more design tenets:

3. taking cover/working angles/strategic team play would not well, since it relies on proper map design
4. dueling another player needed to be fun on a empty map

With these tenets in mind I created what I would describe as a brawler with projectile based combat. Each player has 2 weapons:

• Pistol (offensive option)
• swappable ammo: AOE, slow, stun, poison, etc.
• slower than normal movement
• Sword (defensive option)
• powerful AOE melee attacks, aimed like the pistol for seamless swapping
• faster than normal movement
• a shield that reflects incoming bullets in the direction you are aiming

Players are meant swap between these two constantly, providing an interesting ebb/flow in the games combat.

Technical Details

The combat simulation is built on 2 key concepts effects and effectRecievers. Objects in the game simulation may apply effects to effectRecievers or a location in world. Some examples of effects are:

• damage: reduce Health
• slow: reduce movement speed for a period of time
• spawn: spawn an object at the recievers location
• purge: remove all status effects

EffectRecievers are concrete implementations of the abstract EffectReciever class. They may override how a particular object handles application of a particular effect. Different implementations makes it easy to optimize performance and customize behaviour. Some examples of recievers are:

• defaultEffectReciever: default effect reciever for player controlled entities. Provides
• destructibleObjectEffectReciever: provides massive network optimizations that allows for any object in the world to be destructible.
• shieldEffectReciever: player's shield converts damage application to player stamnia (as opposed to health).

The combat simulation runs on a deterministic tick with clientside prediction/rollback of health values/effect durations.

FLOW: Runtime Visual Scripting Language

Documentation

I created a visual scripting language FLOW that allows players in our community to build anything from within the game itself. Players write Scripts with Variables and place ScriptInstances on their islands. ScriptInstances allow a player to override Variables defined in the source code Script to parameterize them. ScriptInstances may reference C# components to integrate with C# functionality.

Features: synced custom variables, networked events, parallel execution, custom UI, RPCs, minigame integration, error reporting.

Internal tooling

Internal game developers expose C# functionality to players via c# attributes. Methods, Events, Getters and Expressions are supported. Devs can customize the look/documentation of the nodes with optional attributes (ex: optionalArgs, description, portDescription). Players add Components to objects in the world and reference them from scripts call exposed C# code.

Ex: Exposing event from a component

public partial class Trigger : NetworkedCompnent { 
    [ScriptCallable]
    public OutputEvent<Player> onPlayerEnter = new();
}

Technical Details

FLOW is implemented as a runtime interperted language whose execution is split across all network peers. The language toolchain is implemented in c# with a Parser, SemanticAnalyzer, and Interpreter.

• Parser: traverses the visual graph and builds an AbstractSyntaxTree (AST).
• SemanticAnalyzer: traverses the AST and detects semantic errors (ex: using node outputs out of scope)
• Interpreter: traverses the AST and executes ASTNodes. Capable of resuming execution across the network for multi-client/server-client execution chains.

Scripts are compiled on all network peers, and each script instance is linked to instances of itself on each peer. Instances of different peers coordinate execution/sync vairable state across the network.

Component System

I created a Component System that allows internal devs to expose composable behaviors to users. Each component has a presisted Config object that players can modify to customize the behavior. Components may be added to any object in the world (just like a monobehaviour in unity).

Components expose C# code to FLOW (visual scripting language).

Ex: Health component

public partial class HealthConfig : Config {
    [GameState]
    public float maxHealth
}

public partial class HealthState : State {
    [GameState]
    public float currentHealth;
}

public partial class Health<HealthConfig, HealthState> : NetworkedComponent { 
    [ScriptCallable]
    publc void TakeDamage(float amount) {
        ...
    }
}

Custom Netcode Framework: NetDef

NetDef is the custom networking framework I built for Nifty Island. NetDef was custom built to support the unique constraints of building a networked realtime game engine. It is capable to quickly synchronizing massive amounts of data in a deterministic way.

Features:

• networked monobehaviours/POCO classes
• code generation of serialization/deserializtion/synchronization
• deterministic tick based simulation
• supports large amounts of networked objects (50,000+)
• 0 allocation overhead
• customizable interpolation
• serialization of all c# primities, lists, arrays, object references, sub objects
• sycnrhonization layers/channels
• quantization of floats/vectors
• automatic persistence of synchronized state

public partial class TransformState : GameStateProperty {
    [GameState, Compressed(1000, 100, 1000)]
    public Vector3 position;

    [GameState]
    public Quaterion rotation;

    [GameState]
    public Vector3 scale;
}

public partial class WorldObject : GameStateObject {
    [GameState]
    public TransformState transform; //supports serialization of 
}

Game Architecture

The codebase is split across 3 architectural layers: Core, Game, Entities. Each layer may only reference code within a layer below it.

The main goal of this architecture is to separate code into "layers" based on the frequency of change. I strive for code that changes frequently to depend on code that changes infrequently. This has a number of benefits:

1. Limits the "blast radius" of a bug. If code at the "Core" of the application does not depend the "Presentation" then changes to UI, Compenent Implementations, etc.. should not cause an explosion of bugs elsewhere
2. Speeds up compilation/domain reload in a large codebase. Frequently changing change will have very few assemblies depend on it, reducing the scope of what must be compiled.
3. Provides a logical framelogic for ICs to organize their code and forces them to think about the direction of dependencies.

Core

Defines what Nifty Island is. For example:

• WorldObject
• Component
• Script
• Player
• User
• Quest

All of these examples a very basic Core concepts to the game. Due to the fact that they define what Nifty Island is every other layer depends on these classes. Core code may only refernce Core code.

The frequency of change is infrequent when compared to Game and Presentation code. When core code is changed it is generally an extension rather than a modification.

Game

Define what Nifty Island does. For Example:

• QuestService: assigns/spawns player quests, tracks quest completion
• MinigameService: manages all available UGC minigames on an island, manages instances of minigames, provides lobby services to players starting a minigame
• ProgressionService: tracks player progression, rewards experience for performing actions

All of these are examples of extendable game systems that exist as part of the Gameloop. It is important these systems do not know directly about any concrete implementations of the entities they manage. Game code only references Game/Core code.

Game code changes somewhat frequently, but is generally stable once a feature is released.

Entities

Define how Nifty Island behaves, looks, and feels. For Example:

• KillPlayersQuest: a quest implementation that rewards players when they kill others
• Deathmatch: a minigame implementation that pits players against each other in combat
• FishingRodOfAges: item rewarded to the player for reaching fishing level 13

All of these are implementations of core concepts that extend game systems. It is important these systems do not know directly about any concrete implementations of the entities they manage. Entities code may reference any code in the project.

Entities code is changing constantly. This where game content gets created.