More brevity edits

Down to about 6000 words now.

doc/development_process.md

@@ -152,7 +152,7 @@ The short answer is, *yes, of course*, but this doesn't mean what some people mi
 1.  We are not selling a product, so we don't care about mass appeal or how many people play the game.[^massappeal] 
 2.  We already know what game we want, and it's not for everyone.  However, we all play this game and love it.  Nothing we add ever has the goal of making a game we wouldn't like to play ourselves.  Any player feedback that amounts to "change this aspect of the game that *you* like into something *I* prefer" is just a non-starter.  We know that sometimes what you prefer has more mass appeal.  See number 1.  We also don't think mass appeal, or what is fun, is anywhere near as obvious as it can seem at a glance.
 3.  This game is one of the most adjustable and moddable games out there, but that's an outcome of good data driven design, not a specific goal we have.  Including player-facing adjustments for every conceivable game setting is not something we want to maintain.  Explaining this could be a doc in itself, but in the end, it comes down to number 2 plus a bunch of details on the nitty-gritty of managing the code and play balance.  It's fully our intent that if you want something to run differently, you can mod it out; we just don't want to be on the hook to bugtest and manage infinite preference mods.
-4.  Many times, player feedback concerns come down to the playability of the experimental branch of the game.  See [the section on experimental/stable](#experimentalstable).  Experimental is often rendered very weird and imbalanced, sometimes for months at a time. We will basically never revert changes to experimental that we've added in order to test them, nor are we likely to relegate those changes to a mod or an option, because this interferes with testing.  See 2 and 3.  However, nearly all the time, whatever is bothering players about current experimental is something that will shake out and become sorted in time.
+4.  Many times, player feedback concerns come down to the playability of the experimental branch of the game.  See [the section on experimental/stable](#experimentalstable).  We will basically never revert changes to experimental that we've added in order to test them, nor are we likely to relegate those changes to a mod or an option, because this interferes with testing.  See 2 and 3.  However, nearly all the time, whatever is bothering players about current experimental is something that will shake out and become sorted in time.
 5.  The project isn't a democracy.  This rubs some folks the wrong way, but it just isn't.  However, the project also isn't a dictatorship, it's more like an open forum with a moderator.  If you have opinions about something, make your case for it.[^venera]  If what you want doesn't conflict with the game design, and you make a good case for it, you can very often change our minds.
 
 We feel pretty strongly that the reason this project has thrived for so long is that we have a consistent and uncompromised vision for the game that we follow, while also allowing side projects and flavour tweaks to be included in the game.  It's fine if you just don't like what we like.  There are a few ways to reconcile that: you could work on a mod in repo, either your own or someone else's.  You could develop and share a third-party mod that we haven't got any control over at all.  You could join a fork, and help them out.  You could fork the project and demonstrate your own vision for it.  However, if you've looked around and you like where we're going, we'd love to have you join us, or even just play and have fun with our game.
@@ -167,40 +167,40 @@ This section isn't necessary to read, but contains (we hope) some useful fact-ch
 
 ### A Very Brief History of DDA
 
-CDDA is a fork of a game called Cataclysm, developed by a guy called Whales.  Cataclysm was a grab-bag apocalypse roguelike set in a vague near-future setting.  Dark Days Ahead was forked by a group of people (Kevin Granade, TheDarklingWolf, and GlyphGryph) who wanted a more gritty, realistic zombie apocalypse game made from the same general concept.  Why they picked Cataclysm is anyone's guess (Kevin could probably guess, but he's not writing this document).
+CDDA is a fork of a game called Cataclysm, developed by a guy called Whales.  Cataclysm was a grab-bag apocalypse roguelike set in a vague near-future setting.  Dark Days Ahead was forked by a group of people (Kevin Granade, TheDarklingWolf, and GlyphGryph) who wanted a more gritty, realistic zombie apocalypse game made from the same general concept.
 
 We firmly believe that the reason CDDA has persevered and improved steadily since 2013 is that it has a consistent project direction.  We're also aware that many people claim the project direction changed at some point in the past.  [This interview from 2013](https://web.archive.org/web/20140211144953/http://www.jacehallshow.com/news/gaming/preview/20130626/ascii-goodness-living-breathing-3d-world-cataclysm-dark-days/) and [this one from about the same time](http://www.roguelikeradio.com/2013/07/episode-75-cataclysm-dark-days-ahead.html?m=1) show that the original developer team had much the same goals as we currently have in the design doc.  A lot of the misconception comes down to changes that were left to ride from the original Cataclysm before the DDA fork, and were removed in a dedicated push around 2018-2020.
 
 To clear up a few common rumours that circulate in certain channels:
 - Kevin has always been in charge of the repo in his current capacity, even in the original oligarchy days, and there was never any sort of takeover.  The other original devs just left, for various reasons.  It's a hobby project, people come and go.  There was no falling out or hard feelings.
 - Over the years we've lost a lot of developers.  The reason is not as dramatic as you might think: by and large, people get bored and move on to other places.  The number of major fallings-out can be counted on one hand, in over a decade of development.
-- We didn't start a developer discord because of some secret community drama.  We just needed a place we could moderate for a focused discussion.  Community drama followed shortly afterwards, but not for related reasons.
-- That's also the same reason we started a developer-focused subreddit: we wanted a place where we could keep the discussion focused just on game dev and projects related to it, rather than fun and memes.  It wasn't closed because of any internal strife, it was closed because we all used apps to moderate it, and reddit shut down 3rd party apps.  Nothing particularly exciting.
+- We didn't start a developer discord because of some secret community drama.  We just needed a place we could moderate for a focused discussion.
+- That's also the same reason we started a developer-focused subreddit: we wanted a place where we could keep the discussion focused just on game dev and projects related to it, rather than fun and memes.  It wasn't closed because of any internal strife, it was closed because we all used apps to moderate it, and Reddit shut down 3rd party apps.
 - We don't have any animosity to the other major forks of the game.  Mostly, we are glad they exist, even though we know how some of them talk about us.  It's our opinion that it's a *good thing* if someone who doesn't like our way of managing the project has a different place to go.  We don't want to be dictators of our tiny corner of the internet, we want to make a neat game with as little drama as possible.
 
 #### Why did Kevin do this to me?
 
-This merits its own section because it's such a frequent by-line in various Cataclysm communities.  For the most part, for the last five or six years, Kevin has been fairly hands-off in the direct development of CDDA.  He is quite present and involved in a lot of design discussions, and he has his own ongoing code projects, but for some reason he is attributed as the primary source of all changes in Cataclysm.  We know this is usually started as a joke, but it obscures credit from our extremely broad base of contributors.  As mentioned earlier in this document, Kevin is the *final voice* in what goes in to the project or does not.  However, his powers are otherwise quite limited.  In particular, it's helpful to understand that neither the devs, nor Kevin, have any "additive" influence.  Unless we put something in ourselves, we have no way to influence other people to add it besides to ask nicely.  If a feature was added to the game, chances are actually pretty high that someone else did it.  At any given time there are around 50-100 different contributors of various levels working on the project, including both regulars and new faces.  If something was changed, statistically it's most likely one of these people, not Kevin, changed it, and Kevin simply didn't say 'no'.
+This merits its own section because it's such a frequent by-line in various Cataclysm communities.  Kevin is mostly hands-off, although he is quite present and involved in a lot of design discussions, and he has his own ongoing code projects, but for some reason he is attributed as the primary source of all changes in Cataclysm.  We know this is usually started as a joke, but it obscures credit from our extremely broad base of contributors.  Kevin is the *final voice* in what goes in to the project or does not.  However, his powers are otherwise quite limited.  In particular, it's helpful to understand that neither the devs, nor Kevin, have any "additive" influence.  Unless we put something in ourselves, we have no way to influence other people to add it besides to ask nicely.  At any given time there are around 50-100 different contributors of various levels working on the project, including both regulars and new faces.  If something was changed, it's most likely one of these people, not Kevin, changed it, and Kevin simply didn't say 'no'.
 
-As a classic illustrative example, when we first added the mod inclusion criteria and set a bunch of mods to obsolete, Kevin had very little involvement in the process.  It was a collaborative process by around two dozen devs and contributors who were collectively tired of bugfixing mods none of us used.  Years down the road, we continue to see this cited over and over again as an example of Kevin exerting authority on the project, when his main active role was just that he didn't stop us and agreed it was our call to make as the ones doing most of the work.  Similar situations have happened dozens of times, often in cases like this when it furthers a dramatic narrative to claim that it was the unilateral action of a supreme dictator.
+As a classic illustrative example, when we first added the mod inclusion criteria and set a bunch of mods to obsolete, Kevin had very little involvement in the process.  It was a collaborative process by around two dozen devs and contributors who were collectively tired of bugfixing mods none of us used.  Years down the road, we continue to see this cited over and over again as an example of Kevin exerting authority on the project, when his main active role was just that he didn't stop us and agreed it was our call to make as the ones doing most of the work.[^controversy]  Similar situations have happened dozens of times.
 
 ### Realism as a design goal
 
-This is a much repeated buzz word.  Any prospective contributor should understand that we do not consider realism to be the goal of the design.  Rather, we are aiming for *verisimilitude*.  That is to say, most of the time, things should work the way you would expect them to work.  This is a subtle but very important difference.  Many things that would be more realistic may be nixed because of problems with play experience or play balance; for example, at time of writing, we've repeatedly shot down efforts that would make regular laundry and hygeine important, because while realistic these would be tedious and frustrating unless implemented in extremely specific ways.  You can find a lot more detail about this in [the design document](https://docs.cataclysmdda.org/Lore/design-balance.html).
+Any prospective contributor should understand that we do not consider realism to be the goal of the design.  Rather, we are aiming for *verisimilitude*.  That is to say, most of the time, things should work the way you would expect them to work.[^movies]  Many things that would be more realistic may be nixed because of problems with play experience or play balance; for example, at time of writing, we've repeatedly shot down efforts that would make regular laundry and hygeine important, because while realistic these would be tedious and frustrating unless implemented in extremely specific ways.  You can find a lot more detail about this in [the design document](https://docs.cataclysmdda.org/Lore/design-balance.html).
 
-In general, the most common citation of "realism" online comes from laughable misunderstandings where glitches in experimental are mistaken for intended design in certain communities.  AN example was when `charges` were being removed as a part of a major *code infrastructure change* with no intended player impact at all.  This caused several months of shakedown with glitches like players having to move salt in individual pinches, an obviously unintended consequence that was remedied pretty quickly.  This was frequently claimed to be a "realism change", not a bug, in certain circles.  While funny to think back on, this attitude has at times been actively harmful to the project, with people feeling discouraged from fixing bugs because they get the impression it's intended play.  Almost universally, if someone has said that a seemingly hostile and illogical game mechanic is the way it is due to "realism", they're probably wrong, either because the mechanic is bugged or because QoL improvements are desired to make it less frustrating.
+In general, the most common citation of "realism" online comes when glitches in experimental are mistaken for intended design.  An example was when `charges` were being removed as a part of a major *code infrastructure change* with no intended player impact at all.  This caused several months of shakedown with glitches like players having to move salt in individual pinches, an obviously unintended consequence that was fixed pretty quickly.  This was frequently called a "realism change", not a bug, in certain circles.  While funny, this attitude can be actively harmful to the project, deterring people from fixing bugs because they get the impression it's intended play.  If someone has said that a seemingly hostile and illogical game mechanic is the way it is due to "realism", they're probably wrong, either because the mechanic is bugged or because QoL improvements are desired to make it less frustrating.
 
 ### Why did X system get worked on while the more important Y system didn't?
 
 Short answer: Because someone chose to work on X, not Y.
 
-Longer answer: Sometimes, the more important system is much harder or more intimidating (eg NPC AI).  Most of the time, though, it's just that we have infinite possible things to work on and we have to pick something.  If a particular system is important and interesting to you, the only way to *ensure* someone works on it is to learn how to code and to work on it yourself.  Chances are this is not as difficult as it sounds.  However, if you just can't do that for some reason, sometimes you can get headway by becoming a cheerleader for it.  Learn what needs to be done, and make it sound appealing to people who might know how to do it.  Generally, this isn't going to work well unless you also contribute your own stuff, but for example a dedicated tileset artist might have a lot of sway in convincing a coder to do them a favour.
+Longer answer: Sometimes, the more important system is much harder or more intimidating (eg NPC AI).  Most of the time, though, it's just that we have infinite possible things to work on and we have to pick something.  If a particular system is important and interesting to you, the only way to *ensure* someone works on it is to learn how to code and to work on it yourself.  Chances are this is not as difficult as it sounds.  If you just can't do that, sometimes you can get headway by becoming a cheerleader for it.  Learn what needs to be done, and make it sound appealing to people who might know how to do it.  Generally, this isn't going to work well unless you also contribute your own stuff, but for example a dedicated tileset artist or translator might have a lot of sway in convincing a coder to do them a favour.
 
 #### Why did X system get implemented with Y, but not Z?
 
 For example, why did science equipment get added but you could only loot it in one location?  Why did anvils get overhauled in a way that made it hard to craft them?
 
-This is a subset to the question above.  The answer is, because the person implementing it didn't want their PR to explode into a whole bunch of extra features.  This can happen for many reasons, but the most common is probably that the person implementing the PR needed that infrastructure for something else they were doing; they wanted to do it right, but they didn't want to get into the play balance of working out every other step down the road.  This is a consequence of the game being experimental, not the intended design, and the intended fix is that someone should just add missing feature Z: add science equipment to more spawn lists.  Add some new ways to obtain anvils.  It's not the result of malice, it's the side effect of wanting to do something right, but not having the resources to be in every place at every time.
+This is a subset to the question above.  The answer is, because the person implementing it didn't want their PR to explode into a whole bunch of extra features (this doc even has a [FAQ entry on that problem](#How-do-I-deal-with-a-ton-of-comments-and-suggestions-to-my-idea)). This is a consequence of the game being experimental, not the intended design, and the intended fix is that someone should just add missing feature Z: add science equipment to more spawn lists.  Add some new ways to obtain anvils.  It's not the result of malice, it's the side effect of wanting to do something right, but not having the resources to be in every place at every time.
 
 ## The Bottom Line
 
@@ -223,3 +223,5 @@ In the end, we hope you'll share our passion for this project and decide to come
 [^feedback]: Also, if *you* want to listen to player feedback on your additions to the game, you're welcome to do it however you like!
 [^massappeal]: In fact, in some ways, the more popular DDA gets the more trouble it causes from a project management standpoint: we get more drama and have to handle more top-heavy admin work than we would with a smaller project.  "Growing our audience" is something that has happened organically, and we love new people trying out the game, but at the same time it's definitely not a *goal*.
 [^venera]: The general design is quite flexible, and for example when Venera3 started contributing, we were considering removing giant insects from the lore entirely.  Now we all have to deal with those infuriating giant wasps and it's all his fault.
+[^controversy]: At time of writing this is still the most disliked PR in the entire project, and it's kind of interesting to note how little Kevin had to do with it.
+[^movies]: And, to make matters worse, there are a lot of ways we expect things to work that turn out to not be really as clear as they seem, either due to popular "movie logic" misunderstandings, or because reality is rarely as simple as it seems.  Hunger is a fun example of this.