top of page

Spinning Top Prototype

A multiplayer physics-based combat game that pits players against each other. Position yourself well and manage constant propulsion to win.

Development Time: 3 weeks full time (10 weeks part time)

Team Size: Solo                               Role: Gameplay & Technical Design

Tech: Unreal Engine 5, Blueprints (Visual Scripting), Draw.io

Prototype Outline

During childhood I was fond of early 2000's Beyblade games. Despite this, I believe they overemphasize the player's fight to disrupt the inertia of constant circular momentum. As a player, this felt like a loss of agency. This project was for me to learn more about the design of technical gameplay & controls. While also providing alternative gameplay systems & mechanics to the genre.

-  Use the player fantasy of controlling a spinning top to design intuitive controls & game feel.

​

-  Find the fun in players battling the inertia of a spinning top in motion.

-  Players should be able to express skill through the use of timing & positioning.

​

-  Use abstracted & simplified physics to facilitate gameplay interactions.

V1.png

Gamepad & Keyboard Controls

Character Movement = Left Joystick / WASD

Ability - Flip Direction = Bottom Face Button (A on Xbox) / Space Bar

Designing a System for Physics-based Combat

After dissecting many of the games in this niche, I noticed they tend to only have one passive force layer. Player input is then used to accelerate and change the trajectory of the base force. My proposition is that this is why I felt a decreased sense of player agency.

​

In an attempt to explore another method, this prototype uses two main layers of physics being applied, one for the passive rotation and another layered on top in whatever direction the player inputs. Using this setup I was able to more precisely assign the player agency over where they move and their movement force while still maintaining the fight with inertia that is at the core of the experience. As for which method feels better, that would be for players to determine.

Key-Based Passive Movement

For the design of the passive physics I went through a few iterations, but found the most success by building a circle around a central actor and putting keys along its circumference. The player's passive force can then aim towards the next closest circle even if the player's input disrupts that. To make a design without hitches, an outer circle takes over if a player is too close to the center.

Player Interactions + Hit Direction Tool

Part of the development process required some simplistic tools, such as the one below. The center point of registered hits is denoted in yellow. From the center of the hit event a line is then drawn towards the root of each player's pawn. Having the directions available was useful in iterating on knockback strength & determining if players were knocked from the appropriate angle.

Using Input States As a Design Axis for Player Controls

Depending on how players input direction aligned with their pawn's direction to the next key, different input states were assigned. I designed it this way so that players movement could be stronger or weaker depending on if they went in the direction that "made sense" Incentivising players to follow momentum and continuing the management of the rotational force.

-  Abstracts & approximates some of the expected real life physics behaviors like killing momentum. Helps to further gamify controls.

InputStateObjects.thumb.JPG.5ade42f6d0be47b628f27b204ed35e8b.jpg
MovementInputBP.JPG

Determining Input States       (Embedded Graph - Right Click Mouse)

Part Selection & Stats (Rock-Paper-Scissors Balance (RPS))

Along with the player fantasy of how a physical spinning top should behave, another huge fantasy in the genre is players personalising their own unique style of playing the game through part customization. To accommodate this fantasy and learn more about systems design, I made a rudimentary but functional part selection system and had a first pass at balancing it.

​

A RPS approach was taken where there are 3 stats in a triangle relationship. Yet, because of the amount of parts, players can make amalgamations that don't entirely have absolute advantages over each other, just differing rates of effectiveness.

PartSelectionSC.JPG

Game Modes

Players first choose between different sized maps then later decide on teams. This could be 2v2, 1v1v1v1, or 1v3. Once in a match, the base of all game modes consists of round based play, best 2 out of 3. Players can also experience rounds end in a draw.

Battle / Combat  -  Main Game Mode

The main game mode is one of classic arena combat where players try to eliminate each other first. The win/loss conditions within a single round are; depletion of HP, depletion of Rotations, and being knocked out of the arena. (didn't make it into this release). A standard rule set for the genre.

image.thumb.jpeg.20d4c134b9642f7730748f6203676ef7.jpg

Capture The Flag  -  Ancillary Game Mode

Capture the flag was a secondary game mode added to incentivise an inverse pattern of player behavior. Instead of generally being rewarded for seeking each other out, this game mode asks players to prioritize avoidance. Although, in turns based upon who has possession of the flag.

More Script Examples

bottom of page