Proximity between objects, and Picking

I'm not currently working on anything game related but I had an idea I wanted to test some days back. However, to do it proper I'd need to be able to check, on a square grid, if any objects were adjacent to another.

I ran into this problem a while ago with an idea for a grid-based tactical rpg engine I had (though I decided to wait with that game 'til C2 had everything needed for it), and now I find myself facing the same problem (albeit from a slightly different angle), and I've no idea of how to do it. Hopefully some of you guys do.

So, I have object laid out on a square grid basis (have no actual code/events for the grid, I'm just using the grid feature in the layout editor) and I want to be able to check if an object on the grid is adjacent to anything else, so I could change its attributes depending on what surrounds it.

Both CC and C2 can do it fairly easily. Here is one way to go about it.

CC:

http://dl.dropbox.com/u/5426011/examples6/adjacent.cap

C2:

http://dl.dropbox.com/u/5426011/examples6/4direction.capx

That's definitely clever, it's kinda doing what I had in mind backwards though.

What I want to use it for right now is terrain that is more or less interactive (think of Terraria's terrain system for instance).

Maybe this illustrates what I mean better.

<img src="http://i79.photobucket.com/albums/j135/mr_norris/relative_vars.jpg" border="0">

I actually managed to do something to that effect after messing around with the cap you linked to. But it's convoluted and I'm sure there's a better (ie, more efficient) way of doing it.

http://www.box.net/shared/pvhrdvmy872bs0cdm1tk

Any thoughts on how to make this more efficient?

<font size="2">When I get to that other game idea I had it's going to involve A*, and that's a whole other level of complexity other than mere terrain handling.</font>

Might take a look at this site A Bitwise Method For Applying Tilemaps

Also I've been playing with a similar method using sin, cos.

For x= 0 to width

-for y= 0 to height

--for a= 0 to 7

---system compare loopindex("x")+ cos(loopindex("a")*45)* cell width+1,loopindex("y")+ sin(loopindex("a")*45)* cell height= your condition

----> set tile at loopindex("x")+ cos(loopindex("a")*45)* cell width+1,loopindex("y")+ sin(loopindex("a")*45)* cell height to your cell named something&loopindx("a")*45

Ah, that's what I was looking for newt. I just couldn't find it.

The method I used is very similar but keeps track of what direction is blocked with N,S,E,W. It can be expanded to handle all 16 cases, my example only handles 10 cases, which is enough.

Ex:

http://dl.dropbox.com/u/5426011/examples6/surround.cap

Nice, hadn't thought of it like that.

The hard part is corners

<img src="http://i79.photobucket.com/albums/j135/mr_norris/relative_vars.jpg" border="0" />

Like if there was no urc, or llc, and you wanted to put a transition tile there.

newt: That article looks great. I only skimmed it now, going to take a closer look at it tomorrow.

ROJOhound: That was a much better way than what I did. I messed around with it some and it seems like it doesn't want to update all of the sprites (or any at all) if you, during runtime, take some away and run the "for each" loop again.

Following the method on the link it becomes very simple, with a animation frame per combination.

http://dl.dropbox.com/u/5426011/examples6/bitwiseTilemap.cap

That's really nice. Clever solution!

With some little tweaking you can create a level-map very fast:

http://dl.dropbox.com/u/7871870/construct/auto_tile-01.cap

-left click create

-right click destroy

That works really well ROJO (and if you give the tile sprite a variable you can use that as an index for what animation to play, using the same frame hierarchy as the current one you can use that for separate tilesets. =P

Definitely gonna have this in mind if I ever do a level editor.

Anyway. This does what I want to do, but even so it's not efficient enough for actual use. I want to use this real-time on a larger level. Updating every sprite with a loop pretty much constantly will make the framerate drop like a stone.

So I tried to make it more efficient. First, a "for each" loop that runs once at the start of layout, then with a second I tried to limit the loop to only updating the 8 tiles surrounding the tile that was destroyed.

box.net/shared/v990kh0t3c6xse0y5jp1

It seemed to work alright. So I increased the resolution and filled the layout with tiles, and the framerate is still dropping. As I'm typing I realize I made some mistakes (running the loop 8 times and essentially picking all of the eight tiles each time, for instance)

I'm not there yet, but I'm getting closer! =)

Edit: I think I did it. If so, wooh!

box.net/shared/qrib8jot0ejpz5io5q5c

Here InkBot, same thing, but with half the number of event (14 instead of 33), and potentially... I hope... a bit more efficient.

The function object is neat when you begin to see repetition of the same kind of code. There's a getting a use to it, but it's worth it.

also, you put strange values in the random(), I rewrite these line with the equivalent. But if you wanted a particular range value of force, like between -15 and -20, you should put :

20-random(5)

for -20 to 30 it would be :

random(50)-20

bitwise_terrain_better_better.cap

I must say this is totally Neatcake�

And may come in handy in the future... Thanks, Yann.