Talk:Development Q&A

Guidelines for adding to the dev Q&A

1. Keep it as close to the source as possible

Minimum interpretation, no spin. It's not our job to build hype, or decipher what GSG meant to say, or read their minds, or resolve contradictions with answers from the past. It's their responsibility to communicate their point. The page is just documenting what they said.

The reasoning for this is that almost noone checks the source. Very, very few readers are going to compare the summary against the stream snippet. Most people will read the summary, assume it's the truth and run with it. And that's fine; that's largely why this page exists - so that people don't have to watch every dev stream to know how they react to community suggestions.

But that also means we have to convey what was actually said, not what someone else thought was said. Readers expect words from the mouths of GSG. Giving them something else is bad journalism.

It's true that shortening any piece of text is technically personal interpretation on the editor's part, so avoiding interpretation completely isn't possible. That's why every line is accompanied by a URL to the source, where the same answer is available in full.

2. Paraphrase replies to refer to GSG in third person

Filling the spreadsheet with verbatim quotes like "I don't think that's going happen" or "We want to avoid a scenario when..." can lead to the reader assuming the page is filled, maintained or curated by GSG, when in reality none of those are true. Moving the answers to third person helps convey the idea that this page in an outside observer not affiliated with the studio.

3. If a question from the stream audience isn't phrased to be about future content, skip it

There is a lot of questions in every stream. Many of them ask about aspects of the game, logic or reasoning behind decisions, or the developers' opinion. Listing everything would be even more work than it already is - so a line has to be drawn somewhere, arbitrary though it may be. Initially I drew the line at "it has to be a suggestion for game content", and I've stuck with it ever since.

Look at the phrasing. A good candidate to be entered into the spreadsheet starts with:

"Are there any plans for..."

"Have you even considered/thought about..."

"(When) are we going to see..."

If someone asks "Why aren't there humanoid enemies in DRG?", for the purpose of this Q&A that's not a content suggestion - that's a request for reasoning/rationale. Those kinds of answers have value too, but adding them as well is extra work I personally can't be bothered to pick up. I save the timestamp into a personal file, but it's not on the wiki. In contrast, a question "Are there going to be humanoid enemies in DRG?" is a valid entry for the spreadsheet.

Questions like "Are there going to be balance changes for overclock this & that?" are border cases that I choose to count as suggestions for "content", since I think a wider definition of "game content" includes balance changes. However, "What do you think about overclock this & that?" is a request for opinion, there is no implicit suggestion for change - therefore, it's not fit for this Q&A page.

4. When a reply contains different levels of certainty, focus on the more vague one and/or the one that promises less

This is for when someone says "maybe" and someone else adds "don't get your hopes up" in the same reply. The reality is that people are going to retell these in a game of broken telephone. "They might add X" will morph into "they'll probably add X" and then into "it's likely they'll add X", simply because the speakers want to believe X will get added.

In (frequent) cases of "I think the situation with X is ..., but I'm not sure", a good option is to paraphrase that into "The situation with X might be that..."

The stream team already has to be careful with their wording. They're aware that anything that even remotely sounds like a promise will be taken as a promise. If someone comes to the devs saying "but it says here you promised X" and it's because we took one part of the answer that sounded like that, GSG will have to be even more careful and vague going forward - and that's no fun for anyone involved.

5. If none of the devs said anything of substance, don't make an entry

This is for cases when they read out a suggestion, but get distracted by gameplay and don't provide any answer.

When GSG misinterpret the question and instead comment on something unrelated, use your judgement. If the answer they provided is relevant and expresses their plans about some piece of content, maybe it's worth recording - just make sure to assign the category based on the answer, not the question.

A reply that's essentially "not sure" borders on having substance. Sometimes it's useful to know GSG don't have an opinion or consensus about something, and sometimes it's just a lack of something to say. By default, make an entry for it, but again, use your judgement. Most of the time it's clear from context; when a developer's answer boils down to "Not sure, I don't have enough knowledge and I don't want to give false information", it's better to skip that reply.

6. Avoid mentioning the dev by name unless they specifically say it's their personal opinion and it doesn't reflect the general course of development

Most of the time it's not important which of them replied, and mentioning it takes valuable table space (more on that below). However, for example, Johan often says he wants the minigun to have more ammo. Regular viewers and editors know it's an in-joke and that the minigun is not going to get more ammo - but the larger audience for which this page is written doesn't. So, when someone suggests to rebalance the minigun, and Johan off-handedly jokes that it should get more ammo, putting that as a straight impersonal answer will confuse readers. Intonation and context are lost in a short text summary, and that should be kept in mind.

GSG are also aware of this and usually preface their answers with "Well, I think..." when they're about to say something controversial or going against the general design of the game.

7. Avoid editor's notes unless absolutely necessary

Comments from editors should not be needed, as per guideline 1-2. I've used them twice in around 2200 answers, and it was for humor that would get lost in transcription. One was sarcasm and one was the joke where the devs keep pestering Mike to add a petting zoo. Taken at face value, the text could be very misleading, and we can't trust readers to go and listen to the context in audio form. We also can't trust them to read the intro on the Q&A page where it says some replies are jokes.

8. Keep the "Suggestion" text within 57 characters and the "Comment" text within 140 characters

This isn't just for brevity. This is how much text the current font can fit without doing a line break at 13pt on 1920x1080 in wide mode. The table is already enormous, keeping it as trim and short as possible saves a lot of scrolling.

In general, paraphrase the replies until you can get the entry to fit into one line without breaks in the conditions mentioned above.

9. "Comment" text should be one sentence with no period at the end

This limitation is mostly to force the editor to keep it short and save character space. If what GSG replied with constitutes two different sentences, put a semicolon instead of a period. You can find hundreds of examples in the current entries.

10. The timestamp should lead to a moment 1-2 seconds before the dev starts reading out the question

"Reading out the question" includes prefaces like "This & that in Twitch chat asks...". Basically, 1-2 seconds before you hear the voice of whoever starts talking in relation to the suggestion.

11. Keep replies sorted

Sorting is as follows:

1. By stream date from newest to oldest.
2. Within the same date - by category alphabetically.
3. Within the same category - by suggestion alphabetically.

Or just contact me on the official Discord so I can sort them in my Excel sheet/converter.

ArsonCat (talk) 21:40, 2 June 2024 (UTC)