Academic Capstone project, 2014, network and physics programming
Each map has a set of data collection nodes, and a single data deposit node. Players race to collect data and then deposit it; only deposited data counts toward their score. Because there is only a single deposit node, the players are steered into inevitable confrontation from the outset. They must choose their strategy right away: Do they go for lots of data and lots of powerups before making a run on the deposit node? Do they just grab data in small amounts and head to the deposit node as fast as possible to rack up points? Do they grab offensive powerups and try to lay traps around the deposit node? All three strategies have been employed successfully by players, which tells us that we accomplished our goal.
The Hammer is an alternate weapon pickup, deployed like a normal trap, that replaces the Stun Sword. A player hit with the Hammer is knocked back and drops a portion of their data, as well as playing a very fun and rewarding (or humiliating, depending on your place in the transaction) gonging noise.
The Jungle level features ropes that the players can swing on. They're built as hinge joint systems in Unity physics, and took the bulk of my development time to get right because of the networked environment.
To understand why this was so difficult, we need to look at the limitations of Unity's networking out of the box, or at least what its limitations were in the spring of 2014 when these were first in development. The main problem is that Unity doesn't come with a way to smoothly move realtime objects across the network. 15 network frames per second just isn't enough for anything other than painfully jagged movement without some kind of enhancements. So, the first thing I had to do was create an interpolation system, causing the first frame of synchronization to be cached but not applied, and then spending each successive network frame interpolating transform data from the previous to the current just in time for a new frame to arrive, creating a one-frame-back illusion of smooth motion. Pretty typical solution there.
Making the ropes work with players attached was a little trickier. I went with an authoritative server networking model, meaning that the machine hosting the game is the sole arbiter of where everything really is in the game world. Synchronizing physics required some very tricky dancing, ultimately requiring client rope physics to be disabled, with the rope segment transforms synchronizing with the same model as the players. However, because the synchronizations didn't all happen simultaneously, the basic approach caused players on ropes to appear as though they were quickly attaching and detaching from each rope. To correct that required us to expand the network event system so that clients could parent the player transform to their designated rope segment, disregarding synchronization interpolation while the player held on.
Adding another layer of complexity, the ropes don't swing themselves - the player swings them. They jump up to the rope while holding the Climb button, attach to the rope at that point, and then their direction controls allow them to start pushing off in a direction. The steps involved to get that working in a networked environment were complicated: A client player grabs a rope, and all other machines are informed. As the player applies force, the host is informed, physics are applied on the host machine, the rope moves, and all clients are updated with the transform data for the moving rope, carrying along the locally parented instance of that network player.
Takeaway: Networked physics are not simple.
The level-specific hazard of the Jungle level is its vine traps, which cause a player to lose some of their data tokens and then cut themselves out in order to get back into the game. The Jungle level was in development just as we were getting our core platform stabilized, making the implementation of this feature an important success.
Terminals, player positions, player animations, player weapons, trap positions, trap states - in a networked game, everything has to be synchronized. Sometimes it's trivially easy (static objects that don't move once they're spawned are pretty straightforward) and sometimes it's hard (see my post on networked rope swinging physics), but it all has to work. Each player must feel that they are looking into the same world.
A common Jungle level tactic is to blanket the Vine Trap-saturated steps leading to the deposit node with landmines, hoping to force an unlucky player into one of them.
The basic network model I implemented allows for the transmission of both object data and significant events. Animation changes are driven by the player object. Based on their current state and input, they may be walking, standing still, swinging a weapon, jumping, climbing, etc. Each machine in the game can receive this information as a single integer and designate the local instance's animation appropriately, changing animations only when two consecutive values are not identical.
The Data Siphon trap allows a player to leave a fake data token anywhere in the map. When another player picks it up, a portion of their data is instantly transmitted to the player who placed the trap. The visual difference is subtle - noticeable by a careful player, but easily missed by one in a hurry, and the "drain" noise played when someone picks up the wrong token is generally followed by a satisfying groan of dismay.
Each level has themed data collection and deposit nodes. Here we see a mine cart full of valuable crystals into which vital information has been encoded (no, it's not the strongest design, but go along with it and it's still a fun time).
The lava for which the Lava Level is named is deadly to players, causing them to instantly drop all of their data. A player with a Bubble Shield can render themselves temporarily immune to the lava's effect, and a well-prepared and skillful player can use this to follow an unlucky player into the lava, scooping up their dropped data tokens and escaping to higher ground before the shield wears off.
In the lava level, the deposit location is at the highest point the players can normally reach. The lava rises periodically, swallowing resource nodes and driving the action into a more directly competitive pace.
The after-effects of the Landmine trap are a flash of light, a cartoony caption, and the flinging of any affected player through the air away from the point of detonation. In a level where the pathways are narrow and there's player-melting lava below most of the time, this trap is particularly popular.
Well-received Ludum Dare 34 (December 2015) team project in ongoing development by OverHook Games. My contributions are the orbit and momentum physics, designer tools to control the characteristics of each planet, and off-screen indicators. In short, I'm the team's math guy.
The player's job is to get to the black hole in each level by using orbitable bodies to slingshot themselves from orbit to orbit, avoiding danger and being very, very precise. When in orbit, the player gains a visual trail to help gauge their current speed.
The Force Shield powerup allows a player to break through a saw, destroying it without affecting momentum.
The orbit system was designed to allow orbitable bodies to have a range of influence and a pull magnitude. The pull magnitude can be negative, allowing us to create repulsors that push the player away. The visuals associated with an orbitable body are independent from its physics properties, so we can have repulsors that look very different from orbitable bodies.
The first button of our two-button theme is "remove orbit pull," which allows the player to move between orbitable bodies once they've gained enough speed. The second button is "use powerup." Here we see a visualization of the Rocket powerup, usually used to try to correct a short jump - though, as we see here, not always successfully.
Teleportation gates (no relation) are linked pairs that maintain a player's momentum, allowing for some interesting puzzle designs. Here the player must hit the previous teleportation gate with just the right momentum to reach the black hole.
Bumping into one of the buzzing saw blades leaves nothing but a collection of parts and a dwindling trail.
Saw blades can orbit just like the player can. In the Land of Gates level (my design), the player is dropped from a high distance between two such blades into this orbitable planet, from which they must be either very skillful, or use the Force Shield to safely exit.
Prototype team project at OverHook Games
Two players cooperate to complete levels. The infiltrator, shown here as the humanoid in the lower left, navigates physical obstacles and deals with physical enemies, while the hacker, represented by the small blue hexagon at the lower left, navigates logical/virtual obstacles and deals with logical/virtual enemies. The hacker's movement is confined to a connected node graph, which much be edited separately from the level geometry. The goals of the editing system, which I designed and created, were to allow for seamless creation and editing of nodes, to ensure that graph errors were visible, and to automatically connect valid graphs at runtime.
It's very easy to add new nodes to the system, whether by prefabs or just by copying and renaming an existing node. Editor helpers clamp the XY position of each node to integer values, a design restriction to simplify alignment, so the designer can just point-click-drag a node into place and designate its connections, correcting corresponding nodes until the graph shows as valid.
When any node of the graph is selected, all nodes in the graph come into view, effectively entering Edit mode. In this mode, we see green or red arrows in each direction for each node in the graph, indicating whether there is an outbound connection in that direction for that node. For the graph to be valid, all nodes with outgoing connections must be matched by another node.
Clicking on the red or green arrow indicators causes the status of the outbound connection to change. Here we see that the lowest center node has had its left connection removed by a mouse click to the left side arrow.
With the connection no longer valid, it does not appear at runtime. If it were valid, there would be a blue line connecting the lowest left node and the lowest center node.
After moving the node into place and configuring its connections, the graph is back to working. The hacker will stop at each node unless the player is holding their directional stick in a valid direction, in which case movement is seamless.
Still in Edit mode, the level designer can see right away that the graph is invalid. The node at the left, which has an outbound connection to the right, can tell that the node it would next hit does not have a suitable left outbound connection, and so the connection indicator there shows up red to warn the designer. The game can still be run at this point, but no connection will appear there for the hacker to traverse. Without this tool, the designer would have to undergo some tedium to find and correct the missing connection in both nodes' inspectors.
In spring 2013, a group of us decided to test our abilities by creating a 2D BSP room splitter for a procedural tile-based dungeon generator.
The requirements were that each partition needed to contain a room of randomized size and position, and that each partition needed to be connected by exactly one corridor, but corridors had to have at least a one-tile gap between all rooms along its length. Corridors could be connected either to rooms or to other corridors. The idea was to create a dungeon in which each room was connected, and in which there were no loops.
The challenge was to generate 1024 partitions and rooms, and connect them with corridors, in 30 seconds or less (on "fairly common hardware"). We had one week.
Mine creates and connects 3500 rooms in less than 500 milliseconds. Hardware specs are shown in the screen shots.
My dungeon space is 500x500 tiles to allow for all of the splits. I'm going to execute 14 splits to maximize the splitting capacities. In a perfect world, 14 splits would create 16,384 partitions, but because there is a minimum room size, the final two splits operate on only the largest of the remaining partitions.
When I click Do All, the space is partitioned and rooms are generated. As you can see, we've generated about 3600 rooms. The rooms are indicated by the green boxes. The lines dividing them are red for the most recently created partitions, and blue for all higher-level partitions. Note the first partition, the horizontal line just above the vertical middle of the dungeon, dividing the whole space into two pieces.
Corridor generation requires a lot of state testing, so it's much more computationally expensive, and it's where brute force algorithms push over the 30 second time limit. But by applying some optimizations and making use of some hashtable-based data structures for determining candidacy when creating partition connections, my C# code running in Unity on my laptop connects all the partitions in less than half a second.
This early foray into game development started out more ambitious than it ended, but it's still cool enough to show off.
I wanted to create a game that adapted itself to the player's style on the fly. What I wound up with is similar to a roguelike in that the more the player explores, the greater the danger, and the greater the rewards. But unlike a roguelike, in which the dungeon is created before the player can start playing it, this game creates its dungeons on the fly as the player explores.
When the player has explored a certain number of rooms, the next room they explore is automatically the boss fight. The boss moves in a fully random direction, occasionally spawns a Death Mask or three skeletons, and fires a continuous stream of projectiles at the player's position. It is vulnerable only to magic, which the player can regain either over time, or by picking up dropped potions from defeated enemies. Life potions can be dropped as well.
Rooms are created from templates that contain their block positions. Enemies and treasure are placed in the room at any position. This occasionally creates some unpolished output, but the player's magic fireball can destroy blocks (temporarily), and constantly recharges (slowly). The player never has to worry about being trapped.
The hallmarks of the roguelike dungeon crawl are that there monsters to fight, doors to unlock (and keys to unlock them), and treasure to find. Here we see our protagonist using his magic fireball against a Death Mask (his sword is useless against them), and encountering a locked corridor, but with no key to get through.
There are three types of enemies with the most rudimentary AI imaginable: Death Masks, which remain stationary for a moment before starting to chase directly after the player's position, ignoring obstacles; Skeletons, which walk in random directions until they hit an obstacle (and then change to a different, valid random direction), and Gargoyle Turrets, which fire projectiles at the player's position. Each room "buys" enemies at random, with skeletons costing 1 point, Death Masks 2, and Gargoyle Turrets 3. The number of points available to a room increases with each room explored.
The in-game minimap shows explored rooms and connections (black for open, red for locked), and shows exits into unexplored areas. Any space where there is neither a room nor any connection into it have not yet been generated.
How do you create locked doors in a dungeon where the rooms connected by that door aren't created at the same time? Simple - when the room is created and the state of its exits is determined, future rooms that are created adjacent to it already know what their own doors have to look like. But what about keys? Again, not a problem. Keys are quietly placed into created but unexplored rooms when a locked door is created. This means that there will always be a key for each door. Besides, it's very likely that the player won't need a key to access a room with one locked side, because they will probably be able to get to it from another direction if they keep exploring.
A quick one-week experimental project for GameMaker 8.1, this game uses an external visual editor to generate object creation scripts for a level framework. Both the game and the editor were created within the timeframe.
In each level, the player must steer their ship around obstacles, catching the wind to accelerate ahead of the Baron's airships (no relation). "Catching the wind" translates mechanically into contacting a set of three flashing arrows. This causes the player's forward speed to increase, gaining a little bit of distance from the airships. Colliding with rocks will slow the player down. They have a limited number of cannonballs they can fire to eliminate rocks, and can pick up more as they go from random pickups, but mostly this game is all about reflexes (and course memorization).
It's admittedly not the most elegant solution to force the designer to copy and paste GML. It would have been more professional to have the editor write to a file and have a GML script to interpret its format. But it does work - and took less time to implement.
Since the point of this entry is to show off the level editor, we'll get straight to it. It's a simple WinForms application that lets the user point-and-click to place obstacles and acceleration zones. Each division represents one screen length. Note the distinctive pattern of the rocks placed here - we'll be seeing it in-game shortly.
Remember that distinctive rock pattern above, with the accelerator just above it?
Once the level designer is satisfied, they use the Export button to create GML script that describes what objects to place where in the level. They then place this script into that of the corresponding level, which is then acquired by the game controller when the room is created.
