Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
WarpZone6 days ago (3 edits) (+1)

Here's a random grab-bag of system stats. Let me know if you need anything specific (redacted for relevance):

Web Browser   Firefox

Maybe more like 5-10 fps, but in the video I recorded, it drops to 1FPS once three tops start hitting each other. 

It literally looks like the animated gif in the top left corner of this page.😅

It's really interesting that you chose to make your own game engine from scratch. That's literally the hardest thing to do in Game Development, and it usually results in years of wasted effort and developer regrets. One thing you gain from using an established engine like Unity or Unreal or Godot is hardened battle-tested reliability. If someone's using a 4 year old laptop with obscure generic parts from china and out-of-date drivers, that use case has already been encountered hundreds of times by the thousands and thousands of developers using the engine, and is usually long-since patched before you've even picked up the engine.

Now, you can spend hundreds of hours squinting at bad code and pressing the re-roll button until the RNG gods smile upon you and the markov chains manage to guess an answer that looks close enough to what you asked for that AI-bros with high-end systems won't complain too badly about it. Or, you can spend 5 minutes per decision squinting at the engine documentation, make all of the actual decisions yourself, not just the architectural ones, and, most crucially, pivot on a dime when something goes wrong, without completely regenerating everything from scratch and thus losing any institutional knowledge you'd managed to build up about how your own game works.

The downside is that you have to actually think about what to do, and then do it. Every step of the way.

The upside is the 90% of gamers who stay far, far away from anything with the "AI-assisted" tag will not only click on your game, but it might actually just work out-of-the-box on their equally-jank, barely playable devices. When it doesn't, you'll be able to talk to a person in the community or on the engine development team who knows the engine better than you, learn from them, and gradually improve your craft.

I'm sure the sunk cost is probably too great on your end for what I just wrote to change your mind, but I hope you'll think about it for your next project. Whether you were a traditional developer before you picked up AI, or you've been vibe-coding ever since you picked up your first computer, it's worth doing it yourself.

That said, I honestly don't know how I'd go about programming this. Who knows? Maybe this is one of those rare edge-cases where AI is actually the right tool for the job. Maybe there's a big database of Beyblade Math somewhere, and that was the only possible way you could have gotten the arena slope to feel just right to kids who grew up playing BeyBlade, or something. Now, most games fake their physics instead of actually calculating them. But maybe your game uses real physics under-the-hood. Maybe there's a good reason for that. I don't know. If that's the case, I'd love to hear about it. There's a part of me that's rooting for you, even though you're on the other side of the AI debate. I'm not sure why.

Reply
Barely Playable Games6 days ago(+1)

Thank you. This is exactly the kind of system information I needed, especially knowing that the major drop happens when three BAEs collide. If you’re able to share the recording, that would also be useful, but no pressure.

To clarify one point, I’m not literally building an engine entirely from scratch. The game is built on Phaser and Three.js, with custom systems connecting rendering, physics, combat, and the rest of the game. It is still an unconventional stack with plenty of opportunities for me to hurt myself, as demonstrated here.

The broader goal is to combine real physics-driven interactions with an arcade feel. One of the major roadmap features is the ability to shape and sculpt individual BAE parts, somewhat like Spore. Those shapes are intended to affect how the BAE handles, collides, distributes its mass, and behaves in the arena, so the physics become part of the actual build strategy rather than visual decoration.

I have seriously considered using a conventional game engine, and I may still rebuild the game in Godot once the design has earned that investment. Right now, I’m approaching this as product development as much as traditional game development. My priority is to validate the core idea, test its variables with real players, and iterate on feedback as quickly and cheaply as possible.

If the concept proves itself, I can approach a Godot rebuild with the combat rules, game feel, progression, content structure, and technical requirements already understood. That would still be a significant rebuild, not a simple port, but it would be a much more informed one than committing to production architecture before knowing whether the game deserves it.

Thanks again for the detailed follow-up and for giving the game a fair chance!

Reply
Barely Playable Games6 days ago(+1)

SICK. Found it. Looks like this is an issue with Firefox!

Reply
WarpZone6 days ago (2 edits) (+1)

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

Reply
Barely Playable Games6 days ago (1 edit)

You’re not out of line. You’ve actually landed pretty close to how I’m approaching it.

It’s difficult to give the project a clean start date. The concept and systems have evolved through ideas and experiments over a much longer period, while AI has accelerated the recent implementation and iteration. The game still draws on over a decade of accumulated experience across software, design, music, and creative production.

My workflow is essentially rapid hypothesis testing. If I have five possible approaches to a mechanic, I can define them, use AI to help implement bounded experiments, evaluate the results with automated checks and instrumentation (spent a week on building a CICD pipeline and it sucks but it works), then personally playtest each version. I keep, combine, refactor, or discard them based on what actually feels good. AI shortens the distance between an idea and a playable answer, but it does not decide what is fun.

I’d describe the game as physics-based, not physics-pure. Physics creates the interactions, but gameplay remains in charge. If realistic behavior is unreadable, uncontrollable, or boring, I’ll constrain it, exaggerate it, or fake it. I’m building a game, not submitting a spinning-mech dissertation lmao. The future part-shaping system is where this gets especially interesting. Players will be able to sculpt parts somewhat like Spore, with shape influencing mass distribution, balance, contact geometry, handling, and collisions. That should create builds with actual physical consequences rather than slightly different stat cards. Or at least make spinning phallic objects at some point.

It will be difficult to tune perfectly, but the theme gives me permission to embrace some instability. This probably won’t become the world’s most clinically balanced esport. It’s for people who want to build something questionable and watch spinning mechs collide into absolute ragdoll insanity. The simulation creates the surprises, then juiced up feedback and carefully fudged impulses make them feel good.

I’ll be releasing a hotfix for Firefox based on your report but it’ll take time. Today is dedicated to collaborating with the artists, playing other developers’ games, and catching up on real life work (boo fucking hoo, but it pays the bills and funds this project), so the deeper performance investigation may have to wait a little bit :(

Reply
AboutFAQBlogContact us
Copyright © 2026 itch corp · Directory · Terms · Privacy · Cookies