I see that "lightweight objects" and other essentials are coming to GML in the next major point release and I'm I'm really looking forward to it. However, I'm writing projects right now and need to live with what we currently have (FWIW I don't think GML is particularly bad but I'm excited about the upcoming improvements).
In my latest RPG project, I just want some simple classes to describe the party characters and their stats, classes to drive turn based battles etc. None of these have instances directly in a scene and on top of that, things like the character information needs to persist across some (but not all) scenes.
I have this working using a combination of ds maps, indexed using an enum with names for each of the "class members" and then I have scripts prefixed with the "class" name which take the object to operate on as the first parameter to simulate member functions. Essentially I'm taking a C style approach to classes.
Is this how people generally do things? Am I missing a trick? For objects with instances in a room none of this is really a problem but obviously sometimes you want code which lives outside of these.
In my latest RPG project, I just want some simple classes to describe the party characters and their stats, classes to drive turn based battles etc. None of these have instances directly in a scene and on top of that, things like the character information needs to persist across some (but not all) scenes.
I have this working using a combination of ds maps, indexed using an enum with names for each of the "class members" and then I have scripts prefixed with the "class" name which take the object to operate on as the first parameter to simulate member functions. Essentially I'm taking a C style approach to classes.
Is this how people generally do things? Am I missing a trick? For objects with instances in a room none of this is really a problem but obviously sometimes you want code which lives outside of these.