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