Rewrite the design document guidelines

[ArtisticRoomba]

The design document guidelines have been completely rewritten.

We've been getting a lot of questions as to what a design document is and what it's supposed to accomplish. From reviewing old design documents, most are feature lists, which aren't horrible by any means, but they often don't justify why those features are needed and how they contribute to a wider thematic design of whatever someone is adding.

We'd like to push design documents into a tiered structure where previous design documents provide foundation as to why things need to be done, with further design documents establishing how things are done and why it establishes the goals set out by the previous documents. In general, less repetition and derivation of things we already know, and more "how does whatever you want to implement actually align with desired gameplay".

Decorum page was removed because it's unnecessary wording that could be literally anywhere else and it was never followed ever. Game area design document was removed because it's just not where we're pushing docs anymore.

[slarticodefast]

I didn't even know we had all these different explanations about design docs hidden in here

[slarticodefast]

The current template has a small section that requests giving a summary of the technical implemanation that will be needed for the feature, which is conflicting with this statement.
We introduced this because we had a bunch of completely unfeasible doc propoposals from authors with no coding experience. I think it makes sense to keep this requirement as part of the doc, because it

• shows maintainers that someone is actually interested and able to implement the proposed feature.
• ensures that the implementation is actually technically feasible rather than wishful thinking and won't cause massive conflicts with existing systems (for example the time agent doc where a player was supposed to return to a previous moment on the station).
• For things like UI and UX suggestions it helps the reader to better conceptualize the new feature as it gives an example of how players will actually interact with the feature, which can vastly differ depending on the way it is finally implemented. This of course does not need to be final or overly detailed, but things like an UI mockup can help a lot. (example: a player controlling a blob will have an eye similar to the station AI, but is confined to tile movement on or next to converted tiles.)

[slarticodefast]

This template can probably also use some polishing, but we can do that in a future PR.
When I wrote it the previous template was just "do whatever you like!" and the results were as expected and mostly feature shopping lists. So I tried giving a list of questions a design doc could potentially answer in order to have some base level of quality if authors just blindly follow it step by step. Of course the authors don't have to exactly follow this template, but I would not want to return back to the freeform doc - writing an actually good design doc is hard and I think this template is helping by giving authors a base to start from.

[ArtisticRoomba]

In the discord maintainer feedback centered around the template needing a complete rewrite, so I'm going to be doing that when I have time.