R0J0hound's Forum Posts

  • Probably not exactly what you want but you can make multi-line comments by using shift-enter.

  • You can do something more robust than that, which just tests if the point touches the object.

    Like pick all the objects in a radius:

    on touch

    for each sprite

    system compare: distance(sprite.x, sprite.y, touch.x, touch.y) < 50

    --- do something

    or just the closest in a radius:

    on touch

    pick sprite closest to (touch.x, touch.y)

    system compare: distance(sprite.x, sprite.y, touch.x, touch.y) < 50

    --- do something

    Another idea could be to position a circle to the touch location and test what overlaps it.

  • The player doesn't utilize the solid behavior, it's only used for the line of sight.

    It could be re-worked to utilize astar so the shortest distance is used every time, but it would have to be astar done from scratch, since it wouldn't be grid based.

    If smaller objects are passed through you could roll your own LOS with events with that in mind, or probably more appropriate implement some kind of collision response to push objects out of each other. Avoiding moving objects can be done by looking at where the objects will be a little in the future and if they are colliding adjust the current angle of motion so it won't.

  • You possibly could get away with doing something much simpler for a game like that. Most of the moves have a line of sight to the players and the obstacles look to be mainly just rectangles with no crevices.

    You could use line of sight and just move forward if the player has a clear view. If there is an obstacle in the way then just pick the furthest corner of the building that the player can see an move toward that, then they can continue to the goal as they round the corner. This should be able to work with many buildings, but the beauty of it is the player only addresses obstacles as they see them.

    It's simple and fast but can fail if you have alleyways instead of just buildings. I could be acceptable though, as I've played games where I had to help the player pick a better path. But now that I think of it you can mark the alleys in the editor so that the player can know to only go inside if the goal is in there. In a similar way you could mark long winding corridors I think, and just handle that in a unique way.

    EDIT:

    https://dl.dropboxusercontent.com/u/542 ... hfind.capx

  • An action shouldn't be needed, the textures are told to free in the appropriate places. I don't know why they aren't. I'll look into it more later.

  • 1.

    Probably a grid based approach. I might use tiled and a parser to read the iso grid, but that may be an overkill. Or I might just place objects in the editor or make an editor so I also get sorting. The level design is just data and it should be possible to convert it to any format that's needed to use.

    2.

    The isometric view is just smoke and mirrors, I'd use a 2d array with the heightmap info for the grid, and compare the projectile isometric positions with that.

    3.

    I've devised complicated sorting before to find what order to draw the object's based on their isometric size and position, but it's not very fast as i boils down to being a topographical sort. For most isometric games it's acceptable to do sorting like this:

    For each sprite sorted by 10000*isoX+100*isoY+isoZ

    ---- send to front

    Well not exactly, you may need to change the positions around. Basically it reads that more y will be infront of more z and more x is infront of everything.

    4.

    I'd store the fog in an array like the heightmap and set the units to be invisible if they were on grids with fog.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 1. The delay is unavoidable. Path finding can take a while.

    There are other methods but they depend on what you want to do.

    A* (a star) is what the pathfinding behavior uses and is the general purpose solution for simply finding a path as fast as possible. The "turning" can probably be avoided by doing the motion manually using the path points the behavior gives. If you roll your own with events then you could do things to make the delay shorter by exploiting the design of your levels.

    Like say your game consists of rooms then you could do a lower resolution search of just the path from room to room and then find a more detailed path for each room you move through. And on that note you might be able to do a progressive pathfind by doing a search on a coarse grid first and then perhaps using progressively finer grids.

    Also as a note, if you roll your own you could also use something besides a grid, like line segments for pathfinding to reduce the number of nodes to search through.

    Dijkstra's algorithm is another, which is slower but gives you the path from all grid cells to one or more points. It basically is a flood fill that starts at the destination then expands to the neighboring cells and stores the direction to move to get to the beginning cell. This is repeated until all the cells are visited. Then the moving sprites just need to use the direction of the cell they are currently on to know which way to move. Basically the path is only calculated once.

    I have an example here:

    For completely delay free pathfinding you could pre-calculate the path from every point to every other point.

    This guy did just that:

    The disadvantage is it's tedious to setup, but once it is the pathfinding will take no time at all. The cells are pretty big, but the idea is to just get the enemies in the general area and then use something simpler to move toward the player's exact position.

  • sadNES

    Setting the opacity, size and position of the object before pasting is the way to do it. The paste action should paste the object as it appears.

    As I understand it you're erasing one circle and drawing a radial gradient with another. I don't understand how they correlate from how I'm reading it.

    The quality difference is due to the full screen scaling of the project. The resolution of the canvas object by default is 1to1 with an unscaled project. You can change the resolution to be 1to 1 with a fullscreen scaling by using the "resize canvas" action with

    Canvas.width *windowWidth/viewportWidth

    And the same for the height. I don't recall offhand what the expressions are actually called.

  • irina

    Sorry, I don't really know. I haven't tried most of the exporters. The code that loads images from an URL is basically the same as the sprite object. So if loading works for the sprite object and not for the paster object then I'd guess it's an issue in the paster plugin.

  • +1

    Good suggestion.

    I suppose you could use sprite.AsJson and the "load from json" action to copy all the properties of one object to another. Just pick the object you want to use as the default and save the .asJson to a global.

  • It's more of something that should change with the paster plugin. I'm on a mobile right now so I won't be able to find the link, but a search for paster and tilemap should yield a solution.

    Basically to paste a tilemap you move the part you want to paste into the scroll area along with the paster object, then paste it, and move everything back.

  • I'm pretty sure the effects are compiled before the start of the layout, so the constant become unmodifiable. I suppose if you could edit the source and re-compile the shader at runtime the constant could be changed, but there isn't anything in place to do that currently.

    I'd go with the idea in your link and test how it performs.

  • I should. I'll work on getting it put in a tutorial.

  • You can use the 8direction behavior to move the object but you can't use the solid behavior for the walls because the behavior will just stop when hitting a solid.

    At this point we can detect collisions with the overlap condition. The part we want now is some kind of collision response to keep the object out of the walls and do other stuff like sliding.

    The simplest collision response would be to save the object's position before moving and the if it overlaps a wall after moving then undo the move by moving back to the saved position. The drawback is this won't do any sliding and if moving fast the object will stop short of the wall.

    Another method is to move the object a pixel or so at a time until it's not overlapping. All that's needed is a direction. If we use the opposite direction of the motion we'll get the object to stop at the edge of the wall, but not slide. If we instead find the closest direction to move out we can get sliding. We just need a good way to find the closest direction.

    One idea to find the closest direction would be to save the object's position then try moving out in each of the four directions of the wall, and measure the distance moved for each. The closest direction would be the one with the shortest distance. You'll want to do this for each wall. With this you'll get wall sliding but you can get some jumping when hitting a corner which may be kind of like your third picture but not quite.

    One thing to consider is so far all that's being done is correcting the position of the object, but we will also need to correct the velocity of the object. Sliding would basically be setting the velocity perpendicular to the side of wall (or normal) to zero. The normal is also the same as the closest direction that the object moved out.

    Setting the velocity along a direction to zero can be done with some math.

    Var vx= object.velocityX

    Var vy= object.velocityY

    Var dot= vx*cos(dir)+vy*sin(dir)

    Set velocity to (vx-dot*cos(dir), vy-dot*sin(dir))

    Dot is the velocity along a direction and we're subtracting it from the velocity.

    You can avoid the position jumping by not moving out in the closest direction. Instead move out in the opposite direction, keeping track of how far we move out as this is the remaining distance to move. Then we need a way to find the normal of the collision. From that we can the correct the speed as with above and then try to move again with the new velocity, or basically just move in the same direction of the current edge with the remaining distance. This can be repeated as many times as nessisary but usually it's fine to do it once.

    One way to do the normal detection is to use overlaps at offset to check the positions around the object

    Var dx=0

    Var dy=0

    Overlaps at offset(1,0)

    --- add 1 to dx

    Overlaps at offset(1,1)

    --- add 1 to dx

    --- add 1 to dy

    Overlaps at offset(0,1)

    --- add 1 to dy

    Overlaps at offset(-1,1)

    --- add -1 to dx

    --- add 1 to dy

    ...etc

    Then the normal should equal angle(dx,dy,0,0)

    This requires that the object is all the way pushed out first before finding the normal.

    All this will cause a very high amount of collision checks and the object may jitter when repeatedly pushing out of walls due to pushing out a pixel at a time not being precise enough. Both can be solved by implimenting raycasting which can be used to find exact collision points and makes finding the normal simpler, that is once it's all setup which isn't really simple.

    Of course I may be overthinking a lot of this, and even after getting wall sliding working a few times I think it could be made a lot simpler. Instead of handling everything with equations to handle all cases you probably could get by by coming up with a list of cases and handling them one by one. For instance the third case in your image to move around a corner. For example:

    object is moving down

    Wall is below

    ---wall not below to the left

    ------ move object left

    ---wall not below to the right

    ------- move object right

    Just do that for all four directions. Still you'll still need some good collision response like above.

    Anyway I hope some of the above is useful in some way.

  • Until I add such a trigger you could use a sprite to do all the loading and on the loaded trigger paste the image into a paster.