I don't think this belong in the beginners section, it is not easy to answer I think.

And you would probably need Ashley to answer it correctly. Tried doing some tests but the more I tested the less sense the results made, and didn't produce anything that could answer your questions.

For instant it seems that if you create a image for 1 layout and destroy it straight away the memory is not freed up, which makes a bit of sense if you should need the object later. However if you switch layout some of the memory is freed but not all, even though there are no objects, but you can still make all the objects in your project, again could be because you can then make the objects, however it is still able to free up some. And what exactly are freed up I couldn't figure out.

You shouldn't have to keep track of the number of chests to make it work. Your idea of using pick nearest is the way to go as you can use this to pick the nearest, second nearest, third nearest and so on. However to do it you need some way to exclude chests from being picked as the nearest. Which you can do by using a variable "Interact_UID" for the chests.

So to make it work you could do something like this:

Set chest as target for character

Condition:

for each Character (We need the for each at top, as we want to make sure that chests picked by Chest.interact_UID = 0 gets updated for each Character)

Chest.Interact_UID = 0 (Means that no character have currently targeted the chest)

Pick nearest Chest to character

Action:

Set Chest.Interact_UID = Character.UID (Now the chest have been targeted by a character. And the interact_UID is set, so no other can select it.)

Get character to pick up chest

Condition:

Chest.Interact_UID > 0 (Its very unlikely that any of your characters have UID of 0 so this should work)

For each Chest

Pick Character UID = Chest.Interact_UID

Action:

Character (Move to Chest)

When the character arrives you just need to make it so its the correct character that picks it up. To do that best, depends on what type of movement you are using, Path finding, Per tick etc.

The best thing to do, if you need the characters to do a lot of different automatic actions is to make some kind of state machine if you don't already, otherwise you will most likely end up loosing control and have a very hard time getting characters to behave correctly.

You need to pass something to the function. Most likely the UID of the newly created crab.

So in:

Call "EnableCrabby" (Crabby.UID)

Same goes with the call to "CrabbyGO"

Also in the functions you need to pick the crab as well-

So "On "EnableCrabby" you have to add

Pick Crabby.UID = Function.Param(0)

Same goes in "CrabbyGo"

Otherwise the function don't know what crab it should work with and just pick all of them, and that's why they all behave the same.

Hello

i have been thinking about this since i started this project.

Can you please take a look at this? Fps looks fine but there are too many collisions.

http://i59.tinypic.com/2vmiz4z.png

12161 collisions in total and 248/tick. Isn't that too much or is this just normal?

poly checks 504 in total 10/tick

and numbers will roughly be doubled when im done with this project.

Do i need to worry about this and look for solutions or is that ok? <img src="{SMILIES_PATH}/icon_neutral.gif" alt=":|" title="Neutral">

Difficult to say what is normal, it depends on what content your game holds.

1 object needing collision detection against another object, will do 60 checks per sec and ~1/tick

So depending on how many objects and events you have that requires collision checks this number will increase.

An example:

1. Your player have path finding and on the screen you have 1 solid object and no events that need to check for collisions. Then you will have a collision check / sec of 0 and ~0/tick

2. Same as above but this time you have one event that checks for overlaps with the solid object, which would give you a collision check / sec of 60 and ~1/tick

3. Same as above but now you have 4 solid objects and 3 events that checks for collisions, which gives you 720 collision checks per sec and ~12/tick

So whether you have to many or not is hard to say, it depend on you having events that are not needed or to many objects on the screen that wouldn't need to be there. however as you can see from the last example, which doesn't really have a lot of collision objects or events the count is already at 720 checks per second. So 12000 checks is not a lot and in above example it can be achieved by increasing the number of solid objects to 20 and the event count to 5 as that would give you 12000 checks as well.

So if you have some enemies, a player some bullets etc that need collision detection the count will go up rather fast.

I don't think there are any different really. 50 images are 50 images. You could probably argue that making 50 individually images would have a bigger impact since it would have to take the objects into account, but I think that would be such a little impact that it would be a lot more efficient to just reduce the image size by 1 pixel.

Anyway not 100% sure, its just what I think

[quote:2o9onqn3]Then when overlap occures i compare the animation frames of the one on the background and the one dragged over. Is that the way to go?

Yeah that should work fine.

[quote:21iwyttg]1. How do I do ... a simple pathfinding?

For example: I have a "Game Over" screen where I want the "Game Over" sprite simply to move from one position (y coordinate) to the other (from below the screen to the middle). Some easing would also be nice.

At the moment I am either using the bullet behaviour on the object and set speed to zero if it reaches a certain point/coordinate, or to do a "simulate up" on that object.

However both methods seem fairly unsophisticated to me.

I don't think there are anything wrong in the way you do it, using path finding for this would be a bit "overkill" as it would be required to calculate a path there. But since you already know exactly where it is going and is going there each time, starting to calculate a path just doesn't make much sense.

It might be unsophisticated, but its a simple and effective way of doing it, there are no reason to make things more complicated than they need to be in my opinion, the simpler you can make something that works the better, as there are less chance of bugs and it will make you develop faster. And ain't that what is most important.

[quote:21iwyttg]2. How do I ... work with Layers correctly?

Same example as above: The game ends and I want to bring a "Game Over" Screen. I know I could make a Game Over - "Layout" for it however it feels better to me using "Layers" because first of all I don't want the music to stop and want the background to keep moving. It simply feels good I think, if a few things stay but just the layer changes.

That's why I make certain Layers (Game Elements, Player, Score etc.) invisible and another Layer (Game Over Screen) visible. But: Even though a layer is invisible you can still click on items in that layer. (for example you can still click the "invisible" Layer's Game elements). For a workaround I am now using global variables (game_element_layers = false, game_over_layer = true etc.).

But still that way doesn't seem so intelligent to me.

Making UIs are on the very top of things I don't like making, it takes a long time and is really boring And one of the reasons are as you mention, they require a lot of uninteresting coding.

I normally do somewhat like you, when creating layers, probably not as specific as you seem to do, but a normal structure for me is something like this:

Optional:

Depending on the game im making:

Collision (Will hold any collision elements that are invisible. And not part of an object in one of the other layers.)

Markers (If I want to make a more sophisticated building system where markers would be needed, then ill put them here)

4. UI (Will hold all UI elements that requires a parallax of 0)

3. Game high (Flying units, clouds, tree tops, and pretty much all objects that should give the impression of being above the player)

2. Game (All characters go here. Player and enemies a like, exception might be flying units and structures that the player can walk around in)

1. Game Low (All objects that needs to be on ground level, such as rocks, objects that can be collected, but in general objects that can be interacted with and ofc aint suppose to be above the player.)

0. Background (All background stuff, that normally cant be manipulated, exception might be Tilemaps, depending on the game)

But as you said you need some way of detecting whether something should be clickable or not. In your case you don't need a global variable you could just check whether the layer was visible or not. But in the end its pretty much the same, you need to check vs. something no matter what.

Please when you get the time could you take a look at my new setup, it does seem far more stable and easier to manage am I going in the right direction and any tips on a priority system?

https://www.dropbox.com/s/2g71o91svb1g6ld/ai-test.png?dl=0

Its quite hard to see if you are going in the right direction as I don't know your program, but if it works then I assume its fine. One thing that you might consider, unless you do it somewhere else, is in the function "Find area" to lock the area that a worker is moving to, I would imagine not doing that would at some point give you some conflicts with several workers trying to go to the same area.

So when a worker is found set "sm_need_worker = false" for the area.

Also in your for each events at the top, I would personally reorganize it a bit, here is an example:

I would also advise you to start commenting your things, at some point if you don't, you will loose control. And it makes it a lot easier for yourself to later go in an make changes down the line.

To further complicate things, C2 doesn't let you pick a newly created object until the next top level event, so that's getting in your way too. One trick is to put a "Wait 0" before your function call. This will suspend the call until the end of the event sheet and call it then, allowing the pick.

There shouldn't be any problems in this case, as its within the same scoop so passing the Casino object and picking the family object with it will work fine here.

Without the full code its hard to judge as I don't know exactly what your objects are, so its ofc a bit of a guessing

However it seems that you don't need "Rooms Roomtype>= 3" as you don't use it for anything, unless something requires it to be more or equal to 3?

There are some things you need to check:

1. You have to make sure that you don't have several ConstructionFloors that are equal to 3, otherwise you cant be sure what you pass to the function.

2. Is ConstructionFloor also part of Rooms family? if not then you cant use Param(0) to select it? In that case if Casino is part of the family, you can pass its UID as Param(1) and then select the Rooms using that instead.

Unless I misunderstood what you are after, there are not really anything you can do about it in this case. Whether you do it with a function or in the Timer trigger itself you will have to do it for each object, even though these might be part of the same family they ain't the same object meaning that Hotel and Casino are different objects, which you have to set individually. But you can do as you have done with calling a function to set the values as long as they are the same, if you don't want to look at so many actions. However to make your function work, you have change some things:

First you need to pick the ConstructionFloor object as well as the Rooms object.

And you have to change the way you pick to this:

Room Pick instance with UID Function.Param(0)

Since that is holding the UID that you pass to it in the call (Call "SetupRoom" (ConstructionFloor.UID <- This is Function.Param(0) since its the first parameter, the next parameter would be Function.Param(1) that's just the way it is, as C2 doesn't allow you to rename them.)

So in the Function SetupRoom you add these two lines instead of the one you have:

Room Pick instance with UID Function.Param(0)

ConstructionFloor Pick instance with UID Function.Param(0)

Then the function knows which elements you want to work with, and that should solve it for you.

The way you call the function itself is fine, you don't need to change that.

Maybe you can use the System -> "Is on platform" and check if its on "Android" or not and then switch it based on that. I have never used it my self as I only created stuff for desktops, so if it can solve it I don't know its just a guess

So then if you make it a small image (e.g. 32x32) and stretch it up as big as it needs to be, it won't use much memory either.

Never really thought about this taking less resources, but its actually quite a lot you can reduce it if you need collision sprites that are invisible and then just stretch the hell out of them. made a sprite with 150000x150000 and it only used est. 0.3 mb original size was 128, so good to know