Re: Let's make an audio game engine!
@45
Bullet is 3D. Box2d is 2D. These are different. If you try to use Bullet for a 2D game you are adding a ton of complexity for no gain whatsoever.
Even with box2d, things can rotate to not be axis-aligned. When that happens there's no way to debug without being able to see. This means that you have to turn parts of Box2d off as well. Fortunately in Box2d those are settings with functions to toggle them.
You can get a 3D physics library to work for a 2D game if you get the constraints 100% right. If you don't, you can't debug what's wrong and will have objects seemingly glitching through each other because they ended up with different Z coordinates.
It's also next to impossible to get any of these to play nice enough with tilemaps that you can do Swamp-style radars and stuff. If you represent every tile as an axis-aligned box you both waste a huge amount of memory and end up with something absurdly slow. By absurd amounts of memory I mean that even a 50x50 map done that way chews through 20MB or so. So to do it right you have to compile your 2D map to a geometry of some sort, and then all your radar raycasts are slower because there's a much faster algorithm for 2D grids if you're not including game objects. Then you go off and you rewrite half the collision stuff for that, and at that point you're halfway to not using a physics library because you just rewrote a big chunk of collision and turned half the physics library's features off and wrote a tool to convert tilemaps to larger axis-aligned boxes.
I have been down all these avenues. When I say "maybe we need an audiogame-specific physics library" I'm not just saying it because it's fun. Maybe such a library would just wrap another one with a more convenient interface. maybe it rewrites physics for audiogames. I don't care which. But we do need a better option that solves our problems.
@46
I'm not sure if you're not following me because I'm using complex English, so I will put this as simply as I can.
If you have never written games then you do not know what games need.
If you haven't programmed for a long time you do not understand how to write libraries.
If you knew enough to do this project you wouldn't need to ask how long it takes.
You ask questions like you are a new programmer who hasn't written a game or done any other big projects, and have not shown us that you have the skills required.
You are proposing starting over using the hardest technology you can possibly choose when Lucia can be ported to all the desktop platforms in a few days at most, and you aren't proposing any features that Lucia doesn't already have except for phone support.
If you do this you will simply end up with another BGT at best because you do not know enough to do this project. Other programmers may help but only if they have experience with audiogames. I do not personally believe you understand what the community needs.
You should go write some games first.
Being open source or not doesn't change whether you solved problems that people care about in a good way. You will only get contributors if you solve problems in a good way and people decide to use your project.
I can't put it more plainly than this. You're not ready for this project.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
