SMB3-Foundry
SMB3-Foundry copied to clipboard
Warn of game breaking levels?
If you have objects extending to the ground, which hit nothing, the game breaks. We can detect this. How should the error be displayed, if at all.
Maybe a different hue (red) in the object list?
- [x] Objects that hit nothing
- [x] Level will overwrite other data
- [x] Certain known items, that will cause a crash
- [x] incompatible enemies
- [x] Jump on screen without compatible item
- [x] Objects that need a jump, without having one at that screen
Should "incompatible enemies" also apply when it is impossible for them to get close to each other? Example: Dry Bones and Koopa Trooper cannot be together. If you make a really long level, with at the start the Dry Bones, at the end a Koopa Trooper, and in between lots of water. It is not possible to take the shell of the Koopa Trooper close to the Dry Bones now. Should a warning still be shown?
I assume those enemies are ok, as long as they are not on the same Screen, then? I think it would be too complicated to impossible (cheese exists always) to catch situations, where it "shouldn't" be a problem. So I'd be fine with always showing such a warning. Maybe with an option to "ignore" a particular warning for a level or a session.
I think you are right. Warnings are just that, warnings.
Would it be possible to group the enemies so that you can already see which ones can be together and which ones not in the toolbox? Workshop came with a table of enemies (SMB3 enemy compatibility by Spinzig), but the structure might be too complex for a UI...
While looking at the table, I also realise that it was that table where I got the dry bones + koopa trooper example from :P
We might need some warnings for autoscrolling as well:
- [ ] When scrolling above or below level boundaries
- [ ] When you scroll to the left with the original code you will instantly die when you touch the leftside border (this needs to be verified)
- [ ] When the autoscroll does not stop at the end. While this might be intended to never let the player rest, it is probably a mistake
i think the warnings should not be there if like PiJoKra said with a dry bones at the beginning and a koopa at the end with water in between, however if it's too much work to implement that then its not a big deal.
I think each autoscroll position has a certain length to it so when the autoscroll does not stop at the end then the level creator needs to lengthen the level to where the scrolling point does stop. Or did you find one that does not stop no matter how long the level is? Also maybe it should be noted that the Black Level ending screens are not compatible with autoscrolling levels maybe we should include that in the editor so people know to not use them in conjunction.
I didn't know that the endings are not compatible with the autoscroll. We can certainly add a warning for that.
I disagree with the warning for level generators not touching the ground. The generator does not crash the game because it does not touch a block before touching the ground. Rather, the generator crashes the game by going outside the memory bounds of the level. When the generator goes to the bottom of the level without touching the ground, it will actually be moved to the top of the next screen. It is only when the process continues, even after the level, that this results in a problem.
This can best be seen in the sky levels. The sky levels also have generators that extend to the ground. Unlike the Plains tileset though, the sky level has a block at the top of the level to solve this issue. As the generators extend to the bottom of the level they will always loop and hit that block at the top of the level, resulting in them stopping and not expanding any further. This can also be achieved in Plains levels as well, with a bit of trickery. You simply put ground at the top of the level and you can achieve the same effect. It is even used in a few hacks. In Kamikaze Bros, it is used in the boot level for a cool effect.
I believe the warning should reflect this in the editor by actually going through the process to see if it hits the end of the level. The user should not be warned of a sensible idea that is implementable in the actual game.
Warnings are implemented. There can always be more, so no reason to keep this issue open.