That sprite is pretty good, it's easy on the eyes. Adding a fourth frame could make it a lot smoother though depending on what your goal is for that sprite.

I'm considering doing that, especially after seeing it in-game. It doesn't seem to read as well in motion as it does in a .gif.

Anyway, I *think* I've perfected my platform movement (well, as close to perfect as I'm gonna get). I took the default platform movement and fixed it so there's no skating or pogo-jumping. I added in detectors and pvt variable toggles so the engine could tell the difference between jumping, falling, standing, and running. There are a few other minor little tweaks as well just to smooth things out.

Here it is:

http://www.mediafire.com/?1mwz1drlmbz

Jump with Z. There's also a debug key (D) that toggles the detectors on and off so you can see them at work (not that there's much to look at when they're on).

As always, feedback is appreciated. Does he move to fast/slow? Is the jumping too high/short? Is the animation speed okay? Also, I encourage people to try to break it in case there are bugs I missed. (I know of one very minor bug that's hard to reproduce and doesn't really affect gameplay, but I'll keep it to myself in case no one catches it).

The next step is to start on the main gameplay feature, which is being able to change the solidity of different colored platforms.

This thread title is misleading... these are fruit in underwear! I want my money back.

Ah, I see. I suppose it would be handy to add movements to families as well as objects.

I know that Ashley's added private variable support for families in the latest build, so there is a workaround... perhaps you could re-write the engine to convert private variable information into force for individual objects? Kinda like:

[Throwable (Family)]

• Stone

• Box

• Other Stuff

[Stone (Pvt. Variables)]

• forceAdd

• selected

[Box (Pvt. Variables)]

• forceAdd

• selected

etc.

Then instead this (which is what you have now):

+ On Left Clicked on Stone
[ul]
	[li]Set 'selected' to 1[/li]
[/ul]
+ On Left mouse button Clicked
+ Value 'selected' equal to 1
[ul]
	[li]Set force 12000 toward (eye.X, eye.Y)[/li]
[/ul][/code:32qsmzjw]

You could do this:

[code:32qsmzjw]
+ On Left Clicked on familyThrowable
[ul]
	[li]Set 'selected' to 1[/li]
[/ul]
+ On Left mouse button Clicked
+ familyThrowable.Value('selected') equal to 1
[ul]
	[li]Set familyThrowable.Value('forceAdd') to 12000[/li]
[/ul]
+ Stone.Value('forceAdd') Greater than 0
[ul]
	[li]Set force Stone.Value('forceAdd') toward (eye.X, eye.Y)[/li]
	[li]Set Stone.Value('forceAdd') to 0[/li]
[/ul]
+ Box.Value('forceAdd') Greater than 0
[ul]
	[li]Set force Box.Value('forceAdd') toward (eye.X, eye.Y)[/li]
	[li]Set Box.Value('forceAdd') to 0[/li]
[/ul][/code:32qsmzjw]

Hope that makes sense.  Now get back to work! <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />

I wasn't trying to flame anyone, I'm sorry if it seemed that way.

Heres the problem, the link to the forum has "www." while the forum settings itself has no "www.", so the cookie is looking for the address without it, that needs fixing.

Wha...

I'm not on http:\\www.scirra.com\phpbb2 right now, it's just plain old http:\\scirra.com\phpbb2.

Ah, you know what? I totally missed the 3D part. Just skimmed right over it. Forget I said anything.

The short story: The 3D Box doesn't have collision detection, at least not the kind you're probably thinking of. Don't use the 3D box as a game object. It's for display only.

The long story: Okay, fine. You can use it as a game object, as long as you're clever about it. But I don't feel like typing the long story out (again). I've written up the 3D Box description a zillion times already.

Oh what the hell, I'll dig up a link for you...

Okay, here you go:

http://scirra.com/phpBB2/viewtopic.php?p=1406#1406

Anyway, if you want to do collision stuff with the 3D box, use a regular, invisible sprite as your collider. Perform all your game actions on the sprite instead of the box. Then just put in a "Always: 3DBox: Set position to object colliderSprite (image point 0)." Voil�. It looks just like you're manipulating a 3D Box directly, and nobody's the wiser.

For the overlapping:

The first method to fix overlapping is to not spawn a box if the place it's spawning in is already occupied with a box. You could use an invisible detector object to check for it, so if the detector blips in and finds that there's already a box there, it'll just not spawn another.

The second way to do it would be to pick one of the overlapped boxes and use a loop to move it 1 pixel away until it's no longer overlapping. You could try something like this:

+While 
+spriteBox overlaps spriteBox
-Set spriteBox.X to (spriteBox.X-1)
[/code:9brjfm87]

Can't really get anywhere on that one before the familys works perfectly. Haven't tried in a while thogh... do they work yet?

Uh, I dunno. What problems were you having with families? (Oh, and we should probably take this conversation over to your Abdulah thread... no need to hijack Hitman.)

Heh, sorry. Being long-winded is a bad habit of mine

I don't think I will develop again without this feature.

That's a little dramatic, don't you think? Why don't you just take responsibility for your backups? With any game project I have like thirty or forty versions sitting in a folder. I save new versions often just in case something bad does happen. It's best to err on the side of caution, that way when you do lose work (and it will happen) you've only lost a few minutes of work, rather than hours or days.

You know where the save button is. It's not Construct's fault you don't use it as often as you should.

Ah, I see.

Well, if you really want colliders at the edges of the screen then you would have to have them on a layer that matches the same x,y scroll rate as the layer your player sprites are on. This means that you will have to update your colliders x,y coordinates every cycle to match up with the scrolling screen. This can cause some buggy problems, though... if you manually set the x,y of a solid object like your screen barrier, then it's possible to move it into a position where it intersects with your player sprite. It would take a lot of tricky custom events to compensate for this.

If you're dead set on having barrier objects then you might do something like giving your barrier Bullet Movement. That way you can tell it to move towards where you need it on the screen rather than set it's x,y manually (it will still "push" solid objects rather than intersect with them). But even this method is getting rather complicated and convoluted for what you want to do.

The simplest, most efficient method would be to ditch the detectors altogether and use math. If you don't want your sprites to go half-way off the edge of the screen then make your edge collision condition look like this:

sprite.X Less than (ScrollXRight-numOfPixels)
[/code:2yo1b835]

This will check whether your sprite is inside the visible play area as compared to the right edge of the screen, where numOfPixels is the amount of space you want to leave at the edge.

If you want to check if it's in the play area as compared to the top edge, you'd do like so:

[code:2yo1b835]
sprite.Y Greater than (ScrollYTop+numOfPixels)
[/code:2yo1b835]

You can check your second player's location just as easily using x,y value comparisons, so there's really no need for the barrier objects.

Okay, I'm a little confused so let's see if I've got this right... you want to keep something from going offscreen, but you still want scrolling? Correct me if I'm wrong.

The best way to do it would be to check an object's x,y coordinates with the visible edges of the window. It's a quick value compare, which is much more efficient code-wise than setting up collision boxes. Any time you are able to do something with just math, it's a good idea to just work it out. Checking the edge boundaries is quicker than calculating collisions, and having no collision boxes at the edges means less objects.