Legacy LD5

Quite possibly the most influential reason I may provide is that even though I am of the "new" generation, I am quite an ardent fan of the classics. I like games such as Tribes 2, BattleZone, Morrowind and other mostly forgotten titles in this age. That being said, I also liked Zork and any other game utilizing text as its sole component to describe the scene to players. I've noticed that the more modern games, Call of Duty, Unreal Tournament, etc are doing very little to make anything unique aside from perhaps upgrading the graphics a bit. Any of the games I saw that did implement anything unique tended to just have one unique function with which the entire game was hung upon, quickly wearing out that function or even sidestepping the game altogether. I noticed this in games such as Bullet Storm or Red Faction: Guerilla.

I had a handful of reasons for wanting to do it which I felt would have benefited the people at one point or another, and so I suppose I need to reiterate over them.

1. Better database format. The current format is the work of someone who really didn't know how to implement a proper database system,
it is just a giant ASCII dump that nobody really knows the format of anyway as I had to spend a decent bit of time myself reverse engineering it from the base databases to even begin working on the converter I was going to use to bring Faibanx up to date.
2. Better scripting, since it was written in Python and so would the commands, it would be significantly easier to write stuff for the MUCK that's easier to use (and less broken, see: Inrooms) and to make more advanced commands as it's easier to interact with the database and it's actually possible to bring in third party code to do quite literally anything. Some people didn't quite see the benefit of this, I see it as something to improve so that people would actually -like- to code things for the MUCK.
3. People apparently objected to the improved commands mentioned in #2 so I decided I should go along with it and also write a Fuzzball reimplementation so that you had commands that operated in the same way as the old MUCK.

I was completely willing to accommodate at every single turn, I had actually bothered to write the software and I was going to let it have a test drive before completely replacing the old MUCK to have a chance to iron out any last minute kinks but apparently this isn't possible.

I don't care that it was a niche thing to do, it was decent programming practice for me in the end either way. It taught me how to use GIT properly as this is project was the first major codebase I had used GIT for. Furthermore, I developed a decent versioning paradigm from it as my old versioning scheme for ScalyMUCK was completely out of control. It has even taught me some basics of persistent storage across a network as I had to eventually work out a failsafe in the event the connection was closed or the database server became unreachable. The project also taught me that I should think ahead when developing software, as the original codebase that took about two days to actually complete (ask Dinosorceror) was an absolute mess and from then on the core received two more major enhancements that probably should have been in there from the start.

I was just trying to do something nice with my educational drive, but apparently that's a bad thing to do.

I had a handful of reasons for wanting to do it which I felt would have benefited the people at one point or another, and so I suppose I need to reiterate over them.

1. Better database format. The current format is the work of someone who really didn't know how to implement a proper database system,
it is just a giant ASCII dump that nobody really knows the format of anyway as I had to spend a decent bit of time myself reverse engineering it from the base databases to even begin working on the converter I was going to use to bring Faibanx up to date.
2. Better scripting, since it was written in Python and so would the commands, it would be significantly easier to write stuff for the MUCK that's easier to use (and less broken, see: Inrooms) and to make more advanced commands as it's easier to interact with the database and it's actually possible to bring in third party code to do quite literally anything. Some people didn't quite see the benefit of this, I see it as something to improve so that people would actually -like- to code things for the MUCK.
3. People apparently objected to the improved commands mentioned in #2 so I decided I should go along with it and also write a Fuzzball reimplementation so that you had commands that operated in the same way as the old MUCK.

I was completely willing to accommodate at every single turn, I had actually bothered to write the software and I was going to let it have a test drive before completely replacing the old MUCK to have a chance to iron out any last minute kinks but apparently this isn't possible.

I don't care that it was a niche thing to do, it was decent programming practice for me in the end either way. It taught me how to use GIT properly as this is project was the first major codebase I had used GIT for. Furthermore, I developed a decent versioning paradigm from it as my old versioning scheme for ScalyMUCK was completely out of control. It has even taught me some basics of persistent storage across a network as I had to eventually work out a failsafe in the event the connection was closed or the database server became unreachable. The project also taught me that I should think ahead when developing software, as the original codebase that took about two days to actually complete (ask Dinosorceror) was an absolute mess and from then on the core received two more major enhancements that probably should have been in there from the start.

I was just trying to do something nice with my educational drive, but apparently that's a bad thing to do.