I'm going to be using sktilemapnodes for my 2d iOS platformer. What is better or more efficient?
Using a single size sktilemapnode that is the entire level or breaking the area up into multiple sktilemap nodes.
Example:
I have 3 layers of backgrounds that I'm going to use for a parallax background effect.
1st Layer (furthest back) is just a gradient sky. I have it broken up into 512x512 px tiles. I only have 8 different tiles that can be used as a 1x8 grid of tiles. I could then continue this pattern left/right or up/down in order to have the sky be as large as I need it to be.
Question: My question is whether I should use 1 tile map node for the entire sky, or if I should break it up into smaller chunks that are repeatable (like the 1x8 grid). If I break it up into smaller chunks I wouldn't need it to be so big, and as the camera moves around in my game I can move these chunks around.
I'm wondering if this would consume less resources this way.
2nd Layer are hills. I have about 8 different tiles that are 128x64 px each. I can arrange them into a repeatable pattern to my liking. So again I can have a tilemapnode that is the size of the pattern that I can repeat, and I can create multiple nodes or I can just create the entire map in 1 node.
3rd layer is a little different because it is basically a pattern image of trees that holds 27 512x512 px tiles. 9x3 grid. But again, I can use 1 node, or multiple.
I'm just concerned with efficiency. What is going to give me the most bang for my buck so that I can have room to process other game objects. This is just the background u know....
With the Tilemapnode, I'm not sure if tiles that are not visible are not processed each cycle or if I need to do some sort of check manually. I want to have the options of having massive maps on certain levels. I'm new to using sktilemapnodes, so I'm trying to figure out how I would use them in the most efficient way possible.
Each SKTileMapNode is a single node. Apple does a good job of making sure that multiple map nodes don't use too many resources. That is why there is a single node for a map instead of a node for every tile in a map. It is common practice to layer multiple SKTileMapNode(s) to create a parallax effect or simply to create layers.
For example, a platform game with mountains in the background and clouds behind that would use a single SKTileMapNode for the mountains and a single one for clouds. This gives the added benefit of being able to use transparency in tiles.
Related
I am trying to make a Dungeons and Dragons app that has different editable layers of objects. The lowest layer should be the background, such as water, roads, etc. The second layer should be terrain objects such as trees and buildings. The third layer should be placeable objects such as players, monsters, NPCs, and chests.
I have been trying to use two separate SKTileMapNodes, setting one zPosition above the other, then placing SKShapeNodes on top for placeable objects. However, I cannot seem to get two SKTileMapNodes working simultaneously.
Here are my two SKTileMapNodes. I cannot use the editor to get any tiles to display in ObjectMap. The BackgroundMap is all of the coloration currently. I want to put a blank grid of tiles like such in the ObjectMap:
Blank tile
TileMapNodes (used imgur because of an error):
Is there a better way to accomplish my goals? I would like to use the SKTileMap as it is easy to change/ paint over.
How can I scale up the size of my world/level to include more gameobjects without causing lag for the player?
I am creating an asset for the asset store. It is a random procedural world generator. There is only one major problem: world size.
I can't figure out how to scale up the worlds to have more objects/tiles.
I have generated worlds up to 2000x500 tiles, but it lags very badly.
The maximum sized world that will not affect the speed of the game is
around 500x200 tiles.
I have generated worlds of the same size with smaller blocks: 1/4th the size (it doesn't affect how many tiles you can spawn)
I would like to create a world at least the size of 4200x1200 blocks without lag spikes.
I have looked at object pooling (it doesn't seem like it can help me
that much)
I have looked at LoadLevelAsync (don't really know how to use this,
and rumor is that you need Unity Pro which I do not have)
I have tried setting chunks Active or Deactive based on player
position (This caused more lag than just leaving the blocks alone).
Additional Information:
The terrain is split up into chunks. It is 2d, and I have box colliders on all solid tiles/blocks. Players can dig/place blocks. I am not worried about the amount of time it takes for the level to load initially, but rather about the smoothness of the game while playing it -no lag spikes while playing.
question on Unity Forums
If you're storing each tile as an individual GameObject, don't. Use a texture atlas and 'tile data' to generate the look of each chunk whenever it is dug into or a tile placed on it.
Also make sure to disable, potentially even delete any chunks not within the visible range of the player. Object pooling will help significantly here if you can work out the maximum number of chunks that will ever be needed at once, and just recycle chunks as they go off the screen.
DETAILS:
There is a lot to talk about for the optimal generation, so I'm going to post this link (http://studentgamedev.blogspot.co.uk/2013/08/unity-voxel-tutorial-part-1-generating.html) It shows you how to do it in a 3D space, but the principales are essentially the same if not a little easier for 2D space. The following is just a rough outline of what might be involved, and going down this path will result in huge benefits, but will require a lot of work to get there. I've included all the benefits at the bottom of the answer.
Each tile can be made to be a simple struct with fields like int id, vector2d texturePos, bool visible in it's simplest form. You can then store these tiles in a 2 dimensional array within each chunk, though to make them even more memory efficient you could store the texturePos once elsewhere in the program and write a method to get a texturePos by id.
When you make changes to this 2 dimensional array which represents either the addition or removal of a tile, you update the chunk, which is the actual GameObject used to represent the tiles. By iterating over the tile data stored in the chunk, it will be possible to generate a mesh of vertices based on the position of each tile in the 2 dimensional array. If visible is false, simply don't generate any vertices for it.
This mesh alone could be used as a collider, but won't look like anything. It will also be necessary to generate UV co-ords which happen to be the texturePos. When Unity then displays the mesh, it will display specific points of the texture atlas as defined by the UV co-ords of the mesh.
This has the benefit of resulting in significantly fewer GameObjects, better texture batching for Unity, less memory usage, faster random access for any tile as it's not got any MonoBehaviour overhead, and a genuine plethora of additional benefits.
I want to make isometric, tile-based, iPhone games with cocos2D.
Sprites need to be drawn on-top of other sprites that are "behind" it. I'm looking for the best way to do this.
I'd like to avoid the painter's algorithm because it involves sorting all the sprites every frame which is expensive.
The Z buffer algorithm is supported by the GPU and cocos2D so this is what I'd like to use, but there is a problem. Some sprites, like buildings for example, occupy multiple tiles. Assigning a Z value to such sprites is difficult.
These are the options I've thought of:
Comparing two buildings and determining which one is "in-front" is
easy. So buildings can be sorted then assigned a Z value based on
the sort order. This wouldn't be any different from the painter's
algorithm. The OpenGl ES Z buffer wouldn't be necessary.
Assign a Z value to each building based purely on its location on
the map (without knowledge of where other buildings are). I'm
finding this difficult. I think it is possible, but I haven't been
able to come up with a formula yet.
Use multiple sprites for images that occupy more than one tile, so
all sprites will be exactly the same size. Z orders can then be
easily assigned based on what tile the sprite is occupying. The
problem with this solution is that it makes the game logic much more
complicated. All operations on a single building will have to be
repeated for each sprite the building is made-up of. I'd like to
treat each object as a single entity.
Modify the cocos2D code to allow sprites to have multiple Z values
at different points. If a sprite can have multiple Z values based on
what tile a particular part of the sprite falls on, then calculating
a Z value for that section is easy. I won't need to compare the
sprite to any other sprites. I believe this is possible by using
multiple quads for each sprite. The problem with this is that it is
a bit complicated for me since I am new to OpenGL ES and cocos2D. I
don't completely understand how all of the internal data structures
work. Although it seems like the most elegant solution if a formula
cannot be found.
I will up-vote any suggestions or references to helpful resources.
For #2, you can compute the Manhattan distance of the center of the object and use this value as the z-value of that object. It will work as long as you avoid very long objects in your map like 5x1 object or worse. But if you really need a long object to be placed in a tiled map, managing the z-order of objects in the map by setting a z-value using a formula is impossible.
To prove this:
1.) Place two 2x2 objects in a map horizontally and leave a unit tile between them.
2.) Place a 3x1 object between them. Let's name the 2x2 objects to A and B, and the 3x1 object to C.
3.) If you just rotate C(not changing its position), z-order of A and B interchange.
-If B is now in front, some objects behind B will be in front of A because of just the rotation of C. And it's costly to know which objects in back of both A and B previously will become in front of A after C's rotation.
I'm new to game programming. And i have a question. I want to have a dotted circle to be drawn on the screen. I can use one big sprite (for example 256x256 pixels) which contains all the circle or i can use many small sprites representing dots.
I use cocos2d libs and i'm able to render using batch. So what is the best way to perform such tasks ?
In my opinion your best bet (if all the dots are the same) is to have one sprite of the dot, and repeat it in the shape you are looking for.
Generally you'll want a single asset for each unique graphic. You can combine those assets into a single sprite and reuse them. This allows for more flexibility as well as speed.
Most of todays graphics hardware is optimized to texture dimensions that are a power of two. Your sprites are likely to have other dimensions. By using sprites, you can minimize the padding that is needed to fill this space (and thus, minimize CPU/GPU cycles spent on correcting this internally). Besides that, the file size will be smaller, since you need less overhead and compression is likely to be more effective.
Go with one large sprite. It's fewer calls into the rendering engine, and adds flexibility to change the look (for example, if you decide to have the circle made of dashed lines rather than dots).
I am building a cocos2d iPhone game.
There will be 6 'enemy spaceship sprites' that vary only by colour. I.e. all the sprites will have the same shape only some parts of the interior will have different colours.
My two options are:
1)
Create a template shape with a transparent interior.
At runtime, draw this shape on top of a small block of colour X.
The interior of the sprite will be colour X.
2)
Pre-render 6 different sprites
At run time, simply draw the sprite of a given colour.
What is the advantages and disadvantages of each method? Is there a best practice?
If I later wanted to animate the sprites, or dynamically change their colours, would this effect my choice of method?
Thanks!
I think first you need to figure out what it is that you're trying to do... Animation or a large number of color combinations make pre-rendering unfeasible. On the other hand, pre-rendering makes sense if you have a large number of ships on-screen at the same time, because you can use this technique to cut the number of drawing operations in half.