Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1396047 Posts in 67331 Topics- by 60471 Members - Latest Member: AloftDev

October 21, 2021, 08:31:45 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Tile/Map-Based Game Techniques: Handling Terrain Transitions
Pages: 1 2 3 [4]
Print
Author Topic: Tile/Map-Based Game Techniques: Handling Terrain Transitions  (Read 63409 times)
Sqorgar
Level 0
**


View Profile
« Reply #60 on: July 15, 2013, 07:01:59 PM »

hmmmm I have to agree. I did get a dungeon layout working once, but the result was just a little boring. Too predictable and a bit odd. It might need a lot more effort / skill to get things to work properly. The best option is probably to link together prefab rooms. However I persevere as:
1/ it's kinda fun
2/ the tiled layouts are pretty
3/ a breakthrough making all worthwhile might just happen  Grin
I don't think it is impossible to create something through randomly occurring patterns. I think the trick is to identify the patterns after the fact. A sort of "oh, I have pattern X followed by pattern Y, and these are the seven different things I can do with that". If you identify enough patterns and do something smart with them, you can create something unpredictable and surprising. Something you might consider is to use agents to go in and modify the level towards specific goals, using the initial patterns as a sort of guideline rather than the end result itself.

I've, personally, never approached it that way because I'm a top down sort of guy. I want to be able to say the player is going to find the key in the chapel after defeating a mini-boss, which unlocks the door to the catacombs where he fights the undead zombie king. I've spent considerable brain energy on solving that particular problem without really considering any alternatives.

It is true that you could consider the subtiles to be selected parts of a blob pattern made at half size. But that is your supposition, not a fundamental property of the pattern. I could also say that the blob pattern itself is just selected parts of the 256-tile pattern, and therefore is more of special case. That line of reasoning could go on forever. You can actually draw some things with the 256-tile solution that cannot be done with the blob pattern, but none-the-less most people would prefer the trade off the blob pattern offers, as the extra flexibility (which is small) is hardly worth the enormous extra effort.
The 256-tile solution would factor in edges that don't overlap corners, which won't produce quality output. In practice, I would be surprised if anyone could create an attractive tileset in that format.

But blah blah blah. The point is, you are doing the following:

- Using a ruleset to determine which blob tile goes into a particular cell.

- Using a different ruleset to determine which four sub-blob tiles go into that cell based on the previously determined tile.

That's a two step process and the second step feels like a step too many. At this point, it's not about solving the terrain issue and more about proselytizing. People are free to do it however they'd like. It's just that, to me, it feels like a premature optimization.

Quote
Also, one thing I think you may be missing, is that I'm not necessarily talking about tiles from a engine point of view. It probably makes sense to use the blob pattern in your engine even if you designed it with sub-blob, for efficiency, and because as you say, it is kinda a superset of several other patterns you may have drawn. But for artists, it literally will not have occurred to them they could save a lot of work, unless one points out the possibility.
The blob is a specific binary pattern that is not nearly as common as you would initially think. In most cases, you'll have only one or two blobs per tileset - maybe zero. I have this zombie town tileset I made that doesn't have any blobs at all, and it has about 190 tiles in it. There's probably even more patterns that I haven't bothered to formalize yet (like a solid blob with no holes, non-binary patterns, or even patterns which exist on top of other ones).

What I'm saying is, don't count your chickens before they hatch. Don't waste time solving for problems you might not even have. Save time after you've wasted it, because then you know exactly how much time you will save - and how much time you're going to waste saving it.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #61 on: July 16, 2013, 02:10:01 PM »

Quote
The point is, you are doing the following:
- Using a ruleset to determine which blob tile goes into a particular cell.

- Using a different ruleset to determine which four sub-blob tiles go into that cell based on the previously determined tile.

Take a look at my provided code for the sub-blob. I am explicitly *not* doing that - I go straight from adjacent tiles to choice of subtiles, very neatly. I just explained the sub-blob in terms of the blob for clarity. An alternate explanation could avoid any mention of the blob.


Quote
The blob is a specific binary pattern that is not nearly as common as you would initially think. In most cases, you'll have only one or two blobs per tileset - maybe zero. I have this zombie town tileset I made that doesn't have any blobs at all, and it has about 190 tiles in it. There's probably even more patterns that I haven't bothered to formalize yet (like a solid blob with no holes, non-binary patterns, or even patterns which exist on top of other ones).

Yes, there's a definitely limit to the utility of patterns. I know you've recommended rulesets over patterns, but I have some thoughts to pitch in on that too. But it'll wait for a later article.


On non-binary patterns (by which I assume you mean when you want to blend more than 2 textures or colors together), I have the following observation.

You can define the dimension of a pattern to be the exponential power of tiles needed to use n-colors. This is in analogy to fractal dimension. This is one measure of how complicated the pattern is.

For example, marching squares requires 4^n tiles, so it's dimension is 4. This can been seen as there are n choices for each of the 4 corners. The sub-blob needs less than 4*(n-1)*3^n tiles, so it probably also has dimension 4. The blob, I *think*, has dimension 8, though like the sub blob, there is some choice in exactly how to generalize to n colors.

The lowest dimension pattern I can think of is 3. I'll go over what that is, later.
Logged
guy walker
Level 0
*


View Profile WWW
« Reply #62 on: July 17, 2013, 11:34:19 AM »

Success !!

Managed to get the 47 tileset working with the tiles I made yesterday
(updated the image to show tile index numbers / weighting  and added grass)

You can play around with it at the usual [Stage]
http://www.cr31.co.uk/stagecast/wang/stage.html
Also added a balance control to alter landmass. Here's a grab:



Boris -the link to your lookup table of size 256 is broken on your site  Sad
Would be interested to see exactly which tiles you mapped to the allowed 47. Any alternative lookup table would produce very different layouts. Could be interesting.

Might add a short tutorial later...
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #63 on: July 17, 2013, 12:42:57 PM »

Thanks, fixed. I think my table is identical to yours, except I consider tile 0 to have an island in the center, and then have a separate water tile.

I like your stage setup very much. I wouldn't have thought of your grass addition to the blob, which I think illustrates an important point about it's behaviour. I'd love to know how you are randomly picking your tile47 tiles - you've included some combinations (specifically narrow water channels), that never appear when you are considering the tiles as trying to border a spaced defined by whole tiles.

Also like the inclusion of some geomorphic tiles, where all tiles can border any other ones.
Logged
guy walker
Level 0
*


View Profile WWW
« Reply #64 on: July 19, 2013, 06:42:10 AM »

Thanks, fixed. I think my table is identical to yours, except I consider tile 0 to have an island in the center, and then have a separate water tile.

I like your stage setup very much. I wouldn't have thought of your grass addition to the blob, which I think illustrates an important point about it's behaviour. I'd love to know how you are randomly picking your tile47 tiles - you've included some combinations (specifically narrow water channels), that never appear when you are considering the tiles as trying to border a spaced defined by whole tiles.

Also like the inclusion of some geomorphic tiles, where all tiles can border any other ones.

Glad you like it :-)

Here is the step by step method. I just kept it as simple and as random as possible.

This diagram may help. It shows a layout of just 12 blue tiles, 4 wide by 3 high (the black outlines). The centre of each tile is a yellow square. Each tile has 4 corners (red circles) and 4 edges (green rectangles).



1/ Create an array to hold the random data (white lines). You can see that each cell of the array holds a tile corner, edge or centre. It needs to be 'twice plus 1' the width and height of the tiles. So for 4x3 tiles it is 9x7 cells.

2/ Fill each cell with a random '0' or '1'.

      Note each tile 'covers' 9 cells. We can ignore the central cell. (It will always be drawn as a 'blob' of land). So we need 2^8 which is 256 different tiles. This is too many. But we can reduce it to just 47 different tiles by the following clever method:

      For each tile, if the edge is a '0' then make both the corners, either side of the edge a '0' as well. So…

3/ Step through the array, just visiting the tile centres. You only need to check the top and left edge of each tile. If this is '0' then set both corners either side to '0'.

   // if top = 0:    topLeft = 0, topRight = 0
   // if left = 0:    topLeft = 0, bottomLeft = 0

4/ This leaves right column and bottom row of the array unchecked. You can correct this, or simply set all array border cells to '0', which creates an island-in-the-ocean design.
   
      Finally, calculate the index for each tile. The tile47 image shows the weightings used, which by convention 'scan' from topLeft to bottomRight.


 
5/ Step through the array again, just visiting the tile centres. Add up the corner and edge cells with the following weightings:

   // index = topLeft + 2*top + 4*topRight + 8*left + 16*right + 32*bottomLeft + 64*bottom + 128*bottomRight

You should end up with an index of one of 48 numbers. This represents the correct tile to be used.



And that's it.

When randomly filling the array, it's best to choose more 1's than 0's, as many 1's are 'lost'. I added a balance control so you can alter the land mass between 50% and 90%. At 100% it's all land and 0% all water.


Boris -it's interesting that you think there are too many 'narrow water channels'. I'm picking the tiles randomly by the above method, so they must just 'naturally' appear between tiles. If you roll your mouse over the [Stage] a red square outlines each tile. Or choose label to show tile index numbers.
I must admit I was expecting more solid areas of unbroken land to form. I thought I could create an alternative lookup table to control this, but it's not possible.

Will now try splitting the edge and corner cells, so each can have a different balance of 0's and 1's. Should be able to reduce the land 'fingers'. Not sure if it will work...
« Last Edit: July 19, 2013, 07:09:36 AM by guy walker » Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #65 on: July 19, 2013, 12:13:15 PM »

What I meant was that that the way I would have randomly generated it would be to fill each tile face with a random 1 or 0, then mark each vertex as 1 if and only if all 4 surrounding tile faces are 1. and each edge if and only if the 2 surrounding faces are 1. This method never generates narrow water channels, but it is conceptually convenient as you are only coloring faces, vertices and edges are inferred.
Logged
guy walker
Level 0
*


View Profile WWW
« Reply #66 on: July 20, 2013, 03:05:14 PM »

Oh I see !!!
A totally different method (well to me anyway). You only add corner or edge land when surrounding (4 or 2) tiles are also land. Might not be 'messy' enough. I'll try it out. Would be good if a second method makes a very different kind of layout.

Meanwhile… I did experiment with adjusting edges and holes, but not good. Became too complex as both interfered with each other. Anyhow, found an easier solution. I noted that there were lots of 1x1 holes forming at tile corners. So I just removed them.

It doesn't affect the code that switches corners to 0, or that code it, so everything works better. I also include a 'spoiler' so 10% are not filled in, just for visual variety.

Finally, I've redrawn the tiles. Fingers of land are now boardwalks. Works for me. Almost rooms and corridors. Here's a pic. Uploaded to cr31 site.

Logged
guy walker
Level 0
*


View Profile WWW
« Reply #67 on: July 22, 2013, 12:04:01 AM »

What I meant was that that the way I would have randomly generated it would be to fill each tile face with a random 1 or 0, then mark each vertex as 1 if and only if all 4 surrounding tile faces are 1. and each edge if and only if the 2 surrounding faces are 1. This method never generates narrow water channels, but it is conceptually convenient as you are only coloring faces, vertices and edges are inferred.

OK - added in your method Boris, (thanks for your explanation)
It produces good interconnected island layouts. Slightly more sparse and a bit different and a bit more unpredictable but 'messy' enough. Also as you say easier to calculate.
Added a checkbox next to the balance control to select this option.
http://www.cr31.co.uk/stagecast/wang/stage.html
Both methods are good, so kinda 2 4 the price of 1 Smiley
Logged
darkhog
Level 7
**


Dragon Agent


View Profile
« Reply #68 on: July 22, 2013, 06:51:15 AM »



Could you post sample code and image where instead of graphical tiles, tile IDs (numbers) are shown?
Logged


Be a computer virus!


I cannot C well, so I stick with simpler languages.

There are no impossible things, there is only lack of skill.
guy walker
Level 0
*


View Profile WWW
« Reply #69 on: July 22, 2013, 07:16:29 PM »

I now treat these tiles as Wang tiles, so apply weightings clockwise from the top.
index = top + 2*topRight + 4*right + 8*bottomRight + 16*bottom + 32*bottomLeft + 64*left + 128* topLeft

Recommended as simply multiply the index by 4 (mod 256) to rotate 90 degrees. Useful when exporting from Photoshop. Or when sprites interact with the tiles (x2 for 45 degrees).



Each tile has its index below plus any other 90 degree rotations. Each is x4 (mod 256) the one above.

In theory you can convert the 2corner to a 4-edge tileset and add the middle edge to end up with a 5-edge Wang tileset. You can see that there are only 5 different edges (land/sea) in the tile47 tileset.

The step by step method from the post a few days ago is now also on the cr31 website
http://www.cr31.co.uk/stagecast/wang/tileset47.html

If you build the array sequentially, you only need deal with tiles above and to the left. So in code:

   // if top = 0:    topLeft = 0, topRight = 0
   // if left = 0:    topLeft = 0, bottomLeft = 0

Hope that helps. Let me know how you get on.
« Last Edit: July 23, 2013, 03:32:11 AM by guy walker » Logged
Pages: 1 2 3 [4]
Print
Jump to:  

Theme orange-lt created by panic