I'm new to using xna and I want to make my player collide with with multipe walls from the same class. So I looked around and I understood that the best way for doing that is to create a list of variables containing the walls id's and make a loop that circles them all and then returns the variable of the objects that collide.
My question is if there is a faster more efficient way for doing that? I mean if I have like 10000 objects that loop can cause a lot of memory use.
Thx in advance
Option 1) If these 10000 object are walls of a level, then you should probably use some sort of grid (like this very old example: https://en.wikipedia.org/wiki/The_Legend_of_Zelda#mediaviewer/File:Legend_of_Zelda_NES.PNG)
With a grid you only have to check collision with adjacent objects, or only with objects that are nearby.
Option 2) If these 10000 objects are enemies or bullets that move more freely, then you could also calculate the distance first and only check for collision if the objects are nearby.
But may I ask why you are using XNA? I used to work with XNA 4.x but in my understanding it is pretty much dead (http://www.computerandvideogames.com/389018/microsoft-email-confirms-plan-to-cease-xna-support). If you're new to XNA, I would advice to use other software to make games (like Unity3D). In Unity3D the hard part of collision detection is done for you (is has standard functions for collision detection) and Unity3D also works with C# (like XNA)
You always want to do the least amount of processing to get the job done. For a tiled 2D game you usually have a 2 dimensional grid. When the player want to walk on a certain tile you can check that tile if it is allowed to walk there. In this case you just have to check a single tile. If you have a lot of NPC's you could divide your map into sections and keep track of in what sections the NPC's are. Now you just have to do collision detection on the enemies within your section.
When you need expensive collision, pixel perfect or polygon collision you should first check if an object is even close with a simple radius float or BoundingSphere only then you go on with more expensive collision detection.
Same goes for pretty much anything, if you have a 100x100 tilemap but only need to draw 20x10 for the screen then you should just render that portion by calculations. In unreal, mappers create invisible boxes, when inside these boxes it only draws a certain part of the map and only checks collision within these boxes. GameDev is all about tricks to make things work smoothly.
Related
I'm a complete noob in gamedev, but I've watched a number of videos on generating a 2D array to setup Grid-based combat (pathing, obstacles etc), and I don't find the programmable approach intuitive or visually friendly.
Is it possible to setup such level with obstacles using multiple tilemaps?
1st tilemap would include the whole level zone (I named it "General Tilemap"):
2nd tilemap would only contain tiles that would be marked as collision when being read (I named it "Collision Tilemap") and player wouldn't be able to move to them:
My logic would be to read the adjacent tiles around the player, and if:
A tile exists on the General tilemap, but not on the Collision tilemap, player can click it and move there.
A tile exists on both tilemaps, it is marked as collision, it cannot be clicked.
A tile doesn't exist, it is out of boundaries, it cannot be clicked.
Could you please let me know if this is a valid approach (for smaller levels at least, I won't be making anything large so scalability is not an issue), or have I gone completely off course and there's a superior way to do this properly?
I'm currently stuck at the very first step - reading whether the tile on a coordinate (next to player) is existing or null for both tilemaps. Doing my best to figure it out though.
Thanks!
Managed to check if tilemap contains a tile on xy coordinates in Start function, by finding the relevant Tilemap and using hasTile to read it it has value or not. This returns a boolean.
Tilemap generalTilemap = GameObject.Find("General Tilemap").GetComponent<Tilemap>();
hasGTile = generalTilemap.HasTile(playerTileCoord);
Still not sure if this approach will work for me long-term, especially when I get to the pathfinding algorithm, but we'll see!
I try to begin new game development that has rotating circle that has one or many holes as in the attached image , the problem is I need to use circle collides for the big circle., in addition I need to use small collides for the smaller holes to prevent and particles(smaller circles ) input the circle and to count no of collisions occurred
enter image description here
The circle collider itself does not have this functionality since it can only check collisions between perfect circles. (Behind the scenes all circle colliders just check the distance between points and these distances do not work with holes) The best solution I can think of would be to use a polygon collider and make a rough circle that you can then remove parts of (would require some advanced geometry but not impossible). I have tried simillar things in 3D and with the mesh collider, removing parts of it using a method known as CSG (Wikipedia) and something simillar should be possible in 2D however it is really, really hard and even experienced programmers struggle to come up with a system that can handle every scenario.
All hope is not lost though, depending on what you need the collision for, there might be other ways. If you just need to check if two objects intersect and don't want rigibodys and stuff to interact with the collider just checking the distance between the big circle and the object (too figure out if it's close enough) and then checking the distance between the object and the holes (too see if it's inside a hole on thus not colliding) is the best way to solve the issue.
I'm sure someone who have done more in this field than I have will be able to help you out but without more information of what you need it's impossible to say. It all depends on the circumstances!
I'm trying to build an array of all player pawns that are in the players FoV cone. I'd prefer to not have to loop through GetAllActorsofClass for obvious performance reasons. This will be done every tick.
GetAllActorsOfClass iterates over a hash table of things of that class. Even with 100 players it is unlikely to be very costly. I would imagine that a "get actors in frustum" would just do that under the hood.
If you are okay with using it, from there you would use ConvertWorldLocationToScreenLocation and compare that to the screen bounds coordinates with GetViewportSize.
The only method the wouldn't use GetAllActorsOfClass I can think of offhand is to calculate the size of the rectangle at the "end" of the frustum, using a giant multi box trace, and filtering based on the dot product. Traces are cheap, dot product is cheap. Whether or not it's cheaper than GetAllActorsOfClass is going to be specific to your game.
If performance is really a problem the best solution is to use code. Depending on your implementation you might be able to use Blueprint nativization to get an extra boost without digging into code.
Use MultiSphereTrace from your player to his FOV direction and loop through hit results.
Make sure you set the collision layer correctly so the trace only interact with target player.
I do this on my mobile game with around 10-20 actors per frame, and it works fine.
I am working on a 2D game with colleagues that is basically a fighting game on a vertical map with platforms. Right now I am spawning items on the map for player to gather, but I was wondering how could I do that while checking that I'm not in one of the platform's collider to avoid spawning the item in?
You should take a look at the overlap functions from Physics2D (for example here). Just generate a drop position and pass it to this function, if it returns null then the position is free. If you get unexpected results make sure to set the layer mask to the same as the platforms or whatever objects you don't want to intersect with.
I'm working on a 2D physics game that involves collisions between objects which at the moment use complex polygon colliders.
When the objects collide, I get the normal of the contact point using otherObject.contacts[0].normal, and knock the objects apart in equal-but-opposite directions using Rigidbody2D.AddForceAtPosition, with the force being the normal multiplied by a constant.
Most of the time this works flawlessly, but I've found that when the collision occurs with a concave section (aka: an inward "dip") in the polygon collider, the normal will be flipped, and the objects will instead get pushed towards each other.
Alternatively, are there any other ways I could go about solving this?
The blue circled area is an example of a problematic concave section
Alternatively, are there any other ways I could go about solving this?
Yes, the standard thing in vid games is that most stuff has many small simple colliders, rather than one large complex collider.
This is a basic of game engineering.
(It can be very surprising to hobbyists and folks new to the field.)
So, imagine a car in any ordinary 3D game. You'd have a collider for the rear bumper, one for the front, maybe one for "left doors" and so on. Very typically, each has to react in a different way, and you need to know which area was touched.
In your case if the 2D poly has say 12 edges, just make 12 "small" as it were colliders for each of the edges.
We know nothing about your setup since no screenshot, but that could possibly work.
Note however that Unity's 2D poly collider in fact already does know to slice the object in to smaller triangle-like shapes if it is concave - I'm surprused it dinnae work for you.
Further: now that we can see your image.
In any video game on Earth, the way you'd do that helmet is with a square collider as in orange:
If (for some reason .. why? for what purpose? how? where? what possible reason could there be?) you were making the most precise video game, ever created by humans, on an entirely new plane of engineering, for some imaginary new hardware with quantum warpspace cores, ... in that case ... you'd maybe add the two extra colliders to cover the horns. But nobody would ever notice the difference.
I appreciate you may be doing something exceptionally unusual, like a "close up game" ("you're an atom in medieval Scandinavia, bouncing off helmets" or whatever), in which case there'd be some other solution.
The very short answer is you've stumbled on one of the most surprising things about game technology ... we use crappy, simple, colliders, you've been tricked all your life in every title you play!