Prologue
A few years ago, I started making my first Mario fangame; it was titled: “Mario and the Crystal Coins”. It was going to be a 2D open world, Super Mario World-styled game, where you would run around multiple open levels collecting “Crystal Coins”, similar to the 3D Mario games, or another fangame called “Super Mario 63”.
One day, while taking a break from the game’s development, I was playing Super Mario World, specifically the widescreen hack for it, and while playing through Chocolate Island 4, I remember saying out loud: “Yea, I could probably make this…”
And so work began. I took the project files for “Mario and the Crystal Coins”, and immediately started modifying it, to instead be a remake of Super Mario World, titled: Super Mario World Remastered.
Chapter 1 - The Plan
The main idea for this remake was simple.
Remake the original Super Mario World, from the ground up, add all the features and additions from the already existing remake on the GBA, put it in widescreen, and call it a day. Simple.
I wanted it to be my “definitive” way to play Super Mario World, a game which I enjoyed playing quite a bit. I also wanted it to be a way for me to have access to a version of Super Mario World that I could easily modify; since I was no longer working with SNES hardware, I could do anything without the need to fight the limitations of the console, and didn’t need prerequisite knowledge on programming in 65c816 assembly.
I was also quite fond of the art style for Super Mario Maker, which featured a drop shadow behind sprites, and more vibrant colours to help each tileset pop out from the background, so I added these early into the project’s development.
This was my first time doing a remake of an already existing game—an old game specifically—with many design quirks and technical details that some would argue were incredibly important in preserving, to maintain the game’s original identity. However, as I was still a relatively novice game developer (this was my fourth “serious project”), I didn’t make much effort to focus on accuracy to the original.
Resolutions were increased, physics and controls were eyeballed, behavior was tweaked. With most of the first world of the game being completed in about a month; with most of the core systems now in place, the rest of the game’s development was just focused on adding content: more levels, more enemies, more items.
However, as development was going along, I was playing other games too, and slowly getting more and more ideas for new content that I could add to the game…
Some ideas I would argue were signs of me slowly losing my mind…
Chapter 2 - Ambitious, to a fault.
I had many ideas of things that I wanted to add to the game. With most of them actually in the game at one point. However, most were removed, simply due to me realizing that they were over-ambitious, and contributing heavily to the game’s already strongly growing feature creep, so here’s a list most of the ideas that I can recall having.
Scrapped Ideas
- Challenges - after finishing a level, when replaying it, you can select to have an optional challenge, such as running back to the start of the level within a time limit, similar to Pizza Tower and ANTONBLAST. Or being chased by a “Cosmic Clone”, that would mimic every action, like in Super Mario Galaxy.
- Fishing - Yep, not kidding. You would go to various spots on the world map, and you could fish, in a similar manner to Stardew Valley (the game I was playing at the time), and could catch fish which would net you extra lives, or items.
- Toad Houses - Similar to fishing, but more sane / on brand, I think you would’ve played a mini game of some kinda to get a power up, or maybe it would just give you a random one, not sure.
- Encore Mode - Like Sonic Mania’s Encore Mode, would feature new visuals for every level, and new mechanics. Was reworked into the final game’s “Overhauled Autumn”
- Airships - Tied into the Encore Mode idea, but was eventually separated. After finishing a world, it would get a random chance after clearing any level to get invaded by an airship, which you could play to save it. Airship levels were straight from Super Mario Bros. 3, and featured a unique boss fight, featuring Boom Boom.
- Time Trials - After clearing a level you could activate a “Race Gate”, which would start recording your current play-through of a level, and could race against ghosts of previous runs.
- LOADS more power ups - Superball, Racoon Leaf, Mega Mushroom, Metal Cap, all were added at some point, but were left unused / scrapped because of the amount of work required for new sprites.
- VS Mode - Based on New Super Mario Bros.’s VS mode, players would run around a looping level collecting stars in a time limit, scrapped because of difficulty getting split screen to work, alongside the seamless looping. (and also because it was completely off the rails)
So yea, there were a LOT of ideas that I had, and fortunately most of them ended up getting scrapped, but there were still ideas that made it in, that I now regret adding.
The main issue with it was that it showed how ambitious I was during development, alongside how arrogant I was with it too. My mindset became focused on the idea that this game was going to go viral; there were dozens of remakes of SMB1, that all got pretty popular, but there were no remakes of SMW, meaning that this one was GUARENTEED to be more popular than any other! (Ironic, considering how things have now turned out…)
I was so arrogant about it, that it started to affect my personal life as well. I was 17 at the time, in college, and the game was all I talked about with friends; they ended up getting sick of hearing about Super Mario World. I was also so focused on developing this game, that at one point, I wasn’t going to make it into the university I wanted. I didn’t realize that then, since I was so focused on working on this game that was going to be “amazing”, and “popular”.
However, as my personal life began failing, development started getting rockier, and rockier…
Chapter 3 - “A bad workman blames his tools”
Since I was so young and inexperienced while working on this game, I would make a LOT of bad choices during development. Alongside my VERY HIGH ambition, I was adding a lot of features very quickly, with very little regard for the current structure of the codebase, and the overall guidelines that projects should have, to ensure they stay organized, cohesive, and expandable.
Alongside this, I was using Godot; an open-source game engine, which I had used for a few years at that point, but still had a lack of understanding on some of Godot’s technical design features. I was also using Git; a version control system, and it was my first time using it. However, my lack of understanding on how Git works, alongside using it incorrectly with Godot, meant that the project would very soon become “haunted”, with Godot very often either crashing, having export-only bugs, or corrupting scenes and resources, requiring manually fixing their files in text editors—in this project exclusively. This would cause me to develop a STRONG disdain for Godot, as every time one of these issues happened, it reinforced the idea in my mind that Godot was the issue, and that it was unstable, rather than the project and my general workflow actually causing Godot to be this unstable.
Alongside this, any bug reports that I would file for Godot would very often be met with disagreements from key Godot contributors, replying along the lines of: “This is by design” / “This is part of Godot’s design philosophy”, which would cause me to become very frustrated, as I believed that these were genuine issues and bugs with Godot that people were just refusing to fix. Looking back however, I can see that the vast majority of these issues I filed were just a result of not using the engine right. Godot isn’t perfect, but it’s definitely not as bad as I thought it was.
To be honest, the fact that Godot could barely handle my project without crashing should’ve been a sign that things were VERY wrong.
Chapter 3.5 - Raising the bar
During this time, another person started developing their own remake of Super Mario World in Godot.
Their name was wye, and they were uploading devlogs of their progress to YouTube. Unlike me, wye was an incredibly experienced Super Mario World ROM hacker, and had a lot of experience and technical knowledge on Super Mario World, and its code. This allowed them to start recreating the game with horrifyingly accurate gameplay. Up until then, accuracy was something that I ironically wasn’t particularly focused on. But after watching some of these videos, I decided that accuracy should be something I should try and salvage, while I still had time. With this, wye turned into a friendly rival / competitor; I got in contact with them, just to let them know that I was coincidentally doing a Godot remake of SMW, and they were incredibly nice about it, wishing us luck on our projects, present and future! I learnt a lot from wye and their videos, and it really helped me understand some of SMW’s code in a way that was easy to learn and understand, at the time.
I HIGHLY recommend watching their video series; they’re all incredibly well written and really entertaining / informative videos on technicalities of SMW. You can find a link to their channel here.
Chapter 4 - It grew into shame.
At this point, the project was at around 80% completion, and I began sharing builds with some friends and mutuals to get their opinions.
As expected with all games, there were LOTS of bugs, which I quickly got to fixing. However, a lot of these bugs were caused by early design choices with how I designed the codebase. So quite a few bugs required significantly more work than what should be necessary. Alongside this, accuracy was something that a lot of people were unsatisfied with. This was to be expected, as initially, maintaining parity with the original game was not a priority to me. However, as accuracy had recently become something I was more interested in, it meant that these critiques would mean a lot more to me than they would’ve done before. Unfortunately, these accuracy complaints would require total rewrites of various mechanics and entities, to an already nearly complete game. I settled that they were unfortunately just stuck like that, and that it was too late to make any drastic changes.
One person helped to note the more important gameplay inaccuracies, compiling them into a spreadsheet, which I would work my way through. However, the sheer number of inaccuracies and nitpicks (there were over 70) made me realize that the game would be basically unsalvageable, in terms of accuracy. This really bothered me, and it felt like the nearly 2 years I had spent on the project had been for nothing. Alongside all the bugs and issues people were having, as well as this being my first finished project to be released to the world, I was worried that people would judge me, and my ability to program, based on something that I myself wasn’t even particularly proud of.
Because of this, I began to be ashamed of this project. It was something that was disrespectfully inaccurate, buggy, and badly designed, and I didn’t want it to become something that people would judge me with. I released the game in February 2025, more so as a way to just get it over with, and released an update shortly after, fixing the last few bugs I could. In May of 2025, I archived the project, stating that I would no longer support it, nor was interested in it anymore.
The main reason I archived it was because it was something that was not up to my standards anymore. I was working on another project now, and I made sure not to make the same mistakes I did before: properly learning Git w/ Godot, and properly planning out code to ensure that it would be something that could easily be expanded and scaled later on.
I enjoyed remaking a game that I loved; however, by the end, I didn’t enjoy working on Super Mario World Remastered anymore. It didn’t feel like a proper remaster of a game, and more so felt like a crappy attempt to recreate it. I wanted to reassure myself that I COULD remake a game well, so soon before the game would release in February, I began work on my next remaster: Super Mario Bros. Remastered.
I’m happy with how Super Mario Bros. Remastered has turned out, not because it’s simply a better made “remaster”, but because it’s proof that I’d finally learned and applied everything that SMWR taught me.
Chapter 5 - Reflection
So, what actually did cause the project to go so awry? I believe it’s because of a few major things.
1 - Major features, hacked in, later on
This is something I still struggle with to this day, but SMWR definitely had it the worst. Essentially, I would come up with major ideas for new features later on during development. A lot of these features are ones that would require the entire game to be planned around. However, because they were being added later on, they would require significantly more work to ensure that it would work with the current codebase.
The prime example of this would be multiplayer; nearly the whole game should be designed around supporting multiple players. However, multiplayer was something I added about 6 months in. With an already established codebase, it was a nightmare to try and fit in—so much so, that I often wonder why I didn’t just cut my losses, and scrap the idea, like I did with every other. Working on multiplayer was simply a nightmare, as I was unable to effectively test it, due to not having many friends that were available to play it often, and a lack of controllers to test more than 2 players at once. Because of this, multiplayer is one of the buggiest features in SMWR, and working on it is the sole reason why Super Mario Bros. Remastered has no multiplayer at all, even though the original did have a primitive form of multiplayer.
It’s a habit I still struggle with now, and you can see it in Super Mario Bros. Remastered; both the defining features of it to many were added on far later in the project’s development, including Custom Characters, Resource Packs, and the Level Editor—all being added after the core game was essentially finished. These features now require lots of attention to maintain and update; however, they’re features that I enjoy working on, as it allows the community to show off their creativity and further personalize the game.
The issue wasn’t adding ambitious features; it was that, at the time, I wasn’t properly considering the foundations and prerequisites they would require. Features like multiplayer or modding will heavily influence a game’s architecture from the very beginning, and require VERY careful planning and designing to ensure its inclusion isn’t detrimental to the project’s architecture.
2 - A focus on modding
Typically, a game with a focus on modding usually means good things. However, SMWR had a larger than needed focus on it. During the game’s development, I discovered a feature of Godot which would allow players to import custom data and files into the game’s already existing filesystem, similar to how DOOM can load in custom .WAD files containing data. This would mean that if I structured some of the game’s data to be file-based, I could allow for things such as custom characters, levels, campaigns, etc. All of which were added into the game, with various aspects of the game modified to support this.
However, when some friends tried to actually make mods for the game, a huge issue arose.
The way that I had implemented it relied on the functionality of a feature that didn’t work as expected.
This was a big issue. A big feature of the game that I had hyped up for a long time didn’t actually work, and it was something that I couldn’t actually fix. This REALLY killed a lot of motivation for me, as it felt like any other idea I had could be something that just wouldn’t be possible, or would be misleadingly broken. I had spent so much time focusing on modding features, when I could’ve spent that time working on other more important things; a lot of time was wasted because of this.
In hindsight, I was trying to create more of a platform, rather than a game. I wanted people to make their own experiences with SMWR, but SMWR wasn’t designed around that dream.
3 - A toxic mindset
This is probably the thing that harmed the game the most: my mindset.
My main thought while making this game was: “This game is gonna be popular”. My reason for this was because it was the only remake of Super Mario World available, meaning that it was going to be popular due to having no competition. The issue wasn’t that I wanted to make something that could be popular; wanting a project to succeed is normal. The issue was that I thought I was OWED popularity, and that it was guaranteed, as soon as the game released. With this mindset, it also made me believe that this game would set up any future successes I would have.
As a result, the game became my main priority during a time where my education should’ve been the top priority. I would open up Godot in the middle of class just to playtest; because of this, my grades dropped, to the point that I wasn’t going to make it into the university of my choice. Luckily, I took some time off from SMWR to focus on my studies, and with the help of my college’s phenomenal staff, I was able to get the grades and make it into the university where I am now.
Alongside this, I became extremely arrogant. I had remade a game that wasn’t even mine, and I was dead certain it was going to be extremely popular, and for some reason, I thought that’d made me the world’s greatest programmer / game designer. I became insufferable to be around for my friends, as all I’d talk about was Godot or SMW. I’m grateful that one of them stuck by me through it.
Because this was my first serious game, I felt extremely attached to the game, even if I was ashamed by it. I took criticism very badly initially, and took all complaints on the game to be attacks on myself as a programmer. One incident resulted in a pretty bad argument with one person, where they were initially saying stuff that I was saying myself about the game, yet for some reason I took it incredibly personally. As I’ve made more projects afterwards however, I’ve been able to separate my work from myself, and have worked to not take critiques personally.
For a long time, I thought Super Mario World Remastered was a failure. It was a project that has taught me so much, yet it was one that I was the least proud of.
However, after working on other projects, and spending time learning from my mistakes, gaining a better understanding of game development, a thought was in the back of my mind:
“What if I tried again? What if I did it properly this time?”
Chapter 6 - Redemption
And so, that’s what I did.
For the past week, while taking a short break from working on SMB1R, I decided to give it another go: remake Super Mario World, inside Godot, from scratch. But this time, utilize all the lessons and knowledge I had gained, from working on various other projects.
Mind you, I didn’t want to do the full game; that was exhausting, doing it last time. So, I just focused on 1 level: Yoshi’s Island 1. A simple one-and-done project.
I’ve called it: “SMWR Redemption”
And to be honest? I think I’ve done a banging job!
Obviously, it’s not perfect, there’s quite a few missing features, that I didn’t bother adding, simply due to the fact that it’s a single level demo; however, I’m incredibly proud of how it’s come out. Accuracy-wise, I’d say it’s around 90% accurate to the original, compared to the probably 50–60% accuracy the original SMWR had. It’s also fooled every friend I’ve shown footage of it to, when I’ve claimed that it’s just the original game.
On the first day, opening that blank project, it felt incredibly weird. I felt like I was digging up an old grave, of an abandoned friend. I was scared that I wouldn’t get very far, and that I actually had learnt next to nothing. Regardless, I started coding. By the first few hours, I had re-coded the player’s base movement, and it felt right almost instantly. For the first time, I wasn’t just eyeballing or guessing behaviour; I actually understood why the original game behaved how it did. It was an incredibly weird feeling. I felt confident; it felt like I could FINALLY do the thing that I wanted to do, nearly 2 years ago now. It stopped feeling like disturbing the past, and more so properly finishing what I had dropped years ago.
I’ve spent a lot of time focusing on accuracy, specifically. Translating and understanding the original game’s physics and code, through an unofficial reimplementation of the game’s assembly code into C, which is a much more readable coding language. From my experience in university, being able to learn C, I was able to piece together the game’s logic, and physics, and recreate its functionality as best I could, in Godot.
This project would not have been possible without the reimplementation. Please show it some love: https://github.com/snesrev/smw
Super Mario World is an incredibly old game, and some of its code definitely shows it. It utilizes lookup tables nearly everywhere, without weird bit shifting operations being frequent. However, I was able to mostly understand what it was trying to accomplish, without having to really understand the fancy bit logic.
After experiencing all of this, I’d like to talk about some of the more technical things about it, that I found interesting, and other people may find helpful, if they want to do these sorta remakes, feel free to skip this, if you’re not particularly interested in the technical details of a 35 year old game.
Chapter 6.5 - Notes
1 - There is VERY little easy to understand documentation
When developing both SMWR, and SMB1R, the one thing that frustrated me a lot, was the lack of any documentation, on the code for the games, for people that weren’t already familiar with the game’s code.
If you wanted to figure out physics values? You were lucky if there was anything for the player, let alone how fast a Goomba moved.
JDaster64; a fellow SMB1R staff member, has made some excellent physics guides on the player’s raw physics values for both SMB1 and SMW, which were used extensively when developing both SMWR and Redemption.
And that’s sorta it in terms of readable documentation! From there, you’re basically on your own. This was something that I really struggled with in SMWR, as I had to basically eyeball every single line of code. However, this time, I was able to use the reimplementation to get the movement logic and values for the rest of the entities.
The reimplementation works in sub-pixels (1/16 of a regular pixel) for most movement values (a x_speed of 32 = (32 / 16 sub-pixels per pixel) = 2 pixels per frame).
Alongside this, most of the game’s entities (“Sprites” as they’re officially called) use the same gravity logic, meaning that they all have the same gravity values, and max falling speed.
For other retro games, there’s many similar re-implementations, de-compilations, or references online of their code. I highly recommend using these if you can, as they will make or break a project.
For SMB1R, I referenced Mari0’s source code a lot, as it’s pretty damn close to the original game’s behaviour: https://github.com/Stabyourself/mari0
2 - The Coin That’s Actually a Berry, That’s Actually a Star
In Super Mario World, when an enemy gets defeated, they get turned into a coin, which moves along the floor, and bounces upon impact. It’s a simple enough entity, that took nearly 2 hours to find where its code was.
I had already guessed how its behaviour worked. However, I wanted to cross-reference it with the original game’s code, to ensure that my guess was correct. The issue was that I couldn’t find the relevant functions anywhere! I searched for “Coin”, “Bouncing Coin”, “Moving Coin”, and couldn’t find ANYTHING, that would suggest that it was the specific coin that I was after.
So, I tried looking elsewhere. I searched through the SMW Central forums, and found a comment saying that these coins were actually berries; fruit that Yoshi could eat, to give a coin. Why it’s this way, is beyond me. After telling this story to a friend, they suggested that it could be a cut idea, of berries potentially falling off of bushes, and bouncing around?
A coin, that was actually a berry.
Even then, I had no luck finding the berry in the code either. This really frustrated me, so I went into SMW Central’s Discord server to ask; it’s easier to just get a personalized answer from someone that actually knows SMW’s code well.
“Anyone know where the assembly code for moving coin sprites are found? I can’t seem to find them anywhere…”
After talking with some server members for a bit, they said that there was no disassembly of the coin, that they were aware of. Brilliant. If they didn’t know, how the hell was I supposed to? A reminder that all this effort was for a basic coin.
However, they did point me to a fully commented disassembly of the game, which may give me some more answers. One of the comments was for an initialization function for the moving coin object. However, it was in pure assembly code, which I wasn’t able to read. Fortunately, I was able to quickly cross-reference its location, with the reimplementation, to find it point to, a star? That cannot be right…
After reading through its function, it was in fact, a star. The same star that bounced around a level, and gave the player invincibility. I found the code that would draw a berry, if a specific flag was set. Reading on, I then found the code that would make it look and behave like a coin, all in the same function. That one comment was right: The coin, was actually a berry, which was actually a star. No wonder I couldn’t find it!
To top it all off, after translating the code over to Godot, the movement logic ended up only being 5 lines. Great. 2 hours of searching and getting confused and frustrated, for 5 lines of code…
3 - Super Mario World’s Coding Quirks
This is going to be a bit of a rapid fire of funny / interesting discoveries I found, while developing the demo, and reading through the code.
Rex’s stomp height, is higher?
For some reason, when spin jumping on a Rex enemy, the height in which you bounce off is completely different, from every other enemy. It uses the standard bounce heights, instead of the proper spin jumping heights. As to why this is the case, I have no idea, but it’s very easily noticeable when playing the original game.
Most enemies’ function, for handling being spin jumped on.
Rex’s spin stomp function.
Sprites are not pixelated, when transitioning
This is probably one that people are already aware of, but when transitioning to and from levels, the game does this neat pixelation effect. However, this effect only works on the game’s terrain and backgrounds, due to the way that the SNES handles its rendering pipeline, as the pixelation happens to tiles, which are drawn first, before then drawing the sprites.
Notice how the piranha plant is still clear, and isn’t affected by the pixelation, as it is a sprite.
Epilogue
So, after going through all of this; after making the original SMWR, after releasing SMB1R, and after working on Redemption: There’s a question I would like to revisit.
Is Super Mario World Remastered a bad game?
Yes. It’s still bad.
However, I think the way I look at it has definitely changed, and I can definitely see it as more than just a bad game.
It was an incredibly valuable lesson to learn, and it was one that I think any aspiring developers will need to learn, in order to make something they’re truly proud of. It taught me a lot about project management, development, game design, and general programming. All of which are skills that helped me make SMB1R into the game it is today. While still not perfect, it’s in a state where it’s easier to maintain, and continue to improve upon it; that was nearly impossible to do with SMWR.
While making SMWR Redemption, the biggest difference I noticed to how I worked wasn’t the code I wrote, or the new Godot skills I learnt: it was my approach, and mindset.
While making SMWR, I thought the difficult part would be just writing the code, and that if the game LOOKED like the original game, and had all the same mechanics, it would be a good enough remake. However, while working on Redemption, I realized that the difficult part isn’t recreating what the game does; it’s actually being able to understand why it does stuff, and being able to understand what’s going on under the hood, and being able to then re-translate that, into more modern coding practices.
A lot of what makes Super Mario World so iconic isn’t strictly the music and graphics; a lot of it is in the game’s feel, and how it handles. You can have something that looks nearly exactly the same as the original game, but players will quickly notice if a game that they’ve been familiar with for so long, is slightly off. It’s extremely important to be able to recognize, what truly gives a game, its identity.
It’s also ok, to make changes to these games’ design, so long as it’s within reason, and with respect to the original game’s design. It’s ok to adjust player physics, to be less stiff, and provide the player with a more expressive set of controls, provided those changes work well with the original game’s design. It’s ok to be able to recognize, that something that used to work then, may need updating now. The original game designers go through the same mentality, as each game always changes and improves upon something the last game had. It’s how we all learn, grow, and improve, as game developers.
Super Mario World Remastered was never the project I truly wanted it to be. Without it however, SMB1R never would’ve happened; I was able to meet the majority of the team through this game, learned lessons that I still remember today, and have gained an appreciation for game development, that I simply didn’t have, back when I was 17.
Stepping back now, I don’t see SMWR as a successful remake. I see it as the project that truly taught me how to make one.