..

I have no idea how to code in c++, so i dont know if this suggestion has any value, but,

The Express Version of Microsoft Visual C++ is freeware ?

You can find it here ...

http://www.microsoft.com/express/vc/Default.aspx

So since i advice you not to use Families when using advanced expressions for behaviors in the current release of construct (95.3) ...

I made you go stuck in construct ?

Naw, never. Construct is very flexible.

But this means back to instances, and instances all have the same face, the same sprite ?

Yes this is true.

But, a sprite is no more then an objects properties. Almost all properties can be tweened in the events, or changed in the layout editor.

And that is true for sprites also, in the form of animations. A sprite is also 1 frame of an animation.

In this .cap

I gave 1 instance 7 animations. Now all the instances of the same object have this animation.

Its up to you to decide whats steels less of your time and concentration, and disallow you to make the lowest count of errors.....

Or give one object 7 animations.

Or give 7 objects a behavior with 20 behavior properties. And be forced to change them one by one when needed for the good flow of the game. Give 7 objects all those private variables, a normal game can run on 10 private variables. 10 * 7 = 70 times add a private variable. And this list is endless and unpredictable during developing a game.

And in the events sheet there is only 1 action more. The action in event 2, that sets the animation to the loop counter translated to a string to match the animations name.

And thats all !!!

....

To continue the Story.

I hope i did not make you panic with the first post in this topic. I mean, i can imagine that you think: if thats the case ! i find another game maker !!!.

LoL, sorry ?

Yes there is a way to manage 7 different objects easy and comfortable.

But, the time consuming preparations in the layout stay. And the chance to make an error there stays too.

But for the events, wizard Ashley gave us the "Families". Families are a way to group objects.

You add a object to a family in its properties under *groups* and deeper *families*. You can easy define you own families AND give them a personal thumbnail so they show up the way you want in the events.

Once objects are in the same family, they act *almost* as they are instances of the same object in the events.

look at this, download it and fire it up in construct.

7 different objects. All 7 i made member of the family "Items". Then i just took the last .cap from previous post with the instances. And i changed all the referring to "bugs" into referring to "items" in the actions and events.

And it runs as they where instances of the same object.

As you see Families are a BIG help in PICKING objects. Thats is why they exist.

But at the moment, Families have there limitations. There are properties that you can not acces to use in expressions trough a family.

And You sure can not access any behavior properties in expressions trough a family.

In the Current release .95.3

So i kinda advice, not to use families when there are behaviors involved, and you plan to use the behaviors in a *advanced* way.

....

Oh a lot of reasons, as there are ...

Its a personal style and it suits me better then using groups. Those "always" events work as groups. And add the readability to the sheet.

When you collapse them, the whole sheet takes less room. And when collapsed there sub events disapear without to much traces breaking my concentration when bizzy in the current event tree. Commented groups are perhaps better but ...

They are such a big aid when you develop. Normal you start out with a bunch of events, step by step. And never build *serial*, but more *parallel* This means that the *Flow* will appear later in the development. *Flow* like, dead conditions and that kinda stuff. Its so much easier to just double click the "always" and change it to a flow condition, then to figure out which events make up a group and add a tree *up* to them. Should be clear if you read the way i build the simple snake game.

And every thing is just a module till you release the game, and even then you will have to kick the bugs.

It also allows to organize easier and better in sub events.

You forget that Flow conditions when true, execute there actions AND SUB EVENTS. If you do not have a top event, then you can not have sub events. And sub events are heaven in organizing sheets. When you showed the advantages in your last post about construct. You mentioned the sub events as a better way to organize then MMF can do. And i very very agree with you !!!!!!!!

For me it is so much easier to invert an "always" to keep a tree from running. Then to make a group and set the group non active. Even more handy then "toggle" event.

See, its a system. A style system, but also a develop system. And i promises you, once you just do have "a system", and when this "system" keeps you out of little problems, and all the little elements seem to fit, one by one, you not only stick to it, there is *no other* way.

Also, it is so much easier to explain. When u write a guide, its so much easier to remote navigate a reader in the sheet that you are building together.

I guess, you have to develop something in this style to see the advantages, one by one.

but strictly, they are nonessential, no. But then again. Comments are not too then. Groups are not too then. The function object is not too then. : )

Now take a look at this:

download it and fire it up.

First glance at the event. Wah ? Thats like 1/7th compared to the .cap in previous post.

Yes sir, that what Instances are designed for.

But lets start in the layout editor.

The preparations for this project.

I only had to add 1 object to the layout. (yes the selector also, blah)

An instance you make by just copy and past. Thats it.

But i made those instances by,

selecting the first added object, right click it, choose "array past" from the contextual menu.

Its 1D, 7 count.

in the move X i filled the value 60.

and i pressed ok.

And that takes 5 seconds to do.

Because they are instances of the same object.

Adding a private variable has to be done only once on 1 of the objects.

Adding a behavior has to be done only once on 1 of the objects.

Not 7 times !

And if you do this before making the instances, also the private variables initial values,

and all the behavior properties will be exact the same in the copys.

Again this 1/7th of the time to manage this. With 1/7th less chance on errors.

In the events editor.

Event 2 is a special advanced Loop.

the "for each object ordered" loop that can be found in the system conditions.

It runs trough all instances of the Bug,

picks them one by one, here starting with the lowest X,

and feeds the picked objects to its sub events and actions.

So the action to deactivate the behavior we only have to put once.

Storing the start X and Y we only have to do once.

At same time we give the instances a identification number, to be able to pick them by comparing the private variable thats holding the value with the identification number.

The private variable = 'My_number_is"

The value we give it can be found in the system expressions = current loopindex

The instance with the lowest X gets number 1. The next one get 2 .. and so on.

In event 3 we initialize the global variables used for Flow.

in event 4 we set the behavior of the first instance to active.

This is a pick condition. It can be find in any objects conditions as "compare private variable".

What it actual do is:

It picks all instances of the object Bug...

Runs trough the private variable thats given as parameter,

and when the condition is true, here when "My_number_is" = 1,

it will set that object as picked.

So on our case, it picks out the first instance of the bug,

and the action sets the behavior of that Bug to active.

In event 5 and 6

We add or subtract from the global variable 'selected' according the key thats hit.

We have 7 objects, so if the variable gets out the range of 7, we make it loop back/forth

Dont matter how many times u hit the arrow keys, 'selected' will be in between 1 to 7.

Now we have only 2 conditions.

Condition 1: Its "My_number_is" is the same as 'selected'.

In that case the selector must jump to this objects position,

its behavior must be active, and thats it !!!

Condition 2: Its "My_number_is" not the same as 'selected'.

In this case the objects behavior has to be deactivated,

and the object needs to be placed at its starting position

Now the global variable 'select' is not really needed. Its just one of my style elements.

If i dont use it, the 2 conditions will run every tick.

And every tick (by example) the behavior gets activated, because there will always be 1 object selected.

I dont like to spend so much CPU cycles to do only this.

When you hit the arrow key to select another bug, the variable 'select' gets set to "M",

the M from Mark.

When its "M" the 2 conditions run. Directly after they did there work,

'select' gets set to "X", X for crossed out.

The 2 conditions will now not run till hitting an arrow key brings 'select' back to "M"

Of course, explaining all this takes more time then actual make this. I made it in 10 minutes.

Plz, do not ask me how much time i took to make the .cap in previous post.

Now, do you see the power of instances ?

....

Containers are part of the "object picking" story.

So, i have to tell you the story of objects (clones and instances) and how to pick them first,

before i can start explaining containers.

Most of it i explained already. But not in the way i am going to now.

I am gonna make a point later in this topic. So the point will not be made in this post.

As always i build the topic up.

So do not ! take the .cap i post here as an example for good coding. It is only an illustration for this post, and for the sub-point that i try to make in this post.

OK, download this, and fire it up.

There are 7 different objects in that layout. They do have the same sprite. But that is only to make a good link to the next post.

Those 7 objects are totally different. If they are clones from the same object, or objects i added starting from the same sprite. That does not matter in this post. We do not need to change the sprite / animation for each object and different.

They are totally different because they have different names. Talk to those objects with events and actions is whole lotta work.

And this overload in work starts already with in the preparation of this project.

We have to make this object 7 times.

7 times we have to place this object.

7 times we have to give it a name.

7 times we have to give it the "8 direction" behavior.

7 times we have to change the behavior to "only up and down"

14 times add a private variable

Thats 7 times more chance to make an error. And its a real workload. Dont believe me, then start this from scratch, with any sprite you have laying around.

And yet, what i actually want to do is simple.

I want to select 1 of those 7 objects. When the object is selected i want it to be able to move it by the "8 directions" behavior. And only this object, and only up and down.

Selection happens with the left and right arrow key.

I want a selected object to be shown as selected by marking it by a rectangle.

When unselected i want the object to jump back to its starting location.

And that is all.

Now look at the events sheet. Thats a whole bunch of events. And it takes a whole lot of time to make them. And even more concentration to not make NO error.

It starts already in the "start of layout" event.

The behavior for every object, except the starting object needs to be set to non active.

Thats 7 lines already.

We need to store the starting X and Y for each object in a variable, to be able to recall them.

Thats 14 lines already.

And, as i pointed to already, every global variable that acts as a flow variable should be initiated in the "start of layout" event.

Then in line 11 and 12 you have the 2 key inputs. To do it this way, is my style.

Then we have to make conditions for when the left arrow keys is pressed,

and for when the right key arrow is pressed.

And since we only can call those object by there 'names" in the wizards. That will be and event tree for each key and each object.

2 events / object. Thats 14 events.

Each event has 8 actions.

Change the global variable 'selected' to the new selected object.

Activate the behavior for the new selected object

place the selector on the new selected object

Place the previous selected object to its starting place for X

Place the previous selected object to its starting place for Y

Inactivate its behavior.

Set its angle to zero.

keep the next events from running by setting the global variable 'select' to "X"

If you press the left arrow key, previous and next object will be different then when you press the right arrow key. Meaning, each event calls different objects.

Thats a LOT of coding. Each event is different, to actual do the same thing. 14 x 7 = 94 actions. Just to do something simple like this. 94 chances to make an error.

To be honest. If this would be the only way to code in construct, i would pass up.

If all those events are needed to just do this, what i did in this .cap, then dont you even try to imagine how much years you will be bizzy to code a whole complete game.

So we need another way to simplify all this. Bring the time to code down. And limit the chances to error out because doing repetitive and boring coding.

The biggest help = using instances and containers. But also family's, Private variables and last but not least the "on layer" condition.

In next post i do the same with instances.

...

Device name: NVIDIA GeForce 8400

Pixel shader: 3

Estimated VRAM: 1007 MB

Motion blur: Yes