I think the title is rather self explanatory but just to clarify I am trying to figure out how to tell which side the collision has occured on.
For a bit more detail, I'm trying to make a maze-like game so I can't simply stop all movement upon a collision. Instead I need to be able to tell which side the collision has happened on so I can block that direction.
Any help is appreciated and if there is a better approach to this issue, I'm all for trying it out.
I hope this is enough details but if you need anymore, ask and I'll edit. Thanks in advance.
[edit]
#viggity - No, I'm not using any specific game engine and I would post the current "detection" code but it's a little, absurdly, robust.
#Streklin - I'm using the this.Paint event to draw onto the form itself as it was recommended I start by doing that to get better at drawing real time. I'm also using a location that's updated each time the timer ticks based on what I press (left, right, up, down). Yes the maze is tile based. Currently it only consists of 3 colors even. I'm not a very advanced programmer.
#Eric - Definately a one-d game. Again, I only have 3 colors, the lines are black, the background is white and the square (the user) is green. I'm using the DrawImage() with Bitmaps to draw onto the screen.
[edit psuedo-code summary]
foreach(Wall _wall in walls)
if(player.intersectsWith(_wall))
stop movement;
#JeffH - I'm not really sure what you're asking as that's pretty much all there is besides testing code that I was using to try and get it working. The only thing I left out was the if statement to check if it was the x axis or not so that x and y could move indepedently from each other. So instead of getting "stuck" because you touched the wall, you could slide against it. I didn't see the point in including that though since the problem occurs before that.
Assuming you're talking about a 3D game here.
The normal of the face you can see points towards you, so the dot product of your direction vector with the face normal will be negative. If it's positive then you are coming at the face from the back.
If it's zero you're travelling at right angles to the face.
| <---------- your direction of travel
|
|----------> <- face normal
|
| <- face
If you're not in 3D then you could store the direction the wall is facing (as a 2D vector) and do the same dot product with your 2D direction of movement.
Based on your edit you can only go one direction at a time? Or can you go in diagonal directions? If it's the later, ChrisF has provided you the answer in 3D and the corresponding information for 2D. If not, you should just have to stop travel in the direction of travel - since there are only four possibilities it should be easy enough to check them all for simple starter game.
Related
I am trying to make a game where i got a ball with an arrow rotating around it. The ball starts as immovable, but when i hit a button i launch it to the direction the arrow is pointing at. Player will have the option mid air to press another button to make the ball "sticky" so when it hits a wall it will stick to the surface and repeat the process till he gets to the top of the level.
Aside from that, i want to give the option to the player to not stick to the wall if he doesn't press that button and instead bounce off the wall but when he does that, the player should speed up with every bounce, giving the option to either play it safe and slow or try to go fast getting more points as he does.
For the early prototyping i used force to move the player up every time he launches but i am not sure how i can make him speed up every time he bounces off the wall. It feels to me like a math problem more than it is a coding challenge. What i am thinking is that i have to find the angle on which player hits the wall, and add force according to that towards the direction he is supposed to follow after the collision.
Sadly i am not that good with trigonometry (working on it though). I am thinking that i might need to use a formula containing sin, cos, tan formulas but i m not sure how to do it. Any help is much appriciated! If you need more information on it please tell me and i ll be happy to provide.
Edit: After the first reply to this question i also found out those links that dive deeper into the subject. I m gona link them here for people that have the same issue.
Bouncing a ball off a wall with arbitrary angle?
http://www.3dkingdoms.com/weekly/weekly.php?a=2
If your ball has velocity vector V=(vx,vy), then after bouncing from standing surface with normal N, ball's new velocity is
V' = V - 2 * N * (V.dot.N)
where dot is scalar product of vectors (vx*nx+vy*ny)
Particular cases:
bouncing from vertical wall (N=(+-1, 0)) causes reversing of vx-component, vy component remains the same. V' = (-vx, vy)
bouncing from horizontal wall (N=(0, +-1)) causes reversing of vy-component, vx component remains the same. V' = (vx, -vy)
Note I recommend to work in velocity vector components, and use angles only when they are really needed.
If you need to calculate bouncing from moving bat, it is worth to change stationary coordinate system to moving one, connected with the bat, find reflection in that system, and revert to stationary system.
Ok so problem was solved!
I want to thank both #MBo and #shingo for their contribution to the solution. While the answer of Mbo solved the problem via trigonometry and gave me nice material to study and figure out how things work, i followed shingo's advice in the comments of my question and managed to do it without diving deep into math.
So basically what he said, and what i did, was to use Unity's physics engine and let the ball hit the wall. After the ball bounces off the wall, it gets a new Velocity vector towards the direction it would go based on physics. I then created an OnColllisionExit check, and when the ball stops colliding with the wall, i AddForce to it to the direction of its new Velocity Vector3.
Works like a charm!
Thank you all for your contributions!
i am developing a racing game. But it's not your usual racing game, the bike is supposted to always have the Y coordinate of the same value as the closest point on the map mesh, in other words it is ALWAYS touching it.
What i do not want is the Y coordinate to be dependent upon the X and Y position, as there will be 2 (or maybe more floors).
I have absolutely no idea how to implement this. Completly zero. I am rather new to scripting, and this i way out of my league, i don't even know how to start... The map is not a simple plane, so simple maths won't help.
I'll apreaciate any help at all, not necessarily a solution.
Thanks in advance
This idea is an adapted version of #LeoBartkus's
I suggest using 2 raycasts from the bottom of the bike's wheels and using the 2 hits to position and rotate the bike. This allows for an accurate positioning of the bike for all kinds of terrain, except for spikes narrow and tall enough to appear to pierce the bike. Using a single raycast from the bike's center might cause problems if the ground is uneven, like a crater for example
Sorry for the long question. I am making a simple game where you click a cube and it changes its material to a certain color(i.e. dirt/grass >> water and any dirt "tiles" next to the water tile(cardinally) will automatically become yellow). These colors are kept by using an int value to identify the state.
I failed at using an 2d array in c# to store these cubes so I was attempting to use raycasting to check for these neighboring relationships. All the cubes are on a single plane of y=0 and they have a l=1m.
Here is the code for checking the neighbors.
Here is the starting gameboard with all tiles turned into dirt. This means When I click a tile it should turn blue(which is working) and then surrounding brown tiles should change their state to 3 therefore turning them yellow. Here, however, is what happens.
Initial:
After clicking one tile:
I added some debugging console writes to try and help but had no personal luck.
Here they are:
Thank you for any help you can give. I'm new to c# and am having a lot of trouble!
By changing my raycast to
check(tr,transform.forward)
Instead of
check(tr,(tr+transform.forward))
I was able to cast the rays from the proper position. Still a little confused about it but it works.
I need to develop a compass for a device we are using. This device is directionally unaware (no gyroscope), but has a GPS module. How can I make a compass, with a needle, that leads from a start coordinate (likely their current position) to an end coordinate?
My current thoughts are:
Poll coordinates on the GPS sensor as quickly as appropriate.
Record coordinates where the PDOP is within a respectable range (maybe less than 2.0).
Determine the direction they are facing based on the coordinate changes of them walking.
I have a few issues with this though:
Firstly, the unit has to be moved around to get a sense of where they are.
Doesn't seem like it would be the most accurate, i.e. how many past points do you use to determine direction change?
I'm not really sure if this is a feasible solution. Is there some implementation theory I can read on this?
Is there a better way to solve my problem? The scope of the project involves going from a 'current location' to some geo-tagged item in an oil field.
Using a Windows Mobile 6.5 device - C# on VS2008.
I think the issue you have is that the way people use a compass doesn't fit with what you are achieving with a 'getting closer' technique. When you look at a compass you tend to spin to get a sense of direction, which is going to fail in your case, no matter how clever you get with distances. In fact the direction of the phone is going to be irrelevant, because it doesn't know which way up it is to be able to adjust any compass.
I think you'd be better dropping the compass idea and developing an interface that works with the 'getting closer' method you suggest. Maybe a simple distance to target display would be better? I think showing something that doesn't do what it should do is likely to be counter productive. If it was sat nav, within a moving vehicle then maybe it might work, as you can't spin that easily on the spot and it's likely to update itself before you've spun around.
Giving it some further thgouht I think using a map and showing your last movements on that with some sort of line (although the map may display upside down in relation to the users direction) would be better locating a target, if you showed a vector of your current location towards your target. At least if the vector and your movement line were aligned you'd know you were travelling in the right direction.
If I were in your shoes, I would display a notice on the screen that tells the user to always keep the top of the device pointed in the direction of travel. While they are moving, calculate the direction they're going using their current position and their last known position. Then calculate the direction they should be moving based off of their current position and the target's position. Then calculate the difference between their direction of travel and the direction they should be traveling, and use that difference to point an arrow on the screen that shows which direction they should be going relative to their current direction.
Here's an example:
Let D represent Direction of travel. Let's say that's 100 degrees in this example.
Let T represent the direction they should be traveling to reach the target. Let's say that's 90 degrees in this example. T - D = -10, so draw an arrow on the screen pointing -10 degrees from straight up. Remember straight up is the same as D if they're following the instructions I mentioned earlier. This means that the arrow is pointing at D-10, which is 90 degrees, which is the way they should be going.
Now you have another problem: if they stop moving, you no longer have any way to tell which way the device is pointing. In that case, hide the arrow and let the user know that it will return once the GPS starts moving again.
The last thing to keep in mind is that a 1 degree change in latitude represents more distance than a 1 degree change in longitude, so determining your headings isn't as straightforward as you might think. Here's a link to an article that tells you how to calculate headings based on 2 GPS points: http://www.movable-type.co.uk/scripts/latlong.html
Good luck!
Edit: Most GPS devices give you the direction of travel, but unless you're using the same algorithm the GPS uses when you calculate the direction they should be going, there could be a discrepancy that would cause your arrow to be a little off.
In your case you only can create an instrument which shows the geographical direction you are moving.
This is equal (or better) then a compass when the user points the device in the direction he is moving.
This is not equal to a compass, but in some cases even more usefull: e.g inside a vehilce where a compass using the magnet field would not work well.
GPS has a "course" atribute. Just use that, and you are ready.
I'm designing a 3D game with a camera not entirely unlike that in The Sims and I want to prevent the player character from being hidden behind objects, including walls, pillars and other objects.
One easy way to handle the walls case is to have them face inwards and not have an other side, but that won't cover the other cases at all.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
One probably not so good idea I had in mind is to scan from the camera to the player in a straight line and see if you hit a non-hidden object, continuing until you reach the player. Unfortunately, I am an almost complete newbie on 3D programming.
Demonstration SVG illustration < that wall panel obscures the player, so it must be hidden. Another unrelated and pretty much already solved problem is removing all three wall panels on that side, which is irrelevant to this question and only caused by the mapping system I came up with.
What I had planned is to somehow check for objects that are "in front" of the player, relative to the camera, and hide them - be it by alpha blending or not rendering at all.
This is a good plan. You'll want to incorporate some kind of bounding volume onto the player, so the entire player (plus a little extra) is visible at all times. Then, simply run the intersection algorithm for each corner of the bounding volume.
Finding which object is at a given point on screen is called picking. Here's an XNA link for you which should direct you to an example. The idea is that you retrieve the 3D point in the game from the 2D point, and then can use standard collision detection methods to work out which object is occupying that space. Then you can elect to render that object differently.
One hack which might suffice if you have trouble with the picking approach is to render the character once as part of the scene, and then render it again at the end at half-alpha on top of everything. That way you can see the whole character and the wall, though you won't see through the wall as such.
One easy way, at least for prototyping, would be to always draw the player after you draw the rest of the scene. This would ensure that the player is rendered on top of anything else in the scene. Crude but effective.
Create a bounding volume from the camera to the extents of the player, determine what objects intersect that volume, and then render them in whatever alternate style you want?
There might be some ultra-clever way to do this, but this seems like the pretty straightforward version, and shouldn't be too much of a perf hit (you're probably doing collision every frame anyway....)
The simplest thing I can think of that should work relatively well is to model all obstacles by a plane perpendicular to your ground (assuming you have a ground.) Roughly assuming everything that is an obstacle is a wall with some height.
Model your player as a point somewhere, and model your camera as another point. The line in 3d that connects these two points lies in a plane that is particularly interesting to you, because if this plane intersects an "obstacle plane" below the height of the obstacle, that means that that obstacle is blocking your view of the player point.
I hope thats somewhat clear. To make this into an algorithm you'd have to implement a general method for determining where two planes intersect (to determine if the obstacle is tall enough to block view.)