• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - Code [Suggestion] Movable Instance Object layer/group

S

Scrydan

Guest
I have been looking into this lately and been wrapping my head around the limitation of layer moving. For the past week I have been re-implementing some things in my old project while I looked into this. The layer system is quite cool and can easily in my opinion be used to manipulate whole groups of instances as well.

To explain what effect I'd like, no other example comes closer than Super Mario World. Anyone who has ever played with Lunar Magic knows there exists "layer 2" which is the layer that can be manipulated to come crashing down or gradually moving up and down. This can be lava, walls, or anything else solid that isn't a movable sprite (which in comparison to here is an instance object set to have behaviors that usually move them around on their own).

That in mind, I have been wanting the same effect. For example, in one level I have lava that rises while you race to escape to the top. In another I have lava that tries to rise unless you hit a switch and forces the layer's Y to go back down to its base position before it rises once more.


Now of course this effect can be done naturally like its always been. However, I do believe that instances in a layer should be able to be manipulated in such a way that it makes it easier to control groups of instance objects with one line of code. Because this is such a powerful new system, there is tons of potential. Even some organizational purposes.

Code:
layer_vspeed("instances_movable", -1);
This inside a step event would in turn move the layer slowly to attempt to reach the player with instances of lava or whatever from the bottom of the screen with an easy bit of code. For example, if I later decided to add some platforms, those too would be moved within that layer.

This versus adding special flags and cases for those object instances to move like this would be way easier in my opinion. Functions a user makes could also do this, but the idea is to make the process simple.


Now comes possible limitations which I am unsure of. I am not sure the original intent to only move sprites and backgrounds with layers, but I'd assume that instances that also move could cause problems in certain calculations. If this is the case, and that we need to prevent instances from moving from this layer then could there be some flag that states this instance is unmovable? And that the only way it moves is through external means like layer moving?

One other thing I can think of is that instead of moving by layer, there is some way to 'group' instances. This group could have code that effects each instance's X and Y or with proper checks set certain variables. There might be something I am missing too. However, I think a group or layer moving ability would be quite nice.

Group instance functions could look something like (by no means is complete list or exact parameters):
Code:
instance_group_vspeed(groupid, -1);
instance_group_y(groupid, instance_group_gety(groupid)+20);
instance_group_setdisabled(groupid, true);
instance_group_destroy(groupid, layer); //destroys specified layer or destroys all with 'all'.
Also if you edit the room instance group and move it around, it'd be like if you moved it with each instance selected so you move the whole group of instances. Might be handy for some who don't want to constantly select instances over and over to move them.


----Feedback----

I do want to say in advance thank all you wonderful people for making Game Maker Studio 2. It is quite a powerful system compared to the past ones, and it really does feel much more modern and feature rich. Layers for instances, backgrounds, and sprites is quite awesome! No more do I have to create an object for a simple decoration that never moves or acts. Sprite editor is quite feature rich as well. In compares and in some ways better than my editor of choice, Paint.net. Only thing I can think of adding is a way to export sprites. Sure you can do so manually by going into project files, but just an ease of convenience for archival purposes.

Layers can allow for much easier organization and I think can be used in ways still not yet thought of. For example, mass removal of objects based on difficulty based on difficulty layer/group. Allowing the game to be more dynamic rather than assigning a function to give each instance for its self destruct if their range is past the difficulty.
Code:
funct_difficulty(1,3); // would delete the instance if less than 1 or greater than 3
I mostly come from Game Maker 8.1, with some Studio experience. So you can definitely see the night and day differences between the two engines and its editors. Originally making my project back in 2011 for college. Simpler times.

Best of luck with GMS2 development! Thanks for reading this. Hoping for a smooth release!
 

origamihero

Member
Hi! There are a bunch of ways to move instances on the same layer. This would work:
Code:
with all {
if (layer==layer_get_id("MovingLayer")) {x++;}
}
Another possibility is grouping by parenting. Assign the same parent to the objects that you want to group together, and let's call this parent "group1":
Code:
with group1 {
x++;
}
This would move all objects with the parent 'group1' assigned.

I think the parenting stuff comes very close to the kind of grouping you'd like to utilize.
 
S

Scrydan

Guest
That first one is close to the original idea.

I actually overlooked that thought process of a simple manual check of layer checking and making any instance inside that layer move at the same time.

So easily this can be done by taking that code and throwing it into a function for easy future use like funct_moveinstancelayer or what have you.
I'm actually likely to go with this approach unless/until a more native function approach appears.

This new layer system has lots of potential so I haven't thought of that first solution. Thanks for that one, @origamihero .
 

Mike

nobody important
GMC Elder
Use tiles. They can be offset/moved using the layer. Anything large was done using tiles on the SNES, you'd only use sprites if it was a smaller shape. You can have many tile layers and can move them around easily. You can even draw them yourself if you want.

Failing that... if your determined to use instances then either use a parent and a with(), or stick them all in a list and loop over them.
 
S

Scrydan

Guest
I haven't looked into tiles all that much (was one of the ongoing things I am figuring out) but if I can figure out how to use code to determine collision with the player and act on it (spikes and lava for example using the funct_playerattacked function I made), then I can likely work with that, to an extent. There may be times I will need to put special instances of objects in that layer.

Thanks for the help nonetheless. If possible, I'd like this game to make the most of GMS2's features and use most if not all of them. Creating rooms sure is easier than 8.1. Once you get used to the workspace, it is quite nice compared to moving subwindows all the time.
 
Top