I'm a beginner and I need help

vespi

Member
Hello, I want to learn GameMaker properly. I know all the basics (how to make sprites, objects, rooms, the meaning of every option...), but I don't know which things I should focus on. I have two main questions:

-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game? For example, I've seen people put keyboard inputs in the Step Event, but there's already a Keyboard Event for keyboard inputs. I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time? I have some programming experience (1 year of C++), and although it's not much, it was more than enough to understand the basics of programming (variables, statements, logic, arrays, pointers...). Is somewhere out there a course which skips the basics and jumps directly to GML?

I don't know if it is important to say, but the game genre I want to tackle is turn-based RPG. Any help related to that is very appreciated. Thanks in advance, everyone : )
 
Hey there! I'm actually in a very similar boat right now so I thought I'd share how I'm approaching gms2.

I've started with a few of the more general tutorials (for example the "Space Rocks" tutorial that YoYo Games put out.) After I felt I was in a good place I just set out to alter that base of a game into something more. In an effort to implement new features and changes, I'm gradually picking up bits and pieces of gml knowledge and practice. I'm having fun and learning.

At first I approached it with the same mentality that you described but I opted to just dive in instead.

hope that helps!
 

vespi

Member
Hey there! I'm actually in a very similar boat right now so I thought I'd share how I'm approaching gms2.

I've started with a few of the more general tutorials (for example the "Space Rocks" tutorial that YoYo Games put out.) After I felt I was in a good place I just set out to alter that base of a game into something more. In an effort to implement new features and changes, I'm gradually picking up bits and pieces of gml knowledge and practice. I'm having fun and learning.

At first I approached it with the same mentality that you described but I opted to just dive in instead.

hope that helps!
I didn't know that YoYo Games put out official tutorials, I will check them out! I forgot to say that I'm using GMS1.4, do you know if the difference between 1.4 and 2 is that big? Thank you!
 

Psycho_666

Member
Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game?
It all depends on the situation.
Some people put everything in the step event and you can absolutely do that. I prefer to use the keyboard events just so the code is more spread out and when I have an issue I know where to look without having to scroll through hundreds of lines of code. Everything have it's uses, but in general you can do pretty much everything in the step event, draw event and eventually collision event...

How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time?
GML is super intuitive. Since you already have experience with programming you know the basics like loops, arrays, etc etc.
My best advice is just start doing tiny basic projects and research only what you need. Reading the entire manual can become really daunting real fast.
turn-based RPG.
RPGs in general are one of the most complex for beginners just because of all different systems that needs interacting with each other and all the content you need before you can even tell if this is going to work out or not. And then having it turn based is even more complicated... Basically you are looking and the most difficult genre to execute.
 

Psycho_666

Member
do you know if the difference between 1.4 and 2 is that big?
The interface is different, afaik the rendering is different, there are way too many changes between the two.
There are enough GMS1.4 materials around and people still widely use it. Also YouTube is crazy good resource.
 

vespi

Member
It all depends on the situation.
Some people put everything in the step event and you can absolutely do that. I prefer to use the keyboard events just so the code is more spread out and when I have an issue I know where to look without having to scroll through hundreds of lines of code. Everything have it's uses, but in general you can do pretty much everything in the step event, draw event and eventually collision event...
Oh, I didn't know, I thought doing it in the Step Event was more efficient or something like that... Glad to know that there are multiple ways of approaching events!

GML is super intuitive. Since you already have experience with programming you know the basics like loops, arrays, etc etc.
My best advice is just start doing tiny basic projects and research only what you need. Reading the entire manual can become really daunting real fast.
OK, that sounds good, I will try to do some basic code and exercises before jumping onto something bigger. And I'm also glad to know that I don't have to read the full manual from top to bottom.

RPGs in general are one of the most complex for beginners just because of all different systems that needs interacting with each other and all the content you need before you can even tell if this is going to work out or not. And then having it turn based is even more complicated... Basically you are looking and the most difficult genre to execute.
This surprised me, but now that I think about it, makes sense. Maybe I will try to do some kind of RPG without battles and without interface, and add things to the proyect little by little.

Thanks for the help!
 

Psycho_666

Member
I thought doing it in the Step Event was more efficient or something like that
It probably is, but we come back to that it depends on what you do. Movement you can use step event because it's just check and change to the coordinates... 2 lines for each direction. Having different event for each direction is not really helpful. But then you may have something like an attack, that will trigger an animation and create a particle effect and do some other stuff and in that case I would move it outside the step event. If there is an issue with the attacking I will check the attack button event and not go through all the rest of the step event code.
This surprised me, but now that I think about it, makes sense
Well yes. You have movement system and world interaction and combat and health and items and skills and conversation system and leveling up and inventory system and equipment and character stats and all sorts of other things.
What do you need for a top down racing game? Movement.and collisions. That's it.
Thanks for the help!
You are very welcome ☺
 

vespi

Member
It probably is, but we come back to that it depends on what you do. Movement you can use step event because it's just check and change to the coordinates... 2 lines for each direction. Having different event for each direction is not really helpful. But then you may have something like an attack, that will trigger an animation and create a particle effect and do some other stuff and in that case I would move it outside the step event. If there is an issue with the attacking I will check the attack button event and not go through all the rest of the step event code.
Oh that makes a lot more sense, I was only thinking about WASD and the arrow keys.

Well yes. You have movement system and world interaction and combat and health and items and skills and conversation system and leveling up and inventory system and equipment and character stats and all sorts of other things.
What do you need for a top down racing game? Movement.and collisions. That's it.
Hahahaha I don't think I want that level of complexity, I will stick to some simple, exploration-based, RPGMaker-like game. BUT it really needs inventory, conversation, and world interaction system *gasps*. Guess I'll code some tank game (I love them actually).
 

Bearman_18

Member
Read the crap out of the documentation (access it by pressing f1). Almost everything you could want to know is in there, so consult it before looking up the problem, or even watching tutorials. The problem solving you will do is an invaluable experience. Hell, read the documentation for fun sometimes. Just read random functions that catch your eye. After you've solved a problem, then look up tutorials, to see if there's a better way. It's a longer process, but it's helped the development of my abilities considerably.
 
Hello, I want to learn GameMaker properly. I know all the basics (how to make sprites, objects, rooms, the meaning of every option...), but I don't know which things I should focus on. I have two main questions:

-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game? For example, I've seen people put keyboard inputs in the Step Event, but there's already a Keyboard Event for keyboard inputs. I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time? I have some programming experience (1 year of C++), and although it's not much, it was more than enough to understand the basics of programming (variables, statements, logic, arrays, pointers...). Is somewhere out there a course which skips the basics and jumps directly to GML?

I don't know if it is important to say, but the game genre I want to tackle is turn-based RPG. Any help related to that is very appreciated. Thanks in advance, everyone : )
I recommend Slyddar's Udemy course on GMS2, the one with the knight platformer game where you jump, use a sword, and hit the frog. It will teach you fundamentals and good programming practices, and most importantly state machines. These will get you where you want to go. For further education, follow FriendlyCosmonaut, Matharoo, and Pixelated Pope on Youtube. All have great tutorials that will show you how to make neat stuff in GMS2.
 

vespi

Member
I'm curious, is there a reason you are using GMS1.4 instead of GMS2?
It's simply because GMS1.4 Standard does not expire, so it's free and I can use it without worrying much about money or time. I could buy the 99$ version of GMS2, but I prefer to learn a bit more of GameMaker and make sure that it is really a good option.
 

vespi

Member
I recommend Slyddar's Udemy course on GMS2, the one with the knight platformer game where you jump, use a sword, and hit the frog. It will teach you fundamentals and good programming practices, and most importantly state machines. These will get you where you want to go. For further education, follow FriendlyCosmonaut, Matharoo, and Pixelated Pope on Youtube. All have great tutorials that will show you how to make neat stuff in GMS2.
I will check them out, thanks a lot!
 

Bearman_18

Member
1.4 is a fine place to start. It's still GameMaker, it's still good. But if you take a liking to it, it's definitely worthwhile to save up the money to buy the Developer license for GMS2. It has a much better UI for the most part, and adds considerable amounts of functionality. And with the eventual 2.3 release, even more functionality is being added that honestly should've been in the engine ages ago. Lol.
 

Rob

Member
Hello, I want to learn GameMaker properly. I know all the basics (how to make sprites, objects, rooms, the meaning of every option...), but I don't know which things I should focus on. I have two main questions:

-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game? For example, I've seen people put keyboard inputs in the Step Event, but there's already a Keyboard Event for keyboard inputs. I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time? I have some programming experience (1 year of C++), and although it's not much, it was more than enough to understand the basics of programming (variables, statements, logic, arrays, pointers...). Is somewhere out there a course which skips the basics and jumps directly to GML?

I don't know if it is important to say, but the game genre I want to tackle is turn-based RPG. Any help related to that is very appreciated. Thanks in advance, everyone : )
If you can read the manual in its entirety then great but if you at least peruse it so you have a general idea of what's possible, then, when you want to code something, you might think to check the manual to see if a function exists for what you want to achieve. The more you use the manual the more self-sufficient you'll become as well, as you'll feel more and more comfortable trying things out yourself, rather than relying on outside resources like tutorials. Not that using outside resources is a bad thing but how often to you find something that is an exact perfect match for what you have in mind!?

Whenever you come across a function that's new to you, take a minute to check its reference in the manual and see what it returns, if anything.

If a function returns an instance_id or noone and you type:

GML:
soldier = collision_point(x, y, obj_something);
Then soldier will equal an instance_id or noone. All of the other collision_ functions are similar, but other collision functions like instance_place or place_meeting return different things, which is why it's important to check first :p

Just stick with it (making games and using GML) and you should improve over time.

I have a series for a turn-based RPG, but if you want to be able to code it yourself, knowing how to use things like data structures, enumerators, state systems, and collision detection to name a few, will help a lot. You could always try and build the game one system at a time, but do it in little mini projects, like "here's a project that could act as an inventory" or "here's a project full of NPC's that walk around and talk to the player" or "here's the player with a perfect collision system".

I think knowing what systems you want in your game and knowing how everything will fit together is important. Don't leave saving/loading till last - know how you will save/load things as you go, rather than "OK i finished my game but now I have to code a complete saving/loading system for it".
 
Last edited:

samspade

Member
GMS1.4, do you know if the difference between 1.4 and 2 is that big?
Currently, pre 2.3, the most obvious changes are to the IDE. There are many other smaller changes as well, for example a lot of functions are slightly different, but for the most part, the code is exactly the same. You can see the video below for a list of the major changes.

However, when 2.3 goes fully public, there will be massive changes. Not only will there be major changes and additions to code, but there will be significant additions to the built in tools (like animation). Also, as 1.4 isn't supported anymore it wouldn't be a good idea to start developing anything substantial in it.


Is somewhere out there a course which skips the basics and jumps directly to GML?
See this playlist: https://www.youtube.com/playlist?list=PLwgH1hDD0q1Eq2xXKhkiJmtt7ml599CSt

While done in GMS 2, The language itself is mostly the same I'm pretty sure 95%-99% of this series is applicable for both at this point (pre 2.3).
 

TsukaYuriko

🌠
Forum Staff
Moderator
Welcome to the GMC! It's always refreshing to see someone new and enthusiastic trying to tackle things step by step instead of diving in head first. You're on the right track already! :)

I'll be responding to the aspects I believe could use some elaboration or haven't been directly answered yet.

-Which events, actions and options are actually helpful?
Familiarize yourself with the basic event types you'll likely find yourself using most commonly: Create, Step, Draw, Destroy and Cleanup.

  • The Create event runs when an instance of the object is created, and only then.
    • You mainly put declarations into this event, or anything else that needs to happen exactly once when an instance is created and never again.
  • The Step events run every step (also called frame).
    • You put your game's ongoing logic into this event - anything that needs to be continuously checked or changing.
    • The Begin Step event fulfills the same purpose, but all Begin Step events run before all Step events. All End Step events run after all Step events. The order is: All Begin -> All Step -> All End.
  • The Draw events run every step (unless explicitly disabled or the instance is invisible).
    • You put your game's drawing into this event.
    • Common pitfall: Merely having a Draw event disables the automatic drawing of the object's instances. This can be re-enabled by calling draw_self or its DnD equivalent Draw Self.
    • These are the only events in which drawing functions will show a visible effect by default. Your drawing will be overwritten by the room's background otherwise - unless it doesn't have a background. However, the engine is optimized to handle drawing in the Draw events, so you should avoid drawing outside of them.
    • The Draw Begin and Draw End events fulfill the same purpose and are ran in the order of Begin -> Draw -> End, similarly to the Step events.
    • The Draw GUI event and its Begin/End variations run after all the other draw events and disregard the location of any cameras and can be scaled and sized separately from all other drawing. This is useful for user interface elements, for example.
  • The Destroy event runs when an instance is explicitly destroyed, for example via instance_destroy.
    • You can put any code that should run when an instance is destroyed into this event, such as sound effects when an enemy dies.
    • There is no guarantee for this event to run over the course of an instance's life span.
  • The Cleanup event runs when an instance is removed for any reason, for example when it is destroyed or you leave the room it was in.
    • You put deallocations for dynamic resources such as lists, grids or maps (which were declared in the Create event) here.
    • There is a guarantee for this event to run over the course of an instance's life span.
    • This is the counterpart of the Create event, as it denotes the end of the instance's life span.
Internalize these and you will be able to plan out the life span of your objects' instances clearly.
Declare the variables and resources they will be using in Create.
Control how they behave in Step.
Control how they look in Draw.
Make them go out with a bang in Destroy, if applicable.
Free up memory used by the used resources in Cleanup to avoid memory leaks.

Common function families include the keyboard, mouse, draw, collision and random functions (the manual should yield relevant results for these terms).
Other extremely useful functionality includes things like arrays and the dynamic data structures: Lists, grids, maps, and the somewhat more rarely applicable queues, stacks and priority queues.
In terms of controlling the flow of your code, the available statements can be found on the Language Features page.

Which things should I avoid if I want full control over my game?
Avoid setting anything as solid, as you're handing over control over positioning while there is a collision involving a solid instance going on. This is probably the most common cause of beginner frustration.

That aside, avoid relying on events (other than the Step/Draw order I mentioned earlier) executing in a specific order - because they don't. This behavior is subject to change at any point in time. Anything that is critical to execute in a specific order should rely on the Step chain (or depth (1.x) / layers (2.x) for drawing). A classic example of this is "attaching" one instance to another to make them move as if they were one - if you put movement and following of each into the Step event, you have a 50% chance of it working out fine (if the follower's code runs after its target's) and a 50% chance of the follower lagging behind by one frame (if the follower's code runs before its target's). Correct ways to handle these would be to either handle it in a single event (the main body moves, then positions its attachment) or having the follower's code in the End Step event.

I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
The Execute Code action is what lets you use GameMaker's programming language, GML, instead of the visual DnD blocks. GML has everything DnD has (and more). If you wish to use GML, Execute Code is indeed all you need.
Note that in GameMaker Studio 2, you have the option to purely use GML, without the need to put Execute Code blocks everywhere - this interface basically makes object event and script windows look like a text editor and may therefore seem more familiar to you due to having experience with C++.

-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time?
Reading the entirety of the manual is not at all required. A lot of manual sections will deal with platform-specific functions you likely will not be using for a long time to come, if ever. The common function families I mentioned earlier are a good starting point to get a good grip of the basic foundation.

Definitely read up about the difference between instances and objects, as this is something that is often mixed up and then becomes the result of frustration. You can think of this as the difference between objects and classes in C++.
How to address variables in other instances is also a good topic to research.

In general, the manual is an extremely valuable resource to just keep open at any point in time so you can look up new or unfamiliar stuff. Note that you can middle-click a function you're unsure how to use to bring up its manual page.
 
Last edited:

vespi

Member
If you can read the manual in its entirety then great but if you at least peruse it so you have a general idea of what's possible, then, when you want to code something, you might think to check the manual to see if a function exists for what you want to achieve. The more you use the manual the more self-sufficient you'll become as well, as you'll feel more and more comfortable trying things out yourself, rather than relying on outside resources like tutorials. Not that using outside resources is a bad thing but how often to you find something that is an exact perfect match for what you have in mind!?

Whenever you come across a function that's new to you, take a minute to check its reference in the manual and see what it returns, if anything.

If a function returns an instance_id or noone and you type:

GML:
soldier = collision_point(x, y, obj_something);
Then soldier will equal an instance_id or noone. All of the other collision_ functions are similar, but other collision functions like instance_place or place_meeting return different things, which is why it's important to check first :p

Just stick with it (making games and using GML) and you should improve over time.

I have a series for a turn-based RPG, but if you want to be able to code it yourself, knowing how to use things like data structures, enumerators, state systems, and collision detection to name a few, will help a lot. You could always try and build the game one system at a time, but do it in little mini projects, like "here's a project that could act as an inventory" or "here's a project full of NPC's that walk around and talk to the player" or "here's the player with a perfect collision system".

I think knowing what systems you want in your game and knowing how everything will fit together is important. Don't leave saving/loading till last - know how you will save/load things as you go, rather than "OK i finished my game but now I have to code a complete saving/loading system for it".
I'll surely check out your RPG series, thank you very much!! And thank you for the tips, too!
 

vespi

Member
Currently, pre 2.3, the most obvious changes are to the IDE. There are many other smaller changes as well, for example a lot of functions are slightly different, but for the most part, the code is exactly the same. You can see the video below for a list of the major changes.

However, when 2.3 goes fully public, there will be massive changes. Not only will there be major changes and additions to code, but there will be significant additions to the built in tools (like animation). Also, as 1.4 isn't supported anymore it wouldn't be a good idea to start developing anything substantial in it.




See this playlist: https://www.youtube.com/playlist?list=PLwgH1hDD0q1Eq2xXKhkiJmtt7ml599CSt

While done in GMS 2, The language itself is mostly the same I'm pretty sure 95%-99% of this series is applicable for both at this point (pre 2.3).
Thanks!! I appreciate it.
 

vespi

Member
Welcome to the GMC! It's always refreshing to see someone new and enthusiastic trying to tackle things step by step instead of diving in head first. You're on the right track already! :)

I'll be responding to the aspects I believe could use some elaboration or haven't been directly answered yet.


Familiarize yourself with the basic event types you'll likely find yourself using most commonly: Create, Step, Draw, Destroy and Cleanup.

  • The Create event runs when an instance of the object is created, and only then.
    • You mainly put declarations into this event, or anything else that needs to happen exactly once when an instance is created and never again.
  • The Stepevents run every step (also called frame).
    • You put your game's ongoing logic into this event - anything that needs to be continuously checked or changing.
    • The Begin Step event fulfills the same purpose, but all Begin Step events run before all Step events. All End Step events run after all Step events. The order is: All Begin -> All Step -> All End.
  • The Drawevents run every step (unless explicitly disabled or the instance is invisible).
    • You put your game's drawing into this event.
    • Common pitfall: Merely having a Draw event disables the automatic drawing of the object's instances. This can be re-enabled by calling draw_self or its DnD equivalent Draw Self.
    • These are the only events in which drawing functions will show a visible effect by default. Your drawing will be overwritten by the room's background otherwise - unless it doesn't have a background. However, the engine is optimized to handle drawing in the Draw events, so you should avoid drawing outside of them.
    • The Draw Begin and Draw End events fulfill the same purpose and are ran in the order of Begin -> Draw -> End, similarly to the Step events.
    • The Draw GUI event and its Begin/End variations run after all the other draw events and disregard the location of any cameras and can be scaled and sized separately from all other drawing. This is useful for user interface elements, for example.
  • The Destroy event runs when an instance is explicitly destroyed, for example via instance_destroy.
    • You can put any code that should run when an instance is destroyed into this event, such as sound effects when an enemy dies.
    • There is no guarantee for this event to run over the course of an instance's life span.
  • The Cleanup event runs when an instance is removed for any reason, for example when it is destroyed or you leave the room it was in.
    • You put deallocations for dynamic resources such as lists, grids or maps (which were declared in the Create event) here.
    • There is a guarantee for this event to run over the course of an instance's life span.
    • This is the counterpart of the Create event, as it denotes the end of the instance's life span.
Internalize these and you will be able to plan out the life span of your objects' instances clearly.
Declare the variables and resources they will be using in Create.
Control how they behave in Step.
Control how they look in Draw.
Make them go out with a bang in Destroy, if applicable.
Free up memory used by the used resources in Cleanup to avoid memory leaks.

Common function families include the keyboard, mouse, draw, collision and random functions (the manual should yield relevant results for these terms).
Other extremely useful functionality includes things like arrays and the dynamic data structures: Lists, grids, maps, and the somewhat more rarely applicable queues, stacks and priority queues.
In terms of controlling the flow of your code, the available statements can be found on the Language Features page.


Avoid setting anything as solid, as you're handing over control over positioning while there is a collision involving a solid instance going on. This is probably the most common cause of beginner frustration.

That aside, avoid relying on events (other than the Step/Draw order I mentioned earlier) executing in a specific order - because they don't. This behavior is subject to change at any point in time. Anything that is critical to execute in a specific order should rely on the Step chain (or depth (1.x) / layers (2.x) for drawing). A classic example of this is "attaching" one instance to another to make them move as if they were one - if you put movement and following of each into the Step event, you have a 50% chance of it working out fine (if the follower's code runs after its target's) and a 50% chance of the follower lagging behind by one frame (if the follower's code runs before its target's). Correct ways to handle these would be to either handle it in a single event (the main body moves, then positions its attachment) or having the follower's code in the End Step event.


The Execute Code action is what lets you use GameMaker's programming language, GML, instead of the visual DnD blocks. GML has everything DnD has (and more). If you wish to use GML, Execute Code is indeed all you need.
Note that in GameMaker Studio 2, you have the option to purely use GML, without the need to put Execute Code blocks everywhere - this interface basically makes object event and script windows look like a text editor and may therefore seem more familiar to you due to having experience with C++.


Reading the entirety of the manual is not at all required. A lot of manual sections will deal with platform-specific functions you likely will not be using for a long time to come, if ever. The common function families I mentioned earlier are a good starting point to get a good grip of the basic foundation.

Definitely read up about the difference between instances and objects, as this is something that is often mixed up and then becomes the result of frustration. You can think of this as the difference between objects and classes in C++.
How to address variables in other instances is also a good topic to research.

In general, the manual is an extremely valuable resource to just keep open at any point in time so you can look up new or unfamiliar stuff. Note that you can middle-click a function you're unsure how to use to bring up its manual page.
OMG THANK YOU VERY VERY MUCH!!! I think this is everything I need to know, thanks for taking the time to answer! :)
 

woods

Member
i dont know of anybody that has read the players handbook, dungeon master guide, and monster manual front to back full-thru before they started a DnD game ;o)

deff cruz thru the manual .. and reference that thing often. this book is going to be your best friend.


you have a leg up with a year of C++ hellofa lot more of a bonus than me when i first started.

biggest piece of advice i can toss out here is..
baby steps... dont do EVERYTHING all at once. a little planing and forethought goes a long long way .
also the people here on GMS forums are an awesome source for help. dont be afraid to ask... the only stupid question is the one we were afraid to ask
 

Yal

🐧 *penguin noises*
GMC Elder
-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game? For example, I've seen people put keyboard inputs in the Step Event, but there's already a Keyboard Event for keyboard inputs. I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
You essentially can't make a game without the Create, Step and Draw events, so figuring out how they work is an important step. (These days, they're basically the only ones I'm using, too, but I opt in for collision events for debris and other stuff where speed is more important than precision)

Execute Code lets you do anything at the speed you can type it out. Not all advanced functions have D&D actions, and the extra time needed to locate, drag and drop D&D events means they're more inconvenient than code for a power user that knows how everything works already. One of the big features of GMS2 is the ability to make "code-only" projects where you basically get a prefilled single Execute Code action each time you create a new event, and can't use anything else.

Some misc tips in no particular order:
  • The solid property changes how collisions work; if you want full control, you never want to make objects solid. (To be precise, it undoes movement before handling a collision event when two instances collide if either is solid. This makes it really hard to do things like objects that only stops you under certain conditions, like one-way doors)
  • The built-in movement system's movement happens between the Step and End Step events. The order objects are moved is not explicitly defined (same with the order things are drawn). If you want full control, you'd ideally want to handle both of these yourself with some mix of loops and priority queues. (But you only really need to do it yourself if the order is important)
  • One advantage of handling input yourself in the step event and not using keyboard events is that you can check for variable keycodes, so it's easier to add control remapping this way. Events check for a hardcoded key and can't be easily changed.

-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time? I have some programming experience (1 year of C++), and although it's not much, it was more than enough to understand the basics of programming (variables, statements, logic, arrays, pointers...). Is somewhere out there a course which skips the basics and jumps directly to GML?

I don't know if it is important to say, but the game genre I want to tackle is turn-based RPG. Any help related to that is very appreciated. Thanks in advance, everyone : )
The manual probably has too much information to fit into a normal human mind at once, so I wouldn't read the entire thing back-to-back. You can middle-click any function name to open the manual page for it (doing it on an asset name will open the corresponding editor, it's useful with scripts in particular). Usually I'd recommend just skimming through a section when you need to do something relevant... e.g. when you want to make overworld movement, you might be interested in the pages for movement and collision checking. When you work on RPG stats, have a look at the pages for structs, arrays and data structures.

If you're not familiar with state machines, you might wanna read up on how to make those in GM as soon as possible... they're extra useful in RPGs, and since GM is built for action games instead of turn-based games, having layered state machines is the easiest way to split turns up into discrete steps (wait for player input, execute actions, wait for flashy animations to end, check if either side is dead, etc)

IDE-wise, I recommend memorizing the hotkeys Ctrl-T for "go to anything" (type in a resource name, the best matches show up in a list) and Ctrl-Shift-F (search for a text string in the entire codebase of the current project), they speed up looking for information... it's easy to forget how your code works, so being able to look things up quickly when making changes (or just FINDING the damn thing again) shaves off a lot of time and frustration.
 

Niels

Member
Hello, I want to learn GameMaker properly. I know all the basics (how to make sprites, objects, rooms, the meaning of every option...), but I don't know which things I should focus on. I have two main questions:

-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game? For example, I've seen people put keyboard inputs in the Step Event, but there's already a Keyboard Event for keyboard inputs. I've also never seen people utilize any other action apart from Execute Code, can everything be achieved just with that action?
-How should I approach GML? Is it a good idea to read the GML manual in its entirety or is that a waste of time? I have some programming experience (1 year of C++), and although it's not much, it was more than enough to understand the basics of programming (variables, statements, logic, arrays, pointers...). Is somewhere out there a course which skips the basics and jumps directly to GML?

I don't know if it is important to say, but the game genre I want to tackle is turn-based RPG. Any help related to that is very appreciated. Thanks in advance, everyone : )
-Which events, actions and options are actually helpful? Which things should I avoid if I want full control over my game?

In theory every event is useful, but you can follow this general rule:

The most used events are:
Create event = for initialising variables and reading or setting data that ONLY have to be executed once (when the object/instance is created)
(for example, making variables to be used by the instance, getting stats from a datastructure,)
step event = executing code while the game runs, for example getting input, or setting position, angle, animations, and checking for collisions when repositioning the isntance.
draw event = drawing stuff (every draw text, sprite, shape), but is also used to set blendmodes or shaders.
draw_GUI = for drawing stuff on TOP of everything else, and it follows the view/camera instead of using room coordinates.

lesser used events:

Collision event = a simple form of collision detection, IMO using place_meeting, instance_place, or other collision functions in the step event will be more flexible than using this event.
input event = a simple form of input checking, again using the keyboard_check or mouse_input functions in the step even will give you much more flexibility.
 
Top