difficulties and peculiarities during development or why are indie fighting games rare?
Since childhood and starting with PS1 I loved fighting games, and it so happened that I became a game developer. Often, to test technologies or just for fun, I develop pet projects. Naturally, I could not ignore such a genre as fighting games. Here On dtf I wrote about development.
The fighting game genre is specific and difficult to develop. For example, on PC there are one or two fighting games in a realistic setting, one of them is Undisputed on Unity. The game looks beautiful, but unfortunately, due to poor network code, it does not allow you to enjoy the process. Often, the player misses “phantom” hits when he has already moved away from the enemy. With arcade fighting games, things are better, the niche is firmly occupied by MK, SF, Tekken and several other less popular games. So what is the reason that, with relatively little competition, small studios or indies do not release fighting games? Why, apart from large studios and development teams (Capcom, Namco, Arc System Works, Team Ninja), there are practically no fighting games? Let's try to answer this question and expand on the topic.
While there are many ready-made solutions and assets for other genres, the path of developing fighting games is thorny and non-trivial. The network code for fighting games is specific and complex, as everything changes very quickly, and the classic techniques used in shooters to combat lag work poorly here.
Fighting games typically use p2p connections and only exchange input between players. Everything else is calculated locally and synchronized via determinism.
Determinism is the idea that repeating a given action with the same initial condition will always produce the same result.
Andrea “Jens” Demetrio
And here the first difficulties arise for indies. Which engine to choose for developing a fighting game? The most popular indie engine, Unity, is not deterministic “out of the box” (like UE, Godot). If you implement network interaction on Unity and exchange only input, the result will be different for clients. The gold standard in developing fighting games is considered to be network code rollback and the GGPO library. The principle of network code rollback is that we predict the enemy's input, perform actions based on the prediction, and if they were erroneous (after receiving the input), we roll back to the correct actions. Although the rollback sounds scary, it happens quickly, and the player does not notice delays and the actual “rollback”. There is also a Delay-based solution, but it works worse and is not as responsive as network code rollback.
So why can't we just install GGPO on Unity and create the fighting game of our dreams? The answer is simple: GGPO is not adapted for Unity and doesn't even have a stable C# version. Even if you manage to port GGPO, Unity's physics are not deterministic, and you'll have to replace it with another solution and use Unity only for rendering (it's worth noting that the physics in the ECS package is declared as deterministic). In addition, the network part of fighting game development is not the only obstacle: input, animations, characters, balance, etc. For example, you can't just use Unity Animator and be happy, because it is not flexible, it is not reusable, and guess what? The animator is not deterministic. For animation, you will have to use the animator API to manually control the animations.
It's worth mentioning that there is a UFE 2 asset for Unity that uses rollback netcode and allows you to create a fighting game, but:
Uses legacy Photon PUN
Horrible source code and scripts under 2k lines of code
The cost of the source code is $500
Poor optimization
I've dealt with this solution and even tried to use it for my pet fighting game, but it completely killed the desire to work and caused an attack of procrastination.
Which path did I take and what did I end up with?
The first thing I did after the solution was frozen on UFE was to try to write my own solution similar to GGPO:
I quickly realized that this decision would take me many months of development, debugging, and optimization. Network games are hard to debug, and are only fun for the first few days. On the plus side, I got a better understanding of rollback and tried Photon Fusion, which was used for synchronization.
The second and currently relevant solution is to use Photon Quantum for Unity. Quantum is a wonderful ECS network library that uses rollback, is deterministic by default and implements its own physics. I have made decent progress in the Quantum solution, although I do pet in my free time. ECS allows you to effectively structure the logic, separate it from the presentation and get good performance as a result. For animations, the Playables API is used, which allows flexible control of animation timing. In fact, the animation is played on the Quantum side, and Unity Playables is used only for rendering. The entry threshold for Quantum is high due to the small number of training materials, paid examples and relatively low prevalence.
Upon completion of the development, I plan to distribute the solution as an asset that can be used not only for fighting games but also for any other 3D battles. With a convenient API, UI for settings and a convenient shell around Quantum. In theory, this solution will open up access for indies to the development of new genres.
