Help With Puzzle Game

I've been searching few about a week around and haven't had any luck finding anything on puzzle games with construct. I'm familiar with the basics of Construct and have made a break-out clone and a platformer and now want to try my hand at a puzzle game, but i need some help jumping off because I just cannot think of how to get started. Basically I'd just like to populate a 320x480 gameboard with blocks 32x32, 4 different colors, randomly each time.

For now I'm just trying to get a basic engine in place, build initial board and cause blocks to fill in to spots that are not occupied while I finish nailing down the concept so this isn't another bejeweled clone. But I'd honestly be happy if someone could help point me in the right direction to get started just filling in the board the first time. I feel dumb, but there's just some concept I'm missing and I'm just drawing a complete blank over how to begin.

I'll attach a sample .cap of just a blank board with 4 different color blocks in case it'd be easier to show by example. PuzzleFudge.cap

Thanks a ton in advance, loving Construct a ton.

Well, there's one Construct puzzle game I know about, since it's my own.

You can check it out here and this is the thread.

I guess there should be stuff in there that might interest you. There's no source I'm afraid, but I may be able to help you out with particular problems you're having.

Yeah I played your game over the weekend. It came out well. I tried a bunch of different things to produce random sprites on the board but I can't seem to find any event actions that will create a random sprite so I'm not sure how to even get it rolling. essentially I'd like it to start off similar to yours, though I'm thinking of having it fill up slower from the bottom (similar to how collapse does) rather than all at once.

Is yours filled in procedurally or is some sort of place holder object replaced with a random skull color?

Can't believe this idea eluded me but would the way to do it to put each color as a separate frame of animation then tell it to change all of the blocks to a random frame number on layout start and for each subsequent one created?

I can't test this now as I'm at work, I'll throw it together when I get home.

Can't believe this idea eluded me but would the way to do it to put each color as a separate frame of animation then tell it to change all of the blocks to a random frame number on layout start and for each subsequent one created

Indeed this is how it works. Do it with different frames or animations if needed.

Awesome, thanks, I'm glad that worked. Also I can't believe all the random weird events I left in my .cap that I meant to leave blank. oops.

I got the random frame number to work, now to figure out how to call a random animation, only way I can think to is to assign a private variable, have it pick that at random and assign different values to different animations, ie if x=1 set animation to blueShine if x=2 set animation to redShine etc...

You're thinking too complicated... just name your animations 0, 1, 2, 3... and so on. Then use an event that sets the animation to random(4) for example, if you have the animations mentioned 0-3.

That will do.

you're right, I was just about to post, what I said worked, but it seemed convoluted and was wondering if there was an simpler way.

Ok next step, make the blocks swappable and able to fill in open space. I'm thinking of setting it up to function a bit like puzzle league, or henry hatsworth in terms of movement mechanics at least for the time being until we come up with what will make it unique. Thanks for the help. I'm sure I'll have a bunch more questions as I get deeper into this.

Here's an updated .cap with the random colors and animations, 2 animations, each with 4 colors, each block is filled in with a random color from a random tile. PuzzleFudge-01.cap

Ok, so I managed to get a clean way of swapping tiles so the next thing is to cause tiles to fall and fill in if there isn't a tile below them. I've tried a ton of ways and keep getting very unpredictable results.

Best, though messy, way I came up with involves setting a variable to either 0 or 1. 1 if it does not overlap another box (tried with and without offset, identical results). If it is overlapping at offset of (0,3) set to 0. If it's 1 move vertically 1.

Obviously this is way messy and over-complicated. Also it's broken. The offset doesn't seem to recognize positive/negative, so it only falls if there's a gap both below and above.

The use of a variable seems redundant, but if I don't use it, nothing happens. The same conditions that set it to 0 or 1 don't do anything when just told to move the tiles.

I'd really really appreciate some help.

The .cap

Try to make it work with a private variable. No overlaps needed here. When you destroy a sprite you add to that value for all sprites in the same column.

For example three sprites are destroyed in a column, the above sprites would have to move three fields down. For each destroyed you add 1 to the PV for the sprites in the same column which are above the destroyed ones (compare X position for same column and check Y to see if it's above).

Now you could have an event that runs for each sprite with a PV greater than 0 that tells the sprites to move PV * field size pixels down. That's my basic concept at least. Hope it's helpful to you.

Thanks for the reply.

Would that method work if my board isn't full? The general plan right now is to not have the board totally full and have it fill continuously from the bottom so you can essentially drop pieces down columns that aren't full to match either vertically or horizontally trying not to let any pieces leave from the top.

Would that method work if my board isn't full?

I don't see why it wouldn't. It should work in any case.

If I'm not destroying sprites to add to the PV I'm not sure how I would set it up initially since it's not so much the ones already in the column that need to move but the ones you're moving to it.

If you run the cap I attached you'll see that the pieces I left free floating will fall to fill in below unless they are touching one above them or below them. Obviously falling until there's one below it is correct, but 'sticking' to one above it is broke.

Controls btw are arrows to move the cursor (I put a shortcut in allowing you to click boxes to jump the cursor there for testing sake) space switches the tiles or moves one into an empty space horizontally.

Oh, checking for overlap of the same kind of object like you did doesn't work properly. You know about the old 2 families trick? Add 2 families to an object, then check for overlap between the two. Still I wouldn't advice you to use this overlap method here, although it might suit after all.

You could still use the method I described. Some sort of playfield loop was my first idea, to check if there is a block at each possible field position and if there isn't, it will add 1 to the mentioned PV again. Maybe I can come up with something more intuitive when I think a moment about it.

Ah, that's why I was getting such unpredictable results. I don't know that trick, this is only the 3rd thing I've done in Construct so there's still a lot of things I'm learning in terms of tackling specific problems. But I'll have to give that a try. Wish I could put it on my computer at work.

I'm having a bit of a hard time wrapping my head around translating your PV method to work with the specific mechanic I want. I'm sure I'll see it better once I can try it, I do better when I can trial and error things.

I appreciate all your help.