I’ll give you my opinion in a nutshell.
I think it is simply a difference of opinion regarding the expansion of icons.
I will not quit expanding the icons, no matter what you say.
This is because I think it is more important to show how it is currently set up than how it looks.
I don’t think the emblem magic screen is easy to use, so I think this is a matter of personal preference.
I think this topic is probably sterile.
FEBuilderGBA is designed to have a UI that aims to get to all screens with two clicks.
ROMHack is strongly dependent on the ROM structure, so it is inevitably complex.
For example, it would be easy to understand the relationship between Item settings and MagicEffect.
Since this table is a 1:1 relationship, there is no need to set it up as a separate table.
However, it is unavoidable because of the way the ROM data structure is structured.
As for the text formatting, the reason is because vanilla is written that way.
I think vanilla is probably written in some kind of GUI editor as well.
I think the strongest possibility at this time is excel, though.
This is why it looks odd when viewed in text format.
I think the conversational text, which can be complex, should be viewed in the GUI, not in text format.
As for the patch screen, this is a result of going beyond the original plan.
It was initially created to make these patches that were being discovered at the time easily available.
https://dw.ngmansion.xyz/doku.php?id=data:パッチ
However, over the years, various and complex patches have been added to make it what it is today.
Sorting is possible, but the emphasis is on searching rather than sorting.
This is the same for the detailed menu.
The game has a lot of structs, so it’s only natural that the items get complicated.
So, search and find what you’re looking for.
The advantage of the non-ROMHack SRPG game engine is that it is not constrained by the structure of the game.
Therefore, you can create a screen that is easy for the user to set, and you can create a structure that fits the screen.
On the other hand, ROMHack is the opposite, you have to match the screen to the data structure of the structure in the game.
I think the biggest problem with the event engine of FEBuilderGBA is “branching”.
Since it is the same as ASM, the order of branches is reversed, and it takes a little time to understand.
Unfortunately it’s pretty hard to make this look like an if statement.
Regardless of the completely new syntax, existing syntax may not form the body of an if statement.
That’s why we recommend templates instead of writing branches yourself.
Sorting is available in a manner of speaking, but the emphasis is more on searching than on sorting.
The same goes for the detail menu.
Since there are so many structures in the game, it is inevitable that the items will be complex.
Therefore, we try to make it possible to search and reach the desired item.
The advantage of the SRPG game engine that is not ROMHack is that it is not constrained by the game structures.
This means that screens can be created in a way that is easy for the user to set up, and structures can be created to fit the screen.
ROMHack, on the other hand, does the opposite: the screen has no choice but to match the data structures of the structures in the game.
For capacity, there is rebuild.
Please use this to solve the fragmentation.
Since Kaitou has been able to create so much with a 32 MB limit, I think it is possible to create many other works as well.
One of the most common cases of full capacity recently is when a large number of animations are added.
This is the case where the capacity does not decrease much even after rebuild.
I sometimes see games that have imported more than 0x200 animations that are not even used.
It looks like they imported everything they found in the repositories anyway.
It’s like stuffing all the free tissues in your pocket and taking them home, or going to a buffet restaurant and eating until you throw up, no matter how much you can use them for free.
Complex animations waste a lot of space, and you’ll probably reach your capacity limit.
And you shouldn’t eat in a restaurant, throw up in the bathroom, and eat again, because it’s harder on your body than you expect.
People who do this will probably create huge zip files in other engines, importing large amounts of image and music data that they don’t even use.
The GBA has many limitations, but other than capacity, I think the biggest limitation is the lack of Internet access.
Since the GBA cannot physically use the Internet, emulators cannot use the Internet either.
Therefore, it is not possible to collect play reports or automatically update games with ROMs by themselves.
If a game is compatible with FEBuilderGBA’s WorkSupport, automatic updates and automatic feedback can be used if the user is playing the game using FEBuilderGBA.
The restriction that the game must be played using FEBuilderGBA is a bit of a pain, but it is a very useful feature, and I think that projects that do not yet support it should definitely use this feature.
https://dw.ngmansion.xyz/doku.php?id=en:guid:febuildergba:work_support
Also, if you are using a non-GBA engine, you should realize that the Internet is a powerful weapon not available on the GBA.
It would be good to collect user play data and statistics to improve the game and support automatic game updates.
It might also be a good idea to place hints in places where many players have died or are lost.
Just like FE does today.