MonoSMBX (far future)
Posted: Thu Dec 15, 2016 8:18 pm
While I don't have time for it right now (doing my own SMBX world and also working on my indie 3d platformer as my main project) in future I'd like to do completely open-source replacement for SMBX engine, because it being a VB6 one poses few very severe restrictions on amount of stuff possible in a level or a world that cannot be easily overcome.
To do that, I've chosen MonoGame since it's multiplatform which would make it possible to release it on multiple platforms, such as all main operating systems (Windoze, Linux, MacO$X) and possibly even on smartphones (even if Google/Apple won't allow it for some reason, we could still build apk for sideloading and ipk for jailbroken devices) and also because C# is pretty cool and easy.
So why to write about it now even though it's way out? Well, to do that I'd need few things.
- Level format specification and other custom binary format
- LunaLua modules so I can integrate it with the new engine by default
- If Redigit didn't took it away when he left to make Terraria, access to current engine's source code so I can implement stuff using same algorithms, while increasing maintainability and removing bugs/limits of the current engine.
All of the above is needed to maintain backwards compatibility with current worlds. Obviously worlds that relied on exploiting bugs/glitches in the current engine wouldn't be preserved, but rest would need to work.
Another reason is maybe I'll inspire someone to start it already instead and then I could contribute when I'll have time to do so.
What I want to do with it:
- Add higher capacity for customization such as defining block info that gives possibility to set collision type (one-way or not and if one way, which side needed to collide) in similar way you can customize NPCs now
- Better, saner spritesheet format (legacy one will be preserved for compatibility reasons) where GIF transparency/png alpha channel would be used (the latter may already be used by luna lua, but not sure about that as I haven't used pngs in my level yet) while masks would be used for collisions.
- Ability to override title sequence with the custom one if the "customized" world is the ONLY world in the worlds folder which would allow for easy making of "customized" versions of SMBX containing one specific world. Kinda like you can replace title and menus in Doom WADs.
- With the above, no hardcoded graphics whatsoever, every single one would be able to be replaced with caveat that some replacements won't work if there's more than single world in the worlds folder.
- Ability to define custom events commands with Lua so if a programmer works with a designer who isn't particularly good with programming, he could make easy snippets to use within levels. *
- Overhaul of the event system so it would be similar to one used in RPG Maker and thus both easy and powerful. *
- New editor that is similar in usage to Mario Maker while being more powerful.
- Ability to stack enemies/enemies capable of taking modifiers/powerups. *
- Less bugs/exploits and no limits in terms of levels/worlds/tiles
- Better episode selection. Every episode would be able to have custom thumbnail/boxart. The menu would work similar to the one on the NES Mini.
- Ability to launch editor directly from the main menu (and possibly built-in one when new editor would be developed).
* May require new, extended level format - before that full compatibility with existing one is needed and existing one will be kept even after extended one is developed for backwards compatibility.
Someone may say "why not PGE then - we already are using the editor, may as well use the engine"? Good and perfectly valid question. The problem with the engine side of PGE is that it is being developed as general purpose platform engine, which is both a blessing and a curse since SMBX-specific stuff allows for making assumptions about how things would be progressing thorough the level instead of having to account for every single possible outcome in a platform game.
Another problem with PGE is that it is being developed in C++ which has very slow iteration rate and it's easy to introduce a tragic bug such as crashing while there is unsaved progress or invalidating a save file due to a forgetting to close a file.
C# on the other hand is easy and fast to develop for and most common "serious" bugs, such as buffer overflow or segfaults are very hard to produce there, unless you are actively trying to introduce those. Another thing is that you get access to the powerful .NET library which simplifies many things including networking (always PITA) and even handling zip archives (zipped worlds anyone instead of having to unzip those?).
So will you help me? I certainly I can't do it alone, even if I have all the time in the world and without these three things I've mentioned at the beginning it would be even hard for me to actually start (the best place to start with a project like this is to make simple world/level viewer and then slowly add features such as animation, sound/music and finally gameplay and menus).
To do that, I've chosen MonoGame since it's multiplatform which would make it possible to release it on multiple platforms, such as all main operating systems (Windoze, Linux, MacO$X) and possibly even on smartphones (even if Google/Apple won't allow it for some reason, we could still build apk for sideloading and ipk for jailbroken devices) and also because C# is pretty cool and easy.
So why to write about it now even though it's way out? Well, to do that I'd need few things.
- Level format specification and other custom binary format
- LunaLua modules so I can integrate it with the new engine by default
- If Redigit didn't took it away when he left to make Terraria, access to current engine's source code so I can implement stuff using same algorithms, while increasing maintainability and removing bugs/limits of the current engine.
All of the above is needed to maintain backwards compatibility with current worlds. Obviously worlds that relied on exploiting bugs/glitches in the current engine wouldn't be preserved, but rest would need to work.
Another reason is maybe I'll inspire someone to start it already instead and then I could contribute when I'll have time to do so.
What I want to do with it:
- Add higher capacity for customization such as defining block info that gives possibility to set collision type (one-way or not and if one way, which side needed to collide) in similar way you can customize NPCs now
- Better, saner spritesheet format (legacy one will be preserved for compatibility reasons) where GIF transparency/png alpha channel would be used (the latter may already be used by luna lua, but not sure about that as I haven't used pngs in my level yet) while masks would be used for collisions.
- Ability to override title sequence with the custom one if the "customized" world is the ONLY world in the worlds folder which would allow for easy making of "customized" versions of SMBX containing one specific world. Kinda like you can replace title and menus in Doom WADs.
- With the above, no hardcoded graphics whatsoever, every single one would be able to be replaced with caveat that some replacements won't work if there's more than single world in the worlds folder.
- Ability to define custom events commands with Lua so if a programmer works with a designer who isn't particularly good with programming, he could make easy snippets to use within levels. *
- Overhaul of the event system so it would be similar to one used in RPG Maker and thus both easy and powerful. *
- New editor that is similar in usage to Mario Maker while being more powerful.
- Ability to stack enemies/enemies capable of taking modifiers/powerups. *
- Less bugs/exploits and no limits in terms of levels/worlds/tiles
- Better episode selection. Every episode would be able to have custom thumbnail/boxart. The menu would work similar to the one on the NES Mini.
- Ability to launch editor directly from the main menu (and possibly built-in one when new editor would be developed).
* May require new, extended level format - before that full compatibility with existing one is needed and existing one will be kept even after extended one is developed for backwards compatibility.
Someone may say "why not PGE then - we already are using the editor, may as well use the engine"? Good and perfectly valid question. The problem with the engine side of PGE is that it is being developed as general purpose platform engine, which is both a blessing and a curse since SMBX-specific stuff allows for making assumptions about how things would be progressing thorough the level instead of having to account for every single possible outcome in a platform game.
Another problem with PGE is that it is being developed in C++ which has very slow iteration rate and it's easy to introduce a tragic bug such as crashing while there is unsaved progress or invalidating a save file due to a forgetting to close a file.
C# on the other hand is easy and fast to develop for and most common "serious" bugs, such as buffer overflow or segfaults are very hard to produce there, unless you are actively trying to introduce those. Another thing is that you get access to the powerful .NET library which simplifies many things including networking (always PITA) and even handling zip archives (zipped worlds anyone instead of having to unzip those?).
So will you help me? I certainly I can't do it alone, even if I have all the time in the world and without these three things I've mentioned at the beginning it would be even hard for me to actually start (the best place to start with a project like this is to make simple world/level viewer and then slowly add features such as animation, sound/music and finally gameplay and menus).