(separate post since this may warrant splitting the thread)
Honestly, while I completely respect the triage on these feature requests, I think it's getting a bit dangerous that many of the SCP coders haven't stayed in touch with some of the more recent, more ambitious projects. Features have been implemented in the past 'just' for TBP or Diaspora or whatever, and while it's true that these projects have dedicated coders to make it work, I think it would be seductively easy to misapprehend exactly how significant of an achievement WoD represents -- and, from there, decide that 'just for WoD2' is somehow less significant.
And I know that the respect and appreciation of some of the oldest SCP architects would feel really valuable to the people who are pushing that engine.
That's a great perspective, and I know (from what others say, even if I haven't played it myself) that campaigns like WoD and Diaspora are really pushing the envelope of what can be done with SCP. And it is definitely true that both SCP and mods benefit from awesome features. There's plenty of honor to go around, and it is mutually rewarding for both teams.
But I'm looking at this from the opposite perspective. I'm concerned that SCP is currently in a feature bubble that is in dire need of deflation. I remember back around the time of SCP 3.5, people were tossing features into the codebase left and right, often with the specific and
admitted objective of getting the code written whether it worked 100% or not. Eventually the codebase got so buggy and disorganized that people were trying to write features on top of other features, and changing stuff around regardless of whether it affected anything else. The result was a buggy, bloated, unstable mess. It took a lengthy, concerted effort by Taylor to squash all the bugs and re-engineer everything to be more stable, robust, and extensible.
Lots of natural processes go through the boom/bust cycle. You have the economic expand and contract cycle, the predator/prey ecological cycle, the cycle of growth, overgrowth, fire, and seedlings in forests, etc. It is useful for development to follow the same cycle: you add a bunch of cool features for a season, and then for a season you take a step back and make sure things are engineered correctly, make sure features aren't conflicting with other features, and refactor the things that it makes sense to refactor.
For quite some time now, bugfixing has gotten a lot less attention than it deserves. Coders are usually very concerned about making sure their feature is implemented, but how often do they trawl through Mantis and look for bugs that they know how to fix, or that they might be able to fix given a little bit of programmer growth?
I want to make clear that this post isn't directed specifically at WoD, or any poster here in particular. It's generally applicable to everybody in SCP, myself included. Furthermore, there are two very positive developments that distinguish today's development from the development of yore. First of all, coders frequently post "Code review" threads to get multiple sets of eyes on a given patch, with the result that the patch is better designed and better debugged than it would be with a single person working on it. Second of all, coders tend to stick around nowadays; we don't have people dumping 80%-completed features into the code tree and then disappearing for six months, without explaining their feature or providing debugging support for it. This happened a lot in previous years; I can think of three different coders who did this more than once.
But there are a lot of risks we're dealing with nowadays. Larger features are more likely to contain bugs than smaller ones. Complicated features are more likely to contain bugs than simple ones. Special-use features are used less frequently, have fewer pairs of eyes looking at them, and are therefore less likely to have their bugs detected than frequent-use features.
And many parts of the code need to be refactored -- from relatively simple cases like the asteroid code, to relatively complicated cases like subsystem rotation. And considering that refactoring is usually a long, difficult, and thankless job, it's not surprising that coders don't want to do it, or that coders don't do it very often. Not to pick on Valathil, but look at the reception he gets whenever he posts a crazy graphical test build in the public forum -- even a build based on code that isn't even in trunk. Compare that with the reception karajorma got for his brilliant re-engineering of the multiplayer sexp system. Few coders know about it; fewer still use it. And yet it's been instrumental in bringing order to the chaos that is multiplayer gameplay support.
We need to foster a culture that makes the code
better, not just fuller-featured. Better includes fewer bugs, increased stability, better error messages, better documentation, and more elegant design. We need to have a system that satisfies the following three goals:
1) People who are less inclined to fix bugs should be more inclined to fix them
2) People who lack the knowledge or experience to fix bugs should be able to gain it
3) People who have historically been inclined to fix bugs AND have the appropriate knowledge to do so, should not be relied on to the point of getting burned out or having no time to work on stuff that they like
And I'm not sure how best to do that on a project like SCP, where people aren't getting paid to do the work and which tends to shun explicit organization in favor of self-motivation.
TLDR version: fix bugs, y'all.
