#Creating instances with time source?

1 messages · Page 1 of 1 (latest)

flat oxide
#

I saw this specifically in Input: https://github.com/JujuAdams/Input/blob/master/scripts/__input_initialize/__input_initialize.gml.
Usually I have a bunch of persistent objects I want to create at the start of the game. And what I usually do is create some sort of init room and place these objects there. Or place an init object in that room which creates these instances. However I saw this technique in the Input library of creating instances using a time source. This seems elegant to me because you don't have to create an init room or object. But I've never used time sources before, and there's only so much I can gather from copying Juju's code. Are there forum posts or information about the advantages and oddities of doing this, or would anyone care to share their opinions?

#

Here's a code example of what I'm thinking of for a camera object:

global.camera = noone;
global.camera_interval = 0;

function camera_init() {
    // feather ignore GM1043
    global.camera_interval = time_source_create(
        time_source_global,
        1,
        time_source_units_frames,
        function() {
            if (instance_exists(obj_camera)) {
                time_source_stop(global.camera_interval);
                time_source_destroy(global.camera_interval);
                return;
            }
            global.camera = instance_create_depth(0, 0, 16001, obj_camera);
        },
        [],
        -1
    );
    time_source_start(global.camera_interval);
}

camera_init();
unborn swift
#

i'm pretty sure Input has comments on the what and why

#

the reason is we wanted to tap begin step and you can't do that without an object

#

and the only reason for the timesource is we don't want to prescribe library users having to remember to juggle the object themself

#

for your game, you should just put the ncessary persistent objects in an initial room and never return after boot (also don't use restart)

#

that, or use timesources if they will do. no need at all to use both per the library's approach.

azure socket
#

Idk if this is the best approach, but for any persistent game systems I always just have a function create and return a static instance of the systems constructor
( off the top of my head )


function cGameManager() constructor {};

function gameManager() {
   static sClass = new cGameManager();
   return sClass;
}
willow glen
#

The only real benefit of doing a time source for creating an instance is just to be able to ensure that a specific instance always exist.
Input has some further specific reasons (see comments, also this issue)

#

Honestly, I don't really like the idea of a time source creating an object unless you need to track specific events, or moreso in a library, want to catch if someone is inappropriately destroying/deactivating instances where they shouldn't be

#

Also since time sources don't tick til after the begin step has fired for all instances

#

Then if you need to rely/do something with those instances prior to the time source expiring, and they happened to been deactivated/destroyed, it becomes a problem

#

If you just want to init a bunch of instances at the start of the game (without having to add it to a room manually)

#

If you pair it with asset tags on top, you could have something like

var _managers = tag_get_asset_ids("Manager");
for(var _i = 0, _len = array_length(_managers); _i < _len; ++_i) {
  room_instance_add(room_first, 0, 0, _managers[_i]);
}
fair falcon
#

if it was my own code, i wouldn't do it the Input way. only reason we use this complex method is to make the Input experience more automatic. yknow, maybe you want that, but it's probably overkill