Is there a really simple and clean way to set up a grid-based system like this? I’m a newbie who is thinking of making a simple game and I thought a crude Dungeon Master/Eye Of The Beholder clone might be a good way to get started.
1 Like
there is one example script in unity wiki
http://wiki.unity3d.com/index.php/GridMove#C.23_-_GridMove.cs
i’ve used something like this also,
those don’t check for obstacles collisions though, many ways to do that…
you could try with with raycast, spherecast to moving direction - before moving,
or having some 2D array as an map (where cells have values that say whether the cell can be entered)
Well @mgear already answered while I was writing, but here’s my answer anyway 
I don’t know what is really simple and clean way to do this - still looking for that myself too… but you can model your dungeon walkable cells as a grid of blocks, either simply by using some number values in array representing walkable tiles, or use some class defining a block with all the details.
You can move from block to block by checking first if you can move from your current cell [0,0] to target cell [0,1]. If move is valid, then perform the actual move. You can map these dungeon “grid” coordinates to world coordinates, as your dungeon 3D models most likely are not the same size (grid cells could be imagined to be 1x1) and then perform a MoveTowards, Lerp or any other smooth movement from start position to target position. You will also need to map these steps based on facing direction; cell on the left isn’t the same cell when your party is facing east or north.
And then there is the dungeon / level map. Note that there are different ways to define visual walls and doors. Some systems use only two directions for walls, and doors and blocking “fences” can be either centered on the cell or between the cells.
You are also most likely going to need some sort of way to create the levels too, unless you are just creating a maze.
IMHO crawler isn’t a good first project, it can be pretty complicated to setup, but then again, I’m not a professional. Especially if you take those two games as an example, both contain actually quite a good amount of detail related to blocks, movement, walls/cell items and creatures, ignoring the discussion about serialization / dungeon persistence.
I agree with @eses that it’s hard to keep this stuff clean unless you’re super disciplined, and a grid based dungeon isn’t exactly the simplest task, but it’s not TOO bad.
Picking from @mgear 's post, keeping your own array is definitely helpful, but you could do it all by raycasting into the scene. I think the separate array is just cleaner, so you can present the world however you like.
I like this guy’s writing a lot and learned quite a bit from reading his goodies:
https://journal.stuffwithstuff.com/category/roguelike/
The key is to break up your tasks into small steps, and don’t try to make eye of the beholder in one afternoon.
Thank you for the tips, and I’m sorry I’m late to respond. Would any of these methods allow me to simply set the distance a character can move on an axis and then let me build a set of generic chess squares in the world-building window?
“Would any of these methods allow me to simply set the distance a character can move on an axis and then let me build a set of generic chess squares in the world-building window?”
I’m not quite sure what exactly you mean, but you’ll have to manage the movement of character yourself, and you’ll have to check your collisions too, no matter if you use “data only” or colliders.
If you use data only to define collisions, you could use some array. You can use custom class for cells or just ints for example to define your level “collision” data. It would look something like this:
11111
10001
10101
10100
11111
Then you keep book where you are in that array, say you are at above map’s cell 1,1 so then you know that that tile is 0 so it is open cell and if a cell right to it (2,1) is 0 (like here) then you can move to it.
Or if you don’t want to use data to define collisions, you can build your level from blocks either by placing GameObjects manually or by code to form an (visual) array of blocks. Then make them have a box collider. Then the collision checks can be done using one of many physics collision checks. If your character is at cell 1,1 and your cells are 3x3 world units, you could then do a raycast or some other collision check from x:1 + 1.5 z: 1 + 1.5 towards location 3 units towards your current facing direction. If there is a wall layer collider, then don’t allow move.
But IMHO I would go with array based movement.