lag and getting around using collisions with physics

TraXsiv2

Hello. I am making a game with blocks that stack up using gravity and collisions. There are 8 columns and 10 rows which these blocks stack up in. I am noticing a good amount of lag. My objects (blocks) move down by using gravity so if a block below them gets destroyed, the blocks above all move down. My question is, is there a way to get around this by not using physics, gravity, and collisions.

I was thinking of having each block move down going a constant speed checking if there is any object 1 pixel below them. If there was. its speed would be set to 0. Otherwise speed would be set to the original speed. <-- Is there a way to do this

Thanks

firemaplegames

Unfortunately, making puzzle games is a little tough at the moment with GameSalad. You don't have Arrays to easily keep track of data.

Like you said, having 80 objects with physics, collisions, etc. is very taxing on the processor.

Instead of gravity, try using Interpolate to move the blocks down a certain amount. That way you don't need gravity or physics.

However, even with Interpolate, you are still going to have a real tough time keeping track of a grid of 80 objects.

Just beware...

TraXsiv2

I'm sort of confused how interpolate works and how I would use it in my situation. Thanks for the help btw. Also do you know about the "My Behaviors" folder under behaviors

JackBQuick

I've made a demo here for you:

http://gamesalad.com/game/play/58713

I have fewer blocks but the idea is the same.

(I'm assuming that the blocks begin in stacks at the beginning. Perhaps you don't mean for them to be.)

You have 80 blocks. You know the X and Y coordinate of each.

You only need one actor for the demo that I provided. Each block on the scene is an instance of the same actor.

When a block is touched, save its X and Y coordinates to global attributes (let's call them X1 and Y1) before destroying it.

Compare each block's X and Y values to the global attributes X1 and Y1.

If X = X1 and Y > Y1, then interpolate by decreasing the Y value by the height of the block. (Translation: all the blocks above it fall down.)

That's the general idea; the reality is just a tiny bit more complicated, involving timers. You can download the template to examine in greater detail what I've done.

I hope this helps. Cheers!

jmp909

Interpolate is a tween over time. and easing makes the movement more natural

say if your sprite is at (100,10) and you want to move to (200,10) in 2 seconds, then you interpolate self.x to 200 over 2 seconds,... if you use ease in/out then it'll accelerate slightly and then decelerate again. otherwise it'll go at a constant speed all the way.

this is different to the "Move To" command which doesn't let you specify how long you want it to take, it only lets you specify speed

as for "my behaviors" you can drag rules/groups within a project into them, but not between projects necessarily. I also found problems when referencing self when dragging a rule back into a different type of actor (because i think it actually references eg Actor1.whatever not self.whatever even though it says self.whatever... I am not sure of this, maybe admin can confirm)

However if you're giving instances similar rules, (as opposed to prototype rules) it's a good starting point to get the same base behaviour. (I use it on my Map Scrolling example where each scene needs to have a slightly different camera controller but the core functionality is mainly the same. I can't put the behavior on the prototype because it doesnt have access to the camera then. So I drag the rule (which is made up of about 10 individual rules) from "my behaviors" to each instance then modify a few parameters.

TraXsiv2

Thank you everyone! This helped alot

Having a problem downloading the example though

JackBQuick

@TraXsiv2 - You might have been trying to download as I was trying to upload updates. If you are able to download the demo, you can replace my image with yours. I would delete all the instances on the scene and then repopulate. You can place each actor using their X and Y coordinates for accuracy.

A few caveats:

- Although this works well with the number of actors I have, I don't know how it would work with 80 blocks. The more blocks, the more rules to evaluate; the more rules to evaluate, the more that timing and memory become an issue. You should still give it a try though.

- If you have 10 rows, you will want to change the amount to decrease from 80 to maybe 32 (or the height of your blocks).

- You might want to ensure that you can only destroy one block at a time. If you click on a block before the previous column finishes falling, that might cause some problems.

In your original questions, you asked whether there was an alternative to using gravity and collisions. This is one alternative but it might not be the best solution.

Please let us know your results. I'll be on the forums less frequently this week -- busy week -- but I'm curious about how successful this method is.