FEBuilderGBA does not make constraints in particular.
It is about byte boundaries such as 256 and 128.
There are no other restrictions.
This is because we do not know what extension patches will be made in ROM in the future.
suppose that you create a constraint that the level of default behavior is 20.
In this case, you can not set it if you make extensions that exceed 20 in the future.
You probably can not see ROM.
Anything exceeding the set value will result in an error.
Since there are many ways to implement patches, it is a very difficult task to check if the patch is installed.
For this reason, I try not to make restrictions as much as possible except where I can clearly set the limit value.
This is an investment for future extensibility.
Well, I will return to the level's story.
With GBAFE, you can save up to Lv31 values by default.(2^5-1 = 31)
More values can be expressed in the RAM, but if you interrupt or save, it will be incorrect.
To exceed 31, it is necessary to introduce a patch that extends the save data.
For example, using break_save patch seems to be able to save up to Lv63(maybe).(2^6-1=63)
if you create a patch that allows you to store more data yourself, you can save more data.
Perhaps you may wonder why it is 31.
Although the upper limit of Lv is 20, why can you store up to 31?
This can be convinced by thinking in binary number.
It is 2^4-1 = 15. (0b1111)
15 is useless. The value is insufficient.
In FE, it must be able to save up to Lv20.
More bits are needed to store 20.
Let's increase it by 1 bit and let it be 2 ^ 5.
Then the value will be 2^5 - 1 = 31. (0b11111)
Therefore, FE has a system level upper limit of 20, but there are areas that can be saved up to 31.
In break_save, one more bit can be added to save up to 2 ^ 6 - 1 = 63. (0b111111)
Even if only 1 bit is increased, the value is exponential, so the value will increase considerably.