I know it isn’t completely trivial, but as someone with many years of experience making (small) indie games, I know for a fact that a menu like that it should only be changing a few global variables. It’s a frontend with very little backend to consider.
Something like that is not a year’s work. I could agree with a month, and even at that, most of it will be testing, not design.
And tbh - the main problem with it isn’t even its design (the design is fine) just its controls. You inexplicably have to use the D-pad for character select, but the analog stick for everything else, apart from switching to difficulty select with R2. Why not navigate the whole menu with either D-pad or left stick? That should only take a week to fix at the absolute maximum, unless they’ve managed to tie the code in a spaghettified knot that’s unnecessarily coupled with actual game mechanics.
AAA gamedev here. I agree in principle with the gamefeel critiques, but I’d like to bring up that scale absolutely matters here. Every degree of complexity your codebase adds can cause cascading issues, which is one of the million reasons indie devs are told by everyone to keep their game scope small. Not saying these kinds of games shouldn’t improve, but it’s not as trivial as it might appearr.
Scale absolutely matters, but the scale of the new game screen is (or should be) very minor compared to the game itself. That one scene should only be setting the variables for new play, not interacting with anything outside of it.
And, to be clear, the main concern is simply the input handling in that scene. The UI itself doesn’t really need to be changed, just which buttons change the highlight focus.
I can imagine it was likely thrown together quickly, perhaps with some unnecessary coupling, or maybe reading the inputs using action names that also relate to gameplay, so it becomes awkward changing it out.
I’m not so experienced with Unity, but in UE and Godot, adding and mapping inputs is fairly trivial - select the “up” button and map it to “ui_focus_up”, etc. I can’t see it being much more complex in Unity.
The ROR2 new game menu has only a few elements:
That’s it.
I know it isn’t completely trivial, but as someone with many years of experience making (small) indie games, I know for a fact that a menu like that it should only be changing a few global variables. It’s a frontend with very little backend to consider.
Something like that is not a year’s work. I could agree with a month, and even at that, most of it will be testing, not design.
And tbh - the main problem with it isn’t even its design (the design is fine) just its controls. You inexplicably have to use the D-pad for character select, but the analog stick for everything else, apart from switching to difficulty select with R2. Why not navigate the whole menu with either D-pad or left stick? That should only take a week to fix at the absolute maximum, unless they’ve managed to tie the code in a spaghettified knot that’s unnecessarily coupled with actual game mechanics.
AAA gamedev here. I agree in principle with the gamefeel critiques, but I’d like to bring up that scale absolutely matters here. Every degree of complexity your codebase adds can cause cascading issues, which is one of the million reasons indie devs are told by everyone to keep their game scope small. Not saying these kinds of games shouldn’t improve, but it’s not as trivial as it might appearr.
Scale absolutely matters, but the scale of the new game screen is (or should be) very minor compared to the game itself. That one scene should only be setting the variables for new play, not interacting with anything outside of it.
And, to be clear, the main concern is simply the input handling in that scene. The UI itself doesn’t really need to be changed, just which buttons change the highlight focus.
I can imagine it was likely thrown together quickly, perhaps with some unnecessary coupling, or maybe reading the inputs using action names that also relate to gameplay, so it becomes awkward changing it out.
I’m not so experienced with Unity, but in UE and Godot, adding and mapping inputs is fairly trivial - select the “up” button and map it to “ui_focus_up”, etc. I can’t see it being much more complex in Unity.