Guide by Scooternew
Hi, Scooternew here to tell you that you suck! Naw, not really, but if you aren't getting the responses you want while asking for programming help, chances are that you didn't really present yourself in a good manner or give enough information while asking for help. So, I've created a small "guide" that anyone should internalize and go through before creating a topic asking for help - just some simple things. This is mostly directed towards GM users, but is highly applicable to anyone else who codes.
Identify the ProblemBefore you can even try to fix anything, you must identify what the problem is. Is the game running slow? Is a piece of code just not doing what it is supposed to be doing? Is an error thrown? Basically, if what you
expect to happen doesn't happen, you have your problem.
Narrow it DownYou have a whole game's worth of code. So, what you need to try and do now is to find out
what is causing the problem. A good way to do this is to comment out code that you KNOW isn't causing problems. Try and see if you can force the error to pop up again - and if you can, then you in what general vicinity of coding your problem lies.
Use Logic Before PostingOk, so now you know what the problem is and where it appears. You've gotten quite far - halfway there. So, now that you've clearly identified the problem, chances are you might know exactly what needs to be done to fix it. Think - oftentimes de
will point out exactly what is missing. Say something is the wrong color - chances are you typed in the hexadecimal value wrong. Check for missing semicolons - use what errors and de
s tell you to try and figure ou what the problem is.
Post HereChances are, by here, you SHOULD HAVE figured out a solution to your problem. But if not, then you can post here, at ZFGC asking for help. Make sure you always include information such as if GM, your version and whether registered - if not,
what language you are using. Post what the problem is, the general code area in which the error pops up, and what you'd like to happen. Post what you suspect the problem might be, to help other community members narrow down the exact cause of the error. I've seen the following post before:
this dsn't work:
include iostream.
And that's the end of it. That doesn't do ANYTHING to help anyone else.
So, in closing:
1. Try to figure it out and fix it yourself.
2. Ask for help intelligently and post any informatino you can. Help people help you.
---
Guide by TRW
This topic is prompted because of the number of topics in this section that have simply been vague, unworkable, or uninformative lately. If you want people to help you, then give them the information that they need in order to help you.
1) Identify the language. There's a topic in the stickied section that says this, for crying out loud, but I don't know how many topics I've read that don't follow this simple rule I've seen. A lot of topics, the first post is, "Please state what language you're working in." This is because you NEED TO STATE WHAT LANGUAGE YOU'RE WORKING IN. If you have a problem in Visual Basic and don't say so, people may assume it's GML and give you an answer that yuo won't be able to do anything with. It frusturates you AND the people trying to help you.
2) Explain what you're trying to do. I can't stress this one enough. "Help it doesn't work" doesn't say what you're trying to do. "Link isn't responding properly" is pretty close to a topic I just read. The first three posts were, "What's not working right?". Try and be as specific as possible. People can't read your mind. They don't know what you're trying to do. They may get lucky and figure it out, but there's no guarantee. "Link doesn't work right; I'm attempting to make him do a backwards somersault when you go <- <- X X C, but it's not working." is a lot better.
3) Identify the script/object that you are workign on. (Or post code)
If you give people a gml file / a visual studio project/workspace / etc. to help them isolate your error, tell them WHERE to look. Unless you're just giving them a small block of code, tell them EXACTLY where the code is broken, to allow them to be able to fix it faster.
4) Explain the error you are having.
"Link isn't working right." does not really tell people what is wrong, exactly. "When I try and make link do a backflip, he does a forward flip instead." Is a little bit better. "It crashes when Link does a backflip" is another example. Tell them WHAT HAPPENS and WHAT goes wrong. It will make it a lot easier for people to figure it out.
5) Tell people what you have tried so far.
This saves them time from trying the same things, or perhaps, can give them insight into what the nature of the problem is. The more they know, the more they can help you.
6)
http://www.zfgc.com/forum/index.php?topic=7918.0 <-- Read this, and make sure you have followed these guidlines for debugging before you post your topic. You can often solve your own problems faster than you could wait for someone else to come up with a solution for you, if you actually continuosly attempt to solve the problem.
7) If you continue to try and work out the problem after your problem has been posted (much advised), keep your topic up to date with what changes you've made and what new things you have tried.
After someone helps you, THANK THEM. Even if you don't think they'll come back into teh topic, they have taken time out of their schedule to work through your problem for you. The least you can do is give them a little thanks.
Good luck coding!
