Hello, I'm new on Godot (I'm French, that's why my English is not perfect)
I'm trying to create a game (top down) where the principle is the same as a Sumo fight, take out your opponent outside a circle. The problem that I met is that if I use KinematicBody2D the characters don't push each other which is the base of the game, I saw then that it could be possible with RigidBody2D but I can't find any way on internet to make it move like this : https://docs.godotengine.org/fr/stable/tutorials/2d/2d_movement.html#rotation-movement . I then searched if it was possible to push a KinematicBody2D with another KinematicBody2D (so that it can be pushed) but I also couldn't find any way.
So I'm stuck here, and my question is if this is possible and especially how I could do this?
Thanks for reading,
Noflare
I believe the issue here would be that you are not using collisions. The functions move_and_slide or move_and_collide would engage a Kinematic Body to move, and hit other bodies (including Kinematic Body).
However, as soon as you use either function you will realise they don't push each other in the way you need in the question.
From the docs (en, fr)
move_and_collide: The moving object will move and if there is a collider (any obstacle), it will stop immediately upon collision and return a KinematicCollision2D object.
move_and_slide: Takes further action compared to move_and_collide, the moving object will slide over the collider, treating it like a wall or a floor. Useful for platformer games.
In your use case, you have no choice but to control the collision yourself. You can get more info here on KinematicCollision2D here: (en, fr). This could be possibly how you do it:
var collision = player.move_and_collide(direction_vector)
if (!collision):
# No collision occurred
return
else:
# Collided with a wall or player
if (collision.collider == wall)
# if you keep track of wall object as a variable to identify it
# you can have the sumo just stop moving and not process anymore
return
else:
var opponent = collision.collider
# write game logic to move opponent and yourself
return
Related
im currently making a small game by following youtube tutorials. i followed this tutorial by Clear code for the movement: https://www.youtube.com/watch?v=4aZe84vvE20&t=230s&ab_channel=ClearCode
i wanted to take my game to the next level and add a few blocks around the map which the user has to avoid. i want to make it so that if the car hits a block it stops and only moves when the user rotates it to face away from the block, into an empty space. right now, in the player class, ive created a collision attribute and have used pygame.sprite.spritecollide(self, blocks, True) to check for collision. the blocks variable is a group containing all the sprites for the blocks.
if there is a collision, i change the vector to (0,0), which stops the car, like intended. however, i cant figure out a way to change the vector again once ive rotated the car so that it faces away from the block, to get it going again. any help is appreciated. thanks in advance.
Do not change the motion vector to (0, 0). As soon as a collision is detected, change the position of the car so that the car only touches the object but does not intersect the object.
Something like (pseudo code):
if collide_at_left_side:
car.rect.left = obstacle.rect.right
A more general solution would be to correct the position along the normal vector of the collision.
So I've been messing around with Project Tango, and noticed that if I turn on a motion tracking app, and leave the device on a table(blocking all cameras), the motion tracking goes off in crazy directions and makes incredibly wrong predictions on where I'm going (I'm not even moving, but the device thinks I'm going 10 meters to the right). I'm wondering if their is some exception that can be thrown or some warning or api call I can call to stop this from happening.
if you block all the camera, there is not features camera can capture.
so motion tracking may be in two stages:
1. No moving,
2. drifting to Hawaii.
either ways may happen.
If you did block the fisheye camera, yes, this is expected.
For API, There is a way to handle it.
Please check life cycle for motiontracking concept
For example for C/C++ :
https://developers.google.com/project-tango/apis/c/c-motion-tracking
if API detected pose_data as TANGO_POSE_INVALID, the motion tracking system can be reinitialized in two ways. If config_enable_auto_recovery was set to true, the system will immediately enter the TANGO_POSE_INITIALIZING state. It will use the last valid pose as the starting point after recovery. If config_enable_auto_recovery was set to false, the system will essentially pause and always return poses as TANGO_POSE_INVALID until TangoService_resetMotionTracking() is called. Unlike auto recovery, this will also reset the starting point after recovery back to the origin.
Also you can add Handling Adverse Situations with UX-Framework to your app.
check the link:
https://developers.google.com/project-tango/ux/ux-framework-exceptions
The last solution is by write the function handle driftting by measuring velocity of pose_data and call TangoService_resetMotionTracking() and so on.
I run a filter on the intake that tries not to let obviously ridiculous pose changes through, and I believe no reported points whose texel is white nor any pose where the entire texture is in near shouting distance of black
This has been greatly bothering me in the past few weeks. In this time I've been researching online, even reading books in the Computers section at Borders to try to find an answer, but I haven't had much luck.
I programmed a 2D level editor for side-scroller video games. Now I want to turn it into a game where I have a player who can run and jump to explore the level, similar to "Mario".
The thing that is really giving me trouble is the collision response (not detection: I already know how to tell if two blocks are colliding). Here are some scenarios that I am going to illustrate so that you can see my problems (the shaded blocks are the ground, the arrow is the velocity vector of the player, the dashed lines are the projected path of the player).
See this collision response scenarios image:
http://dl.dropbox.com/u/12556943/collision_detection.jpg
Assume that the velocity vectors in scenarios (1) and (2) are equal (same direction and magnitude). Yet, in scenario (1), the player is hitting the side of the block, and in scenario (2), the player is landing on top of the block. This allows me to conclude that determining the collision response is dependent not only on the velocity vector of the player, but also the player's relative position to the colliding block. This leads to my first question: knowing the velocity vector and the relative position of the player, how can I determine from which direction (either left side, right side, top, or bottom) the player is colliding with the block?
Another problem that I'm having is how to determine the collision response if the player collides with multiple blocks in the same frame. For instance, assume that in scenario (3), the player collides with both of those blocks at the same time. I'm assuming that I'm going to have to loop through each block that the player is colliding with and adjust the reaction accordingly from each block. To sum it up, this is my second question: how do I handle collision response if the player collides with multiple blocks?
Notice that I never revealed the language that I'm programming in; this is because I'd prefer for you to not know (nothing personal, though :] ). I'm more interested in pseudo-code than to see language-specific code.
Thanks!
I think the way XNA's example platform game handles collisions could work well for you. I posted this answer to a very similar question elsewhere on Stack Overflow but will relay it here as well.
After applying movement, check for and resolve collisions.
Determine the tiles the player overlaps based on the player's bounding box.
Iterate through all of those tiles doing the following: (it's usually not very many unless your player is huge compared to your world tiles)
If the tile being checked isn't passable:
Determine how far on the X and Y axes the player is overlapping the non-passable tile
Resolve collision by moving the player out of that tile only on the shallow axis (whichever axis is least penetrated)
For example, if Y is the shallow axis and the collision is below, shift the player up to no longer overlap that tile.
Something like this: if(abs(overlap.y) < abs(overlap.x)) { position.y += overlap.y; } else { position.x += overlap.x; }
Update the bounding box's position based on the player's new position
Move on to the next tile...
If the tile being checked is passable, do nothing
If it's possible that resolving a collision could move the player into another collision, you may want to run through the above algorithm a second time. Or redesign your level.
The XNA version of this logic is in player.cs in the HandleCollisions() function if you are interested in grabbing their code to see what they specifically do there.
So what makes this a little more tricky is the constant force of gravity adjusting your players position. If your player jumps on top of a block they shouldn't bounce off they should land on top of the block and stay there. However, if the player hits a block on the left or right they shouldn't just stay there gravity must pull them down. I think that's roughly your question at a high level.
I think you'll want to separate the two forces of gravity and player velocity from collision detection/response algorithm. Using the velocity of the player if they collide with a block regardless of direction simply move the player's position to the edge of the collision, and subtract equal and opposite vector from the player's velocity since not doing this would cause them to collide yet again with the object. You will want to calculate the intersection point and place the player's position there on the block.
On a side note you could vary that really big force by what type of block the player collided with allowing for interesting responses like the player can break through the block if they are running fast enough (ie the player's velocity > than the force of the block)
Then continue to apply the constant force gravity to the player's position and continue doing your normal calculation to determine if the player has reached a floor.
I think by separating these two concepts you have a really simple straight forward collision response algorithm, and you have a fairly simple gravity-floor algorithm. That way you can vary gravity without having to redo your collision response algorithm. Say for example a water level, space level, etc and collision detection response is all the same.
I thought about this for a long time recently.
I am using the separating axis theorem, and so if I detected a collision I proceeded to project the object onto the normalized velocity vector and move the object by that distance in the direction of the negative velocity vector. Assuming the object came from a safe place this solution will position the object in a safe place post collision.
May not be the answer you're looking to get, but hopefully it'll point you in the right direction?
Basically, I have this: First, a bunch of code generates a maze that is non-traversable. It randomly sets walls in certain spaces of a 2D array based on a few parameters. Then I have a backtracking algorithm go through it to knock out walls until the whole thing is traversable. The thing is, the program doesn't seem to be going all the way back in the stack.
It's pretty standard backtracking code. The algorithm starts at a random location, then proceeds thus in pseudocode:
move(x, y){
if you can go up and haven't been there already:
move (x, y - 1)
if you can go right and haven't been there already:
move (x + 1, y)
...
}
And so on for the other directions. Every time you move, two separate 2D arrays of booleans (one temporary, one permanent) are set at the coordinates to show that you've been in a certain element. Once it can't go any further, it checks the permanent 2D array to see if it has been everywhere. If not, it randomly picks a wall that borders between a visited and non visited space (according to the temporary array) and removes it. This whole thing is invoked in a while loop, so once it's traversed a chunk of the maze, the temporary 2D array is reset while the other is kept and it traverses again at another random location until the permanent 2D array shows that the whole maze has been traversed. The check in the move method is compared against the temporary 2D array, not the permanent one.
This almost works, but I kept finding a few unreachable areas in the final generated maze. Otherwise it's doing a wonderful job of generating a maze just the way I want it to. The thing is, I'm finding that the reason for this is that it's not going all the way back in the stack.
If I change it to check the temporary 2D array for completion instead of the permanent one (thus making it do one full traversal in a single run to mark it complete instead of doing a full run across multiple iterations), it will go on and on and on. I have to set a counter to break it. The result is a "maze" with far, far too many walls removed. Checking the route the algorithm takes, I find that it has not been properly backtracking and has not gone back in the stack nearly far enough in the stack and often just gets stuck on a single element for dozens of recursions before declaring itself finished for no reason at all and removing a wall that had zero need to be removed.
I've tried running the earlier one twice, but it keeps knocking out walls that don't need to be knocked out and making the maze too sparse. I have no idea why the heck this is happening.
I've had a similar problem when trying to make a method for creating a labyrinth.
The important thing when making mazes is to try to NOT create isolated "islands" of connected rooms in the maze. Here's my solution in pseudocode
Room r=randomRoom();
while(r!=null){
recursivelyDigNewDoors(r);
r=null;
for(i=0;i<rooms.count;i++){
if(rooms[i].doors.length == 0 && rooms[i].hasNeighborWithDoor() ){
//if there is a room with no doors and that has a neighbor with doors
Create a door between the doorless room and the one
connected to the rest of your maze
r=rooms[i];
}
}
}
where recursivelyDigNewDoors is a lot like your move() function
In reality, you might like to
describe a "door" as a lack of a wall
and a room without doors as a room with four walls
But the general principle is:
Start your recursive algorithm somewhere
When the algorithm stops: find a place where there's 1 unvisited square and 1 visited.
Link those two together and continue from the previously unvisited square
When no two squares fulfill (2) you're done and all squares are connected
I've this application, where two children are playing catch. One throws and the other catches. While I can show a ball object moving between two stationary objects, how do I show the objects "releasing" and "catching" the ball, in a way that is close to lifelike?
EDIT:
The movement of the hands in this game: http://www.acreativedesktop.com/animation-game-slaphands.html is what I would like to replicate. Any tips on how to do that?
As it's already been stated, you need animation to get it right. I suggest looking over Preston Blair's Cartoon Animation Book or The Animator's Survival Kit. You won't need to read the whole thing, just reference the chapters on anticipation and accents.
For example, when one throws, the action doesn't just happen, one first prepares, anticipating the throw, building up energy. In animation you prepare the viewer for the next action, thus creating a seamless link between actions. Once the ball is thrown...there is action and re-action, so the player will return to his casual pose.
The actionscript part should be pretty simple. You should get away with 3 vectors:
1 for setting the balls movement
1 for gravity
1 for friction/wind...etc.
Based on your parameters, you launch the ball, then use the distance between the ball and the catcher to figure out when you can you play the catcher's animation(s)
skeletal animation is a good technique
also reverse kinematics
or even motion-capture
I know this is essentially possible in flash... it does however sound pretty complex. My advice would be to create static animations for the throw action and the catch action, then have these actions play when certain conditions are met (i.e. the ball gets close to one of the people). Trying to get a lifelike throw and catch will be pretty tough. I would think even a lot of console games wouldn't attempt to do this dynamically (i do expect this is in the process or is changing in current gen games)