GML anyone else here using gmk objects as structs/objects?

L

lord_berto

Guest
Its pretty emphasized in game maker studio that, objects are literally like game objects ( game characters,
items, enemies )

but does anyone use game maker objects as a way to create structures/skeletons as "objects in the code"
?
Im currently trying to create a semi complex gui for this rpg. ( gui is something that has always been
so difficult for me because i like to create things that work, and that are expansive/future proof )

I've found myself using objects in game maker as structures/templates and find it a lot cleaner.
anyone else here doing the same? any tips or ideas they'd like to share? perhaps better ways of doing
things in game maker?
 

CloseRange

Member
gui is something that has always been
so difficult for me because i like to create things that work, and that are expansive/future proof
you say that like gui's can't be expansive.

A lot of people do that, using objects as structures/templates. If you wanted to, you could make an entire game out of just one object, so having more is just based on preference and how you use game objects is entirely up to you.
My tip for a gui is to make scripts. I usually have 3 times as many scripts as objects. Let's say you're making a button for your gui:
don't make a button object for each button that's just not smart. Make one script for a button and one object for a button. Have the script control the buttons position, size, and text. The script can return true or false if it's pressed, then where you call that button script is also where you determine what happens when it's pressed
 

samspade

Member
Its pretty emphasized in game maker studio that, objects are literally like game objects ( game characters,
items, enemies )

but does anyone use game maker objects as a way to create structures/skeletons as "objects in the code"
?
Im currently trying to create a semi complex gui for this rpg. ( gui is something that has always been
so difficult for me because i like to create things that work, and that are expansive/future proof )

I've found myself using objects in game maker as structures/templates and find it a lot cleaner.
anyone else here doing the same? any tips or ideas they'd like to share? perhaps better ways of doing
things in game maker?
The primary issue with using gm objects as structs is they come with a 'significant' amount of overhead. Significant is in quotes because it's actually pretty minimal per instance. But if you're using structs the way you would in another language, where you might have dozens of them per object or even hundreds plus all operating at once, then it becomes a problem. In short, if you're creating a dozen or so objects just to store data, you shouldn't have any problems. If you're going to needs hundreds or more, you probably want to use arrays or data structures. With the use of enums and macros and a few holder or controller objects to 'house' the arrays/data structures, you can have a really flexible and easy to use system.

Anyway, that's my understanding. I wouldn't even consider myself an intermediate in any other language, so I might be wrong.
 

CloseRange

Member
The primary issue with using gm objects as structs is they come with a 'significant' amount of overhead. Significant is in quotes because it's actually pretty minimal per instance. But if you're using structs the way you would in another language, where you might have dozens of them per object or even hundreds plus all operating at once, then it becomes a problem. In short, if you're creating a dozen or so objects just to store data, you shouldn't have any problems. If you're going to needs hundreds or more, you probably want to use arrays or data structures. With the use of enums and macros and a few holder or controller objects to 'house' the arrays/data structures, you can have a really flexible and easy to use system.

Anyway, that's my understanding. I wouldn't even consider myself an intermediate in any other language, so I might be wrong.
You're pretty much right on the point there, though with other languages you know what's going on with all your structures so it's easier to avoid that. GM it's hard because you don't fully know what's going on behind the scenes with the objects.

For some reason I misunderstood the question and wasn't thinking of data-structures (i'm a bit tired) but yes as samspade said it's better to usually use arrays, lists, maps, and enums for data-structres. I understand the appeal to make a data-structure using objects especially if you come from an object oriented program but gm-objects always store more information that you put in yourself meaning it takes of more data so having hundreds of instances active at once is bad.
 
L

lord_berto

Guest
you say that like gui's can't be expansive.

A lot of people do that, using objects as structures/templates. If you wanted to, you could make an entire game out of just one object, so having more is just based on preference and how you use game objects is entirely up to you.
My tip for a gui is to make scripts. I usually have 3 times as many scripts as objects. Let's say you're making a button for your gui:
don't make a button object for each button that's just not smart. Make one script for a button and one object for a button. Have the script control the buttons position, size, and text. The script can return true or false if it's pressed, then where you call that button script is also where you determine what happens when it's pressed
thanks for your reply. sorry I was abit confusing/unclear with what I wrote there. I men't to say that , if i wanted to I could code an inventory and game menu super quick and fast with a youtube tutorial.
but will it be expansive future proof? and yes i agree with you, right now im using a buttonObj as a template for multiple buttons in my game.

buttonX,buttonY,text, width,height, etc are some of the variables my buttonObj has.
 

CloseRange

Member
Then yes, that is find and done a lot. Tutorials usually make them the way they do because they are targeted at newer users. If you're new to programming it's easy to understand the straight forward approach without making dynamic objects.
it's 100% better practice to do what you're doing because if you want to change something about the buttons you only have to do it to one object, not every single one.
 
I

icuurd12b42

Guest
I used to until they fixed the array system

inventory = [
["gun",12, 30],
["shotgun",8, 12],
["gold", 200]
];

The cost using instances should not be too much if you dont abuse it... but I hear that you can deactivate instances and still access them if you have the instance id...
 
L

lord_berto

Guest
I used to until they fixed the array system

inventory = [
["gun",12, 30],
["shotgun",8, 12],
["gold", 200]
];
it was broken? i remember doing stuff like this very early in game maker

oops i didnt reply correctly
 
I

icuurd12b42

Guest
oops i didnt reply correctly
>it was broken?

No you could not do this. they added the ability in gms2. I guess fixed it is the wrong term

in gms14 you can have an array creator function to emulate this.

array

inventory = array(
array("gun",12, 30),
array("shotgun",8, 12),
array("gold",200)
);

in earlier version of gml, I dont think array items could hold arrays
 
I

icuurd12b42

Guest
the array function I pointed to enables that. wipe your tears
 

FrostyCat

Redemption Seeker
Objects in GM are great at presenting data, but awful at being data. This is a major difference between objects in the GM sense and objects in the traditional OOP sense.

Buttons on a GUI count as presenting data, so I don't see a problem with using objects for that. But I'm sure you'll soon encounter situations where separating model from presentation would be a sensible move, and I recommend that you learn to use arrays and data structures for those.
 
D

dannyjenn

Guest
I've used instances to implement some of the non-built-in data structures (e.g. trees, one-directional and two-directional linked lists, etc. ... which make text parsing and stuff a lot easier). I've never tried this in an actual game or serious project though. (Only in quick throwaway projects where speed and memory use weren't too important)
 

hippyman

Member
EDIT: Shoot! Just typed up all of this and realized you use 1.4... Dude come on!
Anyways, just ignore the deactivate layer suggestion and use the normal instance_create function instead and you can still use this solution.


Adding onto what icuurd said, you can in fact deactivate an instance and still read/write variables from it.

A solution could be to create a generic Struct object with only instance_deactivate_object(id) in the create event.

Then you can create an instance and add your variables. Then you have a sort of struct prototype.

Code:
//Create a prototype
global.Vec3 = instance_create_layer(0,0,"Instances",Struct);
global.Vec3.x = 0;
global.Vec3.y = 0;
global.Vec3.z = 0;
Then you could make as many Vec3 structs as you want with instance_copy and a little script.

Code:
/// CopyStruct(id)
var _id = argument0;
with (_id) return instance_copy(true);
Code:
someOtherVec3 = CopyStruct(global.Vec3);
someOtherVec3.x = 45;
show_message(someOtherVec3.z);
// blah blah blah

Now after saying all of this. I'm pretty sure the main disadvantage of this would be the amount of wasted memory. The structs won't only be the size of the variables you give it. It is still the same size as an empty object instance plus the size of any new variables you add. You just have the slight performance bonus of it not running any events and getting to use dot notation which is a nice convenience. So it's basically nothing but a data block. There are pros and cons to any of the solutions you'll find. Whether you choose to use this, arrays or data structures. You just have to find what works best for your situation.

Something else you could do that may work but haven't tested is rather than using instance_deactivate_object you could use instance_deactivate_layer and then only create Struct object instances in a special "Structs" room layer. Not sure if this will work since after making the instance_deactivate_layer call, any future instances may still be activated when added to the layer. But if they're automatically deactivated when added to the layer then you could avoid the create event all together and just make an empty generic object named Struct.
 
Top