need help with tile-based map generator

[bearhead]

I’m trying to create a tile-based map generator and I’m having trouble assigning proper sprite sheet reference values to each tile:
(the numbers being generated are not correct)
http://codepen.io/kvana/pen/VKqLWd

EDIT:
I’m pretty sure the problem is how I’m determining the neighbors… it should work for a 3×3 grid, but breaks on anything different…

Need to find a different method :\

[Shikkediel]

Edit – I see you concluded something about the grid size meanwhile as well. Here’s an approach that makes the code a bit shorter:

var that = $(this);
var prev = that.prevAll();
var next = that.nextAll();

var nw= prev.eq(10);
var nn= prev.eq(9);
var ne= prev.eq(8);
var ww= that.prev();
var ee= that.next();
var sw= next.eq(8);
var ss= next.eq(9);
var se= next.eq(10);

Hope I’m understanding correctly…

Thinking about it a bit, the elements that are against the sides will give some more trouble.

[bearhead]

To find the neighboring tiles I am using this method now:

var nw = document.elementFromPoint(my_x - tilesize, my_y - tilesize);  
var nn = document.elementFromPoint(my_x, my_y - tilesize);
var ne = document.elementFromPoint(my_x + tilesize, my_y - tilesize);  
var ww = document.elementFromPoint(my_x - tilesize, my_y);
var ee = document.elementFromPoint(my_x + tilesize, my_y);
var sw = document.elementFromPoint(my_x - tilesize, my_y + tilesize);  
var ss = document.elementFromPoint(my_x, my_y + tilesize);
var se = document.elementFromPoint(my_x + tilesize, my_y + tilesize);  

I have it working on a smaller scale:
http://codepen.io/kvana/pen/RGEWNz

I’m treating the corners and edges as if they’re surrounded by open tiles, so I don’t think they should cause issues? I tried to use the same method in my larger map but it still isn’t working…
http://codepen.io/kvana/pen/VKqLWd

So maybe it has something to do with the each function? That’s the only material difference I am noticing between the two…

[Shikkediel]

I’m not sure I can completely follow what you’re after. Your method for locating the neighbours seems to be a good approach – and it works. Apart from the fact that the bitsum variable becomes null when any adjacent tile would be outside of the parent.

Just trying a bit

You’ll have to click a few times to make sure the sixth element is not closed. I have no idea why it’s creating these line breaks all of a sudden by the way. If someone can enlighten me…

A thing I also noticed – one can create non-standard attributes but should probably best be using data attributes instead.

[Shikkediel]

What also baffles me is that if you make the window too small for the whole map to fit and then scroll down and click the create button, it will only start counting tiles from the first visible line.

:-?

Edit – maybe some of the references to elements are outside the screen and thus creating a null variable…

[bearhead]

yeah it’s super weird… I built off of my smaller scale version that was working, and I now have it working with 10×10 map

http://codepen.io/kvana/pen/NRZzoP

I’m really not sure what I did to make it work… The main difference is that this new version does everything on the click function whereas my old version had some variables being declared in a wrapping document.ready function, so maybe that goofed it up?

Oh and even this version seems to break when I view it on these forums, but it’s ok in codepen???

yeah that’s true about it not counting off-screen lines…
must have something to do with how document.elementFromPoint() does it’s calculations

[Shikkediel]

wrapping document.ready function

I can’t imagine that would make all the difference. I’m curious to find the cause but don’t really see how the numbers in green would be calculated. Makes it hard to conclude if it’s actually working or not. But as long as it does now…

:-)

Edit – working but still tricky, I guess.

[Shikkediel]

This one is from the lastest working pen:

Shouldn’t the bottom outer tiles both be zero then?

[bearhead]

basically the way the numbers are generated is that all the open (green) tiles have by default a total value of 255. Then the script checks neighboring tiles to see if any are closed (blue). If a neighbor is closed, as specific number based on it’s position is subtracted from the total.

If no neighbor is found in a given direction (tile is on edge or corner), then no amount is deducted from the total value. (effectively the script treats the map as if its surrounded by open tiles)

So looking at the map you posted above, the value of 248 for the tile in the lower left corner is correct because 255 – 1(for its N neighbor) -2 (for its NE neighbor) -4(for its E neighbor) = 248

[Shikkediel]

If no neighbor is found in a given direction (tile is on edge or corner), then no amount is deducted from the total value.

Okay , that solves my previous post. Non-existing tiles are treated as if they were open (I think, lol).

It’s more obvious to see it in the code now too.

Edit – plus you already said it. :-S

I’m treating the corners and edges as if they’re surrounded by open tiles

[Shikkediel]

I think I’m zooming in on it. If you look at this test, you’ll see in the console that at times #map is the selected element instead of .tile. There must be some asynchronicity at play, trying to select tiles before they are created?

Link

I think this is a separate issue from when the map is too large for the window – there the characteristic of elementFromPoint might be the cause.

Edit – another thing you changed is raise the scope of bitsum by declaring it outside of the if ($(this).attr("closed")==0){ statement. I’m wondering if that is playing a role too. Before, the scope would be limited to the context inside the if only. So there were actually two bitsum variables earlier, the second with a global scope.

Nope, no block scope (with var) in JS…

[Shikkediel]

Well what do you think of that… it’s the CSS that makes the big difference. Apparently inline-block is creating mismatches when it comes to the neighbours while floating seems to solve the issue.

Some further fiddling

[Shikkediel]

Going over your code (which turned out to be mostly redundant when I noticed the style behaviour) and looking at the repetition of the wind directions, things got away from me a bit. Guess I had the inexplicable urge for random code practice again so I made an approach that uses two objects. The first one (neighbours) is looped to set the bit values and the second (bits) to get the sum.

Right here

You might not end up using it of course but there could still be some pieces of interest in there.

[bearhead]

That’s pretty cool :)

I’m surprised by how much you were able to optimize…

Strange that inline-block was causing the main problem?

[Shikkediel]

Very strange indeed how it mismatches the elements when visually there would be no reason for it. Can’t find anything related to it on Google either. Maybe internally the line breaks (although not visible) are the cause somehow?

You could even use a single object for it by the way and put both the neighbour element and bit value in an array. But the previous version might be a bit more readable.

You often post some interesting bits of code that are tempting to dive into in any case, elementFromPoint is one I wasn’t aware of so that’s a good one to have in the arsenal.

:-)

[Author]

Posts