I'm going to make a mobile 2D rhythm game, but wondering:
Should I use a game engine/framework?
Rhythm games are very different from other games. It is extremely sensitive to audio timing, user interaction, and animations (16ms is too much), and doesn't use things like hitboxes. I see Phira doesn't use a game engine. Maybe existing game engines aren't suitable for music games?
If using a game engine, which ones are suitable for rhythm games?
I searched a lot but having trouble comparing them.
...or should I use Rust? I'm not familiar with Rust.
It's all up to you, honestly. If you already have experience writing game engine code, then rolling your own is a good first step. If you do not have this experience, it might still be worth it for learning purposes but be aware that it can be a huge time sink, depending on how deeply you care about making an engine over making a game.
On the other hand, you may be more willing to exchange flexibility of doing things "your way" with doing things "the engine way" to try focusing more on your game than engine code. It doesn't always work out that, way, since learning an engine can be just as challenging as building one! There are a lot to choose from, including bevy, fyrox, macroquad, and (my personal preference, for reasons I will touch on below) godot-rust gdext.
The pure Rust engines (of which there are several that I have not mentioned) are all quite good enough for certain kinds of games. But in my experience, they are still too immature for making large scale games. You might be able to get pretty far along with a rhythm game using any one of them.
For me, Godot is a much more pragmatic starting point. It has a very good track record, hundreds of real games are made with it, and the Rust bindings are high quality. (I don't actually know which Godot-based games have been released with Rust, if any.) It has practically everything that I want, whereas the pure Rust engines are either lacking features or only support a limited subset of what I need. (3D animations were very under-supported the last time I tried bevy for a big project, but it is improving. Meanwhile, Godot has had awesome animation mixing literally forever.)
Sorry I can't be more specific. It really is a situational thing. I would say you can't really go wrong picking any of these paths. Unless you give up.
Thank you for the detailed reply! What is most troublesome is that rhythm games are generally composed of the game and the chart editor. They share a chart rendering logic (JSON etc. → geometries and animations).
The UI of the game is very suitable for building with Godot, but ideally the UI of the chart editor should be like Godot Editor. I'm not sure if it's a good choice to build all of this with Godot modularly, or build the chart rendering module using a low-level library, and then build the game and the chart editor using different frameworks.
Can you give some advice for this case? Thank you.
I'm not trying to convince anyone that Godot is right for them. And I haven't made a rhythm game with it. But for specifics of the engine, its editor is built with the same UI nodes that you piece together in the editor. It's kind of a "self-hosting" thing at this point. Source: The Godot editor is a Godot game
The Godot editor runs on the game engine. It uses the engine's own UI system, it can hot-reload code and scenes when you test your projects, or run game code in the editor. This means you can use the same code and scenes for your games, or build plugins and extend the editor.
That should clarify your first concern. There is only one Godot, the editor is not a separate product. In fact, you don't have to build your UI with any of the Godot UI nodes. You can build your own nodes with their own shaders and rendering logic.
I'm not sure I can help you make a decision on what to do for chart rendering. Again, it's up to you, and your choice probably depends on many factors which I have I have no visibility into. Your proficiency with various technologies, your willingness to challenge yourself and learn new things, your preference to stay in your comfort zone, what your timeline for the project looks like, and so on. Any one of these could push you more or less in any other direction. And it may not be worth dismissing making your own engine or using any other existing engine.
If what you are really asking is for some nudge to get you over analysis paralysis, I would say go jump into Godot and follow the tutorial in the book. Whatever you do, don't start by building your dream game! Do something small to get a feel for the tools and discover for yourself if it suits your needs.
You can also try out bevy. The only recently modern tutorial I know of is this oversimplified Pong clone tutorial. Most of their learning resources are still focusing on micro pieces of the engine.