LukeWolf's Forum Posts

  • Hello.

    I know it's been a while but I just wanted to share that I have worked out my problem.

    I was not able to do this even with collision filters. Instead I removed the idea of using solids like this all together and instead had to use a helper sprite to detect ahead objects that were not solids but did not want my characters to move there.

  • Nice. I'm in the same boat as you in that regard, except I'm using C3, mainly for convenience and I like the dark theme. I've got like 5 ideas on the table for games. This is the first one I am taking as seriously as I should. :P

  • > Hey GeorgeZaharia

    >

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

    >

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

    >

    > 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. =]

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

  • Hey GeorgeZaharia

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

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

    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.

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

    https://www.dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p?dl=0

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

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

  • Thank you — 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Hey —,

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

    https://www.dropbox.com/s/dmm8nolsu07s9ck/Chomp%20%27N%27%20Cheeky%20Unsaved%20Maintenance%20Version.c3p?dl=0

    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!

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

  • > For anyone that wants to revert back to the previous version of r137 in the mean time: construct.net/en/make-games/releases/beta/r137 - Your projects should work in this version. They work for me.

    It is useless to return to the r137 version, since if you save the project in r138, the program will display a message that the project is saved in a newer version and cannot be opened in an older one.

    True, any way to fix that?

    In Construct 2 you can edit the proj file and revert it back I believe, I'm not sure how to do it with Construct 3.

    I might be just lucky not to save my project with r138!

  • I'm glad I'm not the only one with this problem. I actually wanted to work on my projects today. But I hope this is all recoverable.

    It seems as though as some objects that do not appear in the layout will have the layout load but once they are on screen your layout will just be black.

    For anyone that wants to revert back to the previous version of r137 in the mean time: construct.net/en/make-games/releases/beta/r137 - Your projects should work in this version. They work for me.

  • Hey guys,

    In my game, I have:

    a 32 x 32 grid.

    I use the Tile Movement Behaviour for characters to move along this grid.

    And enemy spawning points with a size of 32x32 and have the solid behaviour.

    What I'm after:

    I have been trying to find a workable method so that the enemy spawns on their spawner, moves out one space out, and then set it so they can no longer go back to their during their randomised 'patrol'. Also disallowing the player or other enemies to go through the spawner while spawning is happening.

    I have tried doing it here:

    dropbox.com/s/javskaf8b2h0ch5/Spawning%20on%20a%20Solid%20Then%20Moving.c3p

    It does not seem to work, can I please get some help with alternatives?

    Thanks!

  • Yeah I am using 8-direction. Sorry I forgot to explain that.

    God I just love you and your ideas. I didn't really understand it at first but I do now.

    So I should be able to use my code to make this work.

    I just have a lot of buildings to put together with two pieces.

  • If I did do that, it would solve the problem on the left hand side but not if the character comes from the footpath or the driveway, it would still look like they were underneath the building. I am trying to work out a way I can organise it with events but I keep running into road blocks at every turn.