I'm developing a small game in python. I am using a 2D rectangular grid. I know that for pathfinding I can use A* and the likes, I know how this works, but the problem I have is a bit different.
Let's say we have a computer controlled human and some computer controlled zombies. When the human spots a zombie, it should get away from this as far as he can. At the moment, to test everything I just turn around 180° and run away, until I spot another zombie and repeat.
Obviously this is not very smart (and can cause problems if there is a zombie on both sides).
I was wondering if there was a smarter way to do this? Something like using Dijkstra to find a "safe zone" where I can run to? Alternatives are always welcome, I can't seem to figure it out.
You could suppose that the zombies can see everything within a particular range (radius or perhaps be more clever) and then have the human look for a spot that he thinks the zombies can't see. Pick the closest spot the zombie can't see and use the A* algorithm to find a path if one exists, else try a different one. Look out when there's nowhere to run. Alternatively you could weight all of the spots in your visibility region with a value based on how far away you would be from the zombies if you chose that spot.
Just off the top of my head, you'll probably be able to do some vector math and have the human run in the normal vector to the zombies.
I don't know how well this will work (or how it will scale to the number of zombies you have), but you could do something like:
For each zombie, compute the distance to the human and the direction it is from the human.
Create a vector for each zombie (or some subset of the close zombies), using the direction and the inverse of the distance, since the closer the zombie is the more important it is to run away.
Find the sum of all the vectors.
Make the human run in the normal vector to your result.
I'm not sure how resource intensive this would be, but it seems like the most logical way to prioritize where to run.
Related
All I'm trying to do is move from one place on the screen to another, as a human would do, but very quickly...
My code looks like this & doesn't seem to work
from pyclick import HumanClicker
hc = HumanClicker()
hc.move((500, 500), 0.04)
Is there anything I'm doing wrong? I've looked at some posts: this & this
They both don't help my issue. if anyone knows the solution, please tell me...
HumanClicker generates a Bezier curve with 100 points to go from your start to your end. It sleeps between each point for your time period divided by the number of points, which in your case would be 0.0004s, which is below the scheduling threshold. That means you're going to delay for 100 scheduling intervals, which is a pretty long time.
If you want to move the mouse to a point, just use
pyautogui.moveTo(point)
You CAN create your own HumanCurve instance and specify fewer points, and then pass that to move.
I'm producing an ugv prototype. The goal is to perform the desired actions to the targets set within the maze. When I surf the Internet, the mere right to navigate in the labyrinth is usually made with a distance sensor. I want to consult more ideas than the question.
I want to navigate the labyrinth by analyzing the image from the 3d stereo camera. Is there a resource or successful method you can suggest for this? As a secondary problem, the car must start in front of the entrance of the labyrinth, see the entrance and go in, and then leave the labyrinth after it completes operations in the labyrinth.
I would be glad if you suggest a source for this problem. :)
The problem description is a bit vague, but i'll try to highlight some general ideas.
An useful assumption is that labyrinth is a 2D environment which you want to explore. You need to know, at every moment, which part of the map has been explored, which part of the map still needs exploring, and which part of the map is accessible in any way (in other words, where are the walls).
An easy initial data structure to help with this is a simple matrix, where each cell represents a square in the real world. Each cell can be then labelled according to its state, starting in an unexplored state. Then you start moving, and exploring. Based on the distances reported by the camera, you can estimate the state of each cell. The exploration can be guided by something such as A* or Q-learning.
Now, a rather subtle issue is that you will have to deal with uncertainty and noise. Sometimes you can ignore it, sometimes you don't. The finer the resolution you need, the bigger is the issue. A probabilistic framework is most likely the best solution.
There is an entire field of research of the so-called SLAM algorithms. SLAM stands for simultaneous localization and mapping. They build a map using some sort of input from various types of cameras or sensors, and they build a map. While building the map, they also solve the localization problem within the map. The algorithms are usually designed for 3d environments, and are more demanding than the simpler solution indicated above, but you can find ready to use implementations. For exploration, something like Q-learning still have to be used.
Query:
I want to estimate the trajectory of a person wearing an IMU between point a and point b. I know the exact location of point a and point b in an x,y,z space and the time it takes the person to walk between the points.
Is it possible to reconstruct the trajectory of the person moving from point a to point b using the data from an IMU and the time?
This question is too broad for SO. You could write a PhD thesis answering it, and I know people who have.
However, yes, it is theoretically possible.
However, there are a few things you'll have to deal with:
Your system is going to discretize time on some level. The result is that your estimate of position will be non-smooth. Increasing sampling rates is one way to address this, but this frequently increases the noise of the measurement.
Possible paths are non-unique. Knowing the time it takes to travel from a-b constrains slightly the information from the IMUs, but you are still left with an infinite family of possible routes between the two. Since you mention that you're considering a person walking between two points with z-components, perhaps you can constrain the route using knowledge of topography and roads?
IMUs function by integrating accelerations to velocities and velocities to positions. If the accelerations have measurement errors, and they always do, then the error in your estimate of the position will grow over time. The longer you run the system for, the more the results will diverge. However, if you're able to use roads/topography as a constraint, you may be able to restart the integration from known points in space; that is, if you can detect 90 degree turns on a street grid, each turn gives you the opportunity to tie the integrator back to a feasible initial condition.
Given the above, perhaps the most important question you have to ask yourself is how much error you can tolerate in your path reconstruction. Low-error estimates are going to require better (i.e. more expensive) sensors, higher sampling rates, and higher-order integrators.
I'm making a game with Python->PyGame->Albow and ran into a problem with board generation. However I'll try to explain the problem in a language agnostic way. I believe it's not related to python.
I've split the game board generation into several parts.
Part one generates the board holes.
Holes are contained in a list/array. Each hole object has a mapping of angles relating to other holes which are surrounding it, each of those holes also links back to it. (Sort of like HTML DOM siblings, the difference being any angle is possible)
A hole is something like:
hole = {
empty: True,
links: {
90: <other hole>,
270: <another hole>,
etc...
}
}
Part two, calculate hole positions.
The code is something like this.
def calculate_position(hole):
for linked_hole in hole.links:
if linked_hole.position == None:
#calculate linked hole's position relative to this hole
linked_hole.position = [position relative to first hole]
calculate_position(linked_hole)
first_hole.position = (0, 0) #x, y
calculate_position( first_hole )
Part three, draw board.
Find the window height, expand the positions of holes (calculated in step two) to fit the window. Draw everything.
I believe that the problem is in step two I am calculating every hole relative to a previous hole. Rounding errors add up and the board goes squint shaped the further away from the starting hole the holes are and the bigger the board is. This only happens when making boards that aren't rectangular because otherwise there aren't rounding errors.
I am using simple trigonometry to calculate the relative positions of holes by converting the angle into radians and using built in sin/cos functions.
Any idea as to a solution or if I'm mistaken as to the problem is useful :)
PS: I will post the source code if it would help however feel it will clutter things up
Thanks for all the answers.
The people who said rounding probably wasn't going to be an issue were spot on. I had another look through the code with that in mind. I'm embarrassed to say I was generating the wrong angles in the first part of the board generation, the rendering part was correct.
I've marked Norman's answer as correct because it explains how to use a linear combination of vectors to solve the problem.
If hole positions are stored as integers, I don't doubt rounding error accumulates quickly enough to kill you. If hole positions are stored as floating point, and if you have an error of one unit in the last place (ULP) at each computation, I'm not quite sure how quickly error accumulates—but if error doubles at each step, then you have at most 53 links before even double-precision floating point would go wrong.
If you want to be rock-solid accurate, I would represent each position as a linear combination of vectors. You can represent each vector by its angle, and you have just a few angles, so you can represent the position of a hole as something like
Take six 30-degree steps and two 90-degree steps and four 180-degree steps
The numbers six, two, and four will be exact, and once you've computed all positions as vectors, you can then do the trig to convert to (x, y) coordinates all at one go. If you're worried about speed you can cache the arctangent of each angle and it will even be fast.
If this description is too terse, let me know.
The bit about accuracy becomes relatively important as soon as we realize these points are going to be converted to pixel coordinates, a.k.a. integers. Accumulate an error of 0.5 and bam! You're one pixel off.
So, either there is a huge problem with accuracy and rounding errors are climbing very very fast, or the source of the issue is elsewhere. I'm looking at this in step in particular:
expand the positions of holes (calculated in step two) to fit the window
Until I see a screenie, I'll assume "squint" means 'oval-kinda-sorta-thing'; sounds exactly what a bug in this step could produce.
I hate to be the one to suggest this, but, start in the the center. Also, you should look at your code and double check for an unfortunate conversion. The is, if a hole ends up at "138.2, 150.8", you need to keep the fractional parts until you have computed the next hole.
I'm working on an adventure game in Python using Pygame. My main problem is how I am going to define the boundaries of the room and make the main character walk aroud without hitting a boundary every time. Sadly, I have never studied algorithms so I have no clue on how to calculate a path. I know this question is quite general and hard to answer but a point in the right direction would be very appreciated. Thanks!
There are two easy ways of defining your boundaries which are appropriate for such a game.
The simpler method is to divide your area into a grid, and use a 2D array to keep track of which squares in the grid are passable. Usually, this array stores your map information too, so in each position, there is a number that indicates whether that square contains grass or wall or road or mountain etc. (and therefore what picture to display). To give you a rough picture:
######
#.# #
# ## #
# #
######
A more complex method which is necessary if you want a sort of "maze" look, with thin walls, is to use a 2D array that indicates whether there is a vertical wall in between grid squares, and also whether there is a horizontal wall between grid squares. A rough picture (it looks a stretched in ASCII but hopefully you'll get the point):
- - - -
| | |
- -
| |
- - - -
The next thing to decide is what directions your character may move in (up/down/left/right is easiest, but diagonals are not too much harder). Then the program basically has to "mentally" explore the area, starting from your current position, hoping to come across the destination.
A simple search that is easy to implement for up/down/left/right and will find you the shortest path, if there is one, is called Breadth-First search. Here is some pseudocode:
queue = new Queue #just a simple first-in-first-out
queue.push(startNode)
while not queue.empty():
exploreNode = queue.pop()
if isWalkable(exploreNode): #this doesn't work if you use
#"thin walls". The check must go
#where the pushes are instead
if isTarget(exploreNode):
#success!!!
else:
#push all neighbours
queue.push( exploreNode.up )
queue.push( exploreNode.down )
queue.push( exploreNode.left )
queue.push( exploreNode.right )
This algorithm is slow for large maps, but it will get you used to some graph-search and pathfinding concepts. Once you've verified that it works properly, you can try replacing it with A* or something similar, which should give the same results in less time!
A* and many other searching algorithms use a priority queue instead of a FIFO queue. This lets them consider "more likely" paths first, but get around to the roundabout paths if it turns out that the more direct paths are blocked.
I recommend you read up on the A* search algorithm as it is commonly used in games for pathing problems.
If this game is two dimensional (or 2.5) I suggest you use a tile system as checking for collisions will be easier. Theres lots of information online that can get you started with these.
Sadly, I have never studied algorithms so I have no clue on how to calculate a path.
Before you start writing games, you should educate yourself on those. This takes a little more effort at the beginning, but will save you much time later.
I am not familiar with pygame, but many applications commonly use bounding volumes to define the edge of some region. The idea is that as your character walks, you will check if the characters volume intersects with the volume of a wall. You can then either adjust the velocity or stop your character from moving. Use differing shapes to get a smooth wall so that your character doesn't get stuck on the pointy edges.
These concepts can be used for any application which requires quick edge and bounds detection.