# Random tiling with a path?

Get help using Construct 2

### » Tue Apr 23, 2013 12:24 am

@Excal

Maybe you can run the maze algo more than once to create 2 or 3 different path before generating the entire map the way I did it.
B
69
S
22
G
14
Posts: 1,488
Reputation: 16,594

### » Tue Apr 23, 2013 9:08 am

@Yann, so many globals in the example that it bothers me :P

When the maze function is called, the maze array is cleared and then the vector array is created. Would I need to clear this vector array if I intend to run the maze function multiple times? There is no 'clear direction array' in the vector function. Would I need to create a second vector list?Excal2013-04-23 09:34:03
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,234

### » Tue Apr 23, 2013 2:59 pm

@Excal
Four of the globals are semantic constant use every where. (well the EMPTY and WALL are just used for the Maze Generation part so you could put them in local constant in this group if you really want)
There shouldn't be any issue with them, and I found out that they were more helpfull in global scope than in local. If you were to define the same constant at other places you wouldn't be sure of if they have the same value or not. I think local constant can lead to confusion.

Now the 3 other constant (WIDTH,HEIGHT and DENSITY) are parameters for the whole algorithm. Soooo I think they have their place on global scope as well.

As far as the runtime variable, generating is a kind of global state of the algorithm so well.. makes sense to be global, and for the three last, if I could initialize them with an expression as it's possible in C they would also be constant.

So yeah as much as I would agree with you that too much globals is bad because of global namespace cluttering and overall incertainty (which doesn't exist with constant). I think these ones are justified.

Now as far as the vector list is concerned, you could actually put the function on start of layout.
The vector list is just a look-up table of the four possible directions you can travel in the maze.
It looks like:[code]Array.At(0,0) = 1
Array.At(0,1) = 0
Array.At(1,0) = 0
Array.At(1,1) = 1
Array.At(2,0) = -1
Array.At(2,1) = 0
Array.At(3,0) = 0
Array.At(3,1) = -1[/code]

This way can just represent a direction by a number (the X index of the array)
For instance going West is the #2 direction.
It's the same as goint X + Array.At(2,0), Y + Array.At(2,1)

If you look at the dig function, you have a local variable named choice with the four direction represented in a string. I should one of this number at random and then remove it, and run the dig function on this direction recursively.
Since the variable is local the list is rebuilt automagically for each new cell you travel.

So for a clear and simple answer, no, you don't need to create other vector list, it's not something that gets modified (which you could create constant array :D)
Also, placing the createVectorList call in start of layout would make more sense (:

Hope I was clear.

Edit: you can redownload my capx, I implemented multiple steps (another constant to control how many)Yann2013-04-23 15:24:38
B
69
S
22
G
14
Posts: 1,488
Reputation: 16,594

### » Wed Apr 24, 2013 5:59 am

@Yann

This makes more sense, thanks!

I've tried to edit your .capx to account for the cellsize I wanted (64x64), but now it seems broken. I also removed the mouse-clicking for spawning the Start and End, and instead just had them placed automatically.

Can you take a look?

BoardGame.capx
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,234

### » Wed Apr 24, 2013 8:39 pm

@Excal
You have a mix of face palm error, object/project settings error and some arithmetical errors

The face palm error is the fact that the GridTiles layer isn't transparent.
So you don't see what is created on Layer 0.

The object settings error is that you don't have the same Cell Size value in your finder in your ObjectDump and in your Gameplay Layouts. It does not necessarily cause the bug, but well... better safe than sorry (:
The project setting error is that you have a layout width which is not a multiple of 64, so it doesn't look good

The arithmetical ones are where you position your end point, and is a bit bound to the layout width error and some wrong calculation
You try to place the end sprite at floor(WIDTH/cellSize)*cellSize which in fact put it out of the layout. The proper formula would be (floor(WIDTH/cellSize)-1)*cellSize
Also since the origin is at the center of the sprite, you have to offset it to half cellSize.
So the proper formula would be:
X = (floor(WIDTH/cellSize) - 0.5) * cellSize
Y = (floor(WIDTH/cellSize) - 0.5) * cellSize

Oh and also I think you were generating the maze constantly... soooo

Excal-RandomPath.capx
Last edited by Yann on Sun Sep 14, 2014 7:17 pm, edited 1 time in total.
B
69
S
22
G
14
Posts: 1,488
Reputation: 16,594

### » Thu Apr 25, 2013 5:04 am

@Yann, thanks for the fix.

And yeah, that was a pretty face-palm error, haha.

About the cell size error, so many globals and different numbers everywhere (I'm trying to keep track of all this in my head), sometimes I forget to update something!

I did the formula for placing startsprite and endsprite very late at night, but now I see what you mean.

And yeah, I figured I was creating an infinite loop when I saw nothing but gray on my screen ;)
Project Lead of Zems Online Card Game

Producer at Impulse Limited
B
18
S
6
G
3
Posts: 677
Reputation: 5,234

### » Thu Apr 25, 2013 6:01 am

Why don't you just make a snake? Start at a random vertical position at the left, and "snake" randomly to the right, then store the coordinates into a 2D array. When done you simply randomize the parts of the array NOT updated, then voila! ;)
Jack of all trades, and master of some.
B
31
S
10
G
7
Posts: 176
Reputation: 7,806

### » Thu Apr 25, 2013 12:17 pm

@JoyfulDreamer

That was my first idea actually, but you have to constantly check that your next random step would still allow you to reach the goal. So you basically have to pathfind for each step.
Unless you decide to just allo the snake to bit its tail.
But than how much iteration until you'll really reach the goal?...

I found that using a maze algo, it creates interesting looking random path and that you always end up with something valid.
B
69
S
22
G
14
Posts: 1,488
Reputation: 16,594

### » Thu Apr 25, 2013 8:29 pm

Well, the number if iterations wouldn't be more than the number of blocks you need to write to, so not much different. ;) Maze algos might be better, but not necessarily faster. You have to backup usually (retrace steps) to find a new open slot and continue (or at least store the most recent one found and return to it). He didn't want a "maze" in his original post, and as per his request, so that's why I suggested it. ;)

@Excal - it really depends on the type of path you want, and if the ending path must land in a specific position.JoyfulDreamer2013-04-25 20:32:33
Jack of all trades, and master of some.
B
31
S
10
G
7
Posts: 176
Reputation: 7,806

### » Thu Apr 25, 2013 11:59 pm

@JoyfulDreamer

Yeah that's a valid way, I don't deny it. But the "asynchronousity" of the pathfinder makes it a bit of a pain to implement.
(I think even the map generation is asynchronous and there's no trigger for that... might have to request that)

And as far as speed goes, he only does that on start of layout it seems. So.. it should be ok as long as he doesn't have more than maybe 2000 grid cell (since I used recursivity, you might stack overflow)
B
69
S
22
G
14
Posts: 1,488
Reputation: 16,594

PreviousNext