More confuddling concerning Instances.

gyroscope

Hallo; more tests to get my head around how GS works; came across something I'm a bit confused about.

For an example, say you have a bouncing ball and 40 possible targets. All these targets are Instances of one Prototype. There's a Rule in this Prototype which says when a collision happens, for it to destroy itself. Now I've learned that when the ball hits one of the targets, they are all destroyed, because the Prototype Rules apply to all of its instances. But then, so as only one Instance at a time is destroyed when hit, I thought I would go into each Instance and click the lock of it, so that, I assumed, the destroy me when hit rule would only apply to that one instance; seeing as its Rules no longer "belong" to its Prototype.

But still they are all destroyed, not just the one hit. I can't see the point of breaking the bond with its prototype if it doesn't then act independently from the others.

Another thing which is confusing: each Instance allows you to change its Name. So i tried making the names different for each instance, i.e Target1, Target2, Target3, etc. But there's nowhere where these new names can be accessed in the Rules, as such. So I can't see the point of being able to change an Instance's name.

So if there's no way to make a large set of Instances act independantly from each other, with their own code, the only other way would be to make, in this example, 40 different actors but all with the same image. At least that way their Rules would act independently? Still be a pain though, I'm sure you'll agree, as well as eating up valuable space.

Sorry about my slowness here; I think I'm trying to apply Basic programming logic to GS, and it's not applicable (surprisingly to me).

If I can get this principle "under my belt" I'd be a happy chappy! Any help appreciated, thanks.

firemaplegames

Hey,

I'll see if I can help...

In GameSalad, there is the concept of Prototypes and Instances. The Prototypes are created by clicking the [+] button on the left, in the Actor pane. Instances of the Prototype are created by dragging copies of the Prototype into the Scene.

Think of the Prototype as the 'blueprint' for its Instances.

Let's create a simple Box Actor. The Prototype for this newly created Actor now sits in the Library. Now drag 5 copies of this Actor out into the Scene.

You now have one Prototype and five Instances of that Prototype. Simple, right?

The subtle power comes when you do this:

Double click on one of the Instances and change its color. Rotate a different Instance 45 degrees. You can change the physics property of another, and even change the Image of another one.

However, if you add code to the Prototype in the Library, ALL of the Instances will receive it. This is a great benefit to keeping your code 'clean' and all in one place.

When you are first starting out, I would keep all of the code in the Library on the Prototypes. Do not click that padlock in the Instances until you understand what that entails.

So, to sum up, you are able to have one Prototype, and lots of different Instances of that Prototype.

In my game Danger Cats!, there are a bunch of items that are stacked up in each level. Boxes, watermelons, gasoline cans, plates of spaghetti, etc.. etc... They are ALL Instances of the SAME 'item' Actor. Some of them have round collision areas, all of them have different images, different densities, etc.

Now, as to your above problem. First, you should open up each Instance and click the 'revert to Prototype' button' in each one to bring back the padlock. Or delete them and drag out new targets.

It sounds like something isn't working correctly.

For the sake of argument, let's say the main actor is a ball and all the targets are coins.

It should be set up like this:

Two Prototypes:
Ball
Coin

Drag a bunch of coin actors out into the Scene. Drag one ball actor into the Scene.

In the coin Prototype, the behaviors and Rules should be like this:

Behavior:
Collide with Actor of type Ball

Rule
When all conditions are valid:
Actor overlaps or collides with Actor of type Ball
-----Destroy

The ball just needs to have its movement Rules defined.

The coins should NOT destroy all at once. Each Instance is its own complete copy of the Prototype. Its own little universe. Destroying one does not (should not) destroy them all.

gyroscope

Another excellent reply, @firemaplegames, thank you again!

Firstly, I'm glad I've got the principle of Prototypes and Instances understood now; thanks for confirmation.

As for your coins example, I'm going to do another test; perhaps I wasn't fully awake when trying my first test. So:

firemaplegames said:

The coins should NOT destroy all at once. Each Instance is its own complete copy of the Prototype. Its own little universe. Destroying one does not (should not) destroy them all.

Hooray for that... :-)

I'm still wondering why there is the facility to rename Instances, but I guess now they just help identify different Instances of the same prototype, i.e different densitites; colour, etc; as you mentioned.

---------------------------------------------------------------
Spiral Gyro Apps

firemaplegames

Well, Instances can 'talk' to one another(Prototypes cannot), so you can use the Instance's Name property for that...

You can also use it in the condition of a Rule in the Prototype, like this:

Rule
When all conditions are valid
Actor overlaps or collides with Actor of type Ball
-----Rule
-----When all conditions are valid
-----self.Name = "SuperSecretBonusCoin"
----------Play Sound: "supersecret_coin.ogg"
----------Change Attribute: game.score To game.score + 100
-----otherwise
----------Play Sound: "regular_coin.ogg"
----------Change Attribute: game.score To game.score + 10

Even though that Rule set is in the Prototype, you would change the Name Attribute of one of the Instances...

gyroscope

firemaplegames said:
Well, Instances can 'talk' to one another(Prototypes cannot), so you can use the Instance's Name property for that...

Excellent news; thanks yet again for info and example! :-)

---------------------------------------------------------------
Spiral Gyro Apps

gyroscope

Still something puzzling me (easy enough!): I've made another simple test with 2 actors; one is a large background that when clicked plays a sound, as well as the smaller actor on top playing a different sound. When I click on the background, its sound plays OK; when I click on the small actor on top, both its sound, and the one belonging to the background play. I've tried both as Prototypes, both as Instances as well as one Prototype + one instance; still the top actor plays both sounds. I put in the Rules when actor receives event mouse button is down, plus when actor receives event mouse position is inside for both actors.

It seems crazy to me that this goes against the grain of Object Oriented programming; it surely is a glaring bug, as Rules should belong to each Prototype/instance, and when overlaid onto another actor, shouldn't "click through" to the back actor?

Unless i'm missing the point here; but for the life of me can't see the benefit of it, only the huge downside.

What's not clicking in my brain? I really don't know; but I do know I'll be using quite a few overlaid actors, and if by clicking one, the whole lot directly behind in the back layer play out their Rules, it'll be quite a mess, I think.

And hoping not to labour the point (and I might be repeating what I've said somewhere else) in other programs (I can think of three I've used) where the engine is OOP, and so an object can be coded, the code belongs to that object - (button, field, graphic, image, etc.) so when clicked, nothing else gets the click message (unless you tell it to) if its on top of another object. I'm probably rambling a bit now, but this aspect is so disappointiing to me; I can almost say i'm disappointed in GS in a big way (personally this is, for what my opinion's worth).

Anyone have any thoughts on this please?

---------------------------------------------------------------
Spiral Gyro Apps

gyroscope

Rambler and moaner here (I blame it on my headache); I'll keep this short! Gone back to my first test, click on screen (actor1); actor2 moves to x,y pos. of click; click on actor3, to fire; originally the first actor moved to the clicked position on the fire button. But now it's working, and actor1 stays put. But the only change I made was add an image to one of the actors. Strange, don't understand why that makes a difference. I think i'm a bit happier; i'll know after I've taken a few paracetomol...

Edit: almost a half an hour later, happening again. Obviously "When "Actor receives Event mouse button is pressed" means the clicked/pressed Actor, but also including all layered Actors behind the one clicked/pressed on. Surely this is wrong.

---------------------------------------------------------------
Spiral Gyro Apps

gyroscope

After a good night's sleep and my headache gone, i'm not so tetchy this morning! I've realised there's a workaround to the limitation: in my example for instance, I'll shorten the background area to leave a strip, left, right, top or bottom, where the Fire button can live quite happily, not overlapping any other actor that has Touch Rules.

Just thought I'd mention it for your interest. Or not... ;-)

:-)