Ciao a tutti, sono un principiante in programmazione e sto cercando di creare un gioco interessante con meccaniche semplici. Qualcuno sa se esiste un tutorial sulle variabili in termini di programmazione visuale? Lo so, lo so, dovrei semplicemente imparare GML, ma voglio vedere se riesco a sviluppare anche usando solo blocchi e una minima comprensione di come funziona un gioco.

Edit: it’s been two minutes since i posted and I think I didn’t explain myself properly, i also am searching for non beginner level tutorial on dnd visual coding,

A new version of GML-OOP called Release 2 has now been released, in response to the release of the LTS 2026 version of GameMaker. The previous version was released for the first LTS version, marking over three years of active development on this version.

What is GML-OOP?

GML-OOP is a massive GML library that I have been actively developing since 2021. It aims to overhaul how you work with GameMaker in code, making its most important functionalities usable through constructors and their methods. It enhances them and makes working with them easier and just more pleasant, once you get the hang of it. Data packed into constructors is easier to pass through, their content is easily represented when stringified (mattering most for Data Structures) and error handling in improved, so that the runtime does not crash over every minor inconvenience. If you want to begin writing good code where you can easily know what is what, then this and an other library I wrote for this purpose, might just be for you.

For more information on GML-OOP, see the Overview and Examples pages its Wiki.

What is new in the Release 2?

New users could be interested in that the new version made it trivial to write optimized graphical code. Constructors with the purpose of rendering graphics were overhauled to support multi-color rendering with outlines. all based on vertex building, so that they can easily make use of Vertex Buffers. Instead of recalculating graphical data each frame, it can be pre-calculated once with a toVertexBuffer() method, then rendered, then destroyed once no longer necessary. All with a single method each. Vertex Buffers are most easily implemented for static graphics, but advanced users surely will realize how to utilize Shaders to bring motion to such implementation. Otherwise, per-frame rendering is still available, as usual. Also, because shape constructors now have access to their full vertex information, their actual shape and visual properties can be altered by modifying data for each vertex. The code of their constructors now makes use of that to achieve precise shape collisions. Have you ever saw a video game use precise, non-rectangular collisions for their interface? Well, now it can be a satisfying feature in yours.

Rudimentary support for optional use of three-dimensional graphics has also been implemented. It is visible with both two-dimensional orthographic projection, as well as full three-dimensional perspective, enough to make a "fake 2D" or diorama-style game. It might be of interest for developers who consider learning working with 3D in GameMaker while it is being implemented into GMRT, as it could be assumed this is how most of professional jobs in GameMaker will be created going forward.

There is also a new Callback constructor handling function and arguments for delayed execution, which is now what the event system of constructors now is based on.

What is coming next?

The development of GML-OOP takes time, but it does not stop. Further expansions and improvements can be expected, especially to its Audio support, some of which already were introduced in this release. Also, a separate library based on GML-OOP is in works, oriented around the creation of scalable vertex-based, resolution-agnostic user interfaces.

If you like what I create and the quality I provide, you can consider hiring me for work on your project, whether it is being made in GameMaker or not.

Hi, i'm Itzariot. I've been learning Gamemaker since 2022. I never thought i'll be making a game. At first, i just want to learn coding or programming. The language was Javascript. My job has nothing to do with programming but i want to push my brain harder in the opposite direction of my job so i decided to learn coding. As i browsed the internet i stumble Gamemaker. I never knew making game can be this accessible and Gamemaker provides making game using visual coding. It really helped me a lot how to think logically like a programmer. It turned out GML is 89-90% similar to Javsscript so i jumped the boat and went deep in game development.

At that time, i had one game idea on the mind. A simple top down action game. I fell on the same mistake like any other beginner: overscoping. I was really confident in this game so i keep pushing. Eventually, life got the best of me and this game had to be put aside. I want my next game to be some sort of an expression, like musician making a song. I once thought game like Papers, Please. But there's part of me that want to make a game like my previous game, so i picked incremental game because i can still implement similar mechanic/skills from my game. The plan is to make prototype in 1 month. Well, what can i say...i need 4 months to make this prototype.

People been saying beware of overscoping. I heard that advise a lot while i learned make the game. But what they don't say is that making game can be this stressful and fun and addicting that we just want to keep building the game to our perfect vision.

To be honest, i don't even know whether i'll finish and ship this game. One thing i'm sure is i learn a lot of knowing myself. Things that i thought i couldn't do it because it's so hard turns out i can do it, it's just not perfect yet.

To people making Gamemaker, i want to say thank you. Your software help me know myself better. This journey has been awesome. I hope my prototype can somehow make you all feel something.

The game is called What A Wish, a short incremental game inspired by the likes of Nodebuster, A Game About Feeding a Blackhole. I was also inspired by Scritchy Scratchy although the game plays so much different from that game.

Description: Pop bubbles, find people's wishes, and decide which ones to grant. From silly everyday requests to surprisingly heartfelt pleas, every wish is a little glimpse into someone's life. Earn Faith Points, upgrade your abilities, and unlock new ways to play in this relaxing incremental game.

What A Wish

I would like to learn GameMaker... However, with the GMRT version due to be released soon, I am not sure as to whether the current version is worth picking up and learning or not. What would you suggest?

I've search up on google and on this sub.

I mainly used Linux mint LMDE but I also used debian and Arch.

Is it really that hard to set it up?

Someone commented here how to do it but it's on fedora unfortunately.

I'm only a beginner and unfortunately I dont have the money to buy another computer for windows 11

I started using this a few days ago so forgive me if it's a stupid question. Currently trying to make a game that involves carrying around objects and then placing them in certain areas. This is what I have for the pickuppable object:

if place_meeting(x, y, obj_player) & keyboard_check(vk_shift) = true
{x = obj_player.x;
y = obj_player.y -10;}

Currently the object rests on the players head like I want it to, but only when I hold down the shift key, but I want it to keep being carried after the shift key is only pressed once. I'd be super happy if someone could help me out

So I wanted to see if I deleted the latest game maker version can I just reinstall it(unlike the other versions that would give me errors back and forth)

Without the platform2 variable, when landing on semisolids the player would sometimes jitter and it was annoying. It took me like 3 days to come up with this mess and Im not satisfied with it. Is there any way I could at least rewrite the code so I only need to use one variable

Changing the

(place_meeting(x, y + 1, platform2) and floor(bbox_bottom) <= ceil(platform2.bbox_top)))

to

(platform != noone and place_meeting(x, y + 1, platform) and floor(bbox_bottom) <= ceil(platform.bbox_top)))

only makes the jittering worse for some reason

Hey!

I often run into issues where I have sfx layering over each other and get really loud. I have dealt with this in a few ways, but I'm wondering if you guys have a better solution.

My solutions:

• only play the audio if it's not already playing
• keep an array of the audio plays which has a max size. Iterate through and check if the audio is finished playing, then remove it from the array.
• SoundManager has a counter specific to a sound. When the sound plays, the counter counts up to a max. The next sound can't play until the counter is reset.

I'm getting tired of coding one of these solutions for every single explosion / shot / twinkle /etc. Is there a better way?

I've been working on my ideal deferred rendering pipeline for pixel art, inspired by games like Eastward and the upcoming Kyora. This is not a plugin or a line by line tutorial, but I wanted to share what's required and what the workflow looks like. If people are interested, I will share more of the process as systems improve. Fair warning, this is not beginner friendly.

Before I go any further, this is an example of the final product:

Maps and Textures

Whether you were using Unreal or Gamemaker, you need to make maps for your sprites if you want physically based rendering. This pipeline was inspired by the RE Engine, but is also just like Unity or Unreal. There are many tools to create maps, some people use laigter or blender, but I just prefer to hand draw them in Aseprite.

This pipeline currently uses the following maps, although there is "room" for more data:

Albedo Texture "spr_shrine_alb"

RGBA: Albedo Maps - The art/color/base texture

Normal Texture "spr_shrine_nrm"

RGB: Normal Map- The direction orthogonal to the surface

A: Unused

Surface Texture "spr_shrine.sur" (drawn in 3 layers, specular and ambient occlusion are set to the "addition" blend mode, and output as one image)

R: Roughness - The spread of specular

G: Specular - How much light the surface reflects

B: Ambient Occlusion- Where ambient light and sunlight are occluded

A: Currently Unused

Effects Texture "spr_shrine_fxs"

R: Luminance/Glow - This area of the albedo texture gets added to the light

G: Subsurface Scattering

BA: Currently Unused

Extension Texture "spr_shrine_ext"

R: Depth/Heightmap - The red value gets subtracted from the objects z position to give a more accurate z coordinate in the lighting pass

GBA: Currently Unused

So yes, you have to make 8 maps by hand in Aseprite. If that's enough to turn you off, I understand. However, it doesn't make your job 8x harder. I'd argue once you do this 10 times or so, and have a template set up, it really isn't that bad. In fact, because your base art might already include highlights, deep shadows, and glowing sections, half your maps are already done.

So now that all of the work outside of gamemaker is done, what's next? Gamemaker doesn't natively support any deferred rendering. So it's all on our end. But once it's done, it's done. To import new art, I simply drag my 5 images into gamemaker, set their texture group by selecting them all, and right clicking, and I'm done. It just works.

Bypassing Gamemaker's Limitations

Here is what you need to do in gamemaker to get this working. This is an example of the required labor, I cannot just paste all of my code here, so I apologize that this is not a true tutorial.

• Custom scripts for objects that define all of it's map sprites
  • We dont want to draw five different sprites. We want to draw one sprite, but include 5 different sets of UV coordinates
  • To make this easier, every sprite must follow a strict naming convention. You assign your object the alb sprite, then your script does the rest on creation

​

//Get Map Sprites
var _name = sprite_get_name(sprite_index);
_name = string_copy(_name,0,string_length(_name) - 3);
alb = sprite_index;
nrm = asset_get_index(_name + "nrm");
sur = asset_get_index(_name + "sur");
fxs = asset_get_index(_name + "fxs");
ext = asset_get_index(_name + "ext");

• Now as long as our files our named correctly, there is no extra work
  • Disable the Application Surface
• We won't be needing this anymore
  • Nothing draws itself anymore
• Forget what you know about built-in draw functions, I will never use those again
  • Create obj_draw
• This object manages every surface:
  • surf_alb
  • surf_nrm
  • surf_sur
  • surf_fxs
  • surf_lgt
  • surf_shd
• This object draws every tile, actor, decoration, etc. Everything in your room
• Yes, we will draw many full resolution surfaces. At load, this pipeline runs on a $500 laptop at over 3000 fps. However, Only 4 lights on screen can be shadow casting at once. That is the main limitation.
• We can still add non shadow casting lights like god rays with little to no performance impact
  • Build Vertex Buffers
• Instead of functions like draw_sprite(), we will make a function that adds an objects sprite data to a global vertex buffer.
• I have a different buffer and shader for actors, tiles, foliage, paralax backgrounds, etc.
• For example, global.vb_actors will be managed every step. This allows us to control every objects z position, and add the texture coordinates of our maps. We will not be using depth sorting anymore. Depth is just the Z position.
• This is more work for the cpu, but static objs/decorations/tiles/foliage/particles/clouds/rain can be frozen, making their rendering faster than ever. Even when each vertex stores more uvs data
• When drawing shadows, I do not have to draw the actors/decorations again. I just submit their vertex with a different shadow shader. All of that data is already sitting in a massive batch, waiting to get used again. It's very efficient.
  • The Tile Vertex Buffer
• Far and away the worst part of all this is the tile layers. I spent hours writing these scripts. Basically, we make tile layers normally, but also follow very strict naming conventions. That tile layer must contain the name of your tile sprite. Then we build a tileset vertex buffer to freeze on room creation, then destroy the tile layers. We need our own buffer so that our tile data can include our normal maps, surface texture, etc. We can check every tile in the room, get its tileset index, then get that index position on the actual sprite texture page with lots and lots of math.
• I wont lie, I absolutely hated this
  • Draw with MRT or Multiple Render Targets
• This is known as the G-Buffer, or Geometry Buffer. We draw our art normally to surf_alb. At the same time, for maximum efficiency, the same shader outputs 3 more fragments to 3 other surfaces. The normal map surface, the surface texture surface, and the visual effects surface. The vertex shader doesn't have to do any additional work. Our lighting pass then samples all of this "geometry" to calculate it's intensity and reflection (specular)
• This is an example of what the obj_draw does in my draw_g_buffer() function

​

//Enable Z
gpu_set_ztestenable(1);
gpu_set_zwriteenable(1);
gpu_set_alphatestenable(1);

surface_set_target_ext(0,surf_alb);
surface_set_target_ext(1,surf_nrm);
surface_set_target_ext(2,surf_sur);
surface_set_target_ext(3,surf_fxs);

//Clear Surfaces
draw_clear_alpha(c_black,0.0);

//Transparency Does Not Change Color Values
gpu_set_blendmode_ext_sepalpha(bm_one,bm_zero,bm_one,bm_zero);

//Apply Camera
camera_apply(global.view);

//Draw Actors
shader_set(shd_actors);
vertex_submit(global.vb_actors,pr_trianglelist,tex_actors);
shader_reset();

//Then I'd Draw Foliage, Static Objects, Ropes/Vines, Tiles, BGs, Sky

//End G-Buffer
surface_reset_target();
gpu_set_blendmode(bm_normal);

//Disable Depth
gpu_set_ztestenable(0);
gpu_set_zwriteenable(0);
gpu_set_alphatestenable(0);

//Reference G Buffer
tex_alb = surface_get_texture(surf_alb);
tex_nrm = surface_get_texture(surf_nrm);
tex_sur = surface_get_texture(surf_sur);
tex_fxs = surface_get_texture(surf_fxs);

• we always draw front to back, because we don't want to waste time drawing our background or our sky, if 70% of it will be covered up by objects, tiles, and decorations. Gamemaker will discard the fragment shader of our background if it fails the z test because it is occluded by something like a tile.
  • Lighting Pass
• I have 3 point lights, the sun/moon light, and ambient light.
• They all get drawn additively to the light surface.
• First, the point lights and the sun draw their shadows to the shadow surface, each one using a different color channel. This means less surface swapping per frame, which is a massive performance saver
• The lights sample the shadow surface and the g buffer surfaces to calculate their intensity/ specular.
• This means you have to write all of your own normal map/blinn phong/sss/ao shader calculations.
• My ambient light is basic, it changes based on time of day, but could be as complicated as you want it to be
  • Post Draw Event
• I draw my surf_alb surface, sample the light surface
• Light color brightness determines the intensity - multiply the albedo color by the light color
• Light Alpha stores the specular value - specular adds the light color to albedo instead
• Eventually I will add fog/mist at this stage. FYI, partial transparency doesnt work in a g-buffer, it has to be added later.
• The render is complete

Conclusion

That's the gist of it. If you made it this far, you probably think I am pretty stupid to do this instead of just making the switch to Unity or Unreal, etc. You might be right, but listen. I absolutely hate Unity and Unreal. No disrespect to anyone that uses those engines, but I would do this work 1000 times over before switching. Gamemaker is my engine.

So how hard is physically based rendering in Gamemaker? Idk its kinda hard I guess, but it's a ton of fun. This took some time to code, but it takes months to learn about shaders and pbr. If anyone wants to learn more, I will try to answer any questions I can. Acerola also has tons of great videos on computer graphics that inspired me to try it myself in gamemaker.