Best Way to Create a Tile Engine in Unity?

I have my own thoughts around how to do this but I wanted to see how others in the community have done it or would do it.

Just for some reference I need to create a tile map that is 122 tiles long by 52 tiles wide and be able to assign objects (avatars) to move to each tile. I also need to be able to track how many moves it will take to move to another tile from where the current object is. That might be outside the scope of this discussion but I wanted to throw it out in case someone had experience doing it.

 

some examples from others:

script:
http://forum.unity3d.com/viewtopic.php?t=13061&start=15

full package:
http://forum.unity3d.com/viewtopic.php?t=8172

: )

 

Thank you sir. I'm not sure if that's what I'm looking for. I want a 3D tile system, those look like 2D tile maps.

I should have mentioned that in my above post I should have been more specific.

I would like a plane with tiles on it that can be rotated around and panned in 3D.

 

example picture, maybe? Even just a sketch?
I'm still confused as to what you are looking for. I assume it needs to be dynamic, or otherwise you'd just model all the "tiles" in a 3D program in the layout you want and import it as one big mesh. Dynamic means using the mesh filter.

 

So essentially you're attempting a Final Fantasy Tactics / Shining Force III kind of thing?

 

re-reading the explanation again, I don't think he means that.

"a plane with tiles on it that can be rotated around and panned in 3D."

Huh.

A 2D plane? Even though the above solutions are "2D" you can rotate and pan on them in the 3D no problem. Then the above solutions are fine, I think. Another way to put it: There is no strictly-2D mode or anything in Unity. The best you get is something on a plane that you view from the correct angle and possibly orthographically. So, you can always view that plane from any angle in 3D.

 

I dunno. We have avatars on a 2D plane, with the count for how many steps they can make. Sounds like a turn-based strategy game to me; I picked my two favorites as examples.

All the stuff Aaron said is right, but I'd also add that saving yourself headache on the programming can be done by moving and spinning the camera, not the plane itself. You can actually parent a camera to an empty game object and rotate the object to achieve nice results.

 

I just figured you meant isometric 3D terrain when you mentioned final fantasy tactics, that's all.

Is this question answered or not, I wonder. lol.

 

Sorry guys, life beckoned and I haven't been back since. Yes I'm thinking an XCom like grid except for it being 2D Isometric, I want it to be 3D so the user can zoom in and rotate around the field to get better looks at the action.

How is this best implemented in Unity? As a 2D plane or a collection of 3D tiles? I'm just looking for ideas or if anyone else has done it already I would love to learn from them.

Thanks.

 

I think both are fine options and it may come down to your other requirements.

For a 2D plane that you just divide up into squares internally (for movement, etc) has some advantages:
- Can use the terrain builder to have a more natural playing surface (doesn't have to be flat or made up of 'tiles').
- Less work (I think?) since you don't have to place tiles or anything. Just make your terrain, assign a size for the virtual squares (like 5 meters) and off you go.

For a tile-based system
- Can customize each tile easier (change the texture on just that tile, move it, etc)
- Requires a more old-school design process of literally building tile textures, take more work for building your levels possibly.

Neither in concept should take much work just to see how it would work.

I'd recommend doing one Scene one way and another test Scene the other.

- Do one with a in-game built terrain and practice moving an object around as thought it were on a grid, same with picking and pointing at 'grid' squares on this terrain so you can see what's involved. I did something similar and one trick I did that worked out well is I created a "GridOrigin" GameObject that I placed on the terrain which marked the (0,0) of the grid. Thus, to figure out how a point on the terrain correlated to a grid point was just (in psuedocode) : "x = terrainPoint.x - gridOrigin.transform.location.x) / gridSize" (repeat for y which would give the (x,y) as grid squares)

- Then do another scene where you make tile objects and place them on a plane, place some object and move it around and select the tiles.

This should give you a good taste of both approaches and see which, to you, fits easier with what you want to do in the game.

(In case it's not obvious: i'm a big proponent of trying to write simple little tests to try out different options as many times your instincts will be different from reality in what is better)