Mapa:

That is really cool. I have no idea what the limitations are for a bitmap map data, so thanks for experimenting.
And I'm seeing a few weird things in your gif, such as goku walking with the head in the ceiling of the underworld tube, and then walking again while getting outside of it 🫤

I think it might be a good idea to allow changing directions when bouncing off of a character using the "stomp" ability?

You'll be able to change direction while bouncing, or even double-jumping. That is considered as a new jump. Just like in Celeste.

I'm addressing core gameplay issues one at a time. It will take a lot of work and fine-tuning before the movement feels just right.

I've also streamlined the process of building, zipping, and sending the entire project by using a single script. Now, I can automate this after each change instead of manually handling everything, once per day.

Additionally, I've added a version number on the BASTON page for better tracking.

I've added an experimental radar to help locate enemies outside the screen. It's experimental because, as of now, there's no real way to play against another player since the camera remains focused on Player 1.

And single camera doesn't seem sufficient to cover the entire arena when players are far apart. I need to try in fullscreen, but I'm also considering the possibility of using one camera per player instead. It's interesting how this was straightforward and intuitive in the tactical version of the game, but it's a tedious challenge here 🙄

Edit:
The game now starts in full-screen mode, and this setting can't be changed in-game. I decided on this to avoid wasting time working on something incompatible with Android devices. It's full-screen for everyone or nothing.
This approach will also improve the experience when using the Fighter Editor.

I also added a QUIT button.

No real progress here. I replaced the camera in the Fighter Editor with a FlxZoomCamera, the same one used in the fighting part. While this makes it much easier to move the spritesheet around and zoom in/out, the problem is that I've spent the last three days trying to correctly convert mouse click coordinates from the screen to the zoomed camera in order to detect which spritesheet frame was clicked...

Edit:
All right, just after writing this, I managed to convert the coordinates. I needed to add the middle of the screen in the calculus, and also add camera.target because the camera is centered on it.

var mouseWorldX:Float = (FlxG.mouse.x - FlxG.width * 0.5) / camera.zoom + camera.target.x; var mouseWorldY:Float = (FlxG.mouse.y - FlxG.height * 0.5) / camera.zoom + camera.target.y;

All right, I’ve finished fixing the Fighter Editor with the new camera system. You can now move around using mouse drag and zoom in/out with the mouse wheel. Alternatively, you can use Shift + arrow keys to move and - / + keys to zoom.

I learned a lot about HaxeFlixel cameras while working on this, but it was rather long and complicated. So, I’m going to take a short break from BASTON to wrap up a few things on Dragon Ball Devolution, then I'll get back to the fighting part. Otherwise, I’ll burn myself out... 😛

I finally managed to differentiate ground collisions from walls and ceilings!
This led to a complete rewrite of movement, plus cleaning and reorganizing the code, especially the jumping mechanics.

The new system now includes:

• Variable jump height – You can release the jump button early to stop rising before reaching the peak
• Apex modifiers – Allows for more precise movement when reaching the top of a jump
• Jump buffering – Lets you press jump a few frames before landing, so it still registers
• Coyote time – Gives you a short window to jump even after stepping off a platform (just like Wile E. Coyote)
• Clamped fall speed – Prevents falling too fast
• Ledge detection – Allows climbing a ledge if the jump reaches just below a platform (I need to verify this one...)

For now, I've deactivated most other mechanics, like attacks, defense, and powers. Please focus on movement. See if it feels good, what could be improved, and report any small bugs I might have missed.

Edit:

I added a directional force to the jump when pressing a direction at the same time. This makes it easier to change direction during a double jump or jump higher by pressing up. All these values can be tweaked later once things are more playable.

I also rewrote the particle engine. Right now, there's just a single pixel effect while jumping, but I'll draw proper FX for ground and air jumps soon.

Setting the origin point of a sprite is still a complete mess in HaxeFlixel. It makes ZERO sense.
So after hours of try and repeat, here's how to set the origin point to the bottom right of a sprite, instead of its center:

sprite.offset.set(0.5 * sprite.width, 0.5 * sprite.height);

Thanks to that, I started experimenting more with particles. They're now stored in a group, but I still need to extract them from the main fight code to keep things clean and readable. This first particle effect, made of two particles, now appears when landing on the ground.

Still rewriting everything from scratch.
I reimplemented speed, allowing fighters to cross gaps without jumping.
I reactivated basic attacks and dash, though the latter currently functions like a basic attack.
Regarding speed/dash, I need to figure out how to program the initial movement boost for speed/dash.

Oh, and instead of testing collisions individually for each fighter, I now test all fighters against the collision map just once. This new system broke a few things, but in the long run, it will be so much better. For instance:

Old system with 10 fighters:
Number of collision tests = (10 fighters * collision map) + (10 fighters * 10 fighters) = 111 tests per frame

New system with 10 fighters:
Number of collision tests = (1 fighter group * collision map) + (1 fighter group * 1 fighter group) = 2 tests per frame

And in case you don't realize, the game runs at 60fps. That's one hell of optimization.
The same will apply to all the projectiles. It's a good thing I'm rewriting everything from scratch!

Edit:

I programmed a custom particle that can be flipped on the X-axis, something the basic FlxParticle can't do. So I could add dash/speed FX when moving quickly at ground level.

I also store the fighter's velocity from the previous frame to compare it with the current frame. This allows me to trigger the landing particle animation when the fighter was falling at a certain speed.

Edit 2:

Added ground and midair jump FX

I modified the maximum velocity so that a double-tap speed boost starts faster at launch and then slows down. There's a lot that can be tweaked from here, but we’ll to be able to play against something in order to fine-tune it.

For now, I’m going to focus on adding a camera for each player, even though I’m not really fond of the idea. At least it will make the game somewhat playable, allowing us to continue implementing and refining the core gameplay, such as bouncing around.

Example of split screen in haxeflixel using FlxCamera:
https://haxeflixel.com/demos/SplitScreen/
Let's hope I won't have problems with my FlxZoomCamera... 😛

Bad news, splitscreen absolutely doesn't work with FlxZoomCamera... 🫤

For starters, their splitscreen example doesn't even work if we change the zoom level when creating the camera.
For example, for a zoom of 3, instead of having one camera rendering from 0 to _halfWidth with a zoom of x3, it is rendering from 0 to _halfWidth x 3.

Honestly, I don't understand why the width and height of the camera display isn't uncorrelated from its zoom level, but let's work with it. This can be fixed by dividing the width and height by the zoom level:

function createCamera(X:Int, Color:Int, Follow:FlxSprite, Zoom:Int):Void { var cameraWidth:Int = Std.int(_halfWidth / Zoom); var cameraHeight:Int = Std.int(_textY / Zoom); var camera:FlxCamera = new FlxCamera(X, 0, cameraWidth, cameraHeight, Zoom); camera.setScrollBoundsRect(0, 0, _level.width - 8, _textY); camera.bgColor = Color; camera.follow(Follow); FlxG.cameras.add(camera); }

And now surprise, it works, with a basic FlxCamera. No need for FlxZoomCamera, it seems... Maybe they fixed their camera since the time I started working on that game. I'm going to use basic FlxCamera within the fighting part, see how it goes, and if everything is fine, I'll replace FlxZoomCamera in the Fighter Editor too. This is so messed up.

Edit:

All right, I managed to make the weird dissociative splitscreen working. I had to deactivate a lot of things, such as player 3 and 4, for starters. The game is starting to get "playable" for 2 players 😛

I quickly edited the setup menu to display only the buttons that have already been validated.

Try "playing" a bit—you’ll see how messed up split-screen feels when you jump on one screen and see yourself jumping on the other at the same time. It's extremely disorienting...

But for now, I need the game to be at least "playable" so I can continue working on the gameplay. We’ll deal with the camera issue later.

Yet another version!

I optimized the calculation of the closest fighter for each fighter. This is reflected in the stance pose and should be useful later on.

I also reworked the HUD camera—there's now a black line separating the two player cameras, making the split screen look much better. Plus, the radar now works separately for each player.

Tomorrow, I'll activate the health gauge. I’m not a fan of the old BASTON health bar, so I’ll use the little hearts from the tactical version instead.

WARNING!!!
If you intend to use the Fighter Editor with the new version of BASTON, I recommend saving your fighter as another file. The files are not patched yet, but I don't know if saving them will keep them compatible with the old release.

I completely rewrote how players are created. (Players are not the same as fighters.) Now, you can choose from 1 to 4 players in the versus screen, and from (number of players) up to 32 fighters. These numbers can easily be adjusted in the future, allowing for 0 players (AI-only battles) and as many fighters as the game can handle simultaneously.

The game now automatically creates the required number of cameras, then divides the screen accordingly and set the radars for each player. Players 3 and 4 currently don’t have keyboard input and will need gamepads to play.

I added a basic HUD with each player's face, name, and HP so we can better understand what's happening. I had to deactivate the blood particles because they were colored and tied to the old system (1v1 = only two fighters at the same time).

Now, I'm going to work on punches and add some momentum to them.

After that, I’d really appreciate some feedback, since I can't properly test the game alone. Something I could do in the tactical version of the game...  🙄

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.

That’s exactly the kind of feedback I’m looking for, so I don’t feel like making a game all by myself for God knows who... 🫤

"You added momentum to the running."
The momentum was introduced with the new jump code in the build from February 20, 2025.
In today’s build, I added a bit of acceleration, so the character reaches maximum speed in fewer frames.

"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.

"I’ve also noticed that even characters without the ability to jump can still do so."
That’s a bug. It’s been fixed now. Thanks for pointing it out 😁

"I assume that you will still be able to see the opponents’ portraits and health, right?"
No. Right now, we’re focusing on controls, camera, and character mechanics.
The HUD is only there to show your health, which will be relevant once I implement punches.

"I think some sort of 'lock on' feature might be necessary."
It’s way too early for that. However, it will definitely become an issue later on. For now, it’s just movement and punches. If the movement and punches aren’t fun to play, there’s no point in continuing working on that game.

"About the 32-fighter limit."
It’s just a number that fits the screen, so I don’t have to waste time programming additional features to handle more fighters in the versus screen before making the game fun to play. Teams were not included in the last build you tested, but they’ll be reintroduced later.

"There’s no way to switch between fighters on your team."
I don’t think I’ll add that feature.

"My suggestion is to re-use those 'miniature characters' standing sprites."
That’s a nice idea, but it only works for smaller fighters. And honestly, i'm getting rid of the mini poses, as most of them are badly done.

The cameras are now bound to their limits, and the radar follows the fighter coordinates, even when the cameras are not centered on them. And I just wasted hours figuring out how to convert a sprite's coordinates to screen coordinates in a four-player split-screen setup, where the cameras can move and zoom.

The HaxeFlixel documentation is scarce, and the whole knowledge is locked behind Discord, making it inaccessible via search engines. So even AI like ChatGPT ends up making things up. So now, only kids are using the HaxeFlixel's Discord to "mod" the stupid Friday Night Funkin', and HaxeFlixel’s accessibility have turned to crap.

I don't think you guys realize the sheer amount of knowledge that is being lost forever because of Discord... 😠

Anyway, here's how to do it:

spriteScreen.x = (sprite.x + 0.5 * sprite.width - camera.viewX) * camera.zoom + camera.x; spriteScreen.y = (sprite.y + 0.5 * sprite.height - camera.viewY) * camera.zoom + camera.y;

Edit:
I adapted the world limits, so the fighter dies when his body entirely crosses the camera boundaries. And I have optimized the world limits test so that he doesn't die on each and every frame. Now I believe I have everything ready to start working on the punches.

I started reprogramming the knock back from scratch when fighters are hit. This needs a lot of little adjustments but it is already working. You can now push enemies off the ledge.

Non-jumping fighters are seriously *NOT FUN* to play. I'm going to add that so they can at least move a bit around the stage just by walking: