an (isometric&low poly) Tower Defense game

Today i worked my self through all sort of forgotten math stuff. With success i think, thought about the whole concept again and now the distance will be in excact tiles, for example one tile around the basetile, for that i use intersection of two linear functions, the first is the edge of the tiles the second is tan(turret.angle), then i use distance to get the range of the turret to this point on the (visible) border of the tile.

Thank you all for helping!

its still not working good, guess my formulas arent correct, tomorrow i will try it again, maybe i just overlooked something but the event structure ive got now is also not very nice.

currently ive managed to calculate the wright distance for 1/4 of the 360°, because the formula i made returns strange values for the other 3/4 of the 360°, i calculated the distance from the middle of the tile to the visible border for a 90° radius in 0.1° steps and saved them to an array, now im checking if the turret is either in 0-90°, 90-180°, 180-270° or 270°-360° and set the turret.range to the corresponding value in the array multiplied by the instancevariable "range" of the tower and get more strange things..

since i calculated "halftile" distances (middle of tile to its borders) i figured when i want the turret to have a "one tile" radius i have to set the range instancevariable to 3 (since 3 * halftile should be basetile+one tile, wright?), it works for all angles except near 270 and 90, no idea why, the value for 90/270 is half a tile height but the result is a range of two tiles. Guess i overlooked something here.

Why do you need to make the distance in tiles, rather than arbitrary distances? That makes it much harder.

"currently ive managed to calculate the wright distance for 1/4 of the 360°, because the formula i made returns strange values for the other 3/4 of the 360°"

Probably due to negative values?

" i calculated the distance from the middle of the tile to the visible border for a 90° radius in 0.1° steps and saved them to an array..."

When you start using lookup tables, you usually know you're doing something wrong.

I don't see how this gets you what you're after.

Particularly, as you advance out multiple tiles, your distances even out and you end up with something more circular.

If you want tile based distances (without diagonal allowed, so it ends up like a diamond):

1. Find which tile (X and Y in your map array) the tower and baddie are currently in.

2. Get the difference in the Xs and the difference in the Ys

Xdiff = Xtower - Xbaddie

Ydiff = Ytower - Ybaddie

3. Add the absolute value of the differences together

Total = |Xdiff| + |Ydiff|

If you want something more circular, you need diagonal movement rules.

Can you make an illustration of what you want to accomplish?

Thank you for your help! I dont really understand what youre saying there so i will try to explain what i want to achieve.

First a picture:

what i want, is to set the turret range to the distance of the turret (P[0/0]) and the point on the dotted line

this was my first approach:

quite complicated, hm? i dont know why, but it produced wright values for this particular "angle section" (even if i used the wrong angle to calculate var_x, or is it the wright angle? because when i change that it gets wrong results?)

Edit: while i was writing this post, i think i found my failure, the distancefactor of the turret (how many tiles around it) must be multiplied with the actual values of my formulas instead of multiplying the results?!

when i copyed this for the other angles and changed the calculation of alpha so i always get an angle between 0 and 90 it made a total mess.

now, like i said, my calculation is for the range of middle of tile (where the turret stands) to its (imaginary) border, so i thought i have to take this calculated "neutral" distance and have to make something like, set turret.range to distancevalue + numberoftileradius * distancevalue, or just distancevalue * 3 for an 1 tile radius.

heres what i did on paper http://fldr.de/DSC_0469.jpg , maybe it helps

this is how i calculated the values for 0-90° in the array:

my variables:

and how i set the range now:

and this is what it does: http://fldr.de/towerturret

only place one tower, if more are placed you never really know which distance the redline is presenting (i was sloppy with that) and dont forget to press A so theres something in the array (again i was sloppy with these debugging things <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">)

Edit2: haha i just found another failure, for 90-180 and 270-360 i set the turret.range to the wrong values, for these angles i should mirror the values, wright?

but like i said before, my math skills arent good so i might do everything wrong here and what you where saying is just what i was trying to do?

Thanks!

Big Edit: i think i got a working solution, but im very open for better performing methods, now theres a "for each turret" event that fires every tick, first compares if the turret has an target and then setting range (and when it has no target also the angle) dependent on the turret.angle

http://fldr.de/towerdefense

fldr , tunepunk

looks promising! Here is an example capx i did for isometric, multilevel and multilayer (one screen) purposes. There is a solution for auto z-indexing according to the position.

Very effective, with no collision checking at all check it out, it might inspire you the right direction. Let me know, if it helps.

Original Post:

Original Text:

Passing beneath/above object (being on different floors)

Finally all the basic features are included. Not using solid-behavior or pushout absicly at all, since you have to be able to pass under walls, which must be colliding with the player on the same floor. (There still can be some reduced even now, eg "guides"). Players can just swap places, like with the wall being put in the foreground or background according to any layers, which is not implemented yet, but easy from here.

No Solids

Obviously, you can work more with collisions, also adding solid behavior -- which is more stable and might be necessary especially on slow devices to prevent passing through walls when slowing down to few ticks per sec. --, and just use this method when both players are on different floors, to disable solid temporarily, but enable the collision-control-lock. But I don't know, how many objects you are going to end up with.. it's always good not to have too many collisions, especially, if you plan to play it on phones/tablets. So its a balancing...

Formula, Family and Harmony

Also, it is just a sketch, I'm sure it can be optimized a bit. Sorry for any longer Formula, but I try to work with families and relative values, to build up a proper engine with all object types are being easily replaced or added easily, without further coding basically, so anyone can use it to start with. Of course, most of them will be registered, to provide some more transparency, (as I did already in this file). I am also thinking of putting them as a collection online somewhere in this forum, since I really enjoy developing different ones and got a bunch of them by now.

CONTROL KEYS:

Player A = AWSD

player B = L/R/UP-ARROWS

Its too bad you can't have a an invisible 2d layer, and just project the isometric objects to the isometric coordinates.... oh wait.

> fldr , tunepunk

looks promising! Here is an example capx i did for isometric, multilevel and multilayer (one screen) purposes. There is a solution for auto z-indexing according to the position.

Very effective, with no collision checking at all check it out, it might inspire you the right direction. Let me know, if it helps.

Original Post:

Original Text:

Passing beneath/above object (being on different floors)

Finally all the basic features are included. Not using solid-behavior or pushout absicly at all, since you have to be able to pass under walls, which must be colliding with the player on the same floor. (There still can be some reduced even now, eg "guides"). Players can just swap places, like with the wall being put in the foreground or background according to any layers, which is not implemented yet, but easy from here.

No Solids

Obviously, you can work more with collisions, also adding solid behavior -- which is more stable and might be necessary especially on slow devices to prevent passing through walls when slowing down to few ticks per sec. --, and just use this method when both players are on different floors, to disable solid temporarily, but enable the collision-control-lock. But I don't know, how many objects you are going to end up with.. it's always good not to have too many collisions, especially, if you plan to play it on phones/tablets. So its a balancing...

Formula, Family and Harmony

Also, it is just a sketch, I'm sure it can be optimized a bit. Sorry for any longer Formula, but I try to work with families and relative values, to build up a proper engine with all object types are being easily replaced or added easily, without further coding basically, so anyone can use it to start with. Of course, most of them will be registered, to provide some more transparency, (as I did already in this file). I am also thinking of putting them as a collection online somewhere in this forum, since I really enjoy developing different ones and got a bunch of them by now.

CONTROL KEYS:

Player A = AWSD

player B = L/R/UP-ARROWS

Thank you for the input! Will try out your capx tomorrow, now its bedtime here and i would propably not understand much

Its too bad you can't have a an invisible 2d layer, and just project the isometric objects to the isometric coordinates.... oh wait.

tell me more, tell me more

am i reinventing the wheel here and everything im looking for can already be found here somewhere?

i saw that projection before but does it allow to set the turret range? or is really everything happening on the invisible 2d layer and the visible part is really only for visual enjoyment?

"or is really everything happening on the invisible 2d layer and the visible part is really only for visual enjoyment?"

Yes, everything except z sorting takes place there.

then i wouldnt have to calculate complicated ranges for the turrets?

i would be thankfull if you could tell me more or point me in the wright direction (what phrase to search for?) how to achieve that

First you make the game in 2d topdown.

Each object there would have a isometric counterpart on another layer that is offset to isometric coordinates.

iso x= 2d x- 2d y *(tile width/2)

iso y = 2d x+2d y *(tile height/2)

Edit:

Let me add containers work pretty good, except the container spawns on the parent objects layer.

If you use Q3D for rendering, it implements a proper Z-Buffer and would correctly render things based on X-Y-Z without the ordering trouble . It has a 2D sprite object you could use so its actually works well for isometric stuff too, and also gives you the freedom to add 3D stuff if you have to and use 3D collision detection, you could also use normal maps on 2D planes and add lights too. There's a bunch of features that would help with this type of project, since ISO is really mostly just 3D game development with 2D sprites instead of models.

Hi,

today i started working on an isometric tower defense game, using the lovely assets by Kenney.

Didnt got much yet, only a map, some enemy walking the path and making sure everything has the wright z-order. Isometric game design is totally new to me and i had a hard time figuring everything out with this damn z-order and where to place the tiles <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

but anyway, you can see what i got here: http://fldr.de/tower3

That looks amazing!

Here is my Isometric Endless runner game <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

viewtopic.php?f=148&t=125571

Video and Google Play link in my signature

Did you manage to raise the sprite when they walk over an elevated road like for instance the Bridge in your screenshot? How is that done?

First you make the game in 2d topdown.

Each object there would have a isometric counterpart on another layer that is offset to isometric coordinates.

iso x= 2d x- 2d y *(tile width/2)

iso y = 2d x+2d y *(tile height/2)

Edit:

Let me add containers work pretty good, except the container spawns on the parent objects layer.

Thank you! will try it!

What do you mean with the edit?

If you use Q3D for rendering, it implements a proper Z-Buffer and would correctly render things based on X-Y-Z without the ordering trouble . It has a 2D sprite object you could use so its actually works well for isometric stuff too, and also gives you the freedom to add 3D stuff if you have to and use 3D collision detection, you could also use normal maps on 2D planes and add lights too. There's a bunch of features that would help with this type of project, since ISO is really mostly just 3D game development with 2D sprites instead of models.

i thought about your plugin before but i fear that its to huge for my current knowledge, but im still following your progress with it and will buy it eventually in the future