DropBear wrote on Jul 14
th, 2015 at 1:04am:
I'm not against a bit of humor at work, but that code is a workspace and it should be kept as clean as possible. Save the humor for the PacMan Larp zone or Friday night beverages.
For example, for the post above, I had to delete several hundred rows of "This is safety valve...." variations.
Haven't they heard of "ditto"?
I believe the problem is a psychological one.
The same behaviors are observable in the work kitchen space.
As soon as anyone leaves a dirty spoon, cup or plate, there is a cascade of shit left there because people feel "someone else did it, so it's ok". I've been quite amazed that even when people know the expectation is to clean your own stuff, that one person failing
suddenly sees everyone break behavior and become lazy asses.
The source code would be the same. Why would a new programmer/dev bother trying to be neat when all of the visible material around him is unregulated crap?
I've inherited legacy systems in my previous life as a systems guy. Fixing legacy systems is a PITA, but if an upgrade/replacement is not an option, then it needs to be done right.
You have a choice, operate it and leave it alone and blame the "other guy" for all the bugs and issues, and hope you don't get fired for it.
Or you get your hands dirty and own it.
You don't touch it till you know what you're doing, and you don't normally flaff around the edges - you start at the core and work out (depending on your timeframe and interest).
You change it and make it yours - no excuses "but the previous guy did that BS". Having bothered to change it, you then structure it in a clean, logical way that future systems people can follow it, understand it and maintain it.
To my mind, its simply about taking pride in your work. I get it, the Turdbine devs are overworked and underpaid, but someone has to bite the bullet before the system implodes.
Some queries for those proficient in game design and programming.
Surely the DDO sourcecode can be broken into modules for specific functions? Break out all the extraneous functions like Crafting, TR'ing, Guilds, AH/ASAH, Traders/turn-ins, Feat swaps, etc and focus the source code on the actual game functions?
For example, things like the Cannith Crafting systems should be a separate module that only is called and released as needed (thus saving memory and overheads), and can be maintained without impacting the rest of the game?
Seriously, how hard can recipes be?
We do some DB work in my business, and my guys can set up many tables collating all the related data separately and call upon the tables as needed. It makes maintenance and analysis so much easier seeing like data/functions together.
Wouldn't crafting recipes just be an entry in a DB table?
You standardize the code for all the parameters - bound/unbound, ML, pre-reqs etc and then make calls on the DB tables?
Same for loot tables? Have a central set of general loot tables that are called upon. So when they decide to change loot, you don't have to change it in 45 places.
Monsters? Shouldn't they be stored in a Monsters table? Bosses and raid bosses with specific behaviours might be different.
This would make coding and tracking monster types in the MM easier.
All the core info on a Monster - it's stats, resistances, AI behaviour, animations, skins etc could be in a central repository. Each content (quest) could then call and modify it as required.
And with the right toolset, you should be able to see the linkages between code and tables so that when you make a change, you know what it is going to effect?
This type of work would be hard in the early days of a game as you're adding new systems and functionality all the time - but in a mature game like DDO, you have or know most of your systems, so do the work to change it knowing you can see the big picture. If you think legendary weapons are possible, allow flexibility for it. That's the reason for having a plan/strategy - you have some idea what you would like to do, time and budget permitting.
Interested to hear your thoughts.
Basically this is known as "Coding best practices" and Turbine is too good for those

Yes, you're right, for a non-programmer you are amazingly right. But a few answers/tweaks
Putting it in a database is fine for the server side, but for the client it's harder because you either have to ship a database to every customer (not just the data, but the whole engine) or deal with network latency and extra bandwidth contacting the central server, neither is attractive. So local .DAT files are a reasonable compromise. Leaving the crap in them, though, is lazy. They don't want to go back and update the pointers of everything when they add a new one, so they add the changed block as a new block and just update the pointer in the one area that called it, rather than updating every pointer. Lazy, bloat inducing, and totally Turbine, through and through.
Putting code in modules is absolutely essential and they almost certainly already are, but they break "encapsulation", meaning they don't respect the boundaries of the modules. It's faster and easier to reach out to global variables than to pass all arguments as function parameters, so the functions see things change out from under them.
Having a tool to show links - probably not. There are some high end tools that can help with this, but not having those tools is understandable. What most of us use is documentation, religiously applied. Not having your links documented and maintained is a huge problem, and probably the first they should address, it shows where all the other changes that need to be made are.
And yes, when the code was young and growing fast putting some of those best practices off until it stabilized was not great, but a reasonable compromise. But that absolutely should have been addressed once the initial push was over, and definitely before a new push was started. That's the unforgivable sin. But it's not too late, they could absolutely clean it up now, and it would be less work to clean it once and code against it 3 times than to code 3 updates against the mess.
Deciding not to clean it up is a good decision only if you don't plan in being in business more than 9 months longer.