an (isometric&low poly) Tower Defense game

Show us your works in progress and request feedback

» Wed Mar 11, 2015 1:35 pm

You should try the layer approach. Send objects that are supposed to be on top of the character, NPC's etc to new layers depending on "Y" and only call the sorting function when that happens. That way you will only need to sort if there is actually something that needs to be sorted instead of every 0,1 seconds.
or in this thread Archer Devlog
B
50
S
22
G
19
Posts: 1,142
Reputation: 14,851

» Wed Mar 11, 2015 2:03 pm

in my game theres a "stream" of enemys constantly walking on the path so when the map is heavily covered by towers there will be permanent requirement for sorting but not for every object at the same time so i think i should find a way to limit the objects being sorted. does that make sense?
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

» Wed Mar 11, 2015 2:22 pm

Maybe add another condition? Once things are sorted the could stay sorted unless something is very close to the object. that needs to be sorted...

Hmmm no idea, maybe distance? is overlapping?

The more conditions to be met the better i guess. I wouldn't go with time as a limiter for sorting. You could get ugly graphical glitches.

There's probably a lot of objects that doesn't need to be sorted because they are not overlapping, so trying to figure out what actually needs to be sorted?
or in this thread Archer Devlog
B
50
S
22
G
19
Posts: 1,142
Reputation: 14,851

» Wed Mar 11, 2015 9:02 pm

yeah i also think something with overlapping should do the trick but all my approaches with this turned out buggy so i stick to the first rule of Lucas Arts (http://images.eurogamer.net/2014/usgamer/Ten-Tips.jpg) and come back to this later.
Now ive got new problems with the turret behaviour
i know i have to set the range of the turret acordingly to its angle but im not good at math and dont know how to set this wright, in theory a circle should become an elypse in the isometric world but what i get is more a distorted shamrock
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

» Thu Mar 12, 2015 12:57 am

Sorry, for some reason I couldn't access the forum yesterday. Looks like tunepunk has a great solution for this though!

Turret range: Can you just do a distance comparison between the sprite and the turret? Multiply the Y by 2 in the point to point distance comparison (before you do the trig), then just set a distance limit.

Distance = Sqrt ( X^2 + (Y*2)^2)
B
9
S
2
G
1
Posts: 48
Reputation: 710

» Thu Mar 12, 2015 4:05 pm

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!
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

» Fri Mar 13, 2015 12:35 am

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.
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

» Fri Mar 13, 2015 8:30 am

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
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?
B
9
S
2
G
1
Posts: 48
Reputation: 710

» Fri Mar 13, 2015 12:00 pm

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 )

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
B
39
S
11
G
5
Posts: 485
Reputation: 5,365

» Fri Mar 13, 2015 9:39 pm

> @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:
isometric-multiple-floors_t121850?start=30

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
B
8
S
3
Posts: 197
Reputation: 1,207

PreviousNext