I don't think it would make a lot of different, unless you mean that you want to use some filters etc within C2 to do it. But doing it with PNG is a hell of a lot easier I think, as it is part of the PNG format by default.

I don't think it will have any considerable impact on the FPS, which is mostly an issue for mobiles I would assume. However the image is still considered an image even if invisible and will take up as many resources as if it was transparent.

You have to make a global variable or something that needs to be checked against. So if "Popup is on screen = false" then the player can continue with the game. And you put this check into all the events that lets the player do something, that could interfere with the popup. And set it to true whenever the pop up is on screen ofc.

Edit: had no idea about how it was constantly making health bars - that system is very much infant stages lol

- you're sure it's not just that it can't tell if the object has taken damg?

because that health bar is supposed to be invisible until it takes damg for the first time - but im having the same issue where it cant single out objects in a family - in the event sheet - since when one object takes damg - all the health bars appear - though im not sure how it's variable is reacting to that - since it should stay false

No I noticed as I tested your game, that after a while there were 77000 objects, which is pretty uncommon.

But you can always run it in debug mode then you can see that it keeps making them.

if i use pick by unique uid - wouldn't that still present the issue of being unable to choose the individual object's uid that is being affected? - since i broke the family system and am unable to make code affect individual members -----

or am i missing something lol

As Magistross said there are some complications

But it shouldn't prevent you from picking individual family members, you just have to make sure that you work with the correct families. So if you pick a canDamage and then need a genEnemy all of the sudden in that event you have to add that:

Pick genEnemy.UID = canDamage.UID

Which in it self is not to bad and can be quite useful in a lot of cases. But it ofc complicate things a bit if you didn't do it on purpose, as some of the code might not have been made with this intention. And the way you created the families might not really work as well as you thought. And that will cause some complications at some point....most likely

Just another thing that you probably would like to solve. Your enemy_health_bar is going nuts and keeps creating them none stop. Just if you weren't aware.

There are some issues, and finding the specific reason is not likely to be one thing.

The first thing that will cause you issues though are that you do a "for each canDamage" however this family is not the same as genEnemy. So even if you do a for each canDamage and then do genEnemy is overlapping Damgbox. the for each have no effect as these are completely different objects to the program. so it selects all genEnemy objects.

The way you use for each is a bit wrong or misunderstood. And doesn't really do anything in this case.

Normally when you need for each is when you need different things to happen to a range of objects. So placing it as the very first condition is not very common as its not really needed in most cases.

The normal way of using it would be for something like this, if we imagine that a bomb explode in the middle of some enemies.

First you need to pick all the enemies that are hit (Enemies overlapping explosion) This will select X amount, lets say 5 enemies.

Each of these enemies we want to fly in random directions. So we add a for each Enemy as the last condition.

And then in the action, we do:

Set Enemy.position X = random(300)-150 Y= random(300)-150

(This is just simplified for the explanation and wouldn't work correctly )

Which will set each enemy position to a random X,Y within that range.

So first you isolate the objects you want to work with and then you do something for each of them.

In your case you might be able to solve it if you after the for each in the top of the event add a "Pick genEnemy.UID = canDamage.UID"

Since these two families have the same UIDs, however I don't know your program well enough to know if that will fix it completely or not

Instead of using waits, you can reorganise some small things to make it work.

Since you are using states for your workers it should at least from what I can see in the screenshot be fairly easy to do.

In:

function "Move_to_water"

Worker within 0.1 degrees of area.angle

you remove the wait 1 seconds and the function call to "Collecting_water"

instead you do "Worker set FSMState to "collecting_water"" and if you don't already have an variable for your workers to hold the UID of the object they need to interact with. You can make one. So as you change the state of the worker you at the same time set the interaction variable to the Area.UID. Since you have already selected it when you call "Move_to_water" it should be easy.

In the function "Collecting water" you remove the Set state to "Collecting water" as you have already done that.

Then you remove the wait*4 loopindex as well.

So to make it work, you make an event like this:

Every 1 second

Worker state = "Collecting water"

For each Worker

Call function "Collecting water" (Worker.UID, Worker.Interact_UID (Which is the area.UID in this case))

So basically what you do is simplifying you functions and you get those nasty waits out of the way, and move the wait time outside the functions.

The benefit of using an interact.UID for everything that the worker have to interact with, is that it makes it very easy to debug your program. As you can always check that this variable for a given worker is correct. And since it cant interact with more than one thing at the time. You could also use it if the worker for instant need to go eat and do that sitting in a chair. You simply set the interact variable to the chair UID.

Another good idea I think is to use Booleans for states instead of text, not that it wont work with texts. But its just faster to work with as you don't have to remember how you wrote different things.

So you could have a series of Booleans:

FSM_Idle_wait

FSM_Idle

etc.

Another tip is to use "flags" for your units, this will also make it easier and will let you control them a lot better.

For instant if you use path finding to move your workers around.

You can add the "On arrived" however it will trigger whenever a worker arrives at something. But if you use flags you can make it very easy to make them do what you want.

"On arrived at chair"

Worker.flag_going_to_eat = true

Call function "worker eat"

"On arrived at chair"

Worker.flag_going_to_repair = true

Call function "worker repair item"

I always use at least 3 "Checks" when doing AI.

Busy (Boolean) <Whenever a unit is not busy, it will look for something to do. This is the main variable for activating different states>

Type (Boolean) <Can be very useful if you have different types of units, with different state machines. So Enemies use there own state machine)

FSM_<Do something> (Boolean)

Flag_<What action to perform> (Boolean)

<State variable> (Boolean) <Very good if you for instant want to make a priority system, so if workers get hungry when hunger = 0 you can set something like "is_Hungry = true"

For the state machine it self (If we should make one for workers):

Unit type = Worker

Worker is busy = false

For each Worker

<The order in which you set conditions will act as priority system>

Check 1:

Worker is hungry

Worker is not busy

Action 1:

Set worker busy = true

Worker set FSM_look_for_food = true

Check 2:

Worker is tired

Worker is not busy

Action 2:

Set worker busy = true

Worker set FSM_look_for_place_to_sleep = true

Etc.

You can make the door on another layer above "Layer 0" or you can make a "If shadow is overlapping door" move to bottom of layer. That should fix it.

[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.

[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.

This is from a post I made a few days ago about the same thing, this is Ashleys answer to that:

https://www.scirra.com/forum/path-finding-no-slow-down_t116391

[quote:3vvfbhnk]The problem is pathfinding can take a moment to complete, in which time the object could move to a new cell, requiring a new path to be found from a new starting location... during which time the object could move to a new cell again, and so on.

If it's noticable, you probably need a larger cell size so paths are quicker to calculate.