First-Person Grid-Based Movement

Everynone,

When you get a minute and this last part is most important - you have the time - can you point me to where exactly I need to hook my grid into the controller and how? I’m having a heck of a time trying to implement snap to grid movement, as well has hooking the grid into the controller. All the tuts and classes that I’ve taken involve point to click on grid tiles and I’m just not getting it to hook into the controller.

Some caveats. I moved all the files into a “Core” folder for ease of migration for others (I have dice mechanics in a 5.4 project, I’ll eventually move this over to and integrate). The day timer works, but the HUD is very ugly and it’s on an temp event tick, as my keybind command isn’t working property (I need more experience with the new EnhancedInput). Also, ignore the BP_SunController - I thought I coded it correctly, but it’s not moving the sun. Need to do more testing.

[EDIT] - Oh, the file is in 7zip format, if anyone needs to know.

What does this mean, precisely?

we

We want to move on the blue grid? Note the grid is purely cosmetic, you move with math - tell the timeline the coords.

I have my grid all set up, but I can’t get the FPS controller to actually move along it. My experience with grid based movement is only with point and click. I’m not understanding how to actually move the controller itself, using key input instead of mouse input.

The grid size is here:

Eyeballing the grid tells me it’s 400uus, place the player start in the middle, set the Move distance to 400, and you should be ready to go. If you’re anticipating inaccuracies (that may or may not build up over time), you can snap the resulting vector:


One note, you named it:

This is quite misleading (hence my original question), because the engine has a dedicated Player Controller class.

Oh, did you already set up the grid movement and I missed it? My Grid is purely for building purposes, so you don’t put a wall or something in a place where it blocks movement or you can’t use an event trigger, like a door. So your version works on the nav mesh and doesn’t require a Nav Mesh bounds volume?

It does not work with navmesh and does not require one. But if I was to seriously consider this a project, I’d definitely set it up.

Oh, did you already set up the grid movement and I missed it?

I mean, this was the whole point of this exercise from the get go! :innocent:

Correct. I was working on 4m x 4m grids. I appreciate the help. This entire time, I was trying to force the controller to move again using another blueprint. Alas, my experience with UE is less than adequate, but I’m getting there. It’s projects like these that keep me interested.

Indeed. I couldn’t think of a better name and after spending 15 years in the industry working with proprietary engines, I have OCDs when it comes to naming.

Which is exactly what I was intending. I wasn’t sure if your code worked with the Z Axis and I wanted up and down movement. That’s why I started working on grid code. Good to know I just need to focus on navmesh integration.

I literally have been spending 6 months just to get the FPS (well, I started with the TPS, as I have more experience with it) to move in this way. Thanks for all your help! I’ll make a new thread with the updates I make, so next time, if someone comes looking for a Dungeon Crawler, they’ll have access to one that is being maintained. :slight_smile:

Not sure if relevant, I see you’ve incorporated procedural mesh for the grid. Not 100% what the intent is but if the plan is to create actual tiles to move on, consider a HISM:

It works with navmesh:

Just a thought, perhaps not applicable - my understanding of the final goal is somewhat fuzzy. Perhaps you want to design the adventure map in Notepad :spiral_notepad: and import it :person_shrugging:

If you’re after something more exciting, like procedural generation, do look into Wave Function Collapse - it’s a general concept that yields pretty good results.

That I’m not quite sure about yet. I have the Dungeon Crawler Kit by ■■■■ Overbye. It’s nice and robust, but I wanted something that had rounds and turn based combat, which it doesn’t. He’s also missing things like stores and what not. I was looking for something more pure, like Might & Magic, Wizardry, Bard’s Tale and DCK is more like EOB. I have two grid systems. One uses procedural meshes to draw the lines and works very well, but it’s stuck on a 2d plane and doesn’t use Z. The second DOES work 3d (at least I think it does. I haven’t actually tested it yet. I’m still working on setting up line by trace for angled meshes), but it uses Draw Lines instead. I borked my code, though, so it’s not doing all of my lines.

The goal is to create a grid that is displayed, in the editor, where you can snap walls, floors, doors and fluff to, with a blueprint special that can run event code for actions, such as traps, spinners, forced encounters, et al. The grid system, itself, is modular, so if someone wants to do change tile size, height or line width, they can in the details panel once they drop the grid system in the level. I would prefer that this system use the built in navmesh from the start, but as of now, I’m using a bounds volume for testing.

The goal is to create something similar to the old Bard’s Tale Construction Set, but it’s a modular set up so the GameMode functions as a DungeonMaster (BP_DungeonMaster) and it loads all the relevant modules for each game system. When kiddo wanted to learn how to mod Fortnite, I figured why not just teach him the engine himself, so I took a couple of intro courses to map out ideas for a course outline. That was last year. After I saw the blueprint code system, which is near identical to the workflow for node based materials (thank you, Maya!), I figured, “Hey, I suck at actual coding, but I’ve always been able to read it and I’m a whiz at node-based material functions, so why not try?” and here we are. I’m starting with Bard’s Tale, as I have more experience with it, but since it’s similar to 1st and 2nd Edition AD&D, I would make that my next module to work on. Then, I was going to get snarky and try to make a GURPS module. It’s what I have most familiarity with, as I pretty much worked on BTBuilder since 2009. There were a lot of features that it was missing, which I wanted and the dev went MIA. The longer this holds my interest, the more I’ll get done. I’ve seen a ton of people wanting an old school dungeon crawler, similar to this - myself included- but the devs typically never released their bits, so I figured I’d get a full-on working movement system done first and make sure that doesn’t happen again. No matter what, I’m going to get this controller moving on a grid system, so at the very least, someone else can get the ball rolling on making a dungeon crawler that ISN’T like EOB (There are two on the market. They both function in a similar style, neither of which I want.)

Sorry, to necro the thread, but I’m have a bit of an issue with this part. Is the capsule trace supposed to go AFTER the line trace, 'cos I swapped the line trace with the capsule trace and followed your schematics, but the only thing it did was prevent the grid movement from moving at all. I thought it might have been my Branch to switch between Free-Form Movement and Grid Based but it did it, before I made the branch and then after, so I wasn’t sure what I was doing wrong. I’ve been digging on tuts to see if I could find any answers, but no joy. Can you either give me an example walk through or just update my build with either up or down so I can just use your OG template to make the other?

BTW, I finally went through your controller node by node to get how it works. That’s some trick coding you did there - I’m learning quite a bit from it. I’ve branched to do either grid based movement or free-form, based off a dev bool, so you have your choice between old-school grid based movement, like Bard’s Tale or Might and Magic or open-world like Wizardry 8. The bIsGridMovement should be set to true, but if it’s moving in free-form, I forgot to toggle it again, in testing.

v3.3

Updated with the ramp movement which is now smooth, too. Added 2 functions, leveraging the existing trace:

In short: if the path is not blocked (green), we trace from the top-down using a capsule (orange):

The resulting hit is the location where we need to move to, and the surface normal can be easily turned into a Control Rotation value, which is also now utilised during movement in order to look up / down:


Project link:

One unsupported thing is rotating sideways while standing on a ramp. Hope you can work on that. Good luck!

Appreciated o7. I’m trying to set up the HISMC_grid like you were talking about. At the same time, I’m trying to set up draw lines to support negative and positive Z axis, to see if either will work. I need to find a good tut on using these HISMC meshes. I don’t think my code is correct. It’s not instancing any meshes that I can see, with the HISMC.

I’m going to go dissect your new project so I can see what you changed. :slight_smile: I’m curious as to how I set up wrong. I was sure I had it right.

[EDIT] - Now I get it. The incline was it’s own separate function! That’s why it wasn’t working and causing the grid movement to lock up and freak out!

Everynone, is there a way I can we can change that green arrow? I changed the step length to 400 (which is what I need for my gridsize default), but once I do, it can no longer move up the slopes, apparently more than 200 cm? I’ve taken apart your blueprints (I do this every time and recreate them by hand, for experience. I can create a controller now with IAs by heart, without messing them up and movement working perfectly thanks to you :D), but I’m not understanding the math that’s required.

I THOUGHT this was the place there you would update the math, but it appears I that am incorrect. Then, I came back here to re-read what you wrote and I realized it probably has something to do with that green arrow as an incline of 400 would block it completely, so it explains why I can’t move up more than one step on an incline. I tried overwriting walking slopes in the capsule and the movement in the controller, but that didn’t work. I’ve literally changed every vector/float variable I could find in both the Find Ramp Location function and the Find Ramp Incline.

If the green trace hits anything it will be considered blocked, and treated as an obstacle; this could easily happen with steep inclines or when already on a ramp:

Many, many ways to handle it: consider checking how steep the hit surface is early on, perhaps there’s not even a need for the 2nd trace when dealing with upwards ramps:

Dot Product tells you how aligned two vectors are. You can aCosD to get degrees if that’s easier to work with.

This would be only useful if were using the movement component for movement, with navmesh and all. This, however, is an old-school, manual method where we have all the control in the world but we also must do everything ourselves.

I’ve literally changed every vector/float variable I could find in both the Find Ramp Location function and the Find Ramp Incline.

As above, if you opt for this method, you will need to script everything (as with any other method, tbh). Note, this script is a tiny stub done over a lunchbreak, so to speak - much more work is needed to make it a movement system that accounts for all the scenarios (that I don’t even know about). And to put the money where my loud mouth is:

This should :crossed_fingers: allow you to traverse on ramps no steeper than 40 degrees rather than simply block movement. Cranked these two up since we must deal with more vertical space now:


The next step I’d consider would to be to isolate what we’re tracing against so you can differentiate between a walkable surface, a prop, an enemy and everything else in between. Understanding Object Types and Collision Channels will be handy:

https://www.unrealengine.com/en-US/blog/collision-filtering

Good luck!

Oh. So that’s what it was. I never thought to put a greater than node there, as I wasn’t entirely sure what that part was (I just read it’s tooltip that popped up) I was just doubling the bottom number of the vector add, following your original design. I made it 400, since the original was 200 and the top 200, since it was 100. Now I’m following along. There’s always something new to learn!

Thank you so much. As I said before, I’m more on the 3D Artist side. Most of my experience is setting up animation rigs, doing the animation itself and modeling, but hey, thanks to you, I’ve created not only my own FPS Controller, but also a TP Controller and a Top Down (all with a module set up for different types of footsteps, depending on the ground type!) I have some experience now with Object Types and Collision Channels, thanks to the footprint tutorial I was following, when I couldn’t find out why the elevation movement wasn’t working. I’ll be sure to read those while the Wife is at her doctor’s appointment and I’m sitting there, as support.

Now is the time to start clean, and go step by step again. I’m at a point where I’m sure I can do the majority of it now, without looking at all the screenshots I made of all your flows and functions. Again, thank you so much. I’ve already got kiddo working on dungeon level prototypes and he’s having a lot of fun making maps that he’s buidling using Dungeon Architect (I picked it up when I came across a nifty plugin called “Electric Nodes” during the grid tutorial I used. I have DA for unity, but didn’t for unreal. Now I do, along with Electric Nodes which is so much nicer for spline work in Blueprints)

Thank you again and especially for taking out of your lunchtime to do all this. You have no idea how grateful I am. I think I can handle the rest on my own. o7