tiles and enemies

i would like some feedback from people that are into tile-based games:

> what's your method of enemies implementation (i mean collision detection)?

i'm now working on a * my really first 100%! * tile-based platform game that is quite similar to kid icarus, nes platform... the playabilty seems perfect and the maps are loading very well. the collision detection with the walls and all elements is working perfectly (blocks, ladders, icy floors, clouds-like platforms etc).
but now i want to implement enemies, and i would like you to share your thoughts on that...

what's the best way...?

1) have enemies that change the initial arrays values of the map: it doesn't seems to be a good idea since the values have to go back to normal after the enemy is gone into another array element...

2) use the "classical" hitTest with their collision detection (between player/enemy i mean). mmmhhh...

3) "emulate" the hitTest: check with your and the enemy's _x and _y properties if you are near him...

4) check in which array position is the enemy and the player. if it's the same (or the one just near), then > game over... but it has quickly as many or more values as 3)

maybe someone has a better idea through his tiles experience?

thanks for help...

regarding type 1)
don't you reset the array element that the enemy is leaving back to null and set the array element that it is going to point to the enemy?

Quote:

---

don't you reset the array element that the enemy is leaving back to null

---

well, no. because the array is not necessary resetted at null... imagine the enemy is on the floor, then it's ok... but if it's inside a wall (a flying enemy? a fantom? etc...), and if the element is resetted to null, the player will go through that piece of wall...
that's why i talked about restore the old value instead of reset the value

Quote:

---

set the array element that it is going to point to the enemy

---

sorry, i'm tired (it's 4.22 in the morning here) so i don't catch what you mean...? maybe record the values (_y and _x) from the array during the time the enemy stays or don't leave the tile? may be good, particularly for non too much walking enemies...

for now i tried the 3)...

but thanks for any infos you can give me anyway ^_^

why not have a separate arry for moving objects?

Just figure out the vector distance between the hero and enemy sprites like this:

Code:

---

function getDistance(clip) {
 for (i=0; i<enemies; i++) {
  var delX = clip.x-t.x;
  var delY = clip.y-t.y;
  var b = int(clip.dist[i]=Math.sqrt((delX*delX)+(delY*delY)));
  if (b<5){
    remove you enemy!
  }
 }
}

---

Then just check if any of the distances are within your specified limit - not pixel perfect, but it's fast, and good for a pool game ;) lol - the function could be spread over the enemies to check every 2/3 frames rather than every frame so it can save a bit of extra cpu! - maybe have to change the code around, most dragged out of something I have!

RipX

yes, that may be a solution...

but the 3) seems good to me, because:

> these are the values used:
1) player._x
2) player._y
3) enemy._x min
4) enemy._x max
5) enemy._y min
6) enemy._y max.

about array checking:
1/2) player._x/tile_width
3/4) player._y/tile_width
5/6) enemy._x/tile_width
7/8) enemy._y/tile_width
^ (these only if i check for the tile, but the collision detection is not too precise like that without adding other values, like the min/max above > 9/10)?
9) check the (big) array for all these values

for an accurate collision detection, the array solution seems to have more values to check for the same thing... that's why i tried the 3) first...

what do you think?

* edit *

thanks RipX, i see exactly what you mean... that's something to try ^_^
simple, and surely fast. i'll do some tests...

you see, you'd need to replicate the same values for the hero sprite too, not just use the _x & _y values!! - working out the distance must be far faster than the multitude of "if" checks required in what your proposing!

I haven't tested it myself, I have used it in something else though checking the distances of a multitude (over 10) of clips all against each other with no noticable speed impact! so since this will be checking only against the hero clip it should cause no slowdown whatsoever! :D

RipX

why not drill down.
first use tilebased
then distance
then hittest

The whole idea of making tile based game, is the use of tiles (lol).

Distance calculation from RipX works well as long all your enemies look like balls. It doesnt work at all if your enemies can be tall (tree and giraffe) or wide (snake and worm).

Thats how I would do it:

Define starting points of enemies (nests) in the map array.

When you create tile and enemy should appear there, create new enemy, remove nest from map array and add enemy to the enemies array.
Use enemies array to move them around.

For both player and each enemy, calculate x/y position for all 4 corners and also tile number for each corner (left-top, left-bottom, rigth-top, right-bottom).

For each enemy mark the tile its corner is on, with property
thistile.enemy=enemy_name
When enemy moves to next tile, make that property false
thistile.enemy=false

To check collision between player and all the enemies, check for thistile.enemy property for every players corner point. If enemy property is not false, check for rectangular collision between player and that enemy.

Good luck :)

well,

why not put all enemies in one mc and do 4 pixelbased hittests on hero's left, right, top and bottom boundary if you hit something you could look further.

i used this for cauldron (but there is a max of 6 enemies per screen, but it should not matter how many enemies are there)

<olli/>

Quote:

---

why not put all enemies in one mc and do 4 pixelbased hittests on hero's left, right, top and bottom boundary if you hit something you could look further.

---

the enemies (and all elements that have a collision factor) are inside a single MC, of course ^_^
pixelbased hitTest? you mean the this.hitTest(blabla) with 4 pixel little gfx?

tonypa
ok, i'll give it a try... i'll create another array specially for enemies and enemies movements... i just wanted to avoid the fact "too many calculations at the same time", for example the playerr has already several arrays check, enemies have the same (because they wander in this tile based world), plus collision detection to add... that's a lot i guess. but the idea of having an enemy array seems great

thanks for your advices, people ^_^

Just thinking about this how about give each character an array based on their (start position+the size of the tile)

so 32*32 tiles tile 0,0

en1=[0,0,32,32]

this can be easily build using the grid refernce when building the enemies, then (if on screen/buffer area) as they move along, you can adjust the values and check against those - would be much neater than maxX, minX, maxY, minY ...

you could then loop through the checks for each value in a set of 4 to do less work per frame:

Code:

---

checkEn = function(val) {
 for(var j=0;j<enemies;j++) {
  check hero hitTest with "val" of array
 }
}

var loopEn=0
onEnterFrame = function() {
 checkEn(loopEn)
  if(loopEn == 3){
    loopEn = 0
  }
 loopEn++
}

---

Something like that - just a neater way of bounds, letting you rotate through the values too! Just an idea?

RipX

I just thought about what you said about the enemies testing against each other:

Using the old %= you could do a check only when the enemy is lined up with a tile against the next tile in the direction it's walking - if there's an enemy there, make it turn around.

That way, there are hardly any checks, but it still would work perfectly :D

Code:

---

enDir = function(){
 if (A%B == 0){
  if(dir =='l'){
    dir = 'r'
  } else if(dir=='r') {
    dir = 'l'
  }
 }
}

---

One thing though, the speed must be divisable by the tile size to result in a "0" during the test, but I'm sure you'll agree, small price to pay :D - Most are like that anyway!

RipX

Quote:

---

Originally posted by marmotte
the enemies (and all elements that have a collision factor) are inside a single MC, of course ^_^
pixelbased hitTest? you mean the this.hitTest(blabla) with 4 pixel little gfx?

---

I think nGFX meant to put all enemies inside 1 mc, lets call it "enemies", and to use:
enemies.hitTest(hero_left_x,hero_top_y, true)
enemies.hitTest(hero_left_x,hero_bot_y, true)
enemies.hitTest(hero_right_x,hero_top_y, true)
enemies.hitTest(hero_right_x,hero_bot_y, true)

So you get hitTest = true when any of the corner points is inside actual shape of some enemy mc.

Quote:

---

I think nGFX meant to put all enemies inside 1 mc, lets call it "enemies", and to use:
enemies.hitTest(hero_left_x,hero_top_y, true)
enemies.hitTest(hero_left_x,hero_bot_y, true)
enemies.hitTest(hero_right_x,hero_top_y, true)
enemies.hitTest(hero_right_x,hero_bot_y, true)

---

haaaa, ok. it's the method i'm generaly using with my art based games ^_^

RipX
thanks. the size of my tiles are 16*16, so speeds like 1,2,4.8 are possible... for example, the player walks at 1. enemies too, but they can run at 3... maybe you missunderstood me, but my enemies are not supposed to to turn around when they hit each other (it may be an interesting behaviour though)

ok, i'll try to put another array dedicated to enemies, and see the result...

some enemies have the ability to look for the player: for example, their visibility are the 6 tiles around horizontally... if the player is there, they run at you. in that case, it's better to use a _x comparaison than checking all these tiles at the same time...
but it's ok, for "basic wandering enemies" i'll try the array system. the hitTest nGFX suggested is great too, since i often used that method... and it desn't require any for loop...

all i have to do now is testing ^_^

Quote:

---

their visibility are the 6 tiles around horizontally

---

Using the last method I posted is possible of doing that ;) - my point was, youd have no actual hitTesting and would only need to run a check everytime the enemy is fully inline with a tile, you could also use this method to check if it will "fall off" the next tile and turn it around then too!

RipX

Oh, I didn't explain the hero, using the same method, if the hero clip is on the same tile as the enemy, then check the you could use the %= to work out the distance between the two!!

RipX

Quote:

---

Originally posted by marmotte
the enemies (and all elements that have a collision factor) are inside a single MC, of course ^_^
pixelbased hitTest? you mean the this.hitTest(blabla) with 4 pixel little gfx?

---

.... i knew i should've made an example ...

but tonypa got it right

<olli/>