I want to make a turn based strategy game but instead of doing it in 2D I want to do it in 3D so I can take advantage of 3D modeling animation, 3rd person camera support, etc… So for this reason I’ve been looking at Unity for the past month or so and I absolutely love it.
Question for the masses…what would be the best way to implement a grid based movement system (similiar to what was found in XCom or Jagged Alliance or most recently Silent Storm) in Unity? Have each square as a separate plane object and just move the player characters from 1 plane to another? Has anyone done something like this yet with Unity and might be able to share their experiences?
Two techniques I have used for this kind of thing:-
Just ignore the Y coordinate and use regular divisions of the XZ plane as your grid. If the ground doesn’t undulate too much then this works quite well (and is very easy). You can use a 2D array the same size as the grid to mark squares as inaccessible, muddy or whatever for pathfinding purposes.
Use a triangulated square grid as the basis for your terrain mesh (ie, start with a plane grid and vary only the Y coordinates of the points to create landscape). Then use the Mesh class to get the appropriate vertices and the edges that connect them. It is often better, actually, if you use a second, invisible mesh that is derived from the terrain. That way, the movement grid doesn’t have to be as detailed as the terrain geometry and you can also use “impossible” coordinate values to code information for pathfinding, etc. For instance, you could say that any vert with a Y coordinate of -1 represents an inaccessible grid square (like a river, deep hole or something).
(Of course, the grid doesn’t have to be square - you can just as easily make a hexagonal/triangular grid and use either of the approaches above.)
Well it’s actually going to be a football field so it’ll be flat.
So what you’re recommending is to have 1 plane with the grass and field line textures on it, and then an invisible plane on top of that to use as the grid?
My plan is for the layout of the field grid is since a football field is 53 1/2 yards by 120 yards long I’ll add a row of tiles on each side to detect if the player is out of bounds. I’ll cheat and get rid of the 1/2 yard. I want each tile to 1 yard by 1 yard so I can easily track stats so my grid array will be 55 tiles (yards) wide by 122 tiles long.
I haven’t actually started coding it yet, I’m just theorizing at this point so any tips or direction is greatly appreciated. 8)
I should have guessed that from your username… (I remember a game called BloodBowl from ages ago that was a sort of fantasy combat gridiron thing, come to think of it.)
Since you are doing a flat field, you needn’t bother with the navigation mesh at all. Use a plane for your field and scale it so that one unit in 3D space corresponds to one yard on the field. Then, you simply move your players in unit increments in the X and Z directions to move one yard in a given direction.
For pathfinding (dodging opposing players, etc), you could use, say, an integer array with one element per grid square - you would just use a different integer value to represent the friendly and opposing players, the referee and whatever else.
If you are going to move players based on a certain number of yards per turn, then it will be a bit more accurate if you count diagonal moves as 1.5 yards (the exact value of root 2 is not intuitive from a gameplay point of view).
It’s easiest to begin by having just a few human controlled characters and then add a computer controlled opposition later. The most obvious approach is simply to read keystrokes in the Update event and use a multi-branch “if” statement to react to them. However, It will help if you define a set of code values to represent each type of move a player can make - these can be as simple as strings (eg, “Forward”, “Left”, “Right”) or numeric values. You then convert each keystroke into one of these values with a multi-branch “if” statement and then use a separate switch statement to respond to the command code and make the move. The idea is that when you do eventually add a computer player, you can use a sequence of these commands in an array to produce a complete turn’s movement, but otherwise use the same code.
Instead of keystrokes I want to use the mouse for movement, at a high level Select Player, Select “Move” from a popup menu, and then a square will appear at the mouse cursor you can move around and choose where to move your player while showing the cost in points somehow. I was thinking a grid originally because I was centered on the fact of showing a grid to the user and having each block highlight as you moved over them with the mouse. Instead I could show a grid with a texture, and just have a block that just moves to the x,z point where my mouse is I guess.
I’ll probably start with keystrokes just to get the guts of the system working and then move on to the mouse movement. I don’t know yet the best way to implement an algorithm for choosing the fastest path to a given point (A* I guess) for a player.
Thanks for the help! If anyone has anymore tips or advice by all means let me know.
I think a plane object is a 10x10 square, actually, so your scale should be 5.5 : 1 : 12.2 to get one unit equal to one yard.
In that case, the control system will be even more similar for the computer and human player - the only difference is how the target position is chosen.
I’m guessing that a player fully occupies a square in your game (ie, another player can’t run through an occupied square). If that is true, then you will probably need to use an A* system to plot paths. However, this will only find the shortest path - if there is some tactical reason to prefer one path over another to a given position then you will need to reflect this in the game (perhaps let the player mark waypoints).
Thanks for the help andeeee, you’ve been really gracious. I appreciate it.
Yes you’re correct, only one player can occupy a given space (or at least that’s the plan without any coding yet) so A* will be the way for me to go and then tweak from there.
In Maya, I can change the grid dimensions to anything so I was thinking that I would change them to 1 x 1 yard, export the UV and then do my football field textures on that UV as the way to create the field. And then export that object to Unity 3D.
You mention using an Unity plane object and set it to the above scale dimensions.
Can I achieve the same texturing with a Unity plane object, ie, grass texture with the field lines drawn on top. I’m not entirely up to speed on Unity’s 3D modeling capabilities in regards to texturing and what not.
The method you suggested with Maya is probably better.
I’m reasonably sure that the measurement units in 3D modelling apps are just for decoration. The numbers are the significant part - you can interpret them as yards, inches or whatever you like.
I gotcha. Since I’m not real familiar with Unity yet, I guess I’m just unfamiliar with how things translate between one another.
It sounds like when it comes to movement, Unity dictates what 1 unit of movement is. So for example if I create a plane 20 units long in Maya, when it’s imported into Unity, will be it 20 units of movement long? I guess the simpler question is the scale the same between both apps when it comes to units?
Although, if you are using physics, its better to think as meters in Unity, or you will have to scale, to the units you choose, every parameter in physics components and settings, and no one knows what could happen if you use very large or very small numbers in there.
Just set the units to meters in your modeling app and you are done.
(I remember a game called BloodBowl from ages ago that was a sort of fantasy combat gridiron thing, come to think of it.)