Pseudo-3D Fixed-Camera Movement Engine- Collision Detection Issue

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    Morning all.
    This is my first post to this forum, to which I've been a reader for some time and have found some invaluable help with my project already.

    I am creating an adventure game based around static frames representing 3D "rooms" created with pre-rendered 3d objects imported as graphics and a 4-direction custom movement system which replicates the Z-axis by adjusting scales and vectors.
    However, to achieve a convincing effect of walking in a straight line in a square room, the forward/backward directions are skewed to an angle depending on the player's X-position in relation to the horizon "vanishing point", which is high up in the horizontal centre of the frame.
    The maths has been baffling so far considering I've learnt it as I've gone along.

    Please login to see this attachment.

    Now, if you'll excuse the pun, I have run into a bit of a problem regarding collisions- particularly in the forward/backward direction due to the interference of the added skew towards the direction of the horizon vanishing point.
    I've drafted up a test frame demonstrating odd lines and objects as obstacles in order to fully test the collision system- nothing fancy and in a couple of scenarios, when attempting to go forward/backward I can get the player to move through objects in the opposite directions because the collision loop is triggering when the collision marker (a black oval) object is placed in a position where it is still overlapping the obstacle, due to the effect of the skew- because the angle is literally reversed to match the direction the player came from.

    Please login to see this attachment.

    Any help would be appreciated.
    Until I overcome this problem, I can't really progress with the rest of the game, as obviously movement is crucial to any game.
    I can try uploading the .mfa file on request.

    My first thought is that if you can't detect the lines on the floor properly, you should break them into smaller segments to increase the fidelity of your collision. But it is a little hard to know the best solution without knowing how you are calculating and creating your 3D environment.

    Please login to see this link.

    It seems like you are not quite using fastloops correctly. You have a lot of redundant "Stop Loop" actions that are not needed. You only use a "Stop Loop" action INSIDE a fastloop. :) With that said, you already check if the detector is overlapping a backdrop within your movement loops. I would recommend adding in another check right after the movement event line (the one inside the fastloop) that check for the backdrop overlap. If there is an overlap, then you "back up" one step and then stop the fastloop. You also should be updating the ACTUAL X/Y Positions of the detector object to the variable inside the fastloop. This is the only way the detectors will update and actually be able to detect something inside the fastloop. I also noticed your collision detector shape for moving down is not the same as the other animation directions. You should probably keep them consistent.

    I have adjusted the up and down movement loop. It seems to have fixed the issue. i would do something similar to your other movement loops.

    Please login to see this link.

    Please login to see this link.

    Thanks for looking in to it.

    The collision detector is the same size in all directions, but I just included an arrow so that I could visibly see which way it was pointing to test when the problem was occurring.

    It would be fair to say that I'm probably putting "Stop Loop"s everywhere in order to attempt to curb the problem.
    I'm quite new to fastloops, as I originally envisaged using the standard 8-direction movement until I needed the speeds of X and Y directions to behave in different ways.

    I shall now go and have a play and analyse what you have done... Thanks for your swift assistance.

    I fixed the down animation direction (24) in the mfa I posted. If you look at the one you posted, it is definitely a slightly different shape. But in the end, you really don't need to do that animation direction switching. Just use a single image for the detector. Fastloops take some time to get your head around, but you seem to be going in a good direction. Good luck. :)

    Please login to see this link.

    Ah. Well done.
    I have a feeling I may have tried resizing it inside one frame in the animation editor. That'll teach me for not checking!

    I see you've condensed the collision detection events so I no longer need so many events for both backdrop and active obstacles (good old OR(Logical) function).

    I have now amended the left/right events in the same fashion and it feels solid as a rock now.

    Just one other thing...
    Would there be a way of over-riding the skewed angle so that when the object collides going forward/back, the player would follow the nearest appropriate Y direction, rather than stop?
    If this is far too difficult to fathom, I may just leave it. It's only going to be a real problem when the player follows the line of the walls at the edges of the room.

    I think you are going about this in completely the wrong way.
    You need to separate the movement engine from the visible sprites.
    You want to handle all movement, collisions and other interactions in two dimensions, using a pure top-down view - but keep it all invisible.
    Then you position your visible sprites using a simple a 3D projection - but those 3D sprites never directly interact with anything.

    I don't think it quite warrants the "top down" collision map, as the position of everything can be worked out by the X and Y positions of the relative objects using collision markers around the bottoms of the moving objects.

    Mobichan appears to have addressed my initial problem relating to the collision detection system (and my lack of experience when it comes to fastloops).
    My next query relates to "sliding" the player along objects in the Y-direction when colliding, because the player's Y movement is affected by a skew in the X direction towards the horizontal centre of the frame.

    I appreciate this may be a unique approach to 2.5D game design. I've not seen anything quite like this that I can draw inspiration from. Those racing games are a similar camera angle, but I don't desire that sort of movement which requires the scene to move towards the camera.

    I attach a couple of images to show how the gameplay will look:

    Please login to see this attachment.

    Please login to see this attachment.

    And yes, the "Corridor of Blades" is now fully-operational with collision detection and a gruesome death sequence.
    See this video:

    [video]Please login to see this media element.]

    Sorry, I didn't check back after you answered about the diagonal movement. I think the best approach with your current setup would be to remove the conditions for the negated inputs (ie, "(NEGATE) Left Arrow is Pressed"). That is what stops the other directions from running their fastloops. But it seems like you will have odd animations if you allow that, since your only animating the cardinal directions. Muddle Mole's suggestion is probably going to make your life easier for collision handling, but if you are prerendering your backgrounds, it might be hard to line up the collision with the visuals.

    Please login to see this link.

    Yes. I think my current collision approach works well, as I can calculate positions of everything as seen in the frame.

    Regarding the diagonal movement, I did try something:
    Creating separate events for the X-position and Y-position updates.
    It ALMOST worked, however, when walking straight into a wall, there's a clear bias towards either left or right, as the X-position event still runs, even when the Y-position events detect a collision, so this issue hasn't quite been solved.

    As you've noticed, I am only using 4 directions (due to the limitation of the animation- taken from a real video sequence with chromakey) and don't want to include diagonal directions as it would look awful.

    After a couple of months, I still haven't resolved this issue.
    The best I can fathom at the moment is as above- separating the X-value and Y-value events, but I'm still not happy with the side-effect of the player then "sliding" towards the centre of the frame (X-direction) when hitting an obstacle in the Y-direction.
    There must be a way to stop this, but it's beyond my capabilities.
    In the meantime, I've been focussing on the graphics side of things using Blender instead.
    Please login to see this attachment.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login