itch.io

That's fantastic news! :D I look forward to the patch. I'll play the existing build later on Chrome or Edge or something and let you know the difference.

I'll be honest, I hadn't looked up what Phaser and Three.js actually were when I wrote my last comment. I haven't done a lot of web frontend development to be familiar with them. I just assumed they were part of the AI stuff. I suppose if you were desperate, you could try hand-optimizing the html5 output? I have a feeling you'll figure out something more elegant, though. You sound like you know your tools.

Out of curiosity, how long did it take you to get this from concept to where it is right now, using AI?

Physics-based gameplay is almost always a bad idea... but I say that with a caveat. 

Many video games have "physics engines," like Bullet and Havok, for example. And Box3D is apparently poised to optimize that whole concept pretty soon. But historically, what I've seen is a lot of "dev trying to make a simulation, the simulation falls apart when people actually play the game, so they start fudging the numbers." Increasing the mass of cardboard boxes or whatever, until the thing looks like it behaves realistically.

The caveat is, people who grey up playing Beyblade probably know how all those fins and grooves would interact, realistically. Maybe not all of them. But if they see a familiar match-up, they'll have a gut feeling about how it will go down. That could be your game's secret sauce, if done right. That could be its killer app.

Then again, if the player can steer their top into a collision, but they can't keep track of the rotating blades or adjust the tilt of their top, there's no practical way for players to leverage that knowledge. The gameplay becomes vibe checks all the way down. That's the point where it starts making more and more sense to fake it.

But what really gives me pause is the idea of adding all-new parts that never existed or can't exist in the real world. I think you'll find that most physical shapes could have been manufactured out of plastic and chrome in the 1990s if corporations had really wanted to do it. What stopped them from putting a big hammer on one side of the top, or a bunch of forked blades sticking out in all directions? 

Well, physics.

The physical laws that you're trying to capture and bottle also constrained the viability of the actual physical beyblade designs IRL. To put it another way, the more heavily you lean into the arcade gameplay, the less sense the physics simulation is going to make, and the more you'll need to override the physics with pre-programmed or at least heavily constrained responses.

Suppose a top fires a missile at another top. How big are these things? What are they made of? Does the explosion send one of the tops rocketing off-screen in less than 1/60th of a second because it weighs as much as a plastic toy? Or do you increase the top's mass to compensate? Or just use a much weaker explosion? I feel like, at some point, intuitively, they're either going to feel like toys on a toy arena instead of giant steel death machines, or else they're going to feel less like Beyblade for the fans.

There are ways to solve this, but they all involve classic game dev smoke-and-mirrors. Juice, sound effects, screen shake, particles, all that good stuff. They're case-by-case, extremely contextual, and hard to describe. The sorts of things that AI can sometimes do with surprising fidelity... until it suddenly doesn't, and it glitches out in some ridiculous way that a human faking the simulation never would.

It might be that I'm still over-estimating how heavily you rely on AI. Let me know if I'm out of line. I don't feel like most of the code I've written over the last 6 months has been boilerplate. I feel like most of that stuff is already taken care of by the engine, to a very reasonable extent, and most of what's left to the developer is game-specific choices. (Then again, I've been using gdscript as a mostly functional language and only relying on signals to interact with UI elements, so it's possible I've either dodged some godot engine boilerplate, or else created some for myself, depending on how you look at it.)