I've been stuck on this the last few days so I'm hoping you guys can help.
I'm making a 2D game and I want my character to slip, fall backwards, and hit his head when he tries to run on ice for too long.
My goal is to have it where if you keep holding the run button long enough on ice, he will slip backwards and damage himself.
I'm using playmaker but I do know a little c# programming.
The first thing I tried was making an animated float that adds the rotation to the Z axis over time, but that went horribly wrong and makes the character jump/skip/glitch all over the place.
The second thing I thought of was to add 2D torque to make him start slipping backwards, but he stays in the same rotation with fixedAngle true.
So then I made it where fixedAngle is false when he is on ice, but he immediately falls forward or backwards as soon as I start running. I made the center of mass right in the middle so he stands fine as long as he is not moving.
Does anybody know a way of achieving the effect I want?
This is my first game and I am a noob, so hopefully there is an easier/correct way of going about this. I could be doing this all wrong, so any guide in the right direction would be greatly appreciated.
It seems like from your verbage, you want to be tracking the amount of time the player has been running on ice.
If you want to tie this to the run key being down, start the timer if the button is down and trigger the "slip-and-fall" event to occur after a certain amount of time.
If you want to tie this to the amount of time the player has been on the ice, start the timer when the player reaches the ice and trigger the "slip-and-fall" event to occur after a certain amount of time.
If you want there to be a visual tilting, tie the time delta to the angle of the object. Set a certain angle to trigger the "slip-and-fall" event.
Update(){
if(this.running && _terrainAtPos == <Ice> && isGrounded){
transform.Rotate(0,0,3*Time.deltaTime);
if(tranform.rotation.z > 180){
//do falling event
}
}
}
EDIT: The above is not a working sample. Just something I whipped up to illustrate.
Related
I'm fairly new to game development and I'm trying to develop a 2D game in unity where the main character has a jetpack with two thrusters and I want him to control each one individually. So if he only turns on one thruster he goes 5 meters above ground and hovers there while using both would make him hover at a height of 10 meters. How would i go about doing this?
I tried just simply adding forces as if the character was jumping and freezing the y-axis to 0 until he let go of the jetpack button but that did not give me the feel i was looking for. I also tried raycasting a line out of the jetpacks to the closest surface and adding a force to the jetpack to allow the player to float at that height but that I couldn't figure out a proper way to implement it.
The Raycast sounds like a great idea. Do the raycast to the next available platform and do as #Ahndwoo said in a comment, `
What you would need to do is divide the force of your thrusters by the
magnitude of the Ray. Thus, as the Ray gets longer, the force
decreases.
By doing this you'll get the natural movement from a force and you'll control how high can you get.
I would Make your thrusters holder as an object and as more turbines it has, the more powerful i'll get.
I've been working on a simple platformer game using XNA. I have been having some trouble working out a good jumping algorithm. After getting rid of the messy half done versions of the jumping algorithm all I have left is.
if (keystate.IsKeyDown(Keys.W))
{
spritePosition.Y = spritePosition.Y - 10;
}
I realise this is a very unsophisticated start but any tips would be great. I'm a self taught programmer so some terminology might be lost on me, I tend to find looking at actual code the best way to learn. Thanks.
When you jump (physically) you are adding an amount to your Y velocity vector, not to your position vector. Moving your position by 10 means you're just teleporting upward 10 ticks.
Try adjusting velocity, then letting your main loop change the position. And remember acceleration downward from gravity!
Edit: Added link from comment below to physics tutorial. rodedev.com/tutorials/gamephysics
Try following:
if(Input.GetKeyDown(KeyCode.W))
{
// your code here
}
It will make it so that every time the player presses W, they will only go until they can press W again. You can always set Rate of Jump and make it so that they can only jump once every so and so seconds.
I'm making the skeleton for the typical BubbleShooter game in XNA, and I'm having issues with my collision detection algorithm, which is explained in the picture here
Depending on where the colliding Rectangle position is at the moment of collision, a new position is assigned to the colliding Bubble.
The issue appears when I shoot a bubble and this happens at the moment of collision.
I have run the debug step by step, and the moment when the collision happens is exactly like the picture, so my algorithm fails.
I tried to post the images directly, but it seems I can't since I'm still a new user here. Sorry about that.
Is there a way I can detect exactly when the boundaries of the Rectangles touch each other?
You can perform a per pixel collision instead, it is explained here:
Click here
So, if I understand, your problem is that you miss the exact moment of collision ?
I guess you are computing collisions in a discreet way, ie. even if your algorithm runs 60 times a second, it is only 60 times when a second could be subdivised in an infinity of instants.
The simple (and bad) solution is to make your objects move slower.
The good one implies to retrieve what happens between the frames. you will need some kind of direction vector and the object speed. With both these values, you can determine where and when the collision did occur.
You will also need the elapsed time between frames. This is the purpose of the GameTime object : it has a property "ElpasedGameTime", which has a property "TotalElapsedMilliseconds".
MSDN Documentation on GameTime class : http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gametime.elapsedgametime.aspx
Some reading material on Wikipedia about collision detection: http://en.wikipedia.org/wiki/Collision_detection#A_posteriori_.28discrete.29_versus_a_priori_.28continuous.29
"A priori" and "A posteriori" detection : that's the keywords you might be missing.
I don't have time to test it right now but you should try to limit your number of collisions per frame to 1.
With a counter when it enters the update part if one collision has been detected block all other collision for the same frame.
This way if your projectile its the bottom part, your code for
if(hitBottomPart)
{
// Logic
}
part will execute in this same frame before the projectile has time to hit another rectangle of the texture.
Although this is just a guess.
Good luck with your game ! Collisions are always a pain to implement.
I'm trying to get a general smooth scrolling mechanism that I can implement in my mobile applications.
I want it to be generic enough so that it can port to any platform, but I am currently working in C# on the .net Compact Framework.
What I'm doing right now is:
Create a Stopwatch object (in the panel's ctor)
on mouse down start the Stopwatch and save the current mouse point _lastMouse
on mouse move, stop the Stopwatch, and store velocity = (_lastMouse - curMouse) / Stopwatch.TotalSeconds then reset the Stopwatch and start it again
In most cases Stopwatch.TotalSeconds is between 0.02 and 0.03
on mouse up, I pass the velocity value into a smooth scrolling function, and that function continues to scroll the panel until either the end is hit or the increasing friction causes the velocity to be == 0
My problem is in the final step. The velocity values are generally int the 2,000-3,000 pixel range. The velocity is in pixels per second, so this is to be expected. I take the Stopwatch (which should be still running), stop it and I find the elapsed time from last mous move and multiply velocity by Stopwatch.TotalSeconds, get that distance and then reset and start the Stopwatch, then loop back and start all over again.
The expected result is that the elapsed time between refreshes multiplied by the velocity should give me the number of pixels (according to the last mouse move) that I should scroll. My actual result is that sometimes the panel goes flying and sometimes it bearly moves! the gradual slowdown is fine, it's just the beginning velocity that is off
Is there a flaw in the logic? Should I be doing something else?
Thanks for any help!
It seems to me that there are three possible sources of inaccuracy here. Firstly, as "A.R." said, you'll have problems if the granularity of your timer isn't good enough. Have you checked IsHighResolution and Frequency to make sure it's OK?
Secondly, even if your timer is perfect, there may be some inaccuracy in your position measurements, and if you're taking two in very quick succession then it may hurt you. My guess is that this isn't a big deal, but e.g. if you're on a capacitive touchscreen then as the finger lifts off you may get variation in position as the contact area goes down.
Thirdly, the physical motion of the finger (or stylus or mouse or whatever you've got doing the actual input; I'm going to guess a finger) may not be all that well behaved. At the end of a gesture, it may change from being mostly horizontal to being mostly vertical.
All these problems would be substantially mitigated by using a longer sampling period and maybe (try it both ways) ignoring the very last sample or two. So, keep a little circular buffer of recent samples, and when you get the mouse-up look back (say) 100ms or thereabouts and use that to decide your velocity. Or, if you don't want to keep that much history, use a simple IIR filter: every time you get a sample, do something like
filtered_dt = filtered_dt + SMALL*(latest_dt-filtered_dt);
filtered_dx = filtered_dx + SMALL*(latest_dx-filtered_dx);
filtered_dy = filtered_dy + SMALL*(latest_dy-filtered_dy);
where SMALL should be, at a guess, somewhere around 0.2 or so; then use filtered_dx/filtered_dt and filtered_dy/filtered_dt as your velocity estimate. (I think this is better than calculating a velocity every time and filtering that, because e.g. the latter will still blow up if you ever get a spuriously small dt. If in doubt, try both ways.)
If you use the IIR approach, you may still want to make it ignore the very last sample if that turns out to be unreliable; if you remember the latest dt,dx and dy you can do that by undoing the last update: use (filtered_dt-SMALL*latest_dt)/(1-SMALL), etc.
Here's an off-the-wall suggestion that may or may not work. You mentioned that you get more erratic results when there's a "flick" at the end of the gesture. Perhaps you can use that to your advantage: look at, say, how rapidly the estimated velocity is changing right at the end of the gesture, and if it's changing very rapidly then increase the velocity you use somewhat.
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.