Like all of us, at some point in your gamedev experience, you hit a roadblock and you set out to get help.
So you write a comment below a tutorial, or you go on Discord, Reddit, even Godot Forums, only to get even more frustrated: Nobody answers or worse you get burnt, and you’re left on your own.
You might be tempted to think everybody’s a jerk but... that’s not a very realistic or even productive worldview.
While it doesn’t excuse the occasional real jerk out there, you may not be following good question etiquette. There are many more people out there who have the good reflex of sharing an answer when they have one. In fact, asking a question in a way that makes it difficult or impossible to help you, probably frustrates your readers too by blocking their goodwill to solve your problem.
So what can you do and what is the etiquette for asking questions?
The golden rule is simple enough to remember:
hmhy: help me help you.
There are 3 basic checks you can do to make sure you follow this rule and start getting invaluable free help from peers. The third and last step we share in this video is the one you should never skip so stick around. We’ll also provide you with a GDQuest template you can use as a checklist. You’d be amazed by how generous people can be with their time and knowledge if you follow these steps.
CTA#1
Let’s breakdown the 3 checks to follow the golden rule of community support:
Are you asking in the right place?
Before you post a question, it’s important to ask yourself if you’re in the right venue. If you’ve just watched a tutorial and you scroll down to the comments section to ask an unrelated question about your own project, that may not be the best place to do it. People going through the comments section are more likely to want to comment on the video itself and its content, they might have questions of their own about the concepts and along the way, they might answer yours. So it’s important to be relevant.
As a rule of thumb, post your question where you would yourself expect to find an answer to it. In the comments section of a video about tilemaps or in a forum thread about creating tilemaps, you would not expect to find an answer on how to set up a state machine for example, so that’s not a good place to ask a question about state machines either.
This brings me to the second check:
Did you look for an answer?
You’re not expected to know how common or uncommon your question is. So don’t worry too much about that. But it may save you and the community some time to look up the question before asking it. Someone may have already asked it and obtained a very good answer:
Run a basic search in your search engine.
Identify the main topic or game mechanic and look up YouTube videos on the subject to see if someone has asked your question in the comments.
Scan forum questions and help threads in the Godot Engine forum, or on Reddit or in the help forums on the Godot Discord Server or the GDQuest Discord server.
If you have a feeling your problem might be connected to a bug, see if someone else has reported it. You can look up the open issues in the Godot project on Github using the link in the description (
)
Besides potentially saving you time and being a show of good citizenship in your community, reading other people’s questions and answers also helps you learn faster and better. Plus when you find a good answer you can share a link to it the next time you run across someone asking the same question.
All of this doesn’t mean you should be terrified of asking a question that’s been asked before. You decide how much time you can spend searching versus setting up your question. Because yes, you do have to set up your question. This take us to the third and most important point. If you do nothing else make sure you at least check this one:
Did I provide enough Context?
People aren’t in your head nor sitting behind your shoulder. They haven’t been running into your problem with you. You have to do your best to remedy to that so they’re on the same page as you. Only describing the failed outcome that is blocking you will not get you answers. So avoid complaints and orphan statements of what’s going wrong.
Giving details does not mean writing pages about it. Be concise but make sure you cover:
Your goal: What you’re trying to accomplish design-wise and the result you expect in your game. Keep it simple because sometimes a picture/video is better than a thousand words
Your issue: Make sure you describe it concisely. If you’re posting in a forum you want your title to be a good representative mix of your goal and your issue.
Your error message You can click on the “copy error” icon in the editor's debugger in the bottom panel. If the log is too long, paste it elsewhere and provide a link. We’ll tell you how to in a moment.
Your code: You can paste a short snippet or a codeblock directly in a chat box if you know where the problem is. For longer code it’s better manners to provide a link only. More on that later. Whatever you do, don’t send photos or screenshots of your code, always use text.
Your scene dock: Sometimes the problem is not in your code but in your scene tree which is part of your source code. So attach or paste a link to a screenshot of your scene dock. The keyword here is screenshot so please use the printscreen tool built into your OS or browser. Do not use your mobile to snap photos of your screen.
Your game: It could take several lines to describe what’s happening in your game and it could still be misunderstood. To avoid that, upload a video of your running game and provide a link to it. You can record your screen with programs like obs studio, screentogif.
Your Godot version: Finally, make sure you mention the version of Godot you’re using as this can considerably impact the solution and the answers you get.
You can use your better judgment to assess when you need to provide all of the details or only a few but it’s best to err on the side of completeness. If you’ve described your goal concisely, no one will be upset because you’ve also pasted 2 additional links they didn’t end up needing.
It may sound like you’re filling out somebody’s university application but it’s actually just a couple of lines. Everything else can and should be just linked.
For example for long code blocks or error messages, copy and paste them in websites like pastebin or
For images, upload them in your cloud storage service or on imgur or any other similar image sharing service.
For videos: again you can use your favorite cloud storage provider, or upload them as unlisted videos on your youtube channel.
We made a free and basic little tool you can use as a sort of checklist to formulate questions that can get answers.
You can bookmark the link in the description: