Bonjour. It’s been a good four months since my last attempt to get into game development. Let me remind you that I planned to rivet a couple of projects for my portfolio and get a job in a studio. The attempt was a failure. But I did not despair and today I am ready to present my new craft to the world. A copy of the game "Blazblue: Entropy Effect".
I rarely enter the field of roguelikes, and therefore “Entropy Effect” made a strong impression on me. I spent several evenings with great pleasure, throwing away packs of enemies with spectacular combos and enjoying the beautiful art style. And, charged with wonderful emotions, I decided to try to copy this fighting game roguelike.
I can’t draw from the word at all, and therefore decided to “borrow” sprites from an existing game. "Dengeki Bunko: Fighting Climax".
"Fighting Climax" is a fighting game featuring characters from visual novels published by Dengeki Bunko. And of all the many franchises represented in the game, I only knew “SAO”, and therefore took the characters from there.
As usual, I did a little research on the game and found out which elements I wanted to copy:
At this stage, the stuffy introduction ends and something much more fun begins – development.
Navigation
The character can walk left and right, crouch, jump and dash. The set of actions is quite typical and there were no interesting incidents during their creation. I would like to make a special mention only at the jump.
Let me remind you, I work in “Unity”, in which with the most standard implementation of a jump, applying an upward force to an object, this same jump turns out … “lunar”.
The object rises into https://noidverificationcasinos.co.uk/review/lucki-casino/ the air and falls to the ground at a uniform speed, which looks and feels strange. And the vast majority of tutorials suggest solving this problem by increasing either mass or gravity. And if I can still understand the first method for individual and obviously heavy objects, then the second method of “improving” the jump makes me dislike. Changing gravity for individual objects seems counterintuitive and wrong to me. There is a non-illusory chance to change the influence of the force of gravity for object “A” and forget to do the same with object “B” and then wonder: “Why does physics act on them differently?"In general, I decided for myself that I would improve the jump by influencing the acceleration of the object.
If an object falls, then the gravity vector is subtracted from the acceleration, multiplied by the falling speed multiplier and the time that passes between physics check cycles. As you rise into the air, the acceleration decreases linearly. Translated from Nerd to human: “When you rise, the speed decreases, when you fall, it increases.”.
Jumping has already begun to feel much smoother and more enjoyable. It would be possible to add a dependence of the jump height on the time of pressing the button and other “platformer” improvements, like “coyote time”, but I decided that my project is not about overcoming platforms and such things would be unnecessary, and moved on to the next element of the game.
Combo system
Unlike the navigation, the combo registration system really made me think about it. I had several options in my head for solving this problem:
Store the sequence of buttons pressed by the player and “substitute” it into attack templates. If the player’s sequence matches the sequence in the blank, then an attack occurs
Store the last action button pressed by the player and, at the moment the attack is completed, check whether this attack can be continued into the player’s chosen action?
After poring over this problem for several evenings, I came to a solution that combines all three of my ideas.
All possible combinations of character attacks are represented by a small graph. For convenience, I suggest calling the player’s actions peaks, and “flowing” from one action to another – ribs. Very complex terms, but with them it will be easier to explain how it all works.
Initially, this graph is in the “zero” position. The player has not yet chosen an action and the unit is standing on the ground. In this state, the graph has access to “basic” vertices that trigger combos. For example, the first attack in a series of three normal strikes. The player then decides to press the left mouse button and perform a normal attack. The graph runs over all base edges and checks the conditions for transition to the vertices of these edges. In our case, the transition will occur at a vertex whose conditions are “the unit is on the ground”, “the normal attack button is pressed”, “the unit is standing still/moving only horizontally”. If the required vertex is found, the graph moves to it, and the unit performs a normal attack. During the attack animation, the player can press the action button again. This action will go to the buffer. If at the end of the attack animation there is an action in the buffer, then running along the edges will be repeated. The only difference with the "zero" position of the graph will be the number of edges. There will be significantly fewer connections coming from the top than from “zero”. If the action buffer is empty, then the graph returns to the “zero” position.
The system turned out to be quite flexible and allows you to freely configure a large number of combos. This prototype does not smell of originality, and therefore I implemented only basic combos of three regular hits and transitions to individual skills. Also, as a nice bonus, there are attacks after the dash.
In addition to regular attacks and skills, you can also include support units in a combo.
The potential of supports is limitless. Dealing damage, stun enemies, healing the player, throwing buffs and debuffs. All this can be found in full-fledged games. In my prototype there is only one support that deals damage to enemies. I already had a system of customizable skills ready, and therefore the development of support units was a breeze. Except for one thing. Appearance and navigation.
I wanted the support to appear at a short distance from the player, run closer, strike and run off into the sunset. In theory it sounds simple, but in practice… No one wants a support to appear in the air when called on a platform, or vice versa in an abyss while jumping over it? So I thought so and decided to write a small algorithm that calculates the coordinates of a unit’s spawn. For six terrible hours I gave birth to such an algorithm.
Operating principle in a nutshell. When calling support, the algorithm finds the floor under the player. Then he begins to quietly check for the presence of the floor behind him. If the floor ends or the algorithm finds a wall, the unit’s spawn point becomes the penultimate verified point. If there are no walls or holes in the floor, then the support appears at a distance from the player.
It was quite difficult to make this whole mess of English letters work, but when it finally deigned to expand, and the player was able to call on additional damage to help himself… Mmmmm, my joy knew no end. However, during testing I noticed one unpleasant bug. Sometimes the support still appeared in the air.
I plan to become an “AAA” level programmer, so I ignored this bug and moved on to the next element of the game.
Bagel
The prototype had already started to take shape and "gameplay", but it still lacked variety. With which various rooms and modifiers happily agreed to help. I decided to start with the rooms.