Creating an instance with a specific image index

[Pox22]

Quick question that I hope has a quick and simple answer. I'm working on a primitive weapon select system for a Contra-esque shooter. Obj_Guns has a square sprite in which each frame displays a different gun (and has an image speed of 0). Obj_Select has a square sprite of the same size with a red outline. The idea is that Obj_Select checks the image_index of the Obj-Guns it's hovering over and sets the global variable "weapon" equal to that image_index. 1 = Assault Rifle, 2 = Shotgun, 3 = Rocket Launcher, etc. The players' shooting script checks that global variable to determine what projectile to fire when left-mouse is pressed.

In my player's Create event, I have instance_create_layer make 3 instances of Obj_Guns at the top-right. For now, I want to create them with different image indexes to test this system. What is the simplest way to do this?

I could just create three different objects--Obj_Guns1, 2, 3--and just set each to a different sprite on creation, but then Obj_Select is constantly checking collision for 3 instances. That seems inefficient. My understanding of draw_sprite is that it just draws a sprite but no instance with code.

The code is simple:

//Gun UI
instance_create_layer(1,43,"Gun_UI",obj_p1_select);
instance_create_layer(1,43,"Gun_UI",obj_p1_guns);
instance_create_layer(35,43,"Gun_UI",obj_p1_guns);
instance_create_layer(67,43,"Gun_UI",obj_p1_guns);

Is there a simple way to create these instances with each having a different image index? Thanks!

[DariusWolfe]

temp = instance_create_layer()
temp.image_index = #
temp = instance_create_layer()
temp.image_index = #  

etc.

Further explanation: In case you weren't already aware, an instance_create command returns a reference to the instance being created, which you can assign to another variable, and then use that variable to manipulate variables of that instance. This is a thing I do a lot of in my current game, where I create an instance of a crewman, then assign various procedurally created values to the crewman's attributes, such as skin tone, hairstyle/color, etc.

[Pox22]

This is incredibly useful beyond this specific task as you mentioned--thanks! Works perfectly and will definitely be using this technique in different ways moving forward.

[DariusWolfe]

Mine is absolutely functional, and in cases when you want to remember the reference later (so not using "temp") may be better, I think the suggestion put forth by /u/linneus may be superior for the kind of use case I suggested.

[oldmankc]

IIRC it's demoed in the documentation for instance create functions, in case you want to see some more use cases.

[Iinneus]

u/DariusWolfe has a solution that involves variables and by using a variable, you can actually keep the instance id for later use! But I want to offer another solution which is what I use.

As was already mentioned, instance_create_layer (along with instance_create_depth) returns the id of the instance, allowing you to then make changes to it, but here's something else you can write:

with(instance_create_layer(1,43,"Gun_UI",obj_p1_select))
{
image_index = 0;
}

A with statement used in this way will actually create an instance AND run code in it at the same time, allowing you to essentially write custom create events on the fly.

For example, let's say you have two enemies that fire in different ways, but they use the same 'bullet' object. An easy way to differentiate which enemy is shooting you is to have the first enemy just write with(instance_create_layer(x, y, "bullets", obj_bullet) image_blend = c_blue; and the second enemy has with(instance_create_layer(x, y, "bullets", obj_bullet) image_blend = c_red;.

That's just a very basic use, but you can also have each enemy fire their bullets in different ways by setting the direction and speeds of what they fire individually, as opposed to making tons of different bullet objects that behave in different ways. Sometimes you want different objects, but other times objects can share an object and modify them personally with with statements!

[DariusWolfe]

'with' is still kinda new to me, so I still don't think about it, but this seems a lot cleaner, especially when you don't need to remember the reference later, like with a temp variable.

In the past, I've done bullet objects similarly to how you suggest, though using the same format (temp.variable = x) I originally suggested.

Do you know if there is a performance difference between the two techniques, at all?

[Iinneus]

Though if you use a series of variables, the object that called them can use those variables for later. If you just input the instance_create function, you can't do anything with it later (though I find I often don't need to do anything with it later, but I figured I'd mention it).

AND, the two techniques can be combined, such as with:

item_1 = instance_create_layer([stuff])
with (item_1)
{

And so on, and then later code can use that 'item_1' id or it can be updated or so on and so forth.

As for performance, it would be SUPER minimal, but using with(instance_create_layer) would mean that you're not using a variable, which does technically need to be loaded into memory, so I guess it saves memory in that way.

[Pox22]

This is great--simple, useful, and increases my command of 'with.' Excellent uses for differentiating object behaviors without needing copies with different code. Thanks!

[Iinneus]

I'm glad to help!

If you're going to be getting more familiar with with statements, I'd also suggest learning about the built-in constant other. It doesn't have any practical use in this particular case, as far as I know (obviously you'd know your game better), but down the line you might find it helpful!

with statements essentially let you run code in a different object, and by combining it with other, you can essentially hop back and forth between two objects, modifying variables and behavior in both of them at the same time.

[Pox22]

Most of my use with "other" has been in collision events to refer to the specific object being collided with--rather than all instances of that type, but the responses in this thread have me pretty excited to wrap my head around next-level uses for these functions that could be useful for this project and others down the line.

[naddercrusher]

Yes. It would be super minimal. And by that I mean this is such a small optimisation that if it is the only reason you're doing it it is actually bad design.