Sword Bros Postmortem: Making a Small Physics-Based Fighting Game
This is a 40 minute talk I gave with Mike Ambrogi Primo at the Philly Game Mechanics meetup on 12/7/17. It details the design and development process of the physics-based sword fighting game Sword Bros. Video/slide links and a slightly expanded article version are below.
talk slides (static .pdf)
talk slides (animated .pptx)
art sidebar slides (static .pdf)
Sections
- What is Sword Bros?
- Development Timeline
- Mike’s Art Sidebar & Restaurant (some notes on the game art)
- Building the Core Physics-Based Sword Controller
- The Fantasy of Sword Physics
- Sword controls work… what now? (Yomi, RPS, and Fighting Games)
- I’m a way better dev now. I should (NOT) start over
What is Sword Bros?
Sword Bros is a small local multiplayer game built around the vision of “physics-based sword fighting”.
Here’s the trailer:
Development Timeline
2013: Bennett Foddy’s Get on Top is released as a hidden game within Sportsfriends, showing that physics-based 1v1 games can also be competitively deep and super fun.
6/25/15: Development begins in Unity on “Sword Puppet,” with the core vision “physics-based sword fighting game.”
The game is ugly and barely playable, but just moving the sword with the joystick is fun enough to justify continuing.
7/6/15: I switch from Unity to Flint (the internal Final Form Games engine used to make Jamestown+), primarily due to familiarity. On a whim, I add the ability to slice things in half. The effect is purely visual, but it was satisfying, flavorful, and exciting enough to convince me that the game was worth pursuing as a full-scale project. Tim Ambrogi Saxon told me (accurately) that I should make it multiplayer, and that was that.
7/9/15: With that direction and core feel established, development started moving fast. Just three days after the initial Flint sword movement port, we demoed a first prototype at Philly Dev Night (now Philly Game Mechanics).
August 2015: By the end of the summer, core gameplay was largely implemented and polished.
October 2015: Soon after, the game was essentially “complete”, with final art, music, and sounds.
November 2017: Two years later, the game finally released. Part of that delay was due to me being in college and having other work, but there are also lots of changes and refinements that make the game play far better.
Read on to learn about:
- The thinking and tech behind the art
- Building the core physics-based sword controller (technical design)
- The fantasy of sword physics (technical design)
- Physics-based fighting game design (design)
- How I used the time between 2015 (feature complete) and 2017 (release)
Mike’s Art Sidebar & Restaurant (some notes on the game art)
Mike Ambrogi Primo is the artist on Sword Bros (follow @mikeambrogi he’s super cool). In this segment/mini-talk he discusses primary goals for game art, the Sword Bros art process, and the Photoshop export system he used to create tiles for our terrain geometry skinning system.
Art Sidebar video (Twitch VOD starting at 30m30s)
Mike’s Art Sidebar & Restaurant (slides - static .pdf)
I’m semi-famous for being long-winded and I only have a few minutes here so I’m going to break tradition, scope everything down, and focus on one very narrow, specific thing, so we actually have time to get to the bottom of it.
Okay.
Drew was well along into what would become Sword Bros. when it started to look like a real thing that could benefit from the injection of art assets. Tim and I agreed to offer him one workday of my time to generate as much art as I possibly could.
Six hours isn’t a lot so, believe it or not, I focused on answering that question: WHY HAVE ART? The answers would dictate what I focused on doing well vs. just doing at all.
The game was already reasonably clear gameplay-wise when it was still vector art. Whenever you punt your prototype art and replace it with something new, you need to be mindful that you don’t sacrifice any Clarity at the altar of Appeal. It’s very easy to misunderstand what your protoype art was actually doing really well until after it’s gone. Plenty of games emerge from this process prettier, but harder to read. And you need to come out ahead on BOTH fronts, or else you wasted your time.
Appeal is the aggregate effect of countless aesthetic factors, but you know it when you see it. There are a million ways to generate appeal, and a trillion ways to miss the mark. Specificity helps. It’s a gut check: get players to say “More, please!” instead of “No, thanks.”
Specificity is the difference between memorable and forgettable. Generic artwork can be very pretty, but still pass through your audience’s brain without leaving a mark. Imbuing your art with character and specificity is kind of like covering it with grappling hooks and razor blades and flamethrowers. You want it to leave a mark.
So this is what I was up against. The constraints were a great help in keeping scope down. I knew we couldn’t give the character arms or animated legs, for example. I knew the character had to be a single sprite so the slice-in-half feature would work. I knew the terrain was going to be tile-filled polygons with procedurally arranged tile hulls. I knew we needed a bunch of characters with clear team-membership tells. And I knew it was a swordfighting game.
So I did what I always do, and what I think everyone else should also always do: bring a screenshot into Photoshop, create some new layers, and paint a mockup.
Mockups let you move quickly as an artist, and try lots of ideas without involving programmers in your iteration loops.
You can see me wending my way towards a sort of rival scottish clans concept, which appealed to me because it was both a) silly and b) obvious. Obvious ideas may not make you feel particularly clever, but they give you a leg up on clarity and time was short so I went for it.
Some of you may be wondering why that dude is wearing a hat.
That is a question for Drew, who returned from a long weekend bender having implemented a hat and sunglasses selection screen. This screen did not survive to ship.
This is an atlas of all the art assets in Sword Bros, just to give a 10,000 foot view of what 6 hours bought us.
The last thing I want to show is this photoshop file where I worked up the tiles for what we call the geomasses. These are the arbitrarily-shaped pieces of geometry the level terrain is composed of.
First I gridded the file off into tiles and figured out the schema of every class of tile I’d need: floors, walls, ceilings, edges, and angles (which I did a stairway treatment for).
Then I laid them out and worked on solving all the seamless tiling cases. This required a lot of export/integrate/test loops, so I used the slicing and Save For Web features in Photoshop to make the whole thing essentially a pushbutton operation.
This is civilization. Like, you can give every slice its own name right in your file, then you just export, drag into your asset folder, build and run. Any of you who are working on game art in Photoshop, I strongly suggest you do this.
Thanks!
(Reminder to follow Mike on Twitter at @mikeambrogi he’s super cool! Also, for comparison, here’s the paintover again alongside some of the completed levels. - Drew)
Building the Core Physics-Based Sword Controller
Drew here again, now returning to design/tech stuff!
The entire game was imagined and built around a core control system where your sword follows your joystick movements (“swing the joystick to swing the sword”).
The sword control system was built with four core constraints in mind:
I started tackling these in order.
A and B were solved with straightforward rigid body physics simulation. Flint (the engine I was using) has Box2d built in, so I used that.
Using simulated physics meant all sword control had to happen through applied forces. I used a PID controller, which sounds fancy which but basically means:
However, testing quickly revealed some fundamental conflicts between these core constraints:
My solutions to these conflicts is to make the player’s hands much more controlled, and the sword blade/tip more physics-driven. More specifically, I solved the conflicts with the following changes:
A/C (Respecting collisions while also following the joystick, which doesn’t respect collisions):
Make the sword balance in the hilt/hands, and give it high mass relative to moment. When the sword is hit, the sword blade will be knocked back, but it will rotate more than it translates, and keep the player’s hands pointing where the joystick is pointing.
B/D (Showing weight (inertia) but also responding immediately to input):
Make the sword translation (which is now centered in the hands) respond fast, and make the blade rotation respond more slowly.
These solutions are summarized in a single section here, but in reality they were discovered and integrated at different points over a period of multiple weeks. The first couple of weeks were dedicated mainly to this system, and the later conflict solutions came about while I was working on other features.
The Fantasy of Sword Physics
After a month or so of development the sword controls were feeling pretty good, but the fights didn’t feel like the sword fights I imagined. I wanted fights that felt clear, almost choreographed. I wanted sword hits to be distinct, either to have a clear “winner” or to be a tense tie (with a winner at the end). Instead, the physics engine gave me two swords bumping/rubbing against each other and hitting both players equally. Even if this was technically realistic, it felt mushy and unexciting.
My solution was to dynamically make a sword 5x-10x heavier when it is doing a “big” swing - when the sword is moving faster, when the joystick is rotating continuously in the same direction, when the joystick angle is far away from the sword angle (“pushing harder”), and so on. When the sword weights filling such a wide range, it’s much less likely that two swords will cancel out when colliding, unless they’re the matching swings necessary for a sword lock.
This is just one example of the countless hand-tuned adjustments and special cases that drive the sword controller system. In all, the system is around 800 lines of code, driven by the following 20 primary tuning variables and a further ~20 hardcoded values scattered throughout.
Sword controls work… what now? (Yomi, RPS, and Fighting Games)
With the core physics controls working, it was time to focus on building an actual strategic fighting game around them.
A central concept in fighting games is “Yomi,” which basically describes the amount of second-guessing and counter-moves that happen during play.
“Yomi” is the Japanese word for “reading,” as in reading the mind of the opponent.
If you have a powerful move and use it against an unskilled opponent, I call that Yomi Layer 0, meaning neither player is even bothering with trying to know what the opponent will do.
At Layer 1, your opponent does the counter to your move because they expect it.
At Layer 2, you do the counter to their counter.
At Layer 3, they do the counter to that.
- David Sirlin, Balancing Multiplayer Games
In traditional fighting game design, the designer builds up a network of moves and counter-moves for the players to intelligently choose between:
Physics games are kind of the opposite - you start with a practically infinite number of “moves,” which probably aren’t balanced. More-powerful and less-powerful moves aren’t necessarily a bad thing - in fact, they’re a big part of what makes these games interesting - but they become an issue when they unbalance the game as a whole. The Magic: The Gathering Banned and Restricted List has a good explanation of this: “Cards are usually banned from play if they enable a deck or play style that heavily skews the play environment. What does that mean? If the card were legal, a competitive player either must be playing it, or must be specifically targeting it with his or her own strategies.” Such a card/move drastically narrows the field of viable options. (This is further explained in the article Skullclamp, We Hardly Knew Ye).
Making a physics game is largely a process of balancing such game-breaking moves. Balancing is much difficult though, due to the interconnectedness of the game’s mechanics and the lack of per-move damage/cost numbers to adjust. For instance, the “big swing” mass/moment adjustment system (detailed in The Fantasy of Sword Physics) made it so that continuously swinging the sword in circles was near-unbeatable, since then the sword would always have maximum mass/moment.
My solution had three parts.
First, I tuned the sword balance and control forces so that the tip of the sword was easier to deflect with a basic mid-sword block. Since continuous-swing players have less control over their attack timing and sword angle, they’re easier to get good blocks against. This made those blocks far more effective.
Second, I tuned the mass adjustment system to max out on a typical 180 degree swing.
Finally, I adjusted the sword anchor point. Previously the sword swung in a circle around the character. In the final version, the sword swings in an ellipse centered just below the character. This makes continuous-swing players much more vulnerable during the lower and back portions of the swing, among other benefits.
Despite the challenge of balancing, I think there’s a real value in building a competitive game around physics systems. Frank Lantz’s “Nothing Beats Rock” (elaborated on in linked articles and in “Life and Death and Middle Pair”) describes a form of yomi for Rock, Paper, Scissors:
“There are noticeable patterns based on the outcome of the previous round – there is a slight tendency to keep the same move after winning, and to pick a new move after losing (win-stay/lose-shift).
My real goal is to efficiently discover what I’m up against – a complete fish who always plays rock, a standard donkey playing w-s/l-s, a medium sized shark playing w-s/l-s’ or a killer with the capacity of identifying my own gear-changing strategy and adapting to me.”
Basically, player tendencies create an additional layer of prediction and second-guessing that’s based in knowing your opponent and understanding your own play style. Players may use “worse” strategies, based on the knowledge that those strategies will counter their opponent’s tendencies. Physics controls play into this perfectly. The difficulty of balancing moves becomes less important when we recognize that players may rationally choose weak moves. At the same time, the impossibility of executing a move perfectly creates an additional place where players’ individuality comes out in play. For instance a friend of mine could swing the sword faster counter-clockwise than clockwise, due to some aspect of how his hands worked, and that created a unique dynamic to all our matches.
I’m a way better dev now. I should (NOT) start over
When working on long-term projects, it’s common to feel like you should redo all your early work using your new skills. Sword Bros was feature complete when I was midway through college and released over two years later, after I’d graduated, so this feeling was especially strong.
The best approach is to work on the places where your time will have the biggest impact (which is hard to predict, but not impossible). I didn’t always do the best job of this, and I’d like to give some examples of features that were and weren’t good uses of my time.
I’ll start with the good choices: things that took little time/energy, and had big impacts.
One good time allotment was reconsidering health totals, and changing them from 2 hits (6 health; full hit does 3 damage) to 4 hits.
For the vast majority of development, players could take 2 hits. This was meant to make every hit count as much as possible, while enabling both even-ground and advantage-disadvantage scenarios (it’s fun to come back from losing). Towards the end of development I was testing with more low-skill players. These players mostly just enjoyed hitting each other with physics swords, and the frequent round endings were .
Doubling the health totals to 4 hits took just a few seconds, largely kept the every-hit-matters feel, and significantly improved the game for low-skill players. As a bonus, it also deepened the advantage-disadvantage spectrum for advanced players, and created the possibility of tanking a hit in order to gain an advantageous position.
A second, more subtle change was that I changed the sword attach point from the center of the body to just below the body. This also took under five minutes, and added a whole new strategic dimension to combat. Also, it looks much more natural.
Polishing the movement code was another good use of time. While it took more time than the health and attach point changes, I was just improving what was already there, so it was still a relatively small allocation of resources.
I designed the movement system to let players freely move around the arena, allowing players to climb walls and air-jump in any direction for any distance. Unfortunately, while it was fully functional, it had some issues. Below is a gif from October 2015 in which I perform a basic jump to wall jump. As you can see, the wall clinging creates an annoying stop when the player hits the wall, and the full-directional/distance jump controls make it difficult to reliably control the wall jump.
Between then and release, I added a number of special cases and tuning variables to the movement system, such as making the player maintain speed when jumping into a wall and holding the same direction, aligning to standard jump vectors when the player is close to them, and maintaining jump velocity even when the player steers in the opposite direction. As you can see below, the same move is now much easier and better-feeling to execute.
I’ll talk now about some less-optimal allocations of time.
The first was a single-player mode. Over the course of development, I wrote three basic single-player modes, one authored story mode and two roguelikes. None of them was anywhere near as good as the multiplayer. I’d designed the combat around player-player interactions, and it lost much of its depth when the other players became AIs. I’m still confident that a single-player mode could be good, but in order to match the multiplayer it would have to be an entire new project worth of work. I’d still like to make a single-player game based on these mechanics, but it’ll have to be a separate game.
Another example is my attempts to rewrite the sword controller. My first version of the sword controller was hundreds of lines of special cases. Now that I’d found solutions to the core design issues, I figured I could rewrite the system to implement those solutions directly, and get both cleaner code and maximally straightforward controls. However, despite solving all of the “main issues,” all of these rewrites felt far worse than the original. I’d forgotten how many days and weeks of tuning had gone into the original controller, and that those all the special cases were part of that tuning. The sword controller accounted for countless subtle values (e.g. physical resistance of the typical joystick). These would be impossible to “design” using pure logic, and could only result from long tuning processes.
Aaand that’s the article. Thanks for reading!
Huge thanks to everyone who worked on the game with me and who made it possible:
Tim Ambrogi Saxon - Engine, Additional Design/Guidance, Sounds
Mike Ambrogi Primo - Art, Additional Design/Guidance
Francisco Cerda - Music
Philly Game Forge - Support and Testing
Huge thanks also to Mike Ambrogi Primo and Jake O’Brien for organizing the event
and to Philly Game Mechanics for hosting!
You can find me on Twitter at @_drew_wallace.