• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GML How did you all learn?

R

RedRedRed

Guest
Hi, I'm relatively new to GML. I've always had it around me with people I work with(am an animator) and I studied a few courses of C and ++ so I know about syntax basics, but I've never really dug deep into it.

I find specific tutorials if I wanna learn how to create a feature...But I find that I'm just following along with their instructions and never really understand WHY I need to code this way and that way.

Right now I'm trying to learn about turned based grid systems like Fire Emblem, and I'm introduced to state machines...and all these complex terms like globals and mp_grids that I don't really understand that much.
I'm very happy to learn along the way, and I seem to be retaining a lot of what I learn...but from my perspective, I'm just walking around aimless absorbing anything I can without structure to my learning.

I'm sure "advanced" GML people think of a feature. and can immediately implement it with their experience, but at one point in their Game Maker journey, had 0 idea what they were doing.

So can some of you guys share the way you learned, what you focused on first, who you learned from, and how you got onto harder and more complex topics?
 

Shut

Member
I think you might be focusing on more advanced stuff than you probably should if you're a beginner. I really think you should get used to the logic behind what you're trying to code and then move on to the advanced features. The way I learned GML, was by looking at the examples of simple mechanics and slowly trying to understand what each line of the code did. Also, try to experiment/practice as much as you can just to get used to the functions and logic. The manual is really helpful and includes samples of code too.

GMS is very beginner friendly, especially since it comes with D&D, if you're an absolute beginner try that and later move on to GML.
 

Nux

GameMaker Staff
GameMaker Dev.
I'm going to oppose the current here, since I learn by jumping into the deep end without the use of tutorials, therefore trying to do it all by myself; I produce a bad solution that works, then - using the knowledge I'd accrued from mildly failing - try and create a better version (similar to rapid application development). That kind of starvation to know how to complete something to the best of your ability, and finally doing it really makes things stick in with me; I always throw away things if I don't believe they're adequate, so you can imagine I'm constantly iterating a given piece of code.

Additionally, if I seriously am unable to do something, I'd look up how to do it. I'd then follow through with a tutorial and analyse everything. Then, once I feel I've sufficiently prepared myself, try and create the system myself.

However, people learn in different ways, so you should find an environment that you personally feel you learn the most efficient, rather than constraining yourself to whatever someone else has told you works for them.

P.s. Knowing how certain functions work before attempting a solution may be beneficial, since there may be a built-in way to do what you wish already.
 

RiK

Member
Long version:

I was born at exactly the right time, at 13 years old I got my first computer, a Sinclair ZX81. The only way to get anywhere back then was to read the manual and learn to program! Eight years later I started a computer science degree and after graduating worked for many years as a software engineer designing robots brains (true story!)

Short version:

Read the help docs, watch some YouTube tutorials, study as many examples as you can, start with really super-simple little projects that you can complete. Don't move on to the next thing until you've finished the current experiment. Rinse & repeat.
 
A

anthropus

Guest
im also a game artist who is relatively new to programming. i also started to learn GML by making a complex game (you said Fire Emblem), but i did not get far at all, and just got frustrated and confused-- this is not the way to do it. what you have to do, what i finally did after much frustration and lots of work but not going anywhere, is i started from the beginning: learn how to control a square, make it jump, make it have good collision, make it change colors. i know this is far from making something like Fire Emblem, but for game artists as ourselves who know little to nothing about game programming, its very important we start at the very beginning, or else we wont really learn much or know why and how code works. and once you do that, you will see yourself learning more and more complex things until you know enough to make a game like Fire Emblem.

hope that helps!
 

RangerX

Member
The best way is to dive in!
Give yourself extremely small goals and make a prototype, a micro game. Stay with ONE focus in mind: perfectly understanding/grasping what you are doing. This is how you will evolve.
Many people learn my heart or immitation. This leads to quite nothing. You have to really grasp and UNDERSTAND. This is the aspect all learning should focus on. The whys behind the whys.
I remember when I started my first programming/scripting class (well, not like I had many lol). The teacher started us at the very beginning, explaining us how a machine in made so we understand how it works and coding logically comes from that.
 

Tsa05

Member
Ultimately, practice is how we all learned.

When starting out, especially following tutorials, there will always seem to be a specific "right" way to do things, and it will be mysterious. Why must this "variable" have the word "var" in front of it, but not that other "variable?" Why must I check for "collisions" at position y+1 before making my character jump?

There's not actually just one right answer, though. There are always many strategies to solve a programming problem, and even multiple types of code that do the same thing!
For example, the following 3 simple examples do the same thing:
Code:
score = 10;
repeat(3)
{
     score+=1;
}
Code:
score = 10;
for(i=0; i<3; i+=1)
{
     score+=1;
}
Code:
score = 10;
i = 0;
while(i<3)
{
     score+=1;
     i+=1;
}
Each of those code segments simply execute a line of code that increases "score" by 1 three times. There is not really any reason for choosing any one of those 3 methods over another. However, they each have some benefits as you build additional functionality into your coding.

For example, in the For and the While loop examples, you can always know "how many times" you've performed the score+=1 code. The variable i keeps track of this. These simple examples have no need for that information, though, so they are just the same as repeat(3), which keeps track of the loop counter internally.

Why choose one method over another, then? Well, it depends upon whether you, the designer, want something else to happen. Maybe, in addition to doing score+=1 on every loop of code, you also want to do something else every second loop. You would be able to do this by checking whether i mod 2 == 0. But this means you could not use the repeat method, since it doesn't give you a way to keep track of how many times you loop.

Tutorials often make it seem like there's only 1 way to do things because this is true for the tutorial. The person making the tutorial has already thought about many strategies, and has chosen one to demonstrate. If you do not use the same code as the tutorial-maker, your program might not work the same way. But this does not mean that there are not many other strategies (and code) that could achieve the same effect. It's only a matter of thinking.

Consider programming to be like baking (everyone has tried to make cookies at some point, right?). You can follow a recipe-book, which has exact measurements and steps, and you will get an exact result. This can be helpful for learning how some things work without fearing total failure at the end. It's like a tutorial.

As you learn a bit about making a cookie, though, you'll start to realize that the exact amounts of ingredients aren't required. You start to learn that you can modify them a little and get similar results--maybe a little different, but maybe more like the way you want. You will also find that the order of steps is not so absolute. You can mix some things in a different order from the recipe and it doesn't matter. But some steps *must* be in order, and you learn this, too.

Eventually, through practice, you understand the effect of each ingredient, and also the effect of each step, so you can make your own recipes.
 

hippyman

Member
Practice, practice, practice.
Find some inspiration. Make a project.
Learn what's pertinent to your end goal.
Try new things. Archive it. Try something new. Archive it. Try something new. etc.
Take advice from people that are better. Read their code until you actually can read their code.
Don't copy-paste-forget. Instead, copy-paste-tweak-test-tweak-test-tweak-test-etc. Break things and fix them again.
Reinvent the wheel. You may get nowhere, but you'll definitely learn something or find a better understanding of something.
If it's something you really enjoy doing, you'll get better.
 

Cpaz

Member
Youtube starting out.
Then some trial and error.
Some google.
More trial and error...
More google...
...

Repeat still to this day.
 
S

Silver_Mantis

Guest
Firstly, Welcome!

So I learned from a lot of tutorials. I even bought some that were well worth it. (Only like 15 bucks or so)
I'd like to say I learned a lot of coding from my Bachelors Degree in Game Design, but that was the more art side of it. (At least I have the paper right? haha)
I'm still new to GML in a many ways and have never been a coder myself, so one thing I changed was my attitude toward coding. At first I thought it was boring and dull, which is can be at times.
But other times I just realize how important it is to accomplish my dreams and ideas, and how much control I have over the project.
If you are willing to learn. anything, even a YouTube tutorial, can be a gold mine of knowledge.

I also would take a look at other peoples projects, and see why they code things a certain way.
Learning from others as a community is such an important trait you must obtain to learn how all this works.

If you ever need help or insight, I can try my best to come up with a solution for ya, because my story started off very similarly to yours, and I hope you do well in your journey! :)
 

Kyon

Member
I had this story idea or gameplay idea and just tried to make exactly that. Every time I stumbled upon something I didn't understand I asked the GMC or looked it up on internet (youtube or tutorials).
 

chaz13

Member
Honestly it was a long time back, but if you're passionate about working on projects - big or small- you'll find you become proficient really quickly, and without putting effort into specifically studying.
 
R

RedRedRed

Guest
Thanks everyone for your replies and feedback. I now know how important it is to have a clear goal of what I want to do, and that there is not one solution to everything. We just have to find the best way ourselves. I'm gonna stick to some basics, learn everything I need at the moment and apply on it further. It also helps if I know all the functions, so iteration and familiarization is great. The community is really big, and the references and tuts can be found anywhere. Makes me think how amazing the pioneers probably were.

Thanks everyone. The community is great. Hoping to learn a whole lot more.

(Also as a side note : do you think I came to GMS at the wrong time? I see Game Maker 2, and I'm scared that I need to throw all my acquired knowledge out.
I'm pretty sure it wont be as drastic as I think it would be, but do I have anything to worry about?
)
 

kamiyasi

Member
I started using Game Maker in 2007. At first I used the drag and drop and only really used the functions that I understood from the example projects. The key for me was practice, practice, and experimentation. I made at least a half dozen short games before I even delved into the world of scripting. Also, pushing myself was a big factor. I experimented with things that were complex for me to understand at the time like 3D functions and physics.
 

FrostyCat

Redemption Seeker
What I'd like to see is less of this YouTube-all-day-long BS, and more background-building in concrete math, CS and physics.

I look at some people on the GMC call Dijkstra's "advanced AI" and elementary kinematics (e.g. displacement with constant speed+acceleration) "advanced movement planning". To anyone teaching these subjects, these items belong in a 101 introductory course and are expected of even flyweights. Dijkstra's is a given within a few months of an average 101 CS course, and the s = v*t + 0.5*a*t*t formula is often one of the first five formulas taught in an average 101 physics course.

I've borne witness to the rise of YouTube GM videos, and the biggest problem is the growing prevalence of conceptual black boxes in novice work today. The instant they need to do even the slightest variation on their own, they can't proceed without rescue. Math and CS are the only keys to unlocking these black boxes, but increasingly novices are encouraged to get into the fray unarmed.

Most novices I see who struggle around here have more pressing issues to address than GML: basic math, basic logic, basic problem-solving skills, even basic literacy. It does them no favours to frame these defects as learning styles and encourage them to progress with their pants down.
 
  • Like
Reactions: Nux
S

Silver_Mantis

Guest
What I'd like to see is less of this YouTube-all-day-long BS, and more background-building in concrete math, CS and physics.

I look at some people on the GMC call Dijkstra's "advanced AI" and elementary kinematics (e.g. displacement with constant speed+acceleration) "advanced movement planning". To anyone teaching these subjects, these items belong in a 101 introductory course and are expected of even flyweights. Dijkstra's is a given within a few months of an average 101 CS course, and the s = v*t + 0.5*a*t*t formula is often one of the first five formulas taught in an average 101 physics course.

I've borne witness to the rise of YouTube GM videos, and the biggest problem is the growing prevalence of conceptual black boxes in novice work today. The instant they need to do even the slightest variation on their own, they can't proceed without rescue. Math and CS are the only keys to unlocking these black boxes, but increasingly novices are encouraged to get into the fray unarmed.

Most novices I see who struggle around here have more pressing issues to address than GML: basic math, basic logic, basic problem-solving skills, even basic literacy. It does them no favours to frame these defects as learning styles and encourage them to progress with their pants down.
Not to be rude, but you always seem to create posts to put others down and act as if you created the GML language.
We are all learning here, and you must have compassion and remember that a lot of us are artists and not C++ Certified IT Techs from Harvard.
We are all people who strive to accomplish our dreams of making great and enjoyable games.

That's great that you understand the concept of why simple issues are not being taught and that YouTube
tutorials may only teach a fraction of the basics, but that attitude does not create a learning environment people want to interact with.
You're a smart person, and we need people like you to explain to us the basics we can't understand, just not in a demeaning way ya know?
Take your skills and use them to benefit others instead of just lifting yourself up and telling everyone why they are novices.
 
S

Silver_Mantis

Guest
(Also as a side note : do you think I came to GMS at the wrong time? I see Game Maker 2, and I'm scared that I need to throw all my acquired knowledge out.
I'm pretty sure it wont be as drastic as I think it would be, but do I have anything to worry about?
)
I feel like if you understand the basics of 1.4, you'll be even better for when GM2 fully releases. :D
A lot of the same concepts are there... Late is better than never! Don't sweat it.
 

TheouAegis

Member
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:
  1. There's more than one way to program a cat.
  2. For every desired action, there is a set of fundamental underlying basic - very basic - logical instructions.
  3. 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.
 
Last edited:
I have been using on and off for about a year or 2 - though, I have ramped up my usage a lot in the last few months.

I learned a ton by doing a bunch of Shaun Spaulding's tutorials. He does a really good job explaining why you are doing something. And even if the game you want to make isn't like his examples - I highly recommend anyone new to GML (even if you have experience coding other languages) to go through his stuff. He also does most of his tutorials in code, not drag & drop. Which is great - D&D is a cool system, but it is also fairly limiting. In theory you can do everything with it (or so people say), but from all accounts I have seen, it takes a lot of extra work to use it with complex games. Learn to code GML as soon as you can and you will have a much easier time.

For example (regarding Shaun's tutorials), I did a large portion of his 2D platformer tutorials and I experimented with it all pretty extensively. And although I came up with a decent start to a platformer, I wasn't really digging it and dropped it. Then I started on a 3D FPS style game (inspired by Heartbeast's 3D dungeon tutorial). 95% of what was done in Shaun's tutorials still applies to what I am doing now in this 3D game. It doesn't really matter what style of game you are making, the basics pretty much apply across the board. Of course, I had some learning curve (still do) with the 3D capabilities, but totally manageable with some time and the help of the nice people on this forum.

I have also found that setting small goals/phases as a useful approach. I see many new people posting here asking how to make an entire game, when of course - no one is going to tell you how to create your entire game. They get stuck on trying to digest a huge concept, get frustrated when they don't receive help. While you need to have a big idea (end goal), you need to break it into small chunks. Then tackle each chunk (maybe even break that into smaller chunks) and go from there. It is both more manageable when you are learning, as well as more likely to get you assistance on the forums here.

Final note: Remember that GMS is not going to make a game for you. It isn't RPG Maker (or others like it). Not that there is anything wrong with RPG Maker, it is a great system. But, GMS is not that. GMS gives you nice tools and a basic frame work to do anything you want. But, you have to set it all up (either code or drag & drop) and really flesh out every element of it. It takes time, patience and in the end it is extremely powerful.
 

Yal

šŸ§ *penguin noises*
GMC Elder
P.s. Knowing how certain functions work before attempting a solution may be beneficial, since there may be a built-in way to do what you wish already.
That pretty much sums stuff up. You can do more or less anything once you get an understanding for base mechanics (try following official tutorials to make a basic platformer or shmup to get that) like how events work, as long as you have an info source (examples, video tutorials on complicated stuff, downloaded engines, etc), but everything you learn about speeds up the process since you can use anything you've mastered in new ways.

I'd personally recommend taking the time to just browse the manual every once in a while and read up on random stuff that seems interesting, it gets much faster to find relevant help/info if you already have some idea about what functionality exists.

Also, don't make too big games too early, smaller projects are easier to finish and learn from and it's kinda discouraging to abandon huge projects because they got too messed up.
 
Top