Hall of Failures

This page describes all the projects that I have attempted and failed to get done. Even though they failed, they don't deserve to be forgotten.

Most of these projects have failed because I lost my motivation at some point. Blarg.

The projects in there aren't available for download because they didn't go far enough to be useful or even usable.

Back to Blarg City

0. Table of Contents
Super NSMB Editor Unnamed NSMB hack NSMB Remaker BlueKinoko NSMBWii worldmap editor FuckedUpTetris LOLbuild NokoBot lolWiki lolBoard SMG2.5 Whitehole

0. Table of Contents

Super NSMB Editor
Unnamed NSMB hack
NSMB Remaker
BlueKinoko
NSMBWii worldmap editor
FuckedUpTetris
LOLbuild
NokoBot
lolWiki
lolBoard
SMG2.5
Whitehole

1. Super NSMB Editor
In September 2008, I found Treeki's NSMB Editor 2.1, and wanted to give it a try. However, back then the editor wasn't very well made. It suffered from a number of issues making it annoying to use. That editor wasn't being developed anymore, and I had some coding skills, so I figured, why not try and make another, better editor. Super NSMB Editor was born. I started coding it in C, using the Win32 API. Eventually, in about 3 months, the motivation fell down, mostly due to that API being a pain in the ass (take the word 'straightforward' and you have the definition of the exact opposite of the Win32 API). The project ultimately died in late November 2008 as I got myself banned from Jul and Board2. It has never been continued since then because it is really badly coded. Few of its features work without crashing, the rendering is wrong, and the translation system really sucks. Also, since then, NSMB Editor has been continued and the 4.x and 5.x versions are much better than the old 2.1.

1. Super NSMB Editor

In September 2008, I found Treeki's NSMB Editor 2.1, and wanted to give it a try. However, back then the editor wasn't very well made. It suffered from a number of issues making it annoying to use.

That editor wasn't being developed anymore, and I had some coding skills, so I figured, why not try and make another, better editor. Super NSMB Editor was born.

I started coding it in C, using the Win32 API. Eventually, in about 3 months, the motivation fell down, mostly due to that API being a pain in the ass (take the word 'straightforward' and you have the definition of the exact opposite of the Win32 API).

The project ultimately died in late November 2008 as I got myself banned from Jul and Board2.

It has never been continued since then because it is really badly coded. Few of its features work without crashing, the rendering is wrong, and the translation system really sucks. Also, since then, NSMB Editor has been continued and the 4.x and 5.x versions are much better than the old 2.1.

2. Unnamed NSMB hack
This project occured in the same time as Super NSMB Editor. Basically, I felt like trying to make a NSMB hack. Given the knowledge and tools available back then, this hack was nothing really impressing, just level editing. I started designing level 1-1, and was more or less satisfied with it. But at some point, NSMB Editor corrupted my level's header, making it unplayable. This event pretty much killed the project. Ignoring all of the good practices in ROM hacking, I didn't have a backup of my ROM, and I never found the motivation to copy my level over to a new ROM. Nothing remains of that project, aside from vague memories of what the beginning of 1-1 looked like. This was the first time I attempted a ROM hack project, and probably the last, given my (lack of) originality.

2. Unnamed NSMB hack

This project occured in the same time as Super NSMB Editor. Basically, I felt like trying to make a NSMB hack.

Given the knowledge and tools available back then, this hack was nothing really impressing, just level editing. I started designing level 1-1, and was more or less satisfied with it. But at some point, NSMB Editor corrupted my level's header, making it unplayable.

This event pretty much killed the project. Ignoring all of the good practices in ROM hacking, I didn't have a backup of my ROM, and I never found the motivation to copy my level over to a new ROM.

Nothing remains of that project, aside from vague memories of what the beginning of 1-1 looked like. This was the first time I attempted a ROM hack project, and probably the last, given my (lack of) originality.

3. NSMB Remaker
This has been my second attempt at a NSMB editor. This time, it was coded in C++/CLI. No more Win32 API. Development started more or less nicely. It was quickly able to render levels, although complex objects like slopes were still not rendering properly. However, my motivation started to fall down before I got around adding some editing support. The project ultimately died when Microworm, my Jul rereg account at the time, got discovered due to an error of mine. All that remains of this is a few screenshots; its source code is lost and no builds exist anymore.

3. NSMB Remaker

This has been my second attempt at a NSMB editor. This time, it was coded in C++/CLI. No more Win32 API.

Development started more or less nicely. It was quickly able to render levels, although complex objects like slopes were still not rendering properly. However, my motivation started to fall down before I got around adding some editing support.

The project ultimately died when Microworm, my Jul rereg account at the time, got discovered due to an error of mine. All that remains of this is a few screenshots; its source code is lost and no builds exist anymore.

4. BlueKinoko
~~It means BlueMushroom... IN JAPANESE!~~ This was meant to be a tileset editor for NSMBWii. After being able to display tilesets, it died. Mostly due to lack of motivation again, but also because there is already a tileset editor for this game (Wart).

4. BlueKinoko

~~It means BlueMushroom... IN JAPANESE!~~

This was meant to be a tileset editor for NSMBWii.

After being able to display tilesets, it died. Mostly due to lack of motivation again, but also because there is already a tileset editor for this game (Wart).

5. NSMBWii worldmap editor
The plan was to let NSMBWii hackers modify worldmaps fully. It would have supported replacing the worldmap models, placing/moving objects on them, modify the paths, etc... I knew nothing about 3D graphics at the time, and the .brres format NSMBWii uses to store its 3D graphics is very complex. These two factors ruined my motivation before I was able to get anything done.

5. NSMBWii worldmap editor

The plan was to let NSMBWii hackers modify worldmaps fully. It would have supported replacing the worldmap models, placing/moving objects on them, modify the paths, etc...

I knew nothing about 3D graphics at the time, and the .brres format NSMBWii uses to store its 3D graphics is very complex. These two factors ruined my motivation before I was able to get anything done.

6. FuckedUpTetris
I once have been linked to this Flash game and liked the concept. I wanted to make a version of it that would actually play like regular Tetris, except with the curved bottom. I started coding it in C++/CLI. But I knew nothing about proper game programming, and I didn't like how the code turned out, which killed my motivation.

6. FuckedUpTetris

I once have been linked to this Flash game and liked the concept. I wanted to make a version of it that would actually play like regular Tetris, except with the curved bottom.

I started coding it in C++/CLI. But I knew nothing about proper game programming, and I didn't like how the code turned out, which killed my motivation.

7. LOLbuild
This was meant to be a block building game, like Minecraft in creative mode. For it to be more than just a random Minecraft clone, one feature was planned: allowing blocks to be scripted with Lua or something similar. This feature would have opened many crazy possibilities. I got a basic rendering engine done, and distributed a test version to some people for testing. The version would display many polygons, just to test the limits of the rendering engine. It would run at ~60FPS for me, but 3FPS for everyone else. Since I didn't have an exceptionally powerful graphics card (some of the people who tested even had more powerful computers than me), I spent ages wondering where that could come from, and how to build a rendering engine that would be fast enough for everyone. This eventually killed my motivation.

7. LOLbuild

This was meant to be a block building game, like Minecraft in creative mode. For it to be more than just a random Minecraft clone, one feature was planned: allowing blocks to be scripted with Lua or something similar. This feature would have opened many crazy possibilities.

I got a basic rendering engine done, and distributed a test version to some people for testing. The version would display many polygons, just to test the limits of the rendering engine. It would run at ~60FPS for me, but 3FPS for everyone else.

Since I didn't have an exceptionally powerful graphics card (some of the people who tested even had more powerful computers than me), I spent ages wondering where that could come from, and how to build a rendering engine that would be fast enough for everyone. This eventually killed my motivation.

8. NokoBot
This was an IRC bot coded in C++ for shits and giggles. It was soon discovered that the IRC class it used suffered from a major issue: when receiving multiple lines of data at once, it would treat them all as one line. Given the non-serious nature of the project, I didn't feel like trying to fix it, and just let the project die.

8. NokoBot

This was an IRC bot coded in C++ for shits and giggles.

It was soon discovered that the IRC class it used suffered from a major issue: when receiving multiple lines of data at once, it would treat them all as one line. Given the non-serious nature of the project, I didn't feel like trying to fix it, and just let the project die.

9. lolWiki
I once wanted to build some wiki software that would have some Acmlmboard look and feel, and avoid some of Mediawiki's design flaws. A crude wiki system was made very quickly. A demo was even put online at some point. People could register and then proceed to edit pages. There were also user pages and talk pages, like on Mediawiki. As the 'Acmlmboard look and feel' part implies, pages could contain HTML. Therefore, little to no markup was supported— <h1> to <h6> tags were automatically numbered and added to the Contents box, but that was all. I never found the motivation to finish this side project or atleast get it somewhere. It is probably the most useful project of this page, but it wouldn't be usable for a serious wiki without quite some work. This hasn't been entirely useless, though. The Blargwiki is built off of it. Some of its code has also been reused to build the WikiXD plugin for ABXD.

9. lolWiki

I once wanted to build some wiki software that would have some Acmlmboard look and feel, and avoid some of Mediawiki's design flaws.

A crude wiki system was made very quickly. A demo was even put online at some point. People could register and then proceed to edit pages. There were also user pages and talk pages, like on Mediawiki.

As the 'Acmlmboard look and feel' part implies, pages could contain HTML. Therefore, little to no markup was supported— <h1> to <h6> tags were automatically numbered and added to the Contents box, but that was all.

I never found the motivation to finish this side project or atleast get it somewhere. It is probably the most useful project of this page, but it wouldn't be usable for a serious wiki without quite some work.

This hasn't been entirely useless, though. The Blargwiki is built off of it. Some of its code has also been reused to build the WikiXD plugin for ABXD.

10. lolBoard
The idea behind this project was to make an Acmlmboard type messageboard software, but using OOP for cleaner code. The project failed miserably. I took the OOP too far, and the code turned into a mess of objects. And nothing was even implemented aside from registering and logging in. The way the codebase turned pretty much destroyed my motivation. This is why trying to use OOP everywhere is a bad thing. OOP is nice in certain situations, but it can't be applied to everything.

10. lolBoard

The idea behind this project was to make an Acmlmboard type messageboard software, but using OOP for cleaner code.

The project failed miserably. I took the OOP too far, and the code turned into a mess of objects. And nothing was even implemented aside from registering and logging in. The way the codebase turned pretty much destroyed my motivation.

This is why trying to use OOP everywhere is a bad thing. OOP is nice in certain situations, but it can't be applied to everything.

11. SMG2.5
This project isn't mine, but given my involvement in it, it's still worth mentioning here. It all started when I showed off Whitehole (mentioned below) at NSMBHD. Members of the SMG2.5 project found it and approached me. I saw the project, and figured I'd be working with competent hackers. I wanted to use SMG2.5 to build a strong SMG hacking scene, pretty much like Newer on the NSMBWii side. I opened a new incarnation of Kuribo64 dedicated to SMG hacking, and offered the SMG2.5 team to move there to give them more credibility (they were using a Proboards forum) and make a stronger SMG scene. I also planned to contribute to SMG2.5 by doing ASM hacking, and of course, working on Whitehole. But things didn't go as I expected. I was quite disappointed when I entered their IRC channel. Nothing like the competent hackers team I imagined. Nothing but a bunch of kids fighting and causing drama. Noone to enforce any kind of rules. As the move to Kuribo64 happened, I institued a staff made of myself as a main admin, and cosmological and Glem3 as admins as they were the project's leaders. I also opened a new IRC channel for SMG2.5, that was under the staff's control. After a while of enforcing Kuribo64's no-drama policy, banning the worst members, and taking decisions in favor of the project's operation, things were a lot better. But of course, it wasn't perfect. While we were able to stop most of the drama, there were still arguments going on between the team members. Other factors, like the project's goals being unrealistic (49 full custom galaxies made of custom planets), or people contesting staff decisions they didn't like (yeah, it's easier to call the admin a dictator than to question yourself), led to very few progress actually happening. After three years and several motivational speeches, the project was getting nowhere. Not even one galaxy completed. It was calculated that at this rate, the project wouldn't be completed before 2158. Therefore, the project was eventually dropped. As of today, some of the project's original ideas are being used to build independent custom galaxies. In the end: • drama plagued SMG2.5 for too long, causing the best members of the team to leave • Glem3 was a good project leader, but unfortunately, not a good moderator. Without the drama, SMG2.5 would likely have went much further. • SMG2.5 was originally meant to just be little galaxy hacks, like shown on their Planet Plains trailer. Sticking to that would have worked better than wanting to make a full hack. I hate to say this, but at the time I joined, SMG2.5 was already doomed to failure. Relatedly, the SMG2.5 members have done an amazing job at documenting the SMG objects in Kuribo64's SMG object database.

11. SMG2.5

This project isn't mine, but given my involvement in it, it's still worth mentioning here.

It all started when I showed off Whitehole (mentioned below) at NSMBHD. Members of the SMG2.5 project found it and approached me. I saw the project, and figured I'd be working with competent hackers. I wanted to use SMG2.5 to build a strong SMG hacking scene, pretty much like Newer on the NSMBWii side.

I opened a new incarnation of Kuribo64 dedicated to SMG hacking, and offered the SMG2.5 team to move there to give them more credibility (they were using a Proboards forum) and make a stronger SMG scene. I also planned to contribute to SMG2.5 by doing ASM hacking, and of course, working on Whitehole.

But things didn't go as I expected. I was quite disappointed when I entered their IRC channel. Nothing like the competent hackers team I imagined. Nothing but a bunch of kids fighting and causing drama. Noone to enforce any kind of rules.

As the move to Kuribo64 happened, I institued a staff made of myself as a main admin, and cosmological and Glem3 as admins as they were the project's leaders. I also opened a new IRC channel for SMG2.5, that was under the staff's control. After a while of enforcing Kuribo64's no-drama policy, banning the worst members, and taking decisions in favor of the project's operation, things were a lot better.

But of course, it wasn't perfect. While we were able to stop most of the drama, there were still arguments going on between the team members. Other factors, like the project's goals being unrealistic (49 full custom galaxies made of custom planets), or people contesting staff decisions they didn't like (yeah, it's easier to call the admin a dictator than to question yourself), led to very few progress actually happening.

After three years and several motivational speeches, the project was getting nowhere. Not even one galaxy completed. It was calculated that at this rate, the project wouldn't be completed before 2158. Therefore, the project was eventually dropped.

As of today, some of the project's original ideas are being used to build independent custom galaxies.

In the end:
• drama plagued SMG2.5 for too long, causing the best members of the team to leave
• Glem3 was a good project leader, but unfortunately, not a good moderator. Without the drama, SMG2.5 would likely have went much further.
• SMG2.5 was originally meant to just be little galaxy hacks, like shown on their Planet Plains trailer. Sticking to that would have worked better than wanting to make a full hack.

I hate to say this, but at the time I joined, SMG2.5 was already doomed to failure.

Relatedly, the SMG2.5 members have done an amazing job at documenting the SMG objects in Kuribo64's SMG object database.

12. Whitehole
Whitehole is a level editor for the SMG games. Unlike Anarchy in the Galaxy, it featured a 3D view of the galaxy being edited, making editing easier. However, it lacked support for editing certain data types that Anarchy supported. It featured a BCSV editor for editing the raw game data, which was user-unfriendly. Making an editor that is easy to use is hard, especially with games as complex as the SMG games. This, combined with how SMG2.5 went, and the use of Java as a programming language for Whitehole, ended up killing my motivation. Given the current status of the SMG scene, Whitehole can be considered a dead project.

12. Whitehole

Whitehole is a level editor for the SMG games. Unlike Anarchy in the Galaxy, it featured a 3D view of the galaxy being edited, making editing easier.

However, it lacked support for editing certain data types that Anarchy supported. It featured a BCSV editor for editing the raw game data, which was user-unfriendly.

Making an editor that is easy to use is hard, especially with games as complex as the SMG games. This, combined with how SMG2.5 went, and the use of Java as a programming language for Whitehole, ended up killing my motivation. Given the current status of the SMG scene, Whitehole can be considered a dead project.