How do I Resolve Instancing & Dynamic Volume Issues

I have a fairly simple project with an clear goal in mind but am finding it oddly difficult to get a working output for some bizarre reason.

Basically, it is meant to be a game where you walk around and beat up enemies.

A new enemy spawns in each time you destroy 1 of them.

The game begins playing peaceful music at the start and when the player gets near enemies.. it fades out and fades in with action music.. once enemies are all gone it fades back to peaceful music.

**

When the player gets too close to an enemy it will randomly start attacking the player moving towards them in short bursts giving the player a chance to run away if they want to. **this part is not yet coded in**

Issues :

1)

I've tried to handle multiple instances using the "For Each Enemy" condition as the first one listed for each event where multiple instances of the Enemy Object will be referenced to, but this results in a rather long error pop-up in the Chrome Browser (the one I am using to test this in)

The only work-around I have found so far is to limit the number of IIDs that can ever spawn at any time and then list each one off. If there were a shorter way of dealing with this, I am all open to ideas.

2)

Sounds are not fading in and out correctly. I have tried to use an approach where the script seeks out the closest instance of Enemy and then determines its proximity to the Player sprite. I then set it up so when the player walks into range of any Enemy instance, the peaceful music fades out and the Action_Intro starts to play with its volume initially being an inaudible dB and gradually getting louder as the player gets closer to the target.

**needs to be coded still** Once the player gets within 400px of the nearest Enemy instance, the Enemy will attack the player randomly as well as move in short bursts towards the general direction of the player with random duration of pausing in between each charge attack. At the same time, the volume will stop getting louder and continue to playback at 0dB untill the player moves more than 400px away from the closest enemy.

If an enemy is destroyed, an invisible sprite is moved to the location of the destroyed Enemy. I then use this sprite as a "place holder" so the sound doesn't instantly cut off or glitch from 1 sound file to another abruptly but can make a smooth transition between them.

**need to add a bullet effect to the invisible Enemy_Ghost sprite so it steadily moves away from the player the moment it is positioned over the destroyed Enemy ... this will make the volume gently transition BUT only i no other enemies are within range of the player still**

That's pretty much it, perhaps there is a far more simple way to achieve what I am after here but since I couldn't figure any other way out, this was the best I could come up with.

I am secretly expecting that I've gone and made things far more complicated than they have to do and that Construct 2 is designed to automate a lot of the things I've tried to micromanage but I just am not sure how to access these things so they function as intended.

Please find the CAPX file linked below :

http://www5.zippyshare.com/d/82926545/508/Street%20Thrash%20Game%20Demo.capx

p.s. there is this odd gap between loops of the audio files and the actual sound files have no silence top or tail so it shouldn't be happening.. if anyone knows why construct 2 is adding this gap of silence between each loop of the files that would be great to know.

bump

double bump... Please can someone please help me with this.

Can someone please help with this, I've tried a lot of things but just can't figure out the solution. This software seems confusing :s

I would suggest that you read about families and how they work as fast as possible, as it will make things a lot easier for you.

Anyway for the issues:

[quote:10n5zsiz]I've tried to handle multiple instances using the "For Each Enemy" condition as the first one listed for each event where multiple instances of the Enemy Object will be referenced to, but this results in a rather long error pop-up in the Chrome Browser (the one I am using to test this in)

The only work-around I have found so far is to limit the number of IIDs that can ever spawn at any time and then list each one off. If there were a shorter way of dealing with this, I am all open to ideas.

I assume that the limit you refer to is 4? exactly why it gives you an error I don't know. However your program as it is currently made wont work with more than your limit, as you have "hard coded" checks into it that uses specific IIDs, so the moment an enemy spawn that are outside this range your game wont react to it. That's why I suggested that you look at families.

In general using IIDs for anything is rarely needed, at least in my experience, in fact I have never found anything where I would use them. The UID for objects on the other hand are very useful as these are unique for each object. So to solve this problem would require you to remake everything that have to do with the enemies unfortunately.

[quote:10n5zsiz]2) Sounds are not fading in and out correctly. I have tried to use an approach where the script seeks out the closest instance of Enemy and then determines its proximity to the Player sprite. I then set it up so when the player walks into range of any Enemy instance, the peaceful music fades out and the Action_Intro starts to play with its volume initially being an inaudible dB and gradually getting louder as the player gets closer to the target.

The reason this doesn't work is because your are calculating it based on the "Enemy_ghost" and that one is offscreen. To fix it you have to add the following:

[quote:10n5zsiz]I am secretly expecting that I've gone and made things far more complicated than they have to do and that Construct 2 is designed to automate a lot of the things I've tried to micromanage but I just am not sure how to access these things so they function as intended.

That is completely correct

Hi, thanks for this information. I'm not sure what families are so i'll try to do a forum search and hopefully it brings up some handy information. At this point the project is so far behind schedule that there isn't too much point trying to further continue working with Construct 2.

I'll likely migrate to a less simplified engine so attempts to micromanage don't become so problematic. I really do want to complete this final project though if I can.. don't like leaving things so close to finished and giving up.

It really bugs me that Construct 2 has so much potential but each time i re-visit it, I'm left with hours of problem solving and running into walls trying to achieve things I thought would be far more simple to achieve based on previous experiences in more advanced engines.. what a waste..the hard stuff is easy and the easy stuff is convoluted or achieved in an abstract manner unfamiliar to all previous engine experiences I've had.

Either way to show my gratitude for your help in response I will do my best to give this families thing (whatever it is) a shot and see if I can at least see this final project through to the end. I do appreciate the time you have taken to look over the topic and attached file so giving it 1 more shot is the least I can do to say thank you.

[quote:3d2clzo3]I'll likely migrate to a less simplified engine so attempts to micromanage don't become so problematic. I really do want to complete this final project though if I can.. don't like leaving things so close to finished and giving up.

That might be better, but I don't think you will get anything out of that. "Micromanagement" is the same no matter what software you use, and its not really about that.

As I see it from reading your code is that you have some gaps in the basic knowledge of how things works, which is very common when starting on something like this, and as a result you take the long and difficult path when trying to achieve something. Which gives you the impression that stuff is very difficult or hard to do, even though you expected them to be easy.

And in most cases it is, but only if you have the basic knowledge in place. My guess is that you will run into the same if not more problems if you use another tool, you might have more experience in those at the moment and therefore they seem easier.

If I were you and you still want to give C2 a chance, the first thing you should get to know, and understand very well is how picking of objects works. I don't mean just reading about it, but really understand the logic behind it. Its in my opinion the most important thing in C2 and if you are used to another type of software, picking might be a bit confusing at first. But if this is not understood, you will keep running into problems, when making things that you thought was easy do. And reading your code, it could suggest that you are not really confident with this, so if that's the case I would wait a bit with families and learn how picking works. The moment you understand this and you go back and look at your game, you will see why the amount of "micromanagement" that you do or think you need is doing nothing more that making things a lot more complicated for you than it have to be and is limiting you quite a bit. Because as you do it now, you check against individual instances of object, and that will do nothing other than making things a lot more complicated to do, since you could check against all the objects in one go, but only if you understand the concept of picking the correct objects.

Micromanagement should be that you give enemies different stats such as health, weapons etc. Moving enemies around a map for instant shouldn't be, you should be able to make a random enemy on the map move exactly as you would if it had been another enemy that was chosen to move, the moment you cant do this and you think its because you have to micromanage them, then something is wrong in my opinion. And that's where understanding the concept of picking and family comes into the picture, these to will let you do it without micromanagement, and why understanding these two is crucial if you want to get anywhere with C2.

This is from an old post I did for someone else about how picking works, maybe that can be helpful for you:

[quote:3d2clzo3]

This might be helpful.

Events:

https://www.scirra.com/manual/75/how-events-work

Objects:

https://www.scirra.com/manual/68/objects

System conditions:

https://www.scirra.com/manual/124/system-conditions

Basic picking:

[quote:3d2clzo3]It sounds like you (not uncommon) get a bit confused about how picking works in C2.

But the way you can look at picking of objects is like a sorting or a reduction machine.

Imagine you have 100 workers with the following attributes.

100 Workers in total

20 Workers are wearing a red shirt.

40 Workers are wearing a blue shirt.

30 Workers are wearing a yellow shirt.

10 workers are not wearing a shirt.

30 Workers are between 40 and 50 years old.

50 Workers are between 20 and 30 years old,

20 Workers are between 60 and 80 years old (No pension for these poor bastards!)

Lets say you want all workers wearing blue shirts and that are above 60 year old to either go home or go to lunch.

So what happens is:

Pick all Workers : You pick all workers that match the condition that they are workers, in this case all are so its 100. (You don't really need this, its only for the explanation.)

Workers must have blue shirts : This will reduce the number to 40 workers.

Workers must be older than 60 : Depending on how many of those 40 workers matching this you will get a new number that further reduce or sort the amount of workers matching the former condition. Lets assume that its 15 workers.

Now we cant reduce the amount anymore and we have found all the workers that match all our conditions. And since we want them to either go home or to lunch, and don't care how many goes where. We can do the following.

For each Worker : This will go through each of the 15 remaining workers and tell each of them to either go home or to lunch.

Go home or Go to Lunch

So that's pretty much how it works whenever you pick objects, that you keep reducing or sorting them until those that remains fit whatever you want. And then if you want them to do different things you throw a "For each" at the end and then the options they have afterwards.

Thank you very much again for taking the time to consider these things. It may be true that not understanding how objects are being targeted in C2 is the root cause of the issue. I do consider that most of the alternatives use a more clear approach for handling this and also agree that understanding this process is critical to success with any engine.

With this in mind I do want to give C2 another shot even if it is just to prove to myself that I can grasp its unique approach.

I will now begin to study these things and will post an update with an improved capx once I have implemented this knowledge.

Thanks again for your support and feedback.

EDIT : based on the example of the workers, since in my scenario I am wanting all the enemies to be chosen.. I don't need to filter anything.. yet when I tried this using both the Pick All command (made no difference) and the For Each (returned errors) I still feel lost as to whether this reduction process would really help.

for identifying which enemy is closest I can imagine it might be of use.. I just need to think of a way to exclude all instances of enemy that are too far away from the player sprite. *which I thought I was already doing with the "Enemy : Pick nearest to Player.X, Player.Y" Condition*

The only possible conclusion as to why this did not work would be that I can't seem to determine the connection between reduction on the Event side of the equation via conditions and then the applied Actions on the right hand side as technically.. it should only be applying actions to the resulting instances left after the reduction process has been applied but this just didn't happen :s

[quote:2wls14h5]EDIT : based on the example of the workers, since in my scenario I am wanting all the enemies to be chosen.. I don't need to filter anything.. yet when I tried this using both the Pick All command (made no difference) and the For Each (returned errors) I still feel lost as to whether this reduction process would really help.

You actually rarely need to use "Pick all" as C2 does that for you automatically by default. And its probably the most complicated about picking, even though its not really that complicated But you should see the "Pick all" as a reset of picking.

Imagine something like this:

Here are two types of enemies one is called "Type 1" and the other is "Type 2"

So therefore you can use "Pick all" to reset the picking, and will now make the last event destroy the type 2 enemies.

So the "Pick all" is not really anymore complicated than that.

[quote:2wls14h5]for identifying which enemy is closest I can imagine it might be of use.. I just need to think of a way to exclude all instances of enemy that are too far away from the player sprite. *which I thought I was already doing with the "Enemy : Pick nearest to Player.X, Player.Y" Condition*

That is the correct way of doing it, and also why this problem with the sound was so easily fixed, because the picking was correct. That you don't really need the "Enemy_ghost" to do it, is another thing. But it just needed one extra action to make it work. Where as to solve the other problem would require you to go through all events that uses the IIDs in the conditions and fix those.

[quote:2wls14h5]The only possible conclusion as to why this did not work would be that I can't seem to determine the connection between reduction on the Event side of the equation via conditions and then the applied Actions on the right hand side as technically.. it should only be applying actions to the resulting instances left after the reduction process has been applied but this just didn't happen :s

Try to do something a lot more simple, like the example as I did above. Make 1 sprite give it a variable, hold down ctrl and drag some copies of it. Change the variable so its different for them all, and then just try to pick them in different ways and destroy them.

Maybe using the variable, the one closest to the mouse cursor etc.

The way I think of picking and setting conditions is to do it rather systematic. lets say I want an enemy to take damage when hit by a bullet:

Conditions:

1. The enemy is actually getting hit by a bullet. (On collision between bullet and enemy)

2. The enemy must be alive (So either health > 0 or some Boolean set to true for the enemy being alive)

That's pretty much the conditions. And with these two conditions we have already found a valid enemy.

Actions:

1. Subtract bullet damage from enemy health

Then we could go on and check if the enemy health is <= to 0 and if that's the case then destroy the enemy.

I have performed a test to determine that I can enforce the spawn distance of enemy sprite instances :

I have assigned the instance variable Type-A to the Enemy sprite in the layout area so all instances of this sprite should have the same variable and therefore be chosen via reduction.

What I find happens instead is that Enemy sprites are still being spawned overlapping even though I have enforced a 1000px distance from their points of origin to the spawner sprites' location.

This shouldn't be happening :s

To me it seems that unless I specify individual IID's for all possible instances, it will treat Enemy.X, Enemy.Y as the X and Y positions for Enemy(0) only and ignore all other IID's even though they should be included in the reduction process based on this being a sub-event.

I just don't understand what is wrong with my logic and approach with this. I understand that based on your most recent post, unless you use Pick All, sub events will be only targeting instances remaining after a reduction condition and will ignore all others .. so I determined that I can simply use a sub-event to ensure that all enemy instances are being targeted.

I mean technically all of this is unnecessary since it should have ALL instances of Enemy being targeted by default regardless of needing that instance variable.. but I wanted to be sure it knew that when I used conditions targeting Enemy.X and Enemy.Y it should be for all instances of the Enemy sprite and not just Enemy(0) *the original instance IID*... the one that was not created during runtime.

EDIT :

Just had an idea after reading up on families, if I were to put the Enemy sprite into a Family called "All_Enemies" then I could simply use All_Enemies.X, All_Enemies.Y and it should technically apply the comparison to all enemy sprite instances.

distance(Spawn_Zone.X, Spawn_Zone.Y, All_Enemies.X, All_Enemies.Y) > 1000

I mean personally I don't get why it should work any differently considering it seems pointless to make a family for just 1 sprite when it is meant to be used for multiple sprites not multiple instances of a single sprite but it might make a difference o.O