I've tested this, and personally, I'm not a fan.

The issue with everything filling the exact same amount of the gauge is that it really encourages otherwise useless strategies, and discourages core mechanics. Once your opponent goes down, why ever both firing a fully-charged energy beam? Instead, just spam a bunch of tiny energy bullets that do barely any damage, and it'll build up your special meter extremely quickly, letting you launch an attack afterwards.

If you want all of the characters to gain special meter at the same rate, but still be based off of how much damage you do, you could probably do some calculations using their actual stats. Like, find out how much damage one character does relative to their opponent, and apply that to the value of the special meter being gained. Or, each time damage is dealt, have a separate background calculation that applies damage as if both fighters had the exact same stats, and use the output of that to fill the special meter.

I think it would function best the way it used to, with more damaging attacks filling up the special meter more (more charged energy beam = more special meter gained), but still fill at the same rate for characters with 10 strength/speed/spirit or 1 strength/speed/spirit.

I launched a KI blast when Caulifla was in the middle of transforming. It hit her during her transformation, so as soon as the cutscene ended, she died. When Broly was automatically swapped in next, he had Caulifla's portrait. I'm not exactly sure if this even needs to be fixed, given how rare and situational it probably is.

Since I saw "Beta is closed and ready for the release." in the development page, I did some last-minute bug-testing, and noticed some issues with the "rocket" ability.

For the normal ability that replaces energy blasts, the one used by Major Metallitron, there's no sound effect for firing the rockets. It just copies whatever was the last sound effect played. For the special attack that Staff Officer Black has, the rocket doesn't actually seem to do any damage upon hitting the opponent. I've also noticed that they don't properly face the opponent when being used, and isn't deleted after exploding.

They weren't stunned, they were just in their default pose when I hit them. I'm not sure why they attacked, it could just be because the AI was still trying to fight me like normal as they clipped through the terrain.

It was not a dash. I jumped up above them, then used a normal "downward" attack as I fell.

I managed to reacreate the bug of players falling through the terrain. I'm not exactly sure what causes it, only that it happens sometimes when attacking a character while falling straight down on them, with no left or right momentum for either character.

Sorry if this isn't too helpful. Is there anything specific I should be testing for when trying to recreate it?

This is something I've noticed for a while now, but thought it had to be brought up with the changes being made to the new combat system, I've noticed it a lot while testing the new update. There's something weird going on with the computer fighters, they don't seem to play by the same rules as the player does.

First, is this: occasionally, seemingly at random, the AI will automatically get a hit of damage in when a melee clash begins. If this happens, not only with the player be hurt, but they will also proceed to fall after the clash, even if they won it.

As for why it happens, I have no clue, but I suspect it has something to do with how the AI is able to react instantly in order to hit the player, and dash instantly. With the player, to dash, you have to double-tap the button. So no matter how good of reaction time you have, there will always be some sort of lag in how fast you can dash attack, since the button has to be pressed, let go, and pressed again. The AI is able to do it instantly, however. I hope this isn't just me being bad at the game, but it does seem like they work on fundamentally different rules.

As an example. When the player attacks normally, they move slightly. If they hit the opponent like this, they don't deal any knockback. if the player dashes, effects play: a little circle effect plays, and dash lines cover the player. If they hit the opponent like this, they deal knockback damage.

However, the AI can do something different. When the AI attacks, they act as if they're attacking normally, doing an instant move towards the player, and they do not have the dash lines. However, the circle effect plays, and when they hit the player, they still do knockback. It's something in-between a normal attack and a dash attack, that combines the best of both types of attacks. It's effectively a dash attack, but it happens instantly like a normal attack, and it feels very unfair to fight against.

I've been trying to test the new combo system, but the fact that the AI does knockback every single time it hits, unlike the player, is making the system feel weirdly unbalanced.

I'll test other stuff like the recovery system soon when I have time, but I just want to say that I tested the newly implemented attack hit detection. It worked incredibly well, the entire thing functioned perfectly. Especially for characters who were given animations that properly corresponded with the attack directions. When the "backwards" attack animation actually attacks behind you, it can perfectly intercept an opponent sneaking up on you.

The best part was that, in almost all the cases, the attack was detected a few frames after the button is pressed, making all the hits feel much more snappy and immediate.

The biggest issue with the attacks are that lots of animations have the first half of the frames dedicated to extending, and the second half the frames dedicated to retracting, with only a few frames in the middle where the punch/kick/etc is fully outstretched. That's where the attack should be registered. Right now, they're registered at the very end, so if the animation is complex enough to return the fighter so their idle pose after they attack, then the attack is basically useless, since the hitbox of the attack doesn't end up extending out at all by the time it's registered (not to mention it takes ages for the attack to be registered).

Here's every idea that comes to mind:

One way it could work is just to have the attack be registered at the very start of the animation, rather than the end. That's how Devolution works, where the attack is registered as soon as the button is pressed. But that has the same issue as currently, just in reverse; the attack would still be useless if its animation starts from the idle pose and extends out.

Maybe have it be registered a few frames after the attack starts? So it would happen when most attacking animations are at their midpoint?

If you want to make things more complicated and have it be a case-by-case basis, either automatically or manually, one of these two options could work:

• Automatic: Check what frame of the attack animation has any non-transparent pixels furthest from the center/closest to the edge of the hitbox, and register the attack when that frame plays (if there's multiple, register the attack when it happens the first time). That way, the attack registers when (most likely) the fighter has a fully extended punch/kick/etc out.
• Manual: This would completely ruin old BASTON fighters and cause a rework of the fighter creator. But, each punch animation on a fighter could allow the creator to pick what frame of the animation the punch is registered on? It would default to the last frame, but they could change it somehow for each attack direction?

• After being hit, my character stays in their damaged animation and is pushed around by the attacker running into them (while the blood particles stay in place). The buttons don't really work, I have to spam the attack button and arrow keys to eventually get control of my character again.
• The characters don't actually seem to get knocked down into their death pose until they lose ALL of their health. I think that getting significantly hurt should make you fall down into the death pose and make it so you can't be interacted with for a moment until you get back up? That way it gives you some time to recover before things start happening again, kind of like invincibility frames. And it utilizes the stun/recover animation from the old characters.

Txori, I saw the site banner asking for feedback.

I'm sorry, I don't mean to complain or give you more work. But I'm just unsure WHAT feedback needs to be given. I've tried to scroll through the many scattered pages of BASTON development, trying to figure out what's being tested, what's already decided, what's undecided, and what needs to be figured out, but I can't understand it. It's too confusing and vague for me to understand.

If you compile some list of what exactly needs testing, and what questions you want answers to, I will test it all extensively and give you in-depth opinions on it.

For now, I just attempted to test the newest version, but I'm not sure what kind of feedback you're looking for. Here are the opinions that came to mine when testing it:
-When walking into a small gap on the worms map, the character bugs out and the camera jitters against the terrain as it tries and fails to fit through the gap.
-The camera shoots up to follow your character each time you jump. It gets a bit nauseating, maybe the camera needs to be adjusted somehow in its vertical movement?
-After being hit, my character stays in their damaged animation and is pushed around by the attacker running into them (while the blood particles stay in place). The buttons don't really work, I have to spam the attack button and arrow keys to eventually get control of my character again.
-The characters don't actually seem to get knocked down into their death pose until they lose ALL of their health. I think that getting significantly hurt should make you fall down into the death pose and make it so you can't be interacted with for a moment until you get back up? That way it gives you some time to recover before things start happening again, kind of like invincibility frames. And it utilizes the stun/recover animation from the old characters.

I think the automatic method works better, just because the player can't control everything they need to.

Manual method might be best with a joystick, but it doesn't work with arrow keys. The enemies aren't just approaching from the 4 cardinal directions, they can approach from any angle. If an enemy is approaching from a 45 degree angle, making the player choose a split-second decision whether an up-attack or a side-attack is more fitting isn't really fair or fun. Since the arrow keys can't account for every possible direction to attack, I think the engine should handle stuff on its own, and make adjustments as needed.

This issue is going to appear again once projectiles are added in. Even moreso than with close-range attacks, a player can't choose exactly what angle to fire a projectile using arrow keys, when the enemies are going to be approaching from diagonal directions. Nobody would ever land their attacks. In fact, I bet it'll be more likely for the AI to accidentally dodge into an attack and get hit, then get hit because the opponent aimed at them. I think, just like with the old BASTON and with Devolution, the engine should auto-aim unless the enemy gets behind you when you're charging up.

Personally, as a side-note, I do still think some sort of lock-on button to choose which enemy to face and focus on could be useful. Maybe pressing it could focus you on the closest character to you, and pressing it again could sequentially select further out for every character currently visible on screen? And if the targeted character went off-screen, it would give you a small arrow at the edge of your screen to let you know what direction your opponent is in? And maybe if you got attacked by some other character it could automatically shift to them instead? IDK, I'm just suggesting stuff.

Alright, I've done some testing, here's my feedback regarding the map tile sizes.

The smaller sizes, like size 1x1 or 2x2, definitely don't work. Each time you approach a 1-tile-tall ledge and automatically walk up it, the camera jerks around a bit, and the character loses all of their momentum. This was happening every fraction of a second while trying to run around in a size 1 map. The only reason to have smaller tile sizes is to make more detailed terrain, so this would be constantly happening on any sort of height-varied ground.

I think 8x8 tiles works the best. Playing with a standard-sized character, 8x8 allows characters to fall down 2-tile-wide holes, and run over 1-tile-wide holes, but still jump up 1-tile-wide holes from above, so they don't get trapped anywhere. It also allows them to fit in 2-tile-tall tunnels easily. The characters just seem the most well-built for this size of ground.

Besides, a smaller tile size will make it more difficult it will be for the average person to draw their own tiles and maps. The smaller the tiles are, the more tiles you have to draw in order to have an actually detailed-looking terrain. Since BASTON is all about accessible character creation, I think 8x8, the easiest to manage, is the best option.

When colliding with other players, it behaves in ways that... either don't seem correct, or don't seem like good design. You just keep jumping around and bouncing on them. Maybe they should only have horizontal collision, so you can't walk into each-other. But if you land on somebody from above, both characters would just push each-other out of the way, and if walls were stopping them from moving out of the way, they'd just overlap each-other like the old BASTON?

Also, maybe it's an option and I'm just missing it, but there's no windowed mode anymore, is there? It's forced into fullscreen whenever I play it. This makes it kind of difficult to give feedback, as I can't have the game open to test things at the same time as I'm typing something on this site.

Yet another Demon Slayer character, this time it's Gyutaro. I'm reasonably proud with how this one turned out, but I still do have stuff to add to it. I'm going to make Daki as complimentary character, but she (like a lot of these Demon Slayer characters so far, it seems) has a bunch of tentacles that she fights with. So it'll take a while to sprite her. When I do, I also plan on making a second form for Gyutaro, when he shares his eye with her. Since he doesn't look very different in that form, I'll need to make a ton of completely new poses to differentiate him.

Here's the character file:
https://www.txori.com/forum/doc/2/17414 … cairns.zip

Since you asked for feedback, here are some things I've noticed.

First of all, movement. I think this has the most issues in the current build. You added momentum to the running, so that you now build up to max speed. However, I've found that this makes platforming incredibly difficult. I don't think building up to max speed is an issue, but maybe the start of the build-up should already have some speed behind it, or build up quicker?

Secondly, the jump height, in my opinion, is far too high. A single jump is able to completely clear any obstacle not built on a massive scale. This can be easily seen in the "Mario 1-1" map from slightly older versions. It feels like it makes vertical mobility obsolete, as anything can be reached super easily. Double jumps just become excessive at that point. But because of the super high jumps, certain places just can't be reached now. Again in the "Mario 1-1" map, there's a horizontal underground tunnel that's raised one block up off of the ground to enter it. Even jumping the smallest amount possible, it's too high to fit in that tunnel. I've also noticed even characters without the ability to jump are still able to do so. I assume that's just for testing purposes currently, but I've already mentioned that I think the option to not let a character jump should be available.

About the HUD that's been added, there's a possible maximum of 32 fighters in a level. in "player VS AI" battles, I assume that you will still be able to see the opponents portraits and health, right? Displaying all members of the opponents team would obviously clutter up the screen. As such, I think some sort of "lock on" feature might be necessary, to focus on one opponent at a time (alongside the other benefits I've listed before, like backwards movement sprites and projectile aiming).

Finally, about the 32-fighter limit: in the old BASTON, you had the line of miniature characters waiting on either side of the arena, so you knew how many characters your team, and the opponents team, had. Now, though, there isn't any way to know that except for before you start the fight. And there's no way to switch between fighters on your team, like you could with the old BASTON. My suggestion is to re-use those "miniature characters" standing sprites, and maybe line them up like icons underneath the HP bar? Something like this?

If this isn't the kind of feedback you were looking for, I apologize.

I love this style! It kind of reminds me of the character designs from "Dragon Ball Z: Gekitō Tenkaichi Budōkai"! It would be awesome to see more characters in this style.

Txori, you mentioned figuring out aiming after you figured out jumping, which is fair. I just wanted to go over some more aiming-related issues since I just found out some during testing, for whenever it is addressed.

Using the arrow keys to aim is unintuitive like you said, especially since you already use the arrow keys to choose which projectile to fire. However, additionally, there are certain "instant projectiles" like lasers, bullets, glue, etc. Anything that doesn't have a charge time, and just fires instantly. It's impossible to aim these with the arrow keys. If it's set to the basic blast, than it will always fire forward, as pressing any direction would trigger a directional blast. If it's set to a directional blast, then it will always only fire in that direction, as pressing a different direction triggers a different directional blast. I think some auto-aiming might be necessary in the future (and could preserve walk/fly back sprites from old characters).

About the jump not allowing you to change directions, I think it might be a good idea to allow changing directions when bouncing off of a character using the "stomp" ability? Since it's sort of like landing for a second, and allows for more acrobatic characters.

Finally I played around with transforming characters. It seems like the transforming no longer centers the player by the bottom of their sprite. This means, if you power-up into a character who's smaller or larger than your current form, it will put them into the air or into the ground.

Oh, and while testing giant characters, I noticed that where the projectiles fire from are totally misaligned now. In the old BASTON, when characters got large, the alignment was off by a few pixels, but it seems even more exaggerated now.

It doesn't seem to work still. Upon clicking the "Versus" option, it closes the game after freezing for a few seconds.

EDIT: Okay, I was able to get it to work: I had to clear my data first. Now, my questions is: are we just testing for bugs and glitches and general game feedback, Txori, or are we allowed to make gameplay suggestions based on the current version? I know that you get annoyed by constant demands and "do this, do that" things, so I want to make sure I'm not doing something wrong.

That being said, here's a couple things I've noticed:

First of all, your character never actually aims towards the opponent, they just fire straight ahead. Personally, I think making some sort of "lock on" would make sense. You are already using the Z, X, C, S, and D keys, so perhaps the A key could work for this, to round out that set of keys. Something that would make your character constantly face a specific opponent, until they leave the visible screen. That way, walking backwards and flying backwards animations could also be preserved from the old characters, instead of you always turning around. Maybe it could lock onto the closest opponent in your characters field of view, and pressing the button again could lock onto the next furthest way, etc.

Second of all, about firing beams. I notice that they keep firing until they hit a wall. However, the player can move before the beam has disappeared. This leaves an awkward floating energy beam that lasts for a few seconds, if the beam doesn't hit anything until it goes out-of-bounds. However, the player character shouldn't be stationary until the beam finishes, as that could keep them in one place for far too long. Maybe, once the beam travels far enough offscreen, the beam trail should disappear when the player can move again? And only the beam head, the projectile, would keep moving.

Third, the jumping is always the exact same height, as opposed to the previous BASTON version where it depended on how long the button was held down for. I think variable jump heights are even more important when you have a platformer-type of game, with different kinds of terrain.

Txori, you mentioned that so far, nobody had offered any feedback to the current version of BASTON, so I will do that now.

I am unable to use the new version of Baston at all. Every time I try to load it, immediately upon clicking the "versus" button, the game crashes. For now, the entire game is a menu with two buttons, and a menu to assign controls. So there is nothing more I can comment on, and I am unable to reach any gameplay. The reason I did not offer feedback on this before is because of this post:

https://www.txori.com/forum/viewtopic.php?id=4693

When you mentioned BASTON "Crashing after versus screen" I assumed that the crash I was experiencing was entirely normal and would not be addressed. It confused me, but I didn't want to complain about it if it was something you were already aware of. Also, I wasn't sure exactly where to post feedback for the new BASTON. Unless I've missed something, every topic about the rebirth is either a bug report post, or is this thread, which is more of a development post. I suggest making a dedicated thread to BASTON feedback, unless this one can be used for that.

I have a question. I apologize if this feels like complaining or demanding, I'm just trying to raise a concern. If all fighters are now being forced to have at least a single jump, won't that mess with currently-existing fighters? It just feels like the character creation will become limiting.

I understand jumping being a requirement for a platformer, but sometimes a character is specifically designed so they aren't able to jump. Or, some characters are designed so that they can fly, but can't jump: they DO have an upward mobility option, but they are supposed to feel more like they can just move themselves anywhere. In both of these situations, forcing a jump onto the character would make the game lose important customization options, and might make characters feel more generic and similar. For example, one of the recently-created characters I made for BASTON is "Gyokko" from Demon Slayer. He absolutely wouldn't work if he was forced to jump. He even has a transformation which specifically gives him a jump and makes him more mobile.

BASTON is made entirely up of community-created characters, right? So if somebody is truly annoyed that the character they created can't jump... then they could just add a jump, right? I think users should have the option of making characters who can't jump. Sure, those characters couldn't do platforming, but that would be the creators choice. After all, the characters don't have to be balanced or fair. This isn't a global game with a competitive leaderboard. I think we should be allowed to make characters who won't work in all situations. I mean, if a character had to be able to navigate the entire stage, then everyone would need to be able to fly, right? Just like a character can be super overpowered (the One Punch ability for example), I think characters who are underpowered and limited are equally important.

Plus, if maps are community-created too, some people can just make flat maps that don't require jumping. Some people might specifically make flat maps for with their characters who can't jump, to be used in a custom story mode for example. I suppose I understand the logic that "jumping is much more necessary, so it shouldn't take up an entire power slot". But in that case, I think a "no jump" power should be added, so it's at least an option if the player WANTS to do it.