> in my rebuttal i would like to point out that even after penile shrinkage, measuring with the metric measurement system will yield a greater, more impressive number compared to the imperial measurement system

>

Hmmm. Maybe you have a point. 19 centimeters does sound more impressive...

(that wasn't over the line, was it? )

Oh brother

You're making an isometric game using the physics?

I... I can't even imagine how that would work.

It looks more smokey than watery to me. It doesn't billow like smoke, but then again it doesn't wave or ripple like water either.

It's still a really cool looking effect regardless.

since we sweeds aren't spoiled with 30 degrees all the year around its hard to stay away from the beach!

At first I thought "spoiled? What the..." Then I remembered you must be using celsius, or centigrade, or whatever. Metric, I dunno. At any rate, 30 degrees here in America is below freezing

Agreed. In any physics puzzle game there has to be a certain degree of "forgiveness" designed into the puzzle to allow for randomness. There might be a "perfect" or "optimal" way to complete the puzzle, but there should be some small amount of leeway on either side of that line. Just try to incorporate that into the design and you'll be fine.

It's like when Jeff Goldblum is flirting with that chick in Jurassic Park... dripping water down her hand, and explaining that it will never follow the exact same path. Chaos Theory, man.

What was the reply?

I wish you luck in your project, but I'm afraid I'm not looking to get into a collaboration right now. Not to mention I haven't used Construct in a couple months and I'm rather behind on new features and bugfixes and such.

Hmm... well, mine says "1 new message" right now, so I don't know what's up there. I'll check it and see.

Edit:

Welp, it was the reply from you, Ash. "Yep, it worked!" And now it says "0 new messages" again.

Is it a problem maybe with the board themes not displaying the number of PM's correctly? I'm using Czar Green and it seems to work for me. I dunno... just a guess.

The reason I say it's inefficient to pass all the level data though an array every cycle is because once the level is loaded you don't really need the array to keep track of walls and floors and such any more. The array is like a blueprint... but once the building is built you don't need to reference the blueprint to walk around in it... you have real-world walls and floors to see and navigate through.

Imagine the building is your house, and you need to go to the bathroom. Instead of looking down the hall and moving toward the bathroom door, you're looking at the blueprint of your house. Every step you take, you have the contractors tear down your house and build a whole new house around you. As fast as those contractors might be, they really don't need to be doing that, and you don't really need to be looking at your blueprint.

So toss the blueprint and just walk to the bathroom on your own.

As for enemies keeping track of the player position and obstacles, you can give each of them a "mini-array." Let's assume, in a grid-based system where each enemy can move one space, that there are nine choices an enemy can make when moving: One of eight spaces surrounding it, or the space it's currently standing on (i.e., do not move). You only need a 3x3 array to cover all movement options. So you run your algorithm to pick the space to move to, and then go on to the next part of the selection, which is checking for obstacles...

Your enemy has a target space that it wants to move to, so it runs a quick check to see if there is a real-world, physical wall in the way. If there is, do not move (or move to the second best space, etc.). If there isn't, then move to the target space.

Using a mini array like this is much more efficient that keeping track of the entire playing field, and what's better is it's recyclable. You can clear the array and reuse it for each enemy during the enemy AI routine. Once they have their final target coordinates stored in a pvt variable or whatever, they don't need to reference the array any more. The engine moves on to the movement routine, checks the coord stored for them, and just places them there.

I know it's not the example you were looking for, and it might not be exactly suited to your purposes, but maybe it'll give you some ideas on how you can craft your own AI/movement. Hope this helps.

Edit:

Er, yeah. What Ashley said.

I replied to a PM from SuperV a few days ago and learned today that he never received it. I tried sending it two more times and it doesn't show up in the "Sent Items" box, it just sits in my Outbox.

Ashley, I also tried sending a PM to you about the problem but, ironically enough, I don't think it went through...

1 use the objects action "set animation speed"

You can also set the default speed from the IDE by clicking the animation you want to change and then setting it's speed in the properties window.

Also, how can I render my array with sprites? Rendering the player is easy, but what about walls and stuff? Won't there be a delay rendering every cell?

Arrays (in this kind of situation) are usually just used for level loading and saving... the array is called on to load the level, then the array just sits there and does nothing until it's needed again (for instance, to load the next level, to save the level, etc.). Game-play functions usually aren't passed through an array like that in the main game loop. I'm curious as to why you would need to do that. Is this a grid-based movement type of game? If so you should separate the array level-loader/saver and the grid movement.

'Pick by evaluate' checks the expression for every object, and picks it if the expression is not zero.

You can use the OR and AND expression operators to do advanced picking, for example:

Pick by evaluate (Sprite.X < 500) AND (Sprite.Y < 500 OR Sprite('Flag') = 1)

That's a very handy feature.