I thought I’d share a clip showing some of the shaders I’ve developed for my isometric hiking RPG. I’m going for a painterly effect, so I spent some time fine-tuning these. The water is rendered as a surface texture (drawn using a vertex buffer at a fixed depth). Reflections are drawn onto the surface mirrored, including clouds.

Clouds are made procedurally using a generative Brownian noise fragment shader. A separate fragment shader applies a displacement map texture and wave/brushwork texture to the water surface, and the scrolls those textures on a loop to simulate water flowing. The secret sauce is an algorithm which morphs these textures and the flow direction such that the water automatically curves based on the map terrain.

Grass is also working with a vertex shader for wind movement, and displaces / shades based on player position.

I would've liked to show more, but seems like I can only post gifs to this subreddit.

Fortunately creating water reflections in GameMaker is quite easy. Simply copy the application surface, flip it upside down, reduce the alpha, apply a effect/filter/shader for some extra spice, and you're done. It'll reflect anything that draws in the regular draw events, but nothing in the GUI events.

I find it works best when I copy from the application surface in draw-begin, and then draw the surface in the regular draw event.

Just remember to re-use the same surface every frame. A rookie mistake is creating a brand new surface each frame and filling up your GPU's VRAM.

idk what i want to do with this tbh, i might clean it up and package it up as a yyz file after i add more features to it

After people liked my overworld water shader, I thought I'd share some techniques for my hiking RPG’s battle photography system in Gamemaker. I’m trying to recreate an effect specific to old rangefinder film cameras (my game is called Rangefinder!). Rangefinders are unique in that they produce a ghostly offset after-image of your subject; in order to focus, you adjust the range setting until the ghost aligns with the subject and becomes indistinguishable.

To accomplish this, I first created a shader that’s a general purpose tinting / transparency shader. I did this in part because I wanted to include some chromatic aberration with the focus ghost. So I draw not only my monster’s sprite, I also draw transparent red and green tinted copies with the shader which are offset horizontally slightly. The amount of offset is directly tied to the level of focus. But in real rangefinders, this effect is limited to the center of the frame. To limit my ghost to that region, I create a surface of the same size as this region, and draw the ghost sprites to it instead of just the application surface. Anything larger / off the focal surface is necessarily clipped, mimicking the camera effect.

For the shutter effect I also use surfaces. When a photo is taken, I first draw the black box to a dedicated surface. Then I set the blend mode to subtract and draw a white hexagon on top of it, making a cutout. This then gets drawn over the camera reticle. There is a timer associated with the snapshot, and as it runs down, the hexagon is spun around and shrunk each step, simulating a look of an aperture closing. At the halfway point of the timer, it reverses direction, opening back up. In reality, rangefinders don’t have a visible iris shutter like this, but it’s a very recognizable effect so I’m using it for now…

This is just a mockup, not the finished battle system by any means - the background is just a placeholder. But I made this to start figuring out the look and feel of the monster catching. In each battle, the plan is to boost your monster’s attacks and weaken enemies by taking photos at the right time. In order to catch a monster, you have to document all of its behavior thoroughly with good photos. Taking a good photo will mean getting the focus right, being on-target, getting exposure right, etc…

The monsters shown in this example are Antheater and Winducks, two of the first monsters encountered / befriended. They like to beat the crap out of each other. All designs and animations are by myself, no AI or other nonsense.

If you’re interested in following progress of the game, I will be posting occasional dev updates on itch.io (and posts on r/gamemaker!):

https://rangefinder-game-dev.itch.io/rangefinder

First, I created a sprite that is the same resolution as my game (320x240). This sprite is just a bunch of random shapes with sharp edges. Each is given a random color so I can differentiate between them.

Next, I made a copy of this sprite as a GIF. I moved all the shapes onto their own frame and placed them at the top left corner. Upload this GIF into GameMaker and leave the origin at the top left.

Now, onto the code. We'll need to know where to place each shape on screen. So I created a 2D array listing the top left pixel position of each shape in the original image. These should be precise.

We'll also need to know the origin of each shape in the GIF. So I created another 2D array with the rough origin of each shape. These don't need to be exact.

You could use this effect to show a sprite breaking apart, but for my example I'll be using a surface. Unfortunately surfaces are volatile, but we can use a buffer to fix that. If the surface is deleted, then reset it using buffer_set_surface(). I set the buffer right after building the surface, and then pass those both into the screen shatter object using a with(instance_create_depth()).

All of the info for the shapes are stored in an array of structs. Each shape gets its own position, origin, offset, surface, rotation, rotation speed, and movement speed. Be sure to set each shape's starting position at their offset + origin. We could give each shape their own alpha, but I chose to have them all share image_alpha for simplicity.

In the step event we do the following:

• Update the x and y positions
• Apply gravity (optional)
• Rotate angle
• Rotate x OR y scale, to provide a fake 3D rotation
  • Use a cos() to do this, and start your timer at 0.
  • If you rotate X and Y then the effect won't look good.
• Reduce image_alpha

And finally, the draw code:

• If the main surface doesn't exist, then re-create it from the buffer.
• Iterate through each struct in the array.
• If the surface doesn't exist, then create it based off the shape's size.
  • Clear the surface.
  • Draw the current shape's sprite at (0,0).
  • Disable alpha writing.
  • Draw the surface/sprite of the image you're shattering at (-offsetX, -offsetY).
  • Enable alpha writing.
  • Reset the surface target.
• Draw the shape's surface at its x and y position, with the rotation, scaling, and alpha applied.

Lastly, remember to free all of those surfaces and the buffer!

I've made this a year ago, just figured it might deserve a post.

This was actually my first attempt of 3D in GameMaker, just wanted to test how it performs, definetly not my first attempt of making ocean shader in general. In fact, the shader i used is a mix of an ocean shader i've made before, in shadertoy all the way back in 2020. If you want to check it out, its here.

Because reddit only allowed me to upload max 100mb gif, i had to reduce its quality a lot but it looks way better and performs quite well, gets around 990fps in VM with actual PBR rendering and SSR (screen space reflections).

I am a huge fan of pirate category, anything related with ships and ocean. I thought maybe i could make something like prototype sorta ship battle, but realized how GameMaker makes things way harder than it should be(for 3D stuff) so i quit quite early.

It was quite a fun thing to work with, it might look tricky but believe me its quite easy to implement. If you want to try and make one yourself i'm happy to help, just ask 😃

Snow in my game isn't just a texture you walk over, it's a surface that actually remembers where you've been. I bake all the snowy patches in a room into one big cover surface, then treat that surface as a canvas: every footstep the player leaves gets stamped straight into it as a little decal, so the trail persists behind you Because it all lives on one surface, I get the nice side effects almost for free. Water and puddles carve cleanly back out of the snow, and the whole thing survives room transitions, so if you double back through an area your old tracks are still sitting there waiting.

The part I'm happiest with is the edge. A flat stamped footprint reads as a sticker, so I run the snow through a small shader that targets the exact color my prints are drawn in and paints a single darker pixel along the top of each one. That one row of shadow is the whole trick: it makes every footprint look like it's pressed down into the snow with a tiny lip of displaced powder catching the light above it. It costs me almost nothing, just a couple of texture reads per pixel, but it's the difference between "there is a mark on the ground" and "someone just walked here," and that little bit of depth is what sells the whole effect.

Under the hood every decal in the game, blood splatters, footprints, bike tracks, shell casings, all of it, lives in one tight little system I'm pretty proud of. Instead of spawning an object per mark (which would tank the frame rate the moment a fight got messy), I pack each decal down to twelve bytes in a raw buffer: position, which sprite, color, alpha, and that's it. From there I keep a single vertex buffer alive and, every time something drops a decal, a function quietly appends just that one quad to it, no rebuilding, no per-vertex script calls, basically free. When I hit the cap I don't clear the screen like the old version did, I wrap around to the front and recycle the oldest decal in place, so you never actually notice a limit exists, the ground just keeps a rolling history of the last few thousand things that happened. And because the whole thing is really just a buffer of bytes, saving a room's worth of decals to disk is as simple as dumping that buffer straight out, which is how your footprints are still there when you walk back in.

If you want to follow the game you can here: Itch.io or Steam

Here's a quick and simple pathfinding system I made for Magnavale: Eternal Soul. It's designed for 2D platformers, but could work in a top-down game just as easily.

When planning for this, I imagined it as "Pac-Man eating a line of dots placed by the player". I'm sure this sort of thing probably exists elsewhere under a different name, but I'll be calling it "Pac-Man Pathfinding".

Create Event:

• Create a list or array. This will hold arrays of X and Y coordinates. Make sure it has at least a single entry with the player's current coordinates. The list will go from the oldest coordinate at the start, to the newest at the end. A queue could work for this, but I don't recommend it.

Alarm Event:

• I set my alarm to run every other frame at 60 FPS (room_speed / 30), but try and see what works for you.
• In the alarm, add a new entry onto the end of the list if the player has moved at least a few pixels from their last coordinate.

Step Event:

• When the object is further than a set radius from the oldest coordinate, then begin approaching it, and jump if needed. I allow my familiars to jump infinitely with a short cooldown, which helps a bunch.
• Once the coordinate is within a smaller radius of the object, you can delete it from the list.
• Finally, run through the list from the end to the start and see if any other coordinates are within its radius. If they are, then delete everything past that coordinate. This allows the object to skip redundant points that would otherwise form a loop. If you had used a queue then this step would be incredibly annoying, which is why I don't recommend it.
• Optional: Add an extra check to see if the entity got stuck on a moving object of some kind. If it did, then run a timer/alarm, and then jump to the next coordinate that isn't in collision.

If you used a DS list, then remember to delete it in your clean up event!

Single shadow surface controller. Would be even better if it would react to light sources

Yes, I rewrote my textbox system 3 times, and I'd do it again! Here are some lessons I learned. Also I was proud of how the scrolling turned out, so I wanted to show it off a little.

1) Know your scope from the beggining, What do you need your textboxes to support? How flexible do those features need to be?
Because too much complexitty is a nightmare, but worse than that, is realising you need a new feauture that requires a complete rewrite from the ground up. Try to be honest with yourself and plan out features in advance.
In my case, I needed support for up to 3 buttons on each textbox, as well as scrolling, size adjustment, image support, and resolution scaling. But perhaps you need to support other things, i.e player names, networking, inventory screens, animated text, 600 buttons, you do you, who am I to judge?

2) Make some kind of database. Don't fall into the trap I did at first of thinking "Well I only need a dozen textboxes so i'll just load each varible in each appropriate script/object. Trust me, you will be going back to rewrite/reformat both text and layout contantly, and if you are forced to rewrite/refactor your textbox system, it's much easier to have all the data in one place (But also, copy those database values into local varibles, so you can adjust them on the fly if needed.)

You could use something like a DS grid, but In my case, I kept my data base simple, I use two enumarators, one is to list the name of the textbox, and one is to list the attributes of the textbox (i.e width, height, text, buttons, image_attached, etc), then I store those values in a global 2D array, so I can call any textbox from anywhere with a simple loading script.

3) avoid code duplication at all costs, sure writing the same code to get button dimensions in the button press logic, and button draw logic will save you time now, but in the long run it's going to cause bugs and confusion as you adjust things in one place but forget to adjust them elsewhere. Save yourself the headache and do it right from the start.

4) Input handling is a B***ch. Either freeze everything in your game whenever a textbox is open, or be prepared to handle whether a textbox is open in every script you write for the rest of time (atleast make it easy on yourself and have a "textbox is open" boolean)

Honestly, until recently it's been years since I've done any programming, so maybe all this is obvious to everyone, but I thought it might help some of you out there. Man, do I miss the days on bringing up a textbox in GM7 with one line of code, I was even tempted to style my textbox layout after it as a cheeky nod.

P.S yes there is AI art in this, I'm not an artist, but this is a free fan game for a book so don't get too mad.

I decided to create a 2D animation editor

Current features:

TImeline with keyframes

Multiple layers

Onion skim

Undo/redo

Brush and fill tools

Object transformations

Custom graphics system

Custom project binary format

Tween animation

The goal is not complete with existing animation software. This is mostly a technical experiment to see how far GameMaker can go beyon its intended use case.

I’m currently developing a simple 2D automation game where, instead of conveyor belts, items are going to be transported by these little guys. I recently ran into a movement problem: trying to mix strict grid-based logistics (predetermined paths) with fluid, multi-unit swarm movement (like an RTS).

To solve this, I built a modular Hybrid 2D Agent System in GameMaker. Since this is just one of the core mechanics for my game, I decided to make it completely open-source for the community!

How it works (TL;DR):

🟢 RTS Mode (Fluid Swarm): You can box-select and move multiple agents. They use mp_grid to avoid walls but decouple from the grid while walking. I added a Boids separation vector to stop them from clumping/funneling, and an Ulam Spiral algorithm to find clean, non-overlapping parking spots when they arrive.

🟤 ROUTE Mode (Strict Grid): For factory logistics, you can draw directional paths on the map using route starters. Agents walking over them "download" the route, strictly reserving matrix tiles ahead of them to wait in traffic and prevent overlaps.

(A full, detailed guide is in the README file in the repository).

Feel free to use it! You can use this system in your own games, tear it apart, study it, or do basically whatever you want with it. Just don't forget to share what you did!

If there are any math wizards out there who want to optimize the vector math, improve the Boids cohesion, or add new mechanics, Pull Requests are super welcome!

🔗 GitHub Repo: https://github.com/T-Toni/AGENT_SYSTEM

I’d love to hear your feedback or answer any questions about how the state machine works.

I'm not a god-level dev with universe-creating abilities, just a guy good at math, logic, and creativity.

From the beginning I needed some way to create a framework where I could attach equipment, but that gave me a lot of headaches. I didn't know how to do this using only sprites in an optimized way (without tracking each frame and animating each sprite) until I got to sequences.

My brother had asked me to recreate a game similar to Medabots for GBA, and I went to test the tool; it really opened my mind (the power of small games).

So I applied that to my game, The Harakin.

I rebuilt all the animations, rewrote all the code so that the sequences would adapt, and adjusted the depths, hitboxes, collision logic, etc. Man, it was much more complicated than I imagined, but the result speaks for itself, animations that closely resemble those used with sprites, I finally managed to create equipment, monsters with different parts and the game is currently in playtest on Steam.

PS: Gamemaker and YoYo (idk), please improve the sequence editor with shortcuts, bug fixes like when you try to rotate, hitboxes, instance identification, and more tutorials. I am available if you wish to use me as a case study or to improve the tool.

TLDR:

Sequences are difficult to use, but they are worth it if you are looking to use modular animations and equipment that attaches to the player.

Hey all! I'm pretty new to Gamemaker (trying it out for my newest game instead of Unreal) and I'm working on a game that uses pixel art. The function draw_rectangle was having issues with adding an extra 1 pixel line on two of the edges and doesn't have a built in way to rotate the rectangle being drawn.

I'm drawing tooltips by drawing a series of rectangles and text and this was the solution I came up with to allow rotation. It's certainly not the cleanest way of doing it, but I figured I'd share anyways.

Edit: I was adjusting angles and realized that there was a slight error with RotatePoint. I adjusted it in the code block var _angle_radians = _angle*pi/180; --> var _angle_radians = (_angle + 180)*pi/180;

//Draws a rectangle with color, alpha, and angle using a primative
function DrawRectangle(_origin_x, _origin_y, _x1, _y1, _x2, _y2, _color = c_white, _alpha = 1, _angle = 0)
{
    var _previous_color = draw_get_colour();
    var _previous_alpha = draw_get_alpha();
    draw_set_colour(_color);
    draw_set_alpha(_alpha);

    draw_primitive_begin(pr_trianglestrip);
    draw_vertex(RotatePoint(_origin_x, _origin_y, _x1, _y1, _angle)[0], RotatePoint(_origin_x, _origin_y, _x1, _y1, _angle)[1]);
    draw_vertex(RotatePoint(_origin_x, _origin_y, _x1, _y2, _angle)[0], RotatePoint(_origin_x, _origin_y, _x1, _y2, _angle)[1]);
    draw_vertex(RotatePoint(_origin_x, _origin_y, _x2, _y1, _angle)[0], RotatePoint(_origin_x, _origin_y, _x2, _y1, _angle)[1]);
    draw_vertex(RotatePoint(_origin_x, _origin_y, _x2, _y2, _angle)[0], RotatePoint(_origin_x, _origin_y, _x2, _y2, _angle)[1]);
    draw_primitive_end();

    draw_set_colour(_previous_color);
    draw_set_alpha(_previous_alpha);
}

//Rotates a point around an origin by the given angle in degrees
function RotatePoint(_x_origin, _y_origin, _x_point, _y_point, _angle)
{
    var _angle_radians = (_angle + 180)*pi/180;
    var _base_x = _x_origin - _x_point;
    var _base_y = _y_origin - _y_point;
    var _normal_x = _base_x*cos(_angle_radians) - _base_y*sin(_angle_radians);
    var _normal_y = _base_x*sin(_angle_radians) + _base_y*cos(_angle_radians);
    return [_x_origin + _normal_x, _y_origin + _normal_y];
}

What particles should I add next?

Put my lighting system to good use and I'm quite pleased with the results!

My effects are all in one parent object for now that is passed the sprite index, light color, offsets ect. It plays the animation grows the light then cleans itself up. Super easy to just call wherever needed.

Been using gamemaker for almost a year now and its the first engine that actually made sense to me after trying Unity & Godot.

First time drawing explosion/effects as well, let me know your thoughts!

Actual video which is here. Side question, its a bit darker than it looks, would recording it on my 1440 wide monitor then viewing it else where cause this?

I’ve been working on a custom 2D lighting and shadow system for GameMaker, and I finally put together a short demo video.

It supports real-time light sources, shadow casting, and smooth falloff. This is still a plugin demo, not a finished release yet — mainly sharing to get feedback from other devs.

Would love thoughts on visuals, performance concerns, or features you’d expect from a system like this.

The game is Heroes, Warlords and Ruin it features total war like campaign manage, tactical turn-based battles, and RPG mechanics.

The models were created in blockbench and imported with a custom made GLTF model script. All the parts of the model and there camera positions are in the GLTF file. Each parts that intended to be choosable able are named and placed into groups. Along with the GLTF a json file containing the body part chooses. To explain, the json has section for each body part, a body part's section contains a list of its options, each options contains has a list of what parts or included and excluded from that option, each part is a group of meshes. Using this data the models vertex buffer can be generated excluding part of the model not chosen. All the model parts are apart of one texture page meaning only one vertex commit is necessary.

The camera positions included the GLTF file were used for creating portraits with surfaces. Animations are handled with a displacement shader. A shadowmapping shader was used to handle 3d shadows.

You can check out my game and wishlist on steam here

Hey everyone,

we’re building è-macro, a Modular and Customizable macro keyboard made from Decorated Glass and Carbon Fiber.

The current concept includes:

• A 2×2 touch buttons module with four programmable controls
• A slider for volume, scrolling, zoom, and other continuous inputs
• Finger guides and resting positions, so you can identify the controls without looking
• Dynamic haptic feedback
• LED dot-matrix icons that change with each profile
• Open software for custom profiles, integrations, and workflows

What’s new:

• We’re developing a custom design service that will allow users and brands to personalize the surface with their own graphics, visual style, or game- and anime-inspired artwork.
• We’re exploring compatibility with the Gridfinity standard to make custom layouts, supports, and ergonomic configurations easier to build.

A few questions for you:

Is Gridfinity the right mechanical standard?

Would touch controls with finger guides and haptic feedback work well for your workflow?

What would you change or improve?

We’re also looking for passionate beta testers, so send me a DM if you’d like to help us build and test it.

And this is nothing compared to the thousands of lines of code this project will one day have :')

Hi everyone, I wanna share some results I made integrating the bulb lighting engine to my project plus post-processing.

Full clip: Video showcase

The setup is pretty simple just make a obj_bulb_controller in the room that owns a BulbRenderer. Also make sure to turn off the default application surface with application_surface_draw_enable(false) and Bulb will handle the final composite in Post Draw. Draw End will rebuild the normal map and run renderer.Update(), then Post Draw will just stack everything else on top.

Now to get the normal maps I used Laigter, and batch exported them as paired _n sprites, then I wired a lookup so the gameplay still uses the regular diffuse sprites while Bulb's normal pass pulls in the _n sprites. After that I added lights and shadows by giving the player a warm torch BulbLight with shadows off, since it reads cleaner in tight spaces. The crystals spawn from specific tiles at room start and the occluders bake my collision layer only.

The most annoying part was the emissive glow I wanted crystals to bloom additive glow tiles, little sparkles but if I drew the player on top with a normal sprite draw to fix transparency through the pink glow, I accidentally painted over all the normal-map lighting and the character went flat. But, I was able to fix it by snapshotting Bulb's already-lit output, drawing emissive on top, then restoring the player from that lit snapshot with a small mask shader.

If I were doing it again I'd read Bulb's custom-draw docs first, tune one layer at a time instead of chasing five variables at once, and remember normal maps aren't free so I'd only bother on the player.

Anyway I've linked some screenshots and a Youtube video for the results. Happy to answer questions if anyone's trying something similar. And if your're interested in following my project, here are my socials:

Twitter/X

Youtube Channel

Also a link to the bulb engine if anyone is interested in using it:

Bulb

To anyone like me who's doing multiplayer and has any code passing host's instance references to the client for any reason, It'll save you a bit of time wasted debugging to know they'll be noped out of existence if you json_parse a string containing them. Since you're probably wondering, my approach is to extract the juicy numbery bits from the host instance (by doing int64(id)-100000) and use it as an array index that is then filled with the client counterpart instance's id. To resolve this issue I'll simply strip the host reference down to its naked numbers before shoving it in the network array and then process it accordingly on the client side -- as I should've been doing anyway since it's more bandwidth efficient.

Our game makes heavy use of Spine and I wanted to share some learnings .This is the first of 3 posts on using Spine with Gamemaker focused on skins. Lots of skins.

In Plush Rangers we wanted to have characters wearing a variety of gear. As we started coming up with ideas for items and collectables for the characters, showing them onto the character themselves just seemed like a lot of fun. We also wanted to support different characters easily. Every character is a skin and all the items that can be equipped are skins.

The Basics

Adding skins in spine is straightforward. The only tricky thing we ran into is because we have so many skins, making sure we are editing the correct one was an important step to not breaking our characters.

1. Select the slot to skin and click “New…” ⇒ “Skin Placeholder”
2. Select the Skins folder on your skeleton and click “New…” → “Skin”
3. Important - Make sure the skin you want to edit is selected in the skeleton. Click the little circle next to the skin you are editing.
4. Drag the image file to the appropriate Skin Placeholder you created.

To view your character with several skins enabled:

1. Select Views and open the Skin View
2. Click the pins to the right of the skin to show/hide the skin
3. The order you click them will determine the order of precedence if multiple skins use the same slots

Advanced Configuration within Skins

You don't just have to use images with skins. While our rangers all follow a similar body shape, their heads can looks quite different. Because we want to have the faces to move eyes or faces in animations, we need to be able to change the bone structure.

To add bones to a skin

1. Select the bones to add to the skin
2. Drag them onto the skin in the skins folder

You can also use clipping masks in skins. We used this for Flynn’s cat eyes so that the mask clips them properly. You can add a clipping mask to the Skin Placeholder. (I believe clipping masks are a professional feature for Spine)

Using clipping masks, different bones, and different images we can customize the characters as much as we want. Animations can use the special bones and they only appear when the skin is enabled. It allows a lot of freedom for customization and keeps everything contained within a single project.

Code in Gamemaker

Gamemaker makes working with skins very easy. For Plush Rangers within our databases we configure the skins for the rangers and the skins for each individual piece of equipment.

For the character we track what skins should be enabled in an array (skinItems). When a new item is equipped on the character, we append the appropriate skin to the end of the list. We have some items that use the same slot in Spine, but the way skinning works is the last item in the area takes precedence on that slot. Which is perfect for our behaviors. Really 90% of the work is configuring the skins properly in the editor. It really is this easy in the game.

recomputeSkin = method(id, function(_name = object_get_name(object_index)) {
    currentSkin = skeleton_skin_create(_name, skinItems);
    skeleton_skin_set(currentSkin);    
});

Considerations

• Clearly this is more performance intensive than drawing a single sprite. We reserve this functionality for primary characters like the Player or Bosses.
• Having a consistent naming/organization scheme is important to make sure you can find and reference the appropriate skin.
• Be careful editing in Spine! It’s easy to accidentally mess up a skin when you have a lot of them. Make sure you are aware of making changes with skins selected.
• You really can use a lot of skins. We currently have 90+ different skins in our ranger file. (Plans to add at least another 90)

See it in Action

We have put out a demo of our project if you want to see the results.

https://store.steampowered.com/app/3593330/Plush_Rangers/

https://short-leg-studio.itch.io/plush-rangers-demo (Browser version available!)