FrostyCat
Redemption Seeker
Advice for posting on the GMC:
Advice for GML basics:
- Stop bringing up old topics by posting "I have the same problem" on them. The topic's owner will likely not be around to answer you anymore, and you'll disturb the topic's archival value if your request turns out to be unrelated to the topic. If you need help and you think an old topic may be relevant, start a new topic and link to that old topic. Let experienced responders decide how relevant it is, don't do it yourself if you're new.
- Post coding questions on the Programming section. The Community Tech Support sections are for when you have issues with the IDE (e.g. setting up the build process, IDE crashes/bugs, project file problems, etc.), not for when you have problem with code. The Community section is for when you have issues concerning the wider GMC community, not for when you have problems with code that isn't normally anyone else's business.
- Stop posting GML code in screenshot form. Code in screenshot form cannot be copy-and-pasted, and longer pieces get cut off by scroll bars.
- Use [code] and [/code] tags when posting code. This protects indentations and certain character sequences like [i] (common in for loops over arrays) from the forum's BBCode parser, and keeps it in a format most readable for trained programmers.
- Post actual error messages, code and behaviours, not vague paraphrases and especially not "doesn't work". When you're new, what you think is happening and what is actually happening are often not the same. Let the problem speak fully for itself, don't let your own inexperience get in its way.
- Write in grammatically correct semi-formal English. People who post in casual, sloppy English also tend to write casual, sloppy code that wastes everyone's time in the end. Writing code takes attention to detail and intentional action, so start practicing that on what you should already do as a literate.
Advice for GML basics:
- Bookmark the Manual and use it often. It's at docs2.yoyogames.com. When responders like me tell people to use the Manual, we mean it.
- Familiarize yourself with basic syntax. At the very least, learn the basic operators and what the keywords if, for, while, switch, with, return do. These are the ABCs of GML. Use the Manual's overview for basic GML. You should aim to understand and eventually memorize most to all of the operators and keywords in that section with practice.
- Know what each event does. At the very least, learn what the 6 basic ones do and what kinds of code go in each. Use the Manual's events reference for the rest, and memorize them as you get to use them.
- Know the roles of local, instance and global scope. Local variables are for temporary values, loop counters and intermediate results, instance variables are for properties specific to individual instances, and global variables are for centralized values accessible everywhere. Read the Manual entry on scope to learn how to declare and reference each type.
- Know the difference between objects and instances. In GM, objects are types (e.g. human, dog) and instances are live individuals (e.g. Alice, Bob, Lassie, Fido). Don't be the moron asking for "the fur colour of the cat" at the SPCA in peak kitten season.
- Proofread your own code and take your wants off centre stage. Spend more time thinking about what your code is actually doing and what may be done wrong, and less time assuring yourself that it must be a bug with GM. Computers do what you say, not what you want, even when what you say is wrong.
- Learn basic syntax before starting tutorials. At the very least, have the Manual open to the GML Overview section when you start.
- Don't search for all-in-one solutions. Except for small beginner-level games, you'll either turn up nothing, or arrive at something with too much content to learn from at once. Instead, break down your search and look for help with components that are likely to recur even across different projects.
- When doing tutorials, always walk through the logic yourself and relate it back to basic elements. Pause and stop often. Step through the code and use the Index tab on the Manual to remind yourself of built-in functions, keywords and concepts. Don't think for a moment that you're done just because your screen or code looks like the tutorial author's, you're only done when your state of mind looks like the tutorial author's.
- Synthesize, don't plagiarize. After consulting a resource, think forward at least 5-10 alternative ways you can use that resource's subject matter outside the resource's original context, and apply some of them in small proof-of-concepts. A skill that you can only use with your hands held is called an incompetency.