Design Match three - design theory

NightFrost

Member
So I've been building generic match three mechanism for some days now, and it got me thinking... does anyone know if someone has done the maths on these? How many different kinds of objects can the field have (jewels, candies, whathaveyou) before it is possible for the game state to devolve into a no-win pattern where there are no valid moves left? Obviously with just two types, there's only one possible initial pattern (a chessboard) and all moves except corners generate a match ad infinitum. I can see the size of the board affecting how quickly a no-win pattern is reached. And if player is allowed to move the object as far as they please instead of just a single grid cell, it should significantly reduce the chances. Basically, I'm wanting to avoid a situation where I have to write code that can verify the board is in unwinnable state... but I may have to.

As an aside, I went with a design decision where player is able to freely drag an element around with mouse, but I've now realized it causes the most work. In a system where player would simply tell the element to switch places, the flow could be broken into discrete phases following each other; issue command - animate move - check matches - either destroy elements and award score, or push elements back to original positions. With free dragging the match checking phase starts as soon as player releases the mouse button, which might happen in the middle of elements animating to their positions. They need to snap to their destinations and get destoyed if there is a match, or reverse their motion back to their origins otherwise. Or to put it in short... if you're doing a match-three system, you may want to avoid having a free drag control.
 

FrostyCat

Redemption Seeker
Explain to me what's so infeasible about verifying a board's viability that you make it an ultimate goal to avoid writing it.

Here's a hint: If you are basing your engine's data model entirely on the placement of instances, it's that you should be avoiding, not the algorithm for verifying a board state's viability.
 

NightFrost

Member
Oh, because I don't realle believe in writing code until it becomes necessary. At its bottom there's the idea that the field should not devolve into a no-win situation. If I want to use the match-three as some game mechanic, like combat (ie You Must Build a Boat) having the field lock up in the middle of a run would be a Bad Thing. Especially with player having only minor control over that (refills being random). [I don't know how they avoid it. Maybe they've crunched the numbers and know their arrangement can't lock up. Maybe they cross fingers and hope rng is always on their side. Maybe they plain cheat and babysit the player.]

The board itself is based on a master grid that updates on every event that changes the layout. Items on the board derive their origin positions from it and also have a switch position in case a player-dragged item forces them to another grid cell (becoming their new origin if the move is valid). Coordinates are considered a visual property to animate changes in location. A grid can be looped quickly to find matches, it would be much more involved process in the instances' step events as it is essentially a random order, so it is not worth it. Especially when one considers longer matches must also be found. Grid also makes managing falling items easy as their destinations can be marked the moment they start falling, and switched if more openings appear while they fall.
 

FrostyCat

Redemption Seeker
[I don't know how they avoid it. Maybe they've crunched the numbers and know their arrangement can't lock up. Maybe they cross fingers and hope rng is always on their side. Maybe they plain cheat and babysit the player.]
They usually avoid it by generating initial board states as a data structure and calling a function that checks the board's viability, repeating until the generated state is viable. Only then do they generate the "gems" on-screen.
 

NightFrost

Member
I guess I should have explained more clearly; I was referring to the long-term viability of the board, how they avoid the player driving it into a state where there are no valid moves. Either the system is built in a manner it can never happen (which would be my preferred goal), it is hoped it never happens, or the new drop-ins are ""randomly"" generated to make sure there is a valid move on the board.
 
S

Storyteller

Guest
for a simple improvement, when you generate your random refill pieces, weight that based on statistics, ie, how many of each tile type are left.
for surety, examine the upper rows of your grid. when you randomly refill, force one to be a horizontal or vertical move to create a 3pt match. this ensures you always have 'at least one move' even if cheap. you can improve that by only supplying a 'certain match' if you scan the grid and find now matches. \
in the end, you probably want a board verification script, but I listed a few tips you could use that fall short of that in the meantime.
consider this before moving, in a chain match where you clear many groups, (like if you clear 3 and a tile falls to make another match) do all of them clear and then refill, or refill between each matched group?
answering that might help you pick how you want to proceed.
 

NightFrost

Member
Yeah I managed to find some good keywords for google search and found some discussion on the board lockout topic. Some mitigation / solution techniques mentioned were "joker card" item spawn that can match with any other, allowing removal of items from locked board, letting to re-randomize a locked board, refilling only with items that exist on board so matches are more likely, and plain refilling with matches or near matches when the board is nearly locked up. I guess if I wanted to cut most corners I'd always make available a button to re-randomize the board at the cost of some game resource, making the "board is locked up or might be locked up" a player decision instead of a hard fact.

My current test build has refills starting to drop in as soon as there's room available. I've noticed if there's large chains it makes it bit hard to follow (and fall speed is probably too high) so I may test delaying refills until all chains are done with. But the exact mechanic to use would also depend on gameplay. If player just has turns to spend they might not care, but if they're against a clock they might not appreciate the forced delay.
 

Yal

šŸ§ *penguin noises*
GMC Elder
but if they're against a clock they might not appreciate the forced delay.
Feh, you'd halt the game (and the clock) until you've verified the board, and even then it shouldn't take enough time that a slow creature like a human would notice anyway.

...oh, you're on fall speed now? My bad. I'd still advocate the "only count down game time when the player is actually able to gameplay" strategy, though: the clock should be paused during effect time, and only tick when the player has agency.
 
Top