koobas.hobune.stream
Is making a 2d tile based game all in UI a bad solution or is it viable?
I'm making a 2D mobile game in which the entire game view is contained within the screen. There is no scrolling. The game is also grid based in that, depending on the difficulty of the level, the playable area will be made up of a certain number of square tiles that all fit flush within the screen. If I make everything based under a canvas then I can easily position things so that they are aligned next to each other as rect transforms are based off of pixels and I can calculate how wide the tiles need to be based on the screen resolution so that it gets filled to the edges of the screen.
Is this a bad approach? I looked into tile maps but I don't know how to align them with screen space so that the edges are flush with the sides and the top, or flush against a UI element like a top menu bar. Is there a way to do that and would it be better than doing everything under a canvas? Is there an alternative solution that I didn't mention or is making everything in UI a fine solution?
You'll end up with a lot of rects / images whatever you want to use for the tiles. This might cause a lot of performance issues due to the amount of rendering. Which you wouldn't get if you went the $$anonymous$$esh route.
@shadyproductions how would you go about the mesh route? I need to align the game view with ui elements and the game view has to be divided up into square tiles that fit flush against the sides of the screen and a menu bar at the top which is a UI element. Are you saying to convert between pixels and units in unity? I've tried that in the past but its kind of a pain. Not sure of an easy way to do that.
there won't be too many ui elements cause the bulk of the tiles will just be one sprite with a tiled texture and I'll just use the tiling component on that texture. There will be a few other objects in the scene but it shouldn't be more than a few dozen I'd say. I've tried doing meshes in the past but I'm just not sure of a good way to convert between pixels and unity units so that I can easily size them through code at the generation of each level.
Depending on what you need this can lead to some issues. But from the way you describe it i see no issues with that approach.
Alternative solution would be to get Screen.width and Screen.height on startup and then use those numbers to calculate size and position of your objects. Assuming of coarse the screen resolution don't change during run-time.
@DrZarqawi what kind of issues can it lead to and what does it depend on exactly?
You say get the width and height at start and use that but that just gives you the dimensions in pixel but if I were to use a game object that uses transform and not rect transform, then how do you convert between the two? There seems to be no easy way to do that unless I just haven't looked in the right places? Is that a good solution to convert between the two and if so how exactly do you do that?
Collisions would be one issue, that the Canvas wouldn't be able to handle too well.
To accomplish the alternative solution you would need to be very structured with your assets.
Decide on a base pixel to units ratio (default 100 px.per unit).
$$anonymous$$ake sure all sprites sizes are the same size
Then decide how many tiles fill the screen in each direction.
Divide Screen.size.x with X amount of tiles and divide Screen.size.y with Y amount of tiles. Lets call that CellSize.
Then lets scale the CellSize to fit the screen, (1/PixelToUnitRatio) * CellSize.x;
(1/PixelToUnitRatio) * CellSize.y;
Set your tile objects localScale to the scaled CellSize
When positioning your objects remember to offset by half a scaled CellSize to each axis relative to the grid position, since its pivot is in center of the object.
Example:
Positioning at coordinate (3,4):
//Gridsize is defined elsewhere as a Vector2Int
Vector2 topLeft = new Vector2(scaledCellSize.x * (gridSize.x * .5f), scaledCellSize.y * (gridSize.y * .5f))
Vector2Int gridPosition = new Vector2Int(3,4);
Vector2 position = new Vector2(((scaledCellSize.x * .5f) + (gridPosition,x * scaledCellSize.x)) - topLeft.x, ((scaledCellSize.y * .5f) + (gridPosition.y * scaledCellSize.y)) - topLeft.y);
