fldr's Forum Posts

  • 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?

  • sure, just set the end of the loop to something like 5+wave*5, that would give you 10 for first wave 15 for second and so on

  • 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

  • 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?

  • > 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

  • here you go

  • i would set the racket to the position/angle on the hand you want it to be, then pin racket to hand (angle&position)

    this way you can rotate the arm and the racket will follow like it was held by the hand

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Wow, thats very nice! Is it allowed to use the created people?

    I made something alike for the "Pixel People" of Tokyo Geisha some time ago

    http://fldr.de/PixelPeopleCreator/

    (i added some more layers, so try around with the characters to get the not-listed parts)

  • Also, the baby with the bulb on his head, is that a graphic you're sharing with fldr ? He also has used the exact same graphic in his game. Or is it from the asset store?

    these are public domain graphics made by Kenney (http://opengameart.org/users/kenney or kenney.nl)

  • i like your tutorials very much and was very excited when you first anounced this complete game tutorial!

    Thanks for sharing!

  • 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

  • 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.

  • 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 because in crosswalk apps there is the chromium engine integrated which makes ~40MB installed without any game data, nothing you can do to change this (theres in fact a "crosswalk lite" which is half the size but not in intel XDK and it has some other flaws from what i heard)

  • 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 <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

    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