I am new to Cocos2d, Box2d and game development all together, but I have read a good bit of tutorials to at least have a good start on a game set up and working...
Im now at the point where I need to start adding more bodies to a layer and need to check and see if and when my main avatar will collide with any of them..
Common sense seems to tell me that the more bodies I add and the more cases I add checking to see if fixture1 is colliding with fixture2 for instance will bog down the processor at some point..
Are there any best practices and/or efficient algorithms to make these checks more efficient over time as the number of bodies grow?
Any links or direction would be appreciated! thank you!
You can use QuadTree to divide the scene and get a list of bodies that needs to be checked.
(There are a lot of articles shows how QuadTree works, just google it:D )
And if that's a little complex for you. Then you can try to divide your scene into many grid, and make a loop to put bodies in their grid based on their 2d position. Then just check bodies in each grid. It's a lot faster than normal loop.
http://i.stack.imgur.com/W5cBT.png
As of iOS 7 you can use Sprite Kit to handle collisions:
https://developer.apple.com/library/ios/documentation/GraphicsAnimation/Conceptual/SpriteKit_PG/Physics/Physics.html#//apple_ref/doc/uid/TP40013043-CH6-SW14
Related
So here is the deal, i have an enemy that is rigged and consists out of quite a few voxels.
When i run the game i get very bad performance overall when its rendering the model because of the amount of objects it needs to render. How can i improve that?
Here's the things i have thought about:
Only rendering the faces we actually can see,
Or maybe using some sort of GPU Instancing?
Anyways, i would like to know how i could resolve such a problem. Any help is much appreciated!
Without knowing how you've actually implemented your voxels in game (i.e what components each voxel consists of and how you're currently managing them) it's hard to offer much specific advice.
In general though there are a few things to consider:
Faces that aren't oriented towards the camera won't be
rendered by default. What you might want to investigate is
Occlusion
Culling, but
since your character is not static within the scene you might not get
much performance improvement from that. The code to
constantly check whether objects are occluded might end up costing
more CPU than not implementing it.
Rendering might not be your actual bottleneck for performance. If each of your voxels is doing some work every update (such as collision detection), then that's going to hit your performance much harder than rendering the objects, particularly for cubic voxels. You'll need to use the Profiler to figure that out.
You need to consider whether you actually REALLY need all those voxels to be in the scene all the time or whether you can replace them with a single GameObject until you need to interact with them, then bring them into the scene as needed. For example, you might replace the upper arm with a mesh that mirrors the shape of the total voxels for that body part. Then when that part is shot, for example, you can detect the point of collision and instantiate the necessary voxels around that point to react as desired, then rebuild the arm mesh to reflect the changed shape.
It might also be worth looking into Unity's Data-oriented Technology Stack (DOTS) features, although that could be overkill for this situation.
Feel free to close this question if it is deemed too subjective. I realize that it might very well be, as it may focus heavily on best practices, which, if not an industry standard, may be subjective.
The Problem & Idea:
I'm using the tilemap system in unity (2D), and its been working great, but I have a few concerns regarding my particular usage. What I'd like to have is multiple "battle maps" that will get instantiated when the battle scene is switched to. My current idea is to just make each type of battle map a prefab (prefab on the grid, since the tilemaps are just layers), and then instantiate the grid when the scene loads in.
Is this best practice or is there any better way? Does having 10 maps vs 200 maps make a difference?
Other Things I've Considered:
Would it be a better idea to make one huge tilemap with all of the battle maps drawn a distance away from each other and just restrict the camera to moving only within the "current" battle map? The absolute max size I could see a map being is, let's say 30x20 tops, probably closer to half that though.
An earlier idea was to use small pixel map images to render the maps in. This was before I found out about Unity's tilemap system, which, admittedly, I'd rather use because it is so much simpler to visualize, and less work to develop.
The Scenario:
For simplicity's sake, let us assume the game has 2 scenes, the main menu, and a battle scene. Basically, the idea is to enter the battle scene and have a random battle map to be spawned out of what's available. The character(s) get placed, and any additionals also get placed, say, items, or what have you.
Is what I proposed above best practice? And should I consider any other other two systems I've also described? Or is there something I'm not thinking of that would be even better?
I don't believe that any of the above ways wouldn't work, I'm just curious if any of them is the best way to go about doing this.
Your consideration to have all of your battle maps drawn on a single tilemap and restricting the camera to only the region of the current map is an instant red-flag.
In my experience with unity, if I want to have a large level drawn on a grid I will have to break it up into chunks (each chunk is a separate tilemap) for performance reasons in the editor and in the game, so I would not recommend doing that.
If your goal is fast load times, then instancing a prefab as you suggested is not a terrible idea as long as the respective tilemap is fairly small (less than 10000 tiles), otherwise you would almost difinitely notice the map getting loaded in. If you are trying to load large tilemaps seemlessly, it may help to load the tilemap asynchronously before the actual switch occurs.
I would keep only the current map and next map loaded in the scene to ensure a seamless transition and optimal resource usage. Unity's tilemaps are not light.
I'm trying to do a little research for my next game that I'm planning to make and just wondering if anyone could give me a little direction.
I'd like to use sprites to show animation, characters walking and such so my question is this. What game engine handles sprites the best?
And how many sprites can be shown per second? Say i had a character walking and wanted it to look pretty fluid, might i be able to get 60fps? or is that way way to high?
Last question.. sorry! If a sprite has more colors and complexity, but is the same file size as something simpler would it take more processing power to display the complex one?
thanks!
James.
I would highly recommend cocos2d for sprite animations. It's very easy to pick up if you already know objective-c. And it's great for working with sprites. The animations are very fluid and when your testing your applications in an iOS simulator, it tells you the frames per second in the bottom left hand corner. The frames per second usually runs at about 60. And regarding the sprite file size, I believe if the file size is the same between two sprites then they require the same amount of processing power.
A good engine to use for it's simplicity is the Sparrow engine for sprites, sound and other things. There is no reason you can't get 60fps. As for your last question, it wouldn't make a difference.
In cocos2d, i've got two objects that I want to detect collision with.
Im using CGrectintersectsrect, which has been working fine thus far.
But I want to divide up the bounding box of one of my objects into 4 quarters, so that if my object collides in any one of these quarters, appropriate physics can then be applied.
At the moment, there is only 1 large boundingBox which is insufficient. Ideally I would want 4+...
Is this possible, and if so how could i achieve this?
If not, is there any other avenue that could work?
Thanks everyone, once again :)
The boundingbox method returns a CGRect. You have to divide your rect manualy, there is no pre-made method for that.
Otherwise if there is a lot of objects, the best way to detect the collisions is to use Box2d. You can follow this tuto to see
How To Use Box2D For Just Collision Detection with Cocos2D iPhone tutorial.
What would be the best way to go about adding collision to my application. Right now I have a lot of jagged walls and a couple of weird shapes that I wanna make collision for but am not sure which is the right path to get the job done. What would you guys do if you had a room full of walls with different shapes and sizes that needed collision implemented ?
I would read a set of articles on collision detection. Paul Nettle used to write about the topic (PDF) and has a nice library for free.
This document will describe a
collision technique that allows you to
move an ellipsoid (a sphere with three
different radii, one for each axis)
through a world that not only properly
detects collisions, but also reacts in
a way that gamers would expect from
the common first person shooter.
This technique also allows for sliding
along surfaces as well as easy
implementation of gravity, which
includes sliding downhill when
standing stationary. This technique
also allows automatic climbing of
stairs and sliding over bumps in walls
(like door frames) and any other
randomly oriented “stair-like
topography”.
You can use Chipmunk physics engine, which has a very good physics + collisions.
Or even Cocos2d-iphone library - 2d game engine with Chipmunk inside. Here are examples of games, created with it.