Dear community,
I'll make it short: The servers are down for a lot of people including me. Many start ranting about refunds, another free compensation, and the incapability of the devs, who have this game in beta for many years. I wanted to play aswell, but now I am forced to do something else after a hard day of work.
BUT:
This game can improve far better, when we all report bugs rather than creating tickets with "I cannot play, I want a refund".
Here is a guide (see below), how you can improve your bug reports. It is a MASSIVE help for every developer comparing to
a) "Yo, my ammo has gone, I lost 30k. Give it back to me" or
b) Not writing a bug report at all.
Here are the links (to be seen as a general guideline):
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
and
https://musescore.org/de/handbook/developers-handbook/getting-started/how-write-good-bug-report-step-step-instructions
Don't take any game so seriously, that "it" ruins your day.
Best Regards
Edit and TLDR:
- Be specific. If you can do the same thing two different ways, state which one you used. "I selected Load" might mean "I clicked on Load" or "I pressed Alt-L". Say which you did. Sometimes it matters.
- Be verbose. Give more information rather than less. If you say too much, the programmer can ignore some of it. If you say too little, they have to come back and ask more questions. One bug report I received was a single sentence; every time I asked for more information, the reporter would reply with another single sentence. It took me several weeks to get a useful amount of information, because it turned up one short sentence at a time.
- Be careful of pronouns. Don't use words like "it", or references like "the window", when it's unclear what they mean. Consider this: "I started FooApp. It put up a warning window. I tried to close it and it crashed." It isn't clear what the user tried to close. Did they try to close the warning window, or the whole of FooApp? It makes a difference. Instead, you could say "I started FooApp, which put up a warning window. I tried to close the warning window, and FooApp crashed." This is longer and more repetitive, but also clearer and less easy to misunderstand.
- Read what you wrote. Read the report back to yourself, and see if you think it's clear. If you have listed a sequence of actions which should produce the failure, try following them yourself, to see if you missed a step.
Summary
- The first aim of a bug report is to let the programmer see the failure with their own eyes. If you can't be with them to make it fail in front of them, give them detailed instructions so that they can make it fail for themselves.
- In case the first aim doesn't succeed, and the programmer can't see it failing themselves, the second aim of a bug report is to describe what went wrong. Describe everything in detail. State what you saw, and also state what you expected to see. Write down the error messages, especially if they have numbers in.
- When your computer does something unexpected, freeze. Do nothing until you're calm, and don't do anything that you think might be dangerous.
- By all means try to diagnose the fault yourself if you think you can, but if you do, you should still report the symptoms as well.
- Be ready to provide extra information if the programmer needs it. If they didn't need it, they wouldn't be asking for it. They aren't being deliberately awkward. Have version numbers at your fingertips, because they will probably be needed.
- Write clearly. Say what you mean, and make sure it can't be misinterpreted.
- Above all, be precise. Programmers like precision.