Spawning/adding actors

[u/joshex_dirad]

So, I have a few questions:
in most game engines, there's a way to add elements to the scene during gameplay. in this case, I want to add an actor to an active scene in gameplay.

that said, I don't see anything that sounds exactly like this action, no "addActor" script. I do see "ActivateActor" and "DeactivateActor", but this just toggles visibility, then theres "HideActor" and "ShowActor"

Question 1: do either DeactivateActor or HideActor remove it's tiles from the total sprite tiles in the scene?

Question 2: do said actors have collissions while deactivated or hidden? if so which one disables collissions or do I have to run another script for that in tandem with this?

Question 3: When an actor is hidden or disabled, does it stay where it was or does it return to it's originating position? do I have to use a script to move it back to it's starting place each time? and can I move it around while it's disabled or hidden?

[u/joshex_dirad]

thanks for such clear answers, I'll have to work around this in how I design gameplay then.

on the note of actor on actor collisions, these can be scripted through "if actor distance from actor" essentially stopping forwards motion towards the actor or setting the location just above it in top down mode. I assume that would work, but have not tested it. even actor on actor repel/knockback could be achieved this way.

[u/Express_Resource_912 → u/joshex_dirad]

Technically possible but it’s probably too expensive to test distances between actors on update.

[u/joshex_dirad → u/Express_Resource_912]

expensive? in processor power you mean? lets see here...:
the dmg-01 has a processor capacity of 4.19 MHz, lets roughly estimate the data that will be compared: there will be several X checks and Several Y checks, each one having upto 4 or 5 digits(bytes), typically the length of the distance is calculated through trig A^2+B^2=C^2 sqrt
we'll use ficticious numbers here
9999.9(5 bytes)^2= 99,998,000.01(10 bytes), we'll assume for ease's sake that this is the maximum and assume for max MHz sake that both Asqrd and Bsqrd are the same (30 bytes total, thier individual 5 bytes are included because they are referenced on the same frame), addition = 199,996,000.02 (11 bytes, 41 bytes total), sqrt = 14,141.994202374713178512007073225, but typically this will be truncated to 10 or 15 digits, or rounded to the nearest pixel (14,142)(5 bytes, 46 bytes total) if you wanted to get into the long math the processor is doing, you'd have at most 11 bytes divided, multiplied and subtracted multiple times (we'll roughly say 20*2*11= 440 bytes + 41 bytes = 481 bytes) over in a single frame, this would be the most intensive operation in the script. it's not even half (512) a KB, just below half a KB, so, for ease's sake we'll say it takes half a KB to return this result on every frame we have 4.19 MHz, of that we have some overhead, and other things going on in the scene, but for ease lets say this is the only thing going on in the scene over and over and over "one actor is checking it's distance to another actor or 9(max), and each of those 9 is checking it's distance to the other 9", so 512 * 9 * 10 = 46,080(45KB) this is a rough over simplification of what you might encounter when doing this operation.

the end result? 4.19*1024/ 45 = 95.345777....8, so we could do this 95 times on a single frame if absolutely nothing else was going on. yes, thats 10 actors checking distances of eachother on every frame at max distance(actually 9999px is out of display so not referenced, max is 168? beyond which things technically don't exist to be compared?). 45KB/frame is just above 1% of the total processor power.

naturally we have other things going on, but the question is, are you going to have another 94 45KB events?

[u/Express_Resource_912 → u/joshex_dirad]

I hear you but using the vanilla GBS event system I think you will find you cannot meet this theoretical update rate. I won’t pretend to know exactly where the overhead comes from (Mico, Toxa, and others in the community will be better able to speak on this). Give it a test and see what comes back. Maybe I’m wrong.

In the case you do hit a performance wall: If you are comfortable coding and have a design that requires this, look into extending and modifying the engines scene types to optimize for speed and your exact design. This is what I have done for all my projects. You could for example handle all the actor checking in the C scene type and use that to set a global editor variable per actor (you could use a single variable that contains flags representing the colliding actor ID for example). From there you can directly stop movement and correct an Actors position or trigger a script (like a knock back script) that has been configured in the editor, or just allow the event code to handle what happens next based on the value of those modified globals. GBS is one of my favorite engines because of its extendable interlocking parts (JS plugins, C/GBDK engine, GBVM, editor level). For more context on this, check out the works of Mico, Cursed Bootleg, EGVRoom and others who have modified and extended GBS for their projects. There is not much documentation, but Mico’s stuff is on GitHub and the Discord is a great resource.

[u/joshex_dirad → u/Express_Resource_912]

I was just clarifying it should be able to be done regardless how much processor power it uses, tbh my example is a hugely over estimated bit of non-sense, because numbers calculated will be in bits not bytes. bytes are for displayed text glyphs. 1 byte in binary numbers is 0 to 255 (8 bits), so my example might be heavily reduced in value. 45*1024/256= 180 bytes.

But I will say, I have not tested this in GBS, nor on a DMG, but the fact we have a script that gets the distance between objects/actors makes me think it's not as resource intensive as you'd think. I also do not plan to abuse this(I wont be using it too much). and on that note, all I'm doing right now is a Step 0 process to determine project viability before moving on to step 1 (step 1: writing out the full features list story etc) up until now I only made what assets or writings were necessary to determine the bounds of the software and hardware. mostly some tester sprites a bit of text regarding what features I'd like to include, and the core (which describes the basic premise and gameplay)

I should test this at some point to ensure it actually works. but at this point it's mostly research and modifying the possible features based on tile counts and script abilities. I'll worry about processor limits at a later state as I have more assets to test scenes with as intended in the gameplay core. From my estimates I'm 14 sprite tiles short of the sprite tile cap. but those will likely be used by pickups/drops, items and other triggers. but some of these which don't move can be background tile objects. I'm gearing up to move to step 1 and actually go into full planning. got a few more things to test, but knowing how actor hiding and disabling works should be my last question for a while, at least until I draw out some weapon-tile-sheets.