You can see where I am go with this. "Construct TBS" is on its way.

Haven't seen anyone doing TBS yet. Looking forward to this!

<img src="http://img204.imageshack.us/img204/5898/puzzlefudgemockup00.png">

tile sliding puzzle game that's filled from bottom.

<img src="http://img442.imageshack.us/img442/2046/shmupmockup00.png">

shmup done with gameboy res.

Awesome pixels you got there mattdubs! And that shmup looks mighty fine!

I guess it has to do with different graphics cards.

Yes, it's a graphics card/driver issue. On my older computer with geforce 6600gt it does the bad bad blur thing, but on my newer one with ati 3870 it looks perfectly crisp!

Oh the window object... another thing I never used, although it's so useful.

Unfortunately I get blurred little kitties here when resizing, while simple zoom 200,200 is still sharp. I take it that doesn't happen for you guys?

Just a little heads up here mattdubs...

I got my own puzzle engine up and running again, complete with field generation, matching block recognition, destroying and spawning of new ones to fill up the gaps. It's made much smarter than the old version, using no detectors or any of the old stuff which I refer to as "MMF-style" sometimes. Although I'm pretty sure it could still be improved upon a lot, with smarter usage of certain objects. But I'm quite happy already in using an array, even if it's just to a pretty limited extent.

It basically uses the same principle as the stuff I put in your cap. But there's one major flaw with that version, since it only works properly while the playfield is full of blocks. So it doesn't recognize gaps which will cause problems, matching blocks wrongly. Just wanted to let you know, because I was confused about it for a sec myself when I realized it didn't work quite right just yet. Maybe you figured it out already or made your own different engine, I don't know. But if you're having trouble with the gap recognition, let me know. It's just a minor change to those events.

It's being asked all the time in one form or another. Should be sticky somewhere or something I don't know.

Add another family to your Spider sprite. Now check for overlap between those two families instead of using the sprite itself and one family. Should work like a charm now.

So your events could look like this (while Vermin is the new family):

[Condition]When Bugs Life=0:[Action] Destroy Bugs

[Sub-condition]If Bugs overlaps Vermin:[Action] spawn Splatter

> Can't you simply have one global mousekeyboard on the first layout?

>

It's practically the same thing, I just prefer to copy paste it so it appears on all layout event sheets. Global just means it doesn't destroy when the layout changes, so copy pasting has the same advantage, only you can access the copies of it from anywhere where they exist. It doesn't really make a difference, I just like it more that way.

Agreed. I also handle my mousekeyboard object that way.

Oh dang it! I was actually using the Compare function lol. Thanks Again!!!!!!!

Haha, I remember doing exactly the same thing when I was new to Constuct.

EDIT: While trying to fix it by myself, I forgot how to validate the global gender variable if its 0 or 1 which can be found in the Hero Movement Event sheet. The old one was using the private variable "gender" of the "player" object. I basically don't know how to do the same using global variables.

SO howz thou does it?

Well, instead of

Sprite: Value 'gender' Equal to X

+do stuff

use

System: Is global variable 'gender' Equal to X

+do stuff

Look for the condition "Compare global variable" in System.

The only globals I think I have are the objects found in the Object Manager layout.

Those don't need to be global in the first place! But the most messed up stuff is in your character selection, which is responsible for most problems. The objects femaledata + maledata are both global too, plus they have freaking RTS movement assigned to them. So do your player sprites in that layout. And this messes things up A LOT. Took me more than half an hour to figure this out, so you owe me now!

So at the very least do the following to fix things:

1. Remove the global attribute of basically all the sprites that have it!

• male + female + player circle in the Object Manager layout

-femaledata + maledate in the CharSelect layout

2. Remove unnecessary RTS behaviors:

• femaledata + maledata + femalepersona + malepersona in the CharSelect layout

3. Use a global for gender selection. A global variable that is!

You'll have to change some events around for this of course in the Hero Movement event sheet. Also change the spawning which I mentioned in my earlier post.

4. Delete all MouseKeyboad objects which are not named "GlobalMouseKeyboard".

Remove the global attribute of your control object GlobalMouseKeyboard. Copy it to all layouts where it isn't already located. Remove all events you can find that are spawning GlobalMouseKeyboard objects!!!

5. You will still need to change a few events around for this stuff to work properly. I believe some events in the CharSelect sheet use different MouseKeyboard objects.

After I did all this, the game worked as intended... finally.

You're already trying to take on a little bigger project it seems.

Anyway, there's some stuff not quite right. Like in your Hero Movement event sheet you keep spawning player characters all the time. This should only be done at Start of layout. Also you don't need to set everything to global. Like the player and all. Just use Globals (global values) for the stuff that need to be carried over to the next layout, like gender, hp, xp and such.

And the worst: get rid of all the different MouseKeyboard objects. Use one and simply copy it to all layouts it's needed. And don't keep spawning additional objects in the GeneralKeys event sheet. Why would you do that?

The way you have it with different events using different control objects and what not, it's all becoming pretty messy.

Even with only the change in the Hero movement sheet I mentioned before, your layouts work as intended when run separately. The whole game still messes up. Probably due to the whole MouseKeyboard object mess I assume. I'd really really fix that issue first!

I'm sure both our techniques are fine, I was kidding, man.

It didn't strike me as dead serious, due to the amount of smilies used. There's one again.

Still why did you reply faster than I did? Don't do that again!

Yey! Thanks for the help guys, that was quick. Amazing!!

No prob. As long as the questions are simple enough for my brain, I will always try to help out, hehe. And many other users do the same thing. You did know this community rocked?

Don't forget about the line object, the gradient object, the tiled bg object, the box object.......

Indeed. Wasn't there something in the Uploads section with many different healthbar examples?

Pfft, my way is better, no need for a fixed original width.

Your talking about the Maxwidth value of the healthbar?

Just set it on start of layout to the width, so you don't have to reenter the value if you change it in the layout.

And how exactly does your example help with the bar slowly resizing?

I quickly made a little example for you: Download