Gun To A SwordFight is a 1v1 topdown 2d couch game where each player controls a swordsman with the objective to kill the other. Each player can orient their blade to strike and parry their adversary. At any point, they can draw their gun to shoot the other player, however the projectiles can be parried back.
I am currently working on this game as a personal project, the idea was to make a simple but deep combat system, inspired by Eggnog+ and Towerfall Ascension, but from a topdown perspective.
The first version of the prototype was heavily physics-driven. Player movement and sword interactions were implemented using Unity’s rigidbody system in order to quickly test how momentum, collisions, and pushing could influence duels. This approach allowed rapid experimentation with the “feel” of combat and helped identify which interactions created interesting moments between players.
While this produced convincing physical interactions, it also introduced a lack of precision in sword control, which later led to changes in the weapon system.
In a top-down duel game, character orientation can quickly become confusing because players must manage both their movement direction and their facing direction. Unlike 2D side-view games, where the opponent is always left or right, the spatial relationship in a top-down environment is more complex.
To reduce cognitive load and improve readability, I implemented a system where both characters always face each other automatically. This ensures that players can focus on positioning and sword placement rather than managing character orientation.
A key goal of the prototype was to encourage players to engage rather than disengage. To support this, the movement system uses different maximum speeds depending on direction:
Forward movement is fastest
Side movement is moderate
Backward movement is slowest
This makes retreating less effective than advancing, creating a natural pressure that encourages players to maintain proximity and commit to exchanges.
The prototype uses the Unity Input System to support multiple players and controllers more easily. Input actions are separated from gameplay logic, allowing additional players to be added without modifying core scripts.
This structure was chosen to keep the prototype scalable and maintainable while testing multiplayer interactions.
At some point, I started having trouble handling the variables linked to the player within different scripts. To make it easier, I stored Character parameters such as movement speeds, attack values, and cooldowns as data using scriptable objects. This allows rapid iteration and balancing without modifying gameplay scripts or the variables in the inspector.
Using data-driven variables makes it easier to tweak combat feel and compare different configurations during testing.
Camera
There were a few problems the camera had to answer to.
Since the game needs the players to be able to react quickly to each other, the camera has to be close to them, so they can properly see.
However, since the game plays on a single camera, both players need to be visible at once, which might make it difficult if the map is too large.
To fix this, I implemented a camera that zooms in when players are close, and zooms out when apart.
The problem was that when it was zoomed in, it was hard for players to know where they were going, so I added a dynamic movement to the camera depending on the player's movement direction, which allowed players to look ahead when they were moving.
Here is a little preview of what it would look like :
The initial sword system relied on physics simulation to create natural interactions between blades.
I implemented a joystick-driven rotation system that allows players to directly control the sword’s orientation. Working with Unity’s rotation systems required handling angles relative to the player’s forward direction, which I debugged using custom Gizmos to visualize sword angles and attack zones in the editor.
While this produced interesting collisions, it made the weapon difficult to control precisely, as it is difficult for the player to know the exact angle at which a type of attack may trigger. There was also issues with physics interactions, which would sometimes jitter the sword out of place or make it move much faster than intended.
Although the current system allows analog control of the sword, this freedom makes combat harder to balance. In future iterations, I plan to experiment with a more constrained input system similar to Eggnog+, where the sword snaps to a small set of predefined angles.
If possible, I would like to reduce the amount of physics based interactions of the sword to a minimum. This approach would improve combat readability and make interactions more predictable while still preserving the core idea of player-driven sword positioning.
The prototype is currently on hold as other projects have taken priority. However, the project served as a valuable exploration of physics-driven melee systems and the challenges of translating the feel of 2D dueling games into a top-down environment.
Both Eggnog+ and Towerfall Ascension share a common design philosophy: a minimal input set that generates deep, readable, and highly replayable gameplay through the interaction of a small number of well-designed mechanics. In both games, the player is never overwhelmed by execution : the cognitive load is entirely dedicated to reading the opponent and making decisions.
This is the core principle driving this project's combat design. The goal is to create a system where both weapons serve distinct and complementary roles. The sword, borrowed from Eggnog+'s directional fighting where attack and parry share the same input, handles close-range reading. The gun, drawn from Towerfall's scarce ranged threat, introduces distance and positioning as a second layer of decision-making. . The sword is the primary tool, demanding constant close-range reading of the opponent; the gun is situational, introducing a ranged threat that forces both players to factor distance and positioning into every exchange. Together, they create a combat loop that is easy to enter, and difficult to master.
Eggnog+ is a minimalist 2D two-player fencing game developed by Madgarden, inspired by Nidhogg. Players must kill each other and reach the far end of the playing area to win.
The game is built on very simple controls, yet manages to create intense duels through a few key systemic decisions that generate depth without complex inputs or large movesets.
Simplicity of Inputs
The inputs are the key to what makes Eggnog+ deep despite its simplicity. The player has very few attack options; a single input triggers the attack, directed by two factors:
Sword orientation : three positions (up / middle / down) that define the angle of the attack
Input length : the player can either attack in front of them, or throw their sword
Sword orientation doesn't only influence attack direction; it also dictates parrying. When the defender holds the same directional input as the attacker, they parry. If they don't, they are briefly stunned, giving the attacker an opening to kill them.
This completely shifts the player's focus. At first, they throw attacks around freely and are still satisfied by the instant feedback. It's easy to attack, easy to parry, easy to score a kill, and not very punishing to fail.
The player also quickly learns to fear the opponent's blade, even a simple contact with its tip is lethal. This naturally draws attention to the enemy's sword position and encourages matching it, which produces parrying almost instinctively.
From Execution to Prediction
Once the basic principles click, the game becomes a series of quick rock/paper/scissors exchanges where the focus shifts to predicting the opponent's next move rather than executing a complex sequence. Will they throw their sword? Will they dive and attack from behind? The player starts questioning the enemy's intentions rather than managing their own execution. With almost no mechanical difficulty, mental bandwidth is freed entirely for reading the opponent.
Game Feel & Advanced Play
The similarity to real swordfighting also plays a key role in how the game feels. Blades don't collide directly, only the sword hand guard blocks the opponent's blade. More advanced players can use sword locking to control the fight, forcing both players to be mindful of sword positioning and movement. The fact that blades pass through each other also pulls players physically closer together, creating tension.
What I'm Taking Into My Game
I want sword fighting to be the main focus of the game, so the core mechanics should reflect that. Swords should feel threatening yet easy to use, arcade in feel, but grounded enough to evoke real swordfighting.
From Eggnog+, I intend to carry forward four specific elements:
Input simplicity : keeping execution demands low so the player's mental bandwidth is entirely dedicated to reading the opponent, not managing their own actions.
Directional attacks : giving attacks an angle creates meaningful asymmetry between exchanges, rewarding spatial awareness without adding complexity.
Blocking and parrying synchronised with direction : tying defence to the same input as offence keeps the control scheme minimal while creating a natural read-or-commit dynamic.
The sword hand guard as the only colliding factor : forcing players to fight in close proximity, raising the tension of every exchange and grounding the combat in something that feels physically real.
The main challenge will be converting thrusting attacks into slicing attacks within a top-down format.
Towerfall Ascension is a local multiplayer archery game where players fight in small arenas with a single tool: a bow with a limited supply of arrows. One hit kills. What makes it stand out is how much strategic depth it wrings out of that scarcity.
The inputs are just as simple as Eggnog+, if not simpler. Yet every mechanic communicates clearly with the others, creating a system where depth emerges entirely from interaction rather than complexity.
Interconnected Mechanics
The player has a limited amount of ammo, each arrow capable of one-shotting the opponent. Scarcity immediately gives every shot weight, firing is a commitment, not a reflex.
When out of ammo, players can still kill by jumping on the opponent's head. Running dry is never a death sentence; it shifts the game into a more aggressive close-range mode, keeping both players active and threatening.
The dash ties everything together. It can be used to escape, to reposition for a headjump, to steal ammo on contact, or to intercept an arrow mid-flight. This makes closing the distance highly strategic but equally risky if it fails due to the cooldown. Every dash is a read of the situation, not just a movement tool.
All these mechanics are bound to the layout of the map. In Towerfall, the arena is never neutral ; walls create cover, platforms control sightlines, and chokepoints dictate where arrows and opponents can come from. Map awareness isn't a separate skill; it's the context in which every other decision is made.
What I'm Taking Into My Game
The core idea is to shift the ranged weapon into a more situational role, a complement to sword fighting but not a dominant strategy that replaces it. The gun should be used to finish a vulnerable opponent or bait an attack, never to dominate an exchange on its own.
From Towerfall, I intend to carry forward:
Limited ammo : each shot must feel like a decision
Ammo stealing : changed into the ability to send a projectile back, rewarding positioning and timing
Dash : used to escape, reposition, projectile dodging or to aggressively close the gap with the other player.
Slight projectile auto-aim : keeping the ranged option accessible without demanding precise execution
Map awareness : the sword can collide with walls, temporarily stunning the player or blocking projectiles, making spatial awareness a core part of the fighting game loop