So I've added stair climbing and global collisions between fighters. With that, I'm putting BASTON on hold, as I can't properly test it all by myself. I'll focus on finishing the new version of Dragon Ball Devolution instead.

Great work Txori, coding almost 3 times the game insure code improvement at each refactoring, positive aspect. What is the tech used for latest version ? Wish you the best for shipping release.

Thanks for the kind words, stereographik. The tech for BASTON is still HaxeFlixel.

Development is on hold for a few days since I can't properly test and tweak the gravity, speed, and force on my own. I've been working on this every day for the past month, and the only helpful feedback I've received was from Igna and Cairns, which makes things complicated. But next week, I'll have friends over, so I'll finally be able to play against someone, gather useful feedback, and make adjustments in order to continue 😉

Attends... Stereographik... C'est toi, François ? 😁

While waiting for testers to provide feedback, I'm programming little things, such as a button that can load a bitmapFont and center itself. The font is temporary, as it comes straight from the arcade game Marvel Super Heroes.

And I just tried playing with two computers using Parsec, it works flawlessly. but I CAN'T play alone against myself in order to see if it's fun or not. I need feedback.

Edit:
The size of bitmapFont buttons now automatically adapts to the size of the screen.

These past few weeks, I've been somewhat overloaded with obligations, so I haven't been able to test the latest version of the game in-depth, but I did notice some areas where it could be improved:

1. Second Player Controls:
- The second player's jump button is bound to the first player's punch button, and it's not possible to configure it with another button.
- The jumping system requires multiple presses to execute, giving a feeling of lack of responsiveness.

2. Pushback Mechanics:
- When tackling or punching characters, they are sometimes thrown excessively or get stuck in walls

3. Interaction with Stairs and Walls:
- While the new ability to climb stairs is innovative, errors occur when:
* Walls are too high (characters repeatedly jump against them without success).
* Some characters stick to walls and remain jumping against them.

4. Character Selection:
- The system seems to randomize the opponent's characters:
* The character selected in the menu changes at the start of the game.

Sorry if you're seeing these comments, these aren't the kind of things you were hoping for. As soon as I can, I'll write a list of all the bugs or details that need to be fixed, as well as restructure my post with ideas for the new staff 😛

Note: The menu typography is excellent! It has a very cool style.

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.

Thanks a lot for the feedback ❤️

The second player's jump button is bound to the first player's punch button, and it's not possible to configure it with another button.

Buttons... Did you plug in two gamepads? Or are you talking about the keyboard? Here's the basic layout for the keyboard, no keys are overlapping:

And it can be changed, as this is a layout for a French keyboard. So I don't understand your problem. Please fill a bug report with details about how to reproduce that one.

The jumping system requires multiple presses to execute, giving a feeling of lack of responsiveness.

I don't have this problem here. Please open another bug report with useful details such as the kind of machine you are playing on and whatnots, so I can fix it 😉

When tackling or punching characters, they are sometimes thrown excessively or get stuck in walls
Some characters stick to walls and remain jumping against them.

More bugs for the bug report. What fighters are broken? I need clear details about bugs so I can reproduce them. Can you provide video or picture about those? I'm suspecting the game to lag on your computer at this point... 😛

Walls are too high (characters repeatedly jump against them without success)

That was to give player feedback that it's not a stair and that it is not climbable, instead of not moving. The fighter is actually jumping lower than a climbable stair. We don't have animation to bump into something, and using the hurt animation might be too much. If you guys have an idea for that, it might be interesting to discuss.

Character Selection

I know. I need to rework the whole team saving. I'll do it, as it is annoying, even for me, but let's focus on the move/jump/punch for now 😉

The menu typography is excellent! It has a very cool style.

Yeah, but as I wrote, it is temporary. As it's taken directly from a Capcom game. I need to find a screen layout, then a style and design the font myself.

You just keep jumping around and bouncing on them.

1. 1- Yeah. At first, the fighters were passing through each other. And it wasn't fun, as there could be up to 32 fighters in the exact same spot.
2. 2- Then I added collisions and the fighters could walk on top of another, and make some nice human columns. The problem is that the collision is pixel perfect, so it can be erratic when walking on the ears of Batman. And a fighter that is stuck under another can't properly walk.
3. 3- Then I added the bouncing. It's not perfect, but I find it fun.

I'm going to review how it is programmed and see if I can do something in between 2 and 3. Keep in mind that this is exactly the kind of tweak that needs two or more real players that are moving and not just static targets. But if anyone has interesting idea on that topic, now's the time.

there's no windowed mode anymore

Handling the viewport, the cameras and the layout is extra complicated in HaxeFlixel. So I'll do that later, as it's not the core gameplay. Just press alt+tab to switch between which program to display 😉

So, bugs go the bug report zone.
Tweaks are discussed here 😉

Tweaks are discussed here

What type of problem should be categorized as 'Tweaks'?

Example:

• You jump, and the fighter passes through the ground and gets stuck. That’s a bug.
• You jump, and it works, but the feeling of force and gravity isn’t quite right. That needs tweaking.

Tweaking every parameter in the game is essential, but also the most complicated part. Take our jump example: the fighter might feel like they’re floating in the air. To fix that, I can adjust the gravity, the acceleration when pressing the jump button, or the maximum velocity they can reach... But any change to one parameter affects the overall look and feel of the game, and can also impact other mechanics, like how an enemy reacts when punched away.

That's why I won't add anything before the basics are done correctly: move around, jump and punch.

Given that this is the premise of this post, I believe an adjustment that could be made is to make the characters a bit heavier so that they perform a normal jump instead of a super jump.

Taking the characters as a reference (each occupies 1 block of the map), I determine that the push strength per hit is 4 blocks; I think it would be good to adjust it to 2-3 so that the hits are not oversized.

Regarding the flying characters, I think it would be good if they were lighter so that they are not slow while in the air.

In my opinion, that's what can be adjusted in the game; it would be a matter of others giving their opinion on whether they agree or not.

The jump was just an example to illustrate the difference between a bug and a tweak 😁
Regarding the jump height, here’s where we currently stand:

"the jump height, in my opinion, is far too high"
Currently, the jump height is 9 blocks. I’ve reduced it to 5, so a double jump will reach 10. However, this is something that will need further adjustment once we’re able to properly fight against (human) opponents.

That said, I’m honestly happy with this number. In a video game, the purpose of jumping is to reach otherwise inaccessible places. I just don’t see the fun in only being able to jump 2–3 blocks, and I can’t think of many games that do so. You can edit the map.png file in the data folder to see what I mean.

I haven’t tested the flying speed much yet. Keep in mind that flying characters shouldn’t have an additional advantage over jumping fighters beyond the ability to fly itself. Also, the speed power will influence their flying speed.

As I mentioned, we’ll fine-tune it further when playing against real opponents 😉

I’ll be on the road for 10 hours today. When I’m not driving, I’ll try to work on fixing the collision response between fighters. It’s far from simple...

In the end, I replaced HaxeFlixel's basic collision with my own system for fighter collisions. It’s far from perfect, but I believe it’s already working better.

I had a little time today to fix the save of the Versus screen configuration and deal with the bouncing of dead bodies.

hi i recorded some gameplay with my brother and figured i'd share them (they're hidden videos btw)
i think the most relevant ones are 1,2 and 7

i'm the one on the left

here i showcase richter belmont and do a super mega instakill dash attack

here my brother air dashes unto the sky and uh does this

nothing much happens in this one but there's a part at the end where some funny collision stuff happens

here i try to get out of a hole and my brother dies and then spins

here we have a gruesome battle to the death

here we try to push each other to see what happens and then we go to spain without he a

Thanks, Bosha! That was helpful 😉
I edited your post to include your comments after discovering them by opening the video on YouTube. But what version of the game were you playing? The rotating dead corpses issue was fixed a week ago. The version number is displayed on the title screen, so you should make sure you're playing the latest version.

After watching your videos, my next tweaks will focus on:

• The double-tap to speed up, as it's not meant to be a way to fly around.
• The calculation of the fighters' collision boxes. For example, Richter likely has a lot of empty space around him for the whip, so right now, his collision box is wider than the sprite. This isn't a simple fix... 😛

One last note: since there's no AI yet, there's no need to drop 32 non-moving fighters into the match. A simple one-player vs. one-player fight in the small original stage is better.

I just uploaded a new version with a new way to calculate the bounding boxes of the fighters.

Regarding them, here's what was happening in the old version of BASTON:

From left to right, you can see a normal fighter, a big fighter, and a weirdly positioned fighter (not centered due to certain factors).

The red line represents the frame of the spritesheet.
The orange box represents the bounding box, which was calculated as 40% of the frame's width and 60% of its height.

This method worked fine for normal-sized fighters, but it had issues:

• Big fighters had bounding boxes that were too small for their actual size.
• Fighters that weren't centered properly had misaligned bounding boxes, causing them to float outside of platforms.

Here’s the new way I'm calculating bounding boxes:

I now scan the first frame (standing pose) to detect areas without pixels. This determines the initial bounding box. For width, I take the smallest detected value to avoid covering unnecessary empty space—for example, if a fighter is centered but holding a sword on one side. Then, I apply a percentage reduction to fine-tune the box, and voilà!

The weird fighter’s bounding box is still a bit off, but honestly, fighters SHOULD BE CENTERED in their frames. I'm not going to account for poorly positioned sprites, as the whole system should be simple for everyone 😛

-

Thanks, Bosha, for your input on the dash system. While waiting for more feedback, I'll work on platform ledges. A fighter should fall off a ledge if more than half of their bounding box is in the air, rather than floating just because a single pixel of their foot is touching the ground 😀

Edit:
I added a camera shake when a player is hit, and I also save the number of players configuration in the Versus screen.

The new bounding box system works really well 😁 (the issue would be to get people to go back and update their chars accordingly but no matter)

also i have a few very minor nitpicks regarding animations:

• I think stair climbing could look more natural if characters did their walk animation uninterrupted instead of jumping maybe
• When jumping forward, characters should do their "jumping forward" animation from frame 1 (currently they do their neutral jump animation first for a few frames) then maybe go into their fall animation
• just nitpicks tho

Bad news. I’ve been wondering for a while why artifacts sometimes appear on the borders of fighters and why their collision boxes are off by half a pixel.

To understand the issue, take this sprite sheet of a 14x13 fighter:

At the very beginning of BASTON, when it was still a Flash game and fighters weren’t stored as files but saved in browser cookies, I was heavily limited by file size, since cookies have a maximum storage limit. To work around this, I decided to gain some octets by slicing the sprite sheets like this: four sprites of 15x14 pixels, including the top and left borders.

At the time, this wasn’t a big deal. But now that the game runs as a Windows executable with a different rendering system, this method causes visual artifacts at certain camera zoom levels:

And now that the game has platform collisions, as I was working on ledge detection, this is becoming a visible problem. It is "breaking" all pixel-perfect collisions by half a pixel, since the collider is centered on the sprite.

To fix this, sprite sheets will now require a two-pixel separation between each pose, like this:

Resulting in a 16x15 fighter:

So first, I’ll modify some fighters to match this new slicing method within the game. Then, I’ll heavily modify the Fighter Editor to reflect these changes. Finally, I’ll try to find a way to automatically patch old fighters so they are sliced correctly with the new system when they are loaded.

This is hell.

All right, I’ve made almost all the necessary changes, and everything is now much simpler regarding fighter collision bounds. However, I can’t upload a new version yet because I still need to tackle the hard part: patching existing fighters during their loading. I’ll check on that tomorrow.

That went pretty well! I was able to program the automation of patching sprite sheets of 'old' fighters when they are loaded into the Fighter Editor. However, the version isn’t ready yet because I still need to figure out how to patch fighters that are locked, as they can’t be opened in the Fighter Editor.

One option is to patch them when they’re loaded for a fight, but that would require a warning message, since patching multiple files every time a fight starts isn’t viable. Another option is to add a ‘Load + Patch + Save’ button in the Fighter Editor, allowing patches without opening the files in the editor.

I’ll think about it while watching Daredevil on TV.