I'm aware this is going to be somewhat vague. I'm writing an action adventure style game and I'm having a random (as in seemingly spontaneous) issue where the body I'm using for the character is getting caught on nothing. I'm not actually handling collisions, I'm just using the built in body touches body causes collision feature. The debug renderer indicates that there is a collision when there shouldn't be one and I can't discern why it would happen. What I suppose I need is someone more familiar with LibGDX than I am to surmise why this would happen.
I guess #CoderMusgrove is right.
If you have a flat floor, created out of many boxes, you might get stuck on the edges of them.
Thats because in the physics simulation, the body will be pushed down by gravity. This results in a collision, which usualy pushes the body back up.
But if you get pushed down in between two boxes, the collision resolver sometimes decides to push you back, as this is the shorter way out of the collision.
You can read more about this here.
Also the solutions are discussed in the link. There are a few different ways:
- Cutting the edges: If you cut the edges of your character, the collision resolver will more likely decide to push your character up. I tryed this solution to, but in my case it slowed down the character a bit. Also when i cut the edges to much, the character started jumping every time he moved onto another box.
- Using edge-shapes: Instead of using boxes, you could just use edges. It seems like you don't get stuck on edges that often, so that might allready solve your issue.
- Use gost vertices: Using Ghost Vertices, you can give the resolver a hint on how to resolve the colission. Those ghost vertices are used for collision response only, so they won't affect the rest of the simmulation.
- Combining boxes: The best solution would be to create one big box out of all adjacent boxes, if possible. This would solve the problem, as there are no more edges where the body could get stuck.
Related
Similar to the game Factorio im trying to create "3D" terrain but of course in 2D Factorio seems to do this very well, creating terrain that looks like this
Where you can see edges of terrain and its very clearly curved. In my own 2D game Ive been trying to think of how to do the same thing, but all the ways I can think of seem to be slow or CPU intensive. Currently my terrain looks like this:
Simply 2D quads textured and drawn on screen, each quad is 16x16 (except the water thats technically a background but its not important now), How could I even begin to change my terrain to look more like a Factorio or other "2.5D" games, do they simply use different textures and check where the tile would be relative to other tiles? Or do they take a different approach?
Thanks in advance for your help!
I am a Factorio dev but I have not done this, so I can only tell you what I know generally.
There is a basic way to do it and then there are optional improvements.
Either way you will need two things
Set of textures for every situation you want to handle
Set of rules "local topology -> texture"
So you have your 2d tile map, and you move a window across it and whenever it matches a pattern, you apply an appropriate texture.
You probably wouldn't want to do that on the run in every tick, but rather calculate it all when you generate the map (or map segment - Factorio generates new areas when needed).
I will be using your picture and my imba ms paint skills to demonstrate.
This is an example of such rule. Green is land, blue is water, grey is "I don't care".
In reality you will need a lot of such rules to cover all cases (100+ I believe).
In your case, this rule would apply at the two highlighted spots.
This is all you need to have a working generator.
There is one decision that you need to make here. As you can see, the shoreline runs inside the tile, not between tiles. So you need to chose whether it will run through the last land tile, or the last water tile. The picture can therefore be a result of these two maps (my template example would be from the left one):
Both choices are ok. In fact, Factorio switched from the "shoreline on land" on the left to the "shoreline on water" on the right quite recently. Just keep in mind that you will need to adjust the walking/pathfinding to account for this.
Now note that the two areas matched by the one pattern in the example look different. This can be a result of two possible improvements that make the result nicer.
First is that for one case you can have more different textures and pick a random one. You will need to keep that choice in the game save so that it looks the same after load.
Another one is more advanced. While the basic algorithm can already give you pretty good results, there are things it can't do.
You can use larger templates and larger textures that span over several tiles. That way you can draw larger compact pieces of the terrain without being limited by the fact that all the tiles need to be connectable to all (valid) others.
The example you provided are still 2D textures (technically). But since the textures themselves are 'fancy 3D', they appear to be 3D/2D angled.
So your best bet would be to upgrade your textures. (and add shadow to entities for extra depth).
Edit:
The edges you asked about are probably layed-out by checking if a 'tile' is an edge, and if so it adds an edge-texture on top the background. While the actual tile itself is also a flat image (just like the water). Add some shadow afterwards and the 3D illusion is complete.
I hope this answers your question, otherwise feel free to ask clarification.
on a 100x50 orthogonal tilegrid with 32x32 tiles, i created some animated Units, which are moved by A* (like in many strategy games usual) with a rightclick on the mouse.
The collision detection works by using a two dimensional booleanarray i gave the grid in the constructor and this says whether a tile is an obstacle or not.
Thats what i have so far and it works.
I am now figuring out, some Kind of Units coordinationsystem, which simply doesnt allows the Units to walk into each other. All of this just should be in this 32x32 tilesized RASTER not more for the moment.
I just thought this should be easy, but the grid is loaded once just like the obstacles, while the Units positions are always different and the Problem here is, that if i define each unit as an obstacle at Runtime, the obstacle at its Position stays stored in the gridarray and it stay some Kind of invisible obstacle, although it shouldnt be one. The result is, that the unit cant go the way back, where it cames from. Another Problem is of Course, that a unit can stand still or move arround(so far) and if it moves arround ist not rastered anymore.
My question now is: How can i implement a movable obstacle or do i have to implement a separate collision detection for my Units here?
PS: The Programm is quite big and i dont like to post the whole Code, although that would make all easier for u guys to help me, but if somebody understand what i mean, i can post the relevant Code snippets here on the Forum.
I am using Box2D with libgdx. I am having an issue with the default collision action. When I jump or hit the top of an object, everything works fine. My object doesn't stick. If it hits the top, it stands on it. If it hits the bottom, it falls back down. But if it hits either of the sides, my object sticks, as long as I'm moving in that direction. In other words, the gravity has no effect on it while it collides with the side of the block/wall. I did some research, but all solutions said to use the b2Settings, which I can't use with libgdx. Is there any way I can fix this? The code I use to move my character(moving left) is as follows:
level.character.body.setLinearVelocity(
-level.character.terminalVelocity.x,
level.character.body.getLinearVelocity().y);
Here's an illustration. As you can see, it sticks to the brick instead of falling. (My character is currently a coin :p)
Instead of using SetLinearVelocity, try using ApplyForce or ApplyImpulse to move things around. The problem is that SetLinearVelocity allows you to create unrealistic situations, for example in this case when the ball hits the wall it should stop and the horizontal velocity really should be zero, but you are overriding the natural result and saying that the ball did not stop at all, and it is still moving.
Note that you may still get this problem even when using ApplyForce or ApplyImpulse, if the force is strong enough and there is enough friction between the fixtures (just like in the real world, if you push something against a wall hard enough and the surfaces are not too slippery, you can stop it from falling).
I am making a game in java which involves characters moving around a map and having some solid collision objects (i.e. buildings) placed around the map by reading certain data from a text file. There will be multiple maps where these objects' locations will change. My question is would painting a rectangle in a certain color that indicates collision behind such structures or would reading mouse coordinates and searching an array of these structures to see if that point lies on a building, thus denying the move or altering, be more resourceful and/or quicker. If painting a rectangle is the best, would leaving it behind the structure or deleting it after detecting for collision be better. Thanks for your time!
In my junior year in college I worked on a Collision detection system algorithm for the windows phone. It is hardly perfect but it was EXTREMELY efficient and can be adapted to a majority of games.
The way that it worked was pretty simple. There were two types of objects; Collidable objects (such as enemies or buildings) and Objects that you wish to check for collisions with these collidable objects.
I had this idea when I was going through a data structures class and we spoke about Linked Lists. I thought what if each link was a collidable object that you could stick your game objects that were already created in it. Then as the game objects moved around you would have a lightweight way of checking their locations for collisions. Thus my system was born.
All it really is, is a class that fires off either every game cycle or when ever you choose to check for collisions. You give it your players location, or bullet location or what ever object you want to see if it is colliding with something and it searches all of the collidable object locations and conducts test to see if they are overlapping.
The real efficiency of it comes into play when you add in a second element (Locations AND quadrant)
For Example if I break the phone screen up into for parts and I know which quadrant my player or bullet is in I can choose to only scan a list of collidable objects that are within that quadrant. Thus cutting your search algorithm to a fourth of its origonal size.
There are many different ways of detecting collisions. This was a simple example I used in my class to show how you could detect two circles colliding that were actually squares. As you can see simply by taking the center point coords of the circles and the radius's you can calculate the hypotenuse and determine where or if they are touching.
Good luck! if you have any questions feel free to ask!
The last reply in this posting may help you out. It is a simple maze. The structure of the maze is controlled by a data file which simply contains 0, 1 to indicate a path or a wall. You navigate through the maze using the arrow keys. When an arrow key is pressed the code checks to make sure the next square is not a wall.
I am planning to develop a jigsaw puzzle game.
Now I already have images and image pieces, so we don't need algorithm to cut the image in pieces.
On the UI side there would be two sections
First section contains the broken images in random order.
Second section contains the outline of the full image. User need to drag and drop the the cut images onto the outline image.
I am not sure how can the pieces be matched on the the outline image?
Any idea about the algorithm or the starting pointers?
Allow the user to drag each piece into the outline area. Allow the piece to be rotated in 90 degree increments.
Option 1:
If a piece is in the correct location in the overall puzzle, and at the correct angle, AND connected to another piece, then snap it into place with some user feedback. The outside edge of the puzzle can count for a connection to edge pieces.
Option 2:
A neighbor is an adjacent puzzle piece when the puzzle is assembled. When the puzzle pieces are mixed up, they still have the same neighbors. Each puzzle piece (except the edge pieces) has four neighbors.
If a piece is near one of its neighbors at the correct angle relative to that neighbor, then snap it to the other piece. Then allow the two (or more) pieces to be dragged around as a unit, as is done with a single piece. This would allow the user to assemble subsections of the puzzle in any area, much like is done with a physical jigsaw puzzle, and connect the subsections with one another.
You can check the piece being moved to its four neighbors to see if they are close enough to snap together. If a piece has its proper edge close enough to the proper edge of its neighbor, at the same angle, then they match.
There are several ways to check relative locations. One way would be to temporarily rotate the coordinates of the piece you are testing so it is upright, then rotate the coordinates of all its desired neighbors, also temporarily, to the same angle. (Use the same center of rotation for all the rotations.) Then you can easily test to see if they are close enough to match. If the user is dragging a subassembly, then you will need to check each unmatched edge in the subassembly.
Option 2 is more complex and more realistic. Option 1 can be further simplified by omitting the rotation of pieces and making every piece the proper angle initally.
For a regular shapes you can go with a matrix. I recommend this as the first approach. Dividing the puzzle is as simple as defining X,Y dimensions of the matrix. For each piece you have a series of four values then, one for each side, saying whether it is flat, pointing out, or pointing in. This will give you a very classic jigsaw puzzle setup.
How the pieces actually look becomes a strict GUI thing. Now, for the first draft I recommend getting it working with perfectly square pieces. Taking rectangular bits of an image should be easy to do in any GUI framework.
To go to shaped pieces you'll need a series of templates. These will become masks that you apply to the image. Each mask clips out a tiny portion of the image to produce your piece. You'll probably need to dynamically create the masks in order to fit them to the puzzle. At first start with simply triangular connections. Once you have that working you can do the math to get nice bulbous connector shapes. Look up "clip" and "mask" in your GUI framework.
If you wish to do irregular polygon shapes that don't follow a general matrix layout, then you need to do a lot more work. This is why I recommend getting the square first working as a good example. Now you'll need to delve into graph theory and partitioning. Pick up some books on 3D programming -- focusing on algorithms, as they do partitioning all the time. Though I wouldn't doubt if there is a book with this exact topic in it.
Have fun.
the data structure is simple I guess- each peace will point to it's neighbors and will hold the actual shape to display.
on the MMI (UI) of the app - what is your developing environment ?
If it's windows - I would go with c# and winforms or even better wpf.
if it's unix, you'll have to get someone else's advise, as I'm not an expert there.
1) How to break image into random polygons
It seems that you have figured out this part. (from : "Now I already have images and image pieces, so we don't need algorithm to cut the image in pieces.")
2) what kind of data structure can solve the problem
You can create a Class Piece like Scribble class in this example and your pieces would be array of objects of Piece class.
So, you will have two arrays,
(i) actual image pieces array
(ii) image piece outline array
So, whenever you drag and drop one piece on to the full outline of image, it will check whether the image piece object is intersecting more than 80% and ID (member variable of Piece object) of actual image piece and image piece outline matches, then you got the right piece at right place...
3) UI implementation
Check this out.
You could make an array of objects of the class "PuzzleTile"
Every such tile has an image and an integer
After every move, check if the integers are sorted correctly, means:
123
456
789
You could make a function for that which returns a bool.
Note: I'm currently developing under C#, that's why it's probably easiest to realize especially this concept under C#, although other platforms need none up to barely some modification to this.