[SOLVED] Delay is now there but Character will not move

  • Hello,

    I am creating a game where the Tile Movement behaviour is the primary form of movement for both the player and enemy characters.

    When an enemy is travelling in a direction it will need to stop and chase the player instead when they 'see' them (if player.x = enemy.x or if player.y = enemy.y and there are no obstacles in the way).

    However, I am creating my own bugs by doing that because instead of the enemy stopping on the in-line tile to change direction, they either keep going and ignore the player or they move to the next tile and then attempt to chase which causes them to get stuck.

    I want to be able to get all character objects to wait at least 1 tick before moving to the next tile, getting everything to wait 0.03 seconds after simulating control does not seem to work.

    Please help me get my head around this, I've been working on it all day and I'm stuck.

    Thanks for your help in advance.

  • What is your logic for movement, you simulate control every tick then wait 0.03 seconds? Let's see the events for enemy movement.

  • Hey plinkie,

    Thank you so much for responding. I couldn't get help from anyone better considering the type of game I am making! :D

    dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

    Note: You'll need to scroll down to the Cheeky and Clamp Categories to see the events for movement logic. I created my own LoS since the LoS object seemed to be conflicting with the way I wanted it to work (Characters have to be equal on either or axis and clear of all obstacles).

    Edit: Sorry the wait was 0.3 not 0.03. My initial information to you was wrong. That's fatigue talking after spending late nights up trying to work all this out haha!

  • Holy shiz that's some events, I was expecting something basic haha. Looks like the problem is he freezes because your normal movement of clamp stops if seescheeky is true, so maybe you need to override or create new movement events for when seescheeky is true? Maybe it's not that simple as it's quite in depth but I had a good read of the event sheet.

  • Thank you plinkie for your advice.

    I thought I already created movement for him when he is b_SeesCheeky because, for example on event 66, if he sees cheeky but his charbox object is not on the same tile as cheeky's silouette then he should move, so I am a bit confused here. I'll have a look for a conflicting event that might be stopping this from happpening. I was pretty sure I put all of his movement commands in one group.

    Sorry about the complicated events. I'm just trying to achieve the following and if I can get this fixed, I'm done with Chomp's movement:

    1) Chomp spawns out of cave and moves out of the cave, depending on where the cave is facing (done)

    2) Chomp randomly patrols, assisted by a timer (on timer events change his direction to a random direction, making his routine unpredictable)

    3) Chases Cheeky when he sees him.

    4) If Cheeky goes out of sight during the chase, Chomp will stop at his last seen location - This is why I get Chomp to only 'see' the Silhouette that I have on Cheeky. The Silhouette will follow Cheeky everywhere until Chomp sees and then 'loses sight' of him.

    However, the trouble I am having is:

    1) Getting Chomp to accurately stop his movement the moment he is in-line with Cheeky on an axis (clear of obstacles) every time as it's only happening sometimes and;

    2) When he is chasing and does catch up to the Silhouette, instead of stopping on the same tile as the Silhouette, he exceeds by one tile. This happens almost every time.

    It's like Chomp is moving too fast for the game to stop and go "Okay I'm on this tile, I need to do this now." This is why I was hoping to find some way of getting this checked without creating noticeable jerky movement in the game play.

  • Ya I was expecting simpler tile movement events but you have a lot of events with sub events running every tick, and I can't edit the file as I don't own C3. I just apply the same logic from C2 on projects I can test :D I did notice that event 77 doesn't have a wait though which might cause inconsistencies.

  • Oh I see. No worries, you seem like you have a lot of experience though, so any advice would be appreciated of course.

    I am still searching through my events regarding what you said about b_SeesCheeky = True is stopping movement.

    I have also added an else condition in for Clamp Direction, I'll post again with an update soon. I am hoping to overcome my issue this way.

    Another idea I had was to use the timer behaviour to initiate movement, that way I might be able to give Construct 3 the chance to consider the position of objects before moving again, but I have not tried this yet.

    Edit: I'm a bit inexperienced with the 'wait' system action, I sorta just threw it in there thinking it would allow the game to check other things before coming back to that event again. Am I wrong to do this or do you think a timer would be better?

  • Yeah I was about to post that the top level of the moment for clamp should really start with an on timer, that way you can split it out easily. On timer, then check if the angles match up with cheeky, if not then move. I think the rotate happening independently is going to cause problems too, you should try and fit that within the movement somehow, I think a lot of those events can be trimmed down so you have more control.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I have been very careful to ensure that rotating and moving are completely separate and do not happen at the same time. I wanted to provide the effect that the Clamp is changing direction but I did not want it to interfere with the Clamp's movement. Clamps should not be rotating at the same time they are moving, basically. What kind of problems do you believe I may have with the way it is now?

    Also, after checking my events, I cannot see where b_SeesCheeky = True was stopping movement. However, I can see there is a problem with him chasing to the right as oppose to chasing downwards. I'm still trying to see how this is not working.

    What I might do is start doing the timer idea and then come back to this and see if it's still happening. I get the feeling that it has something to do with the conditions checking the i_Tile_X and i_Tile_Y variables.

    I also get the feeling that there is definitely a shorter way to do this but my limited experience is preventing me from working that out.

  • Okay, I am more stuck than before now. I have put timers in, this has now fixed the delay issue with Chomp (I'm yet to add a similar mechanic for Cheeky), but now Chomp will not move at all when he sees Cheeky:

    dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

    All I did was change it so that I was considering Chomp's X and Y. If they are not the same then simulate control in the appropriate direction. It's not doing that, so I am very confused. What am I doing wrong here?

    Edit: Definitely an issue with considering the X and Y. The conditions there were wrong before moving the clamp. I have now fixed this problem. I just had to think more about how event conditions work more.

    Indeed I could tweak all this to perform better, but I have not got to that stage yet.

    Thanks for your help, Plinkie!

  • i would like to take a look at your isolated movement part of the code if possible.

    what my suggestion is if is not possible to be shared, is that you could try instead of using X or Y as prerequisite for line of sight and instead use movement direction +distance from where it should stop.

    for example if enemy is moving only in a foward type of patern or clockwise lets say in a square or round pattern, u can say that is "front_movement" if he moves any other direction then is not forward... with that logic in mind, adding additionally a distance to stop from objective point reached.

    so enemy is moving_forward

    and

    distance(enemy.x,enemy.y, player.x,player.y) less or equal with 32 pixels lets say don't know ur grid size but lets assume u have a 32 by 32 grid movement block that means he is on a block adjacent to another meaning he needs to stop at a 32 pixels distance from players XY.

    hope it makes sense to you and helps you achieve a new solution.

    if it doesn't i could demonstrate it to you on ur tilebased movement i guess.

    also the movement should be general for all enemys, not just 1 type of mob... with little tweaks for type of mobs of course but the core movement system should be the same for all enemy (ex distance+movement forward has to be basic rules, what is considered additional ruling based on class is up to you to decide being it speed movement, waiting time etc), otherwise you will cause long run development conflicts.

    Try refresh the page using shift+f5 or ctrl+f5 to force clear the website memory cache... i tend to edit a lot of times my posts.

    Edit ~5: the problem i see with using x enemy = player x or y is that the enemy if is a large patch of grid movements, then the enemy can be at 10-20 grid spaces distance but on same X or Y and that would might be true for the logic of the system, but it would look glitchy as hell, as won't be near the player at all.

  • Hey GeorgeZaharia

    Thank you for your interest. I understand you wish to have a look.

    Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

    This is my current version after the fix I made. Please check it out.

    I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

  • Hey GeorgeZaharia

    Thank you for your interest. I understand you wish to have a look.

    Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

    This is my current version after the fix I made. Please check it out.

    I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

    Cool, thanks il upload my own version on a personal link, u can remove urs from public view, also, i just noticed this says Solved in title yet the last commentary you posted about being "solved", i sort of skipped it(my bad). il try simplify ur movement if u didn't already i guess and get back to you.

    took a quick glimpse at the movement, is a bit overworked but it does what u intended so it should be fine.

    but u could just added pathfinding behavior to the Clamp, and go with a logic somewhere like when he has line of sight on player find path to player and make it move towards player along the path every time%speed where speed = anywhere from 0.1 to n which would make him look like is doing tile movement pattern.

  • Cool I'm glad that you managed to find a fix there, I wasn't able to mess around with it :)

  • > Hey GeorgeZaharia

    >

    > Thank you for your interest. I understand you wish to have a look.

    >

    > Please go to this link I have made available: dropbox.com/s/9upzsaiuaorva6p/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p

    >

    > This is my current version after the fix I made. Please check it out.

    >

    > I have not read your entire post yet because I have to go out. I'll be back and have a proper look at what you're saying.

    Cool, thanks il upload my own version on a personal link, u can remove urs from public view, also, i just noticed this says Solved in title yet the last commentary you posted about being "solved", i sort of skipped it(my bad). il try simplify ur movement if u didn't already i guess and get back to you.

    took a quick glimpse at the movement, is a bit overworked but it does what u intended so it should be fine.

    but u could just added pathfinding behavior to the Clamp, and go with a logic somewhere like when he has line of sight on player find path to player and make it move towards player along the path every time%speed where speed = anywhere from 0.1 to n which would make him look like is doing tile movement pattern.

    Hey George. I just read your post. Your initial explanation in your first post seemed a bit unclear to me. Yes I do plan to make this type of movement uniformed across all character objects, and I do feel like I am overworking the tile movement. I'd say this is because of the combination of different AI: Patrol vs Chew vs Chase vs not moving onto Obstacles that I have to consider.

    I did consider the pathfinding behaviour a few times. But I kept coming back to the tile movement behaviour since I was not confident that the path finding behaviour would deliver exactly the type of movement I am wanting for my game. However, I would really love to see your suggestions to improve it, regardless what it is, if it's good and it works well with what I am after, I'll implement it and give you credit.

    My opportunities for development in getting better at Construct is to stop over-complicating basic functions because often I would put in extra conditions in for an action that is not necessarily required. I try not to do this but sometimes because of how Construct works I have to provide additional work-arounds. For example, you will notice before my clamp moves, his angle snaps to exactly the correct angle. This is because despite my attempts to stop his rotation when he faces a certain way, he will miss the angle he needs to be at or he will be off by a few degrees which ends up causing other bugs. The same thing happens with snapping his axis to exactly the silhouette's. If I don't do that, it might be 0.00000001 pixel off, so the event for chasing Cheeky will not run because it's not the same. I like the idea of checking his position in comparison to the the silhouette in pixels because doing it tile based seems to conflict because the image of the CHARBOX objects are different sizes (which seems to cause a slight misalignment despite the fact that all tile movement behaviours are set to 32x32), rendering checking position in such a game to be inconsistent, so I need a more consistent approach. At my experience level, I found that this was the best thing I could up with. It's also comforting to know that my characters are perfectly travelling and fixing themselves accordingly. However, I honestly believe this is the difference between my personal experience with Construct's engine as opposed to most people on this forum such as yourself. I am always very open and interested to listening to feedback about how I can improve my projects, so if I share something I am working on, do not hesitate to provide your recommendations because I want to learn. =]

    plinkie Cool I'm glad that you managed to find a fix there, I wasn't able to mess around with it :)

    Thanks! I wish I could private message this but why do you choose Construct 2 and not Construct 3?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)