Does anyone know how to make a puzzle like this?

Each shape can be placed anywhere on that area and has a magnet effect (it is attracted to that surface).
I know how to do the part with drag and drop but I don't know how to do with the positioning of the pieces.
For example: if I take the square first I can place it anywhere and if I put it near any edge, it sits exactly on that edge.

Thanks!

 

Add hidden object to determine correct position for every piece. If a piece player is dragging becomes close enough to it's hidden shadow brother then magnet it to.

 

This ^^.

Just to add, basically you comparing difference of positions, between piece and mentioned shadow.
Then you can use squared magnitude, to to determine snap.
Alternatively, without shadow GameObject, your piece can hold information about target position. So you end up with one piece object only. You will just need shape of socket, with all available pieces. It can be generate in fact, relatively easy.

If orientation is involved as well, you may need also take it into account.

 

Hello! Thanks for the answers.
I've seen some tutorials with this method. Sometimes it's good. But not all the time.
For example: the square can be placed anywhere in that area. It does not matter if it is positioned correctly; you can put it in any corner or even in the middle - it still has that magnet effect. And from what I've seen, all games like this are made this way.
I have a few months since I am still trying to figure out how they are made, but I'm not even close to the answer.

 

Still, the solution remains the same. Place hidden collider or anything what has bounds or even write your script for creating shadow bounds in the editor and check square against that bounds. You may create interface for shadow object script with only one method

Code (CSharp):

1. bool IsValidLocation(Piece piece);

And then make different shadow objects to implement different placement rules.

 

That's the method I've tried so far. I created for each shape a brother object and compared the position and rotation to these two. But what do I do in a situation like this?



There are many possible variants and all are correct.

 

So you should be able to see that the target grid is made up of squares, and each square is divided into 4 sections divided diagonally like this [X]. (In practice it's always 2 adjacent diagonal sections that are used together, but let's have the engine consider all 4 separately because it makes it easier.) So create a "cell" class with those 4 sections, and sprites representing each section; each cell will have the 4 sections enabled or disabled individually and will control the enabling of the sprites. The game pieces will have a similar setup, and the ability to compare itself to a cell to see if the cell "contains" the game-piece-cell.

The "magnet" effect, in this setup, is basically just snapping to grid. Then use the snapped position to determine which GamePieceCell aligns with which BoardCell. If the game pieces check themselves against the cell that will contain them and come back negative, then the snapping fails (the piece probably returns to its last position, or the "piece purgatory" area); if they all succeed, then it snaps.

Checking for completion just involves checking all BoardCells to see if all 4 of their sub-sections are filled by a sub-section of a GamePieceCell.

 

That's harder. Filling surface with predefined arbitrary pieces is complex and tricky mathematical problem. It is called tesselation, also known as mosaic. You need to precalculate all possible solutions or implement algorithm to check if current pieces positions forms a solution or not. Start here: https://en.wikipedia.org/wiki/Tessellation

If you assume all pieces are triangles or combinations of triangles, then solution becomes a little easier.

 

Yep, for rotation like cases, I would go with grid.
Divide into cells of the size, of smallest figure.
Such approach doesn't require complex mathematical rules.
Just checking relevant cells.

Each cell may contain none, square, one triangle, two triangles and rotation variation for last two.
Well, something like that, of top of my head.

 

Thanks for the reply.
I'm sure this is the solution used by those who make puzzles like this.
Unfortunately, my knowledge is quite limited. I try to learn by doing simple things but often what seems simple at first, proves to be quite complicated.
If you have a link with something like that it would be a great help.

 

Thanks for the idea. I didn't think of it as a mosaic. But I think it's a very good starting point. I'll check the link you recommended to me.

 

Thanks for the reply.
Can grids be used even if I have many types of "canvases" of different shapes?

 

I would just think of all puzzles starting off as the square grid, then with "locked" pieces added to the grid to give each puzzle its unique shape and problem. These locked pieces will define the shape that you need to fit your puzzle pieces into. All Canvases are the same shape, but having different sets of locked pieces will allow you to create non-square puzzles.

So taking the first image you posted as an example, the "vertical wallpaper" background is actually many locked and non-interactive pieces on the entire grid, but stitched together to look like one contiguous border piece. and they also occupy those grid locations to prevent pieces being dropped there.

 

Grid may be challenging, or even not an option(?) if you want allow cases like 3, 4, 5, 7, when right angles are rotated 45 degrees. The edges won't fit into the grid anymore. So that adds to design challenge.

I have no thought on the solution atm.

 

These games exist in reallife as well, so effectively we only want to mimic that behavior. What does this mean? We want to be able to create a target shape (often the "square container") with any shape we want. We want to be able to place puzzle pieces of any shape we want into that (potentially even organic looking, wavy pieces). We want to be able to freely place these objects. And we want the goal to be to place all puzzle pieces into the target shape, obviously without them overlapping. To do this, we should only need accurate collider representation of the puzzle pieces as well as the target shape. You can then mimic the desired behavior by implementing simple game rules for:

• Free movement: Let the user drag it where ever they want. For that, we only care about the center point of each shape right now. To prevent pixel-sized spaces between the shapes, i'd snap the pieces to reasonable values (does not even have to be a noticable snapping, just enough to prevent small spaces between fitting pieces).
• Placement rules: Only allow actually placing the piece if it's not overlapping. This goes for both; the target shape area (eg "square container"), as well as other puzzle pieces. This is where you need colliders, or some other way to accurately track their shape. In case they cant be placed, either mark them as such, for as long as the user is holding it but cannot place it, or snap it to the next best position as soon as the user lets go of the piece. The latter may be harder to implement, as well as potentially annoying to the user.
• Win condition: The player wins as soon as all X pieces are used up. Can be easily tracked by counting the amount of pieces successfully placed on the target shape at any given moment.

This should mimic the game as it is in reallife, while eliminating potential precision problems coming from the digital version. It should also allow for total freedom of the player, as well as the level and puzzle piece designs, because placement is free and the win condition relies on the amount of pieces only, as it does in the real version.

Hope this helps.

 

Hello!
Thanks for your reply and I'm sorry for responding so late.
Everything you said is correct but it still doesn't help me figure out how I can do what I want. I know these games exist in real life. From here comes my frustration. There are many people who make these games and I not only can not do them but I have no idea where to start. I am beginning to think that they cannot be realized in Unity.
Thanks to everyone for their involvement.

 

Why would that be? Unity is just a toolkit, making game development easier with C#. So everything C# can do, Unity can do. Which is.. everything, since C#, like most other programming languages, is turing-complete. So by definition, there is nothing you cannot do with Unity, even tho since Unity is a game engine, it's frame-based update/workflow may get in the way of some programs. In your case however, i dont see this being the case.

I did not do any tests for what i wrote, nor did i work with colliders a lot, but the only assumption i made for my post, was that we can have accurate collider representations of our shapes. Under that assumption, i divided the problem into 3 steps which you should be able to just implement in that order to get the finished product.
So your reply of being frustrated, Unity being unable to do this, or you having no idea where to start, kind of confuses me. Unless of course you did some tests on collider precision, and found that there is no way to make them accurate enough. But even then there would be lots of more complex solutions we could try, like for example if the shape can be described mathematically, then we could fake a collider, by casting rays though the outline of the object and seeing if there is more than 1 collision, meaning we overlapped with something.
TL;DR it's definitely doable, the question is just how simple or complex the solution needs to be.

 

OP problem is most likely lack of enough programming and math expertise. Therefore should really start simpler.

Make puzzle game without 45 degree rotations. Allow only 90 deg rotation. Or I would even go few steps back and try make basics puzzle game, without rotation at all.

Try that first. Learn some basics concepts. Make sure it works. Only then try implement 90 degree rotation.

Again, start from basics.

 

I was wrong. I'm sure this game can be done with Unity.
I'll start with the basics.
Thank you all!