My advice is: Don't expect to program games within the first month or even the first year of picking up Game Maker. I've never taken a computer programming class in my life. My first attempt at computer programming was fidgeting with BASIC on my Commodore 64 back when I was 8 years old. I could print "HELLO WORLD!", make a yellow ball bounce around the screen, and play the national anthem. That was as far as I got - with the help of a manual that my cousin gave me.
Fast forward 10 years later, I fidgeted with the RPG Maker series (first 95, then RM2k). That had a forum to seek help on. There was a plethora of resources online to aid you in using it if you knew how to use a search engine. In the end, I had made a name for myself on the forums back then for learning for myself the ins and outs of the program and how to make it do things that I wanted that other people on the forums hadn't even considered. I'd download a game made by someone in Japan that didn't look like anything I'd seen before in RPG Maker, then try to figure out how they possibly could have done that. Then I'd post my ideas on the forum, get feedback from other members that could make sense of my posts, then things took off from there.
Enter Game Maker. I dabbled with GM5 for a while. My first few attempts at coding by myself were a flop. I tried again with GM6 after reformatting my computer. Again, my attempts at coding anything were a flop. I got on the forums and read through various posts. I saw how people said they did things. So I tried those things that I read. Things started working; I was happy. Then I started finding bugs in things I thought had worked. I started finding bugs in other people's projects. Someone would post something open-source and it'd be highly rated by other people, I'd download it, then I'd discover a bunch of glaring (for me) bugs in it. Then I would try to figure out what was causing those bugs. Then I'd go back to my own code. I'd try to code something of my own based around the source for the projects I was finding bugs in. If I was lucky, I'd discover the cause of the bug. I might not have a working alternative, but I'd find the shortcomings. I never got anything done, but I learned coding tricks others used and discovered my own coding style (which has actually changed many times over the years). I'd post my ideas on the forums, get feedback, then go back to the drawing board. I'd study not just other people's codes but my own codes as well - very critically. I learned some fun codes over the years, but I've also seen plenty of trash codes.
At one point I got tired of trying to write my own code and creating a full working project, even so much as an alpha stage. So I took a "break" and taught myself 6502 Assembly so I could study how Nintendo games were made. I couldn't focus for very long, so it's been many years studying codes. Mostly I studied just one game because it took so long for me to make sense of the code. I'd take some of the things I'd learned from studying that one game and apply it to my projects in Game Maker. Ultimately, studying Nintendo game codes taught me three things:
- There's more than one way to program a cat.
- For every desired action, there is a set of fundamental underlying basic - very basic - logical instructions.
- Even the most basic instruction in a programming language is logically complex (see point 2).
Lesson 1 wasn't anything new, but it makes learning how to code a pain in the ass. Lesson 1 is why a lot of rookies fail so hard at Game Maker. They read a lesson book or watch a tutorial on how to do something, then they try to modify the code logic and get stuck, then come on here asking for help. The problem with that is the coding practices one person uses isn't necessarily the same as another person. Furthermore, one code/method you might learn from a "trusted source" could be fatally flawed; you seek help on the forums with your code which is inherently flawed, receive help which is completely unrelated to your previous code, and are left feeling stranded because the person didn't help you with your code. The rookie fails because he looks at code as the answer, but code is only the clue - the answer is the logic behind the code, which the rookie must understand in order to learn from the help of others.
To help understand lesson 2, consider for example the classic jump-through platform. The player jumps up, passes through a platform, then lands on it. Simple to an untrained eye. While the rookie will see "the platform can be collided with when landing" and try to go from there, the more experienced person will see "the unit is only affected by platforms at its feet when vertical speed is positive and the unit either is not already in a collision or was previously not in a collision; at which point if the platform is a tile the unit's vertical position needs to be set relative to the top coordinate of the tile, otherwise if the platform is an object the unit's vertical position needs to be set relative to the vertical position of the platform object; in either case the unit's vertical speed needs to be set to 0 upon collision."
Lesson 3 is very similar to lesson 2, but is the most important to some extent. First off, the rookie takes everything Game Maker does for him for granted. For example, set hspeed to a value other than 0 and the unit will move horizontally based on that value. Why? The rookie rarely stops to ask, just sets hspeed and watches the unit move horizontally off-screen. For example, set direction to 90 and set speed to some value other than 0 and the unit will move vertically based on the value of speed. Why? The rookie rarely stops to ask. For example, set alarm[0] to some positive value, create an alarm event, add some code in it, then watch the alarm tick down before running its code. Why? The rookie rarely stops to ask. For example, set a variable to the value returned by point_distance(x, y, player.x, player.y) and that variable will hold how far away a unit is from the player. Why? The rookie rarely stops to ask.
First off, point_distance() and its sister function distance_to_object() both triangulate the distance in two-dimensional space. Why should that be reason for concern for anyone? In many cases only one dimension is necessary for calculations; in most cases, factoring in an extra dimension just slows the code down, but sometimes it can drastically change the behavior of the project. I don't even want to think about how distance_to_object() is coded, since it has to take into account bounding boxes for the instances.
Now, as for the simplest example I mentioned, setting hspeed to make an object move, let's look at what's actually going on.
Code:
hspeed = 1;
//This is what you do, this is the easy part.
x += hspeed
//This is what Game Maker does
Seems simple enough. That's because it is. But what studying Nintendo games taught me is that simple routine GM runs isn't as simple as it looks.
Code:
JSR
CLC
LDA x
ADC hspeed
STA x
RTS
Something as simple as basic addition takes a computer a while. Multiplication and division are much worse.
The point is, rookies will usually just look at the end result ("setting hspeed makes the unit move left or right") rather than the logic behind that and then they will completely miss the point of that logic or even the beauty in the logic. Yes, there can be beauty in the logic of a simple code/function. One of the popular codes used almost routinely around here is
Code:
hspeed = keyboard_check(vk_right) - keyboard_check(vk_left)
Let's overlook the fact that it's an outdated, slow code in terms of the points made in Lesson 3. Before this code, most of the time people (including me) would do something like
Code:
if keyboard_check(vk_right) {
if keyboard_check(vk_left) hspeed = 0
else hspeed = 1
}
if keyboard_check(vk_left) {
if keyboard_check(vk_right) hspeed = 0
else hspeed = -1
}
This was horribly slow code. Each key was being checked twice for something so simple. Part of the problem was also that people just took for granted that keyboard_check() returns TRUE or FALSE without even considering what TRUE or FALSE even meant. Really, TRUE and FALSE are nothing but the number 1 and 0 respectively, so it thus followed that you could add or subtract boolean statements in Game Maker without issue.
Sorry, I rambled on a lot. I was bored waiting for my gf to get home from work. The whole point of this post really was just to, in a way, argue against the whole YouTube thing as well as against some of the books and written tutorials floating around. Don't get me wrong, they're great resources - I've watched some of the tutorials out of curiosity and learned a couple things from them sometimes. However, I've also watched some of the most popular tutorials and found myself cussing at my computer screen because of the horrendous logic in some of them. Then people watch those videos and come on here asking for help with something based on those videos; we've seen the codes from those videos so much that we get short-tempered and irritated by people that use them with all of the bugs that we expect from them. (I vaguely remember one time when someone asked for help with jump-through platforms, had watched one of the faulty tutorial videos, and said he was looking for a better code than what was in the tutorial because he foresaw certain bugs - and let me tell you, I told him just how happy I was that he was smart enough to recognize the faulty logic.) The people making those videos rarely explain the logic behind their code. Sometimes they don't even edit their videos and you see them flailing around blindly wondering why their demo isn't working over a single, stupid little typo.
But the fault isn't in the guys making those videos, it's in the people watching them. The YouTube tutorials are like elementary school math -- you're taught a+b=c and expected to remember that for the rest of your life, but then you get to college and WHAM! you're expected to be able to explain
why a+b=c. Most of the people watching the YouTube videos are still stuck in elementary math mode, not collegiate math mode. They expect the answer to, "What is 10 times 5?" to be "50" and then a week later have to get on the forums to ask, "What is 10 times 8?"
FrostyCat is just frustrated after years and years of seeing the same questions on the forums day after day after day. (S)He's been around a long, long time. In the past, our biggest gripe was that people don't read through the forums before asking a question (nothing new on any forum, it drove me nuts on the RM2K forums back in the day); but lately it's been all the people watching YouTube tutorials without a single inkling of understanding of the logic behind the code used in those videos and then needing their hand held every step of the way through their projects. With the advent of Studio 2, most of those video tutorials are out-of-date. The logic still holds in many cases, but the code is otherwise useless now.
Follow-up: Why is hspeed=keyboard_check(vk_right)-keyboard_check(vk_left) an outdated, slow code? Don't get me wrong - I love the code still to this day - but it is still running two keyboard checks every step just in that one line alone. Furthermore Game Maker is doing the same thing automatically as well, so this code is potentially slowing the projects down. It's better to use hspeed=RIGHT-LEFT where RIGHT and LEFT are variables that are set when the keys are pressed. The other benefit to this is if elsewhere in the code the right and left keys need to be checked, you aren't slowing things down with additional keyboard checks.