• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!

GameMaker/GML Tips

matharoo

Udemy Instructor
Hey!

I'm creating this thread for posting tips, tricks and random knowledge that may help GameMaker users. Users can look here and read the posts by our amazing members and learn awesome stuff!

I also have a page like this on my website, which targets beginners: Link

--------------------------------------------------------------------------------------------------------------
I am posting Tip #7 from that page here.

GameDev Palace said:
In this tip, I will address something that creates confusion for beginner developers.

I am talking about the _create functions. These are functions you use to create something (surface, buffer, data structure, etc.) and store the result in a variable.

Code:
surface = surface_create(args);

list = ds_list_create();

buff = buffer_create(args);
Let’s take a DS list as an example. The function creates the list and stores it in the variable, right?

So this way, if I create the list in a local variable, it will be gone at the end of the event, because the variable is local. Right?

Code:
var list = ds_list_create();
Actually, that is not how it works. Whenever you create a list, it creates it inside the memory. That is where the list exists. The function just returns a pointer that points to the list inside the memory. So the variable you use as the “list” is just a pointer which allows you to access the actual list in the memory.

So, even if the variable is local, the list is not. Remember, the variable is just a pointer. So to destroy the list, you have to use:

Code:
ds_list_destroy(list)
This function will remove the list from the memory.

Also, when you do this:

Code:
list_1 = ds_list_create();

list_2 = list_1;
You’re not creating another list called “list_2” which is the same as “list_1”. You’re just copying the pointer value to that variable, so both of these variables point to the same list on the memory.

So this is the same with the other things, like surfaces, particle systems, and buffers. The variable is only a pointer to something that exists inside the memory until it is destroyed.
--------------------------------------------------------------------------------------------------------------

Post your tips here. I may post some of them on my website if they are for beginners, but well, let's keep those things to this thread for a start.

Thanks!
 
Last edited:

zbox

Member
GMC Elder
Grouping them by *_create() functions is certainly a... unique way to do it.
Sort of implies that the concept you are learning is "creation", rather than: "surfaces, lists, buffers".
Creation is very easy to get your head around; however the concept of surfaces, lists and buffers which are all entirely different, and is very sophisticated for new users - hence its a bit strange to emphasize the creation aspect .
 

matharoo

Udemy Instructor
Grouping them by *_create() functions is certainly a... unique way to do it.
Sort of implies that the concept you are learning is "creation", rather than: "surfaces, lists, buffers".
Creation is very easy to get your head around; however the concept of surfaces, lists and buffers which are all entirely different, and is very sophisticated for new users - hence its a bit strange to emphasize the creation aspect .
Well yes, that tip is not about surfaces, lists or buffers, just how creating them creates them inside the memory, not inside the variable. Some beginning devs use data structures and knowing this might help them. But if you do have something to suggest that can make that tip better, sure do.
 

GMWolf

aka fel666
I have a whole library of tips!

  1. Use arrays to group data together as structures
    The idea here is simple: arrays can hold a group of values under a single name. why not use them as struts?

  2. Store your states as different objects:
    It greatly improves code reuse, and allows you states to operate across a range of events:

  3. Colour code your objects in the room editor.
    Do you have trigger - response objects in your levels? Perhaps a set of doors and keys? or buttons and explosives?
    Then you can easily pair them up in the room editor by colour coding them, making level building much easier:

  4. Use collision_line to improve collision detection of fast moving objects:
    Do your bullets keep going through walls because they move too fast? Collision_line is here to help:

  5. Improve your codes flexibility with dependency injection
    You will often want systems to do similar things, but with one key difference in logic.
    Rather than copy your code again and again, use dependency injection to only change that one part!

I consider a lot of these essential (such as the array structs). They make an immediate difference to your code quality.
 
- Always backup your projects manually once or so a week. Just copy and paste the project folder its just that simple. A lot of the time GMS 1 will fail to make a backup and you'll be left with empty backup folders.
 
Last edited:

zbox

Member
GMC Elder
- Always backup your projects manually once or so a week. Just copy and paste the project folder its just that simple. A lot of the time GMS 1 will fail to make a backup and you'll be left with empty backup folders.
Change this one - there is simply no excuse not to use source control. The GUI for github makes the process highly comprehensible and most people can either afford to pay for private repos or get them for free as part of an education program. Should be used even for recreational stuff. Makes the words "Backup" and "lost progress" foreign.
 

matharoo

Udemy Instructor
Change this one - there is simply no excuse not to use source control. The GUI for github makes the process highly comprehensible and most people can either afford to pay for private repos or get them for free as part of an education program. Should be used even for recreational stuff. Makes the words "Backup" and "lost progress" foreign.
I just have my GMS1 and 2 project folders symlinked to my dropbox folder, so everything keeps getting backed up automatically.
 
Change this one - there is simply no excuse not to use source control. The GUI for github makes the process highly comprehensible and most people can either afford to pay for private repos or get them for free as part of an education program. Should be used even for recreational stuff. Makes the words "Backup" and "lost progress" foreign.
Thanks for the tip!
 

zbox

Member
GMC Elder
I just have my GMS1 and 2 project folders symlinked to my dropbox folder, so everything keeps getting backed up automatically.
That's a "better than nothing" way to do it, but I still really would not recommend. Say you make some changes you don't like and want to revert, collaborate simultaneously, branch and work on different features at different times, so many reasons. Not to mention that is what I used to do with Google drive and had a whole host of corruptions, might be different now but you're still missing all the aforementioned and essential functions!

Edit: Seriously though if I can convince at least one person to use source control it's worth it, take my word: https://github-windows.s3.amazonaws.com/GitHubSetup.exe
 
Last edited:
Top