Good morning,
I'm working currently on a pathfinding project. Basically, I got this map on my application :
And so I just want to determine the shortest way to go from A to B (of course, I can't go through the blue and gray part which are basically walls...)
Is A* algorithm a good way to start ?
Well if you have any ideas, any suggestions about this problems, tell me ^^
Thank's for your help !
Yes, A* is a good start, assuming you mean to allow movement on the grid only. I mean an agent on a pixel would only travel North, East, South, West and never diagonally. Be warn you will obtain rather un-natural looking paths with 90° and 45° angles everywhere, but this can be mitigated later using some appropriate tie-breaker.
I propose you start using Dijkstra, and once you got that working modify it to implement A* - both algorithms are very close.
If instead you intend to allow your agents to travel diagonally from any pixel to any other pixel which has direct visibility, then no, an other algorithm is needed.
Related
I'm writing 2D space shooter game, something like space invaders, kind of. Right now I have to decide in what way
I will be moving enemy sprites and I can't move forward until I will implement some kind of solution.
Newest version of game source code on my GitHub page (link in profile).
OK, so to the point. First of, I'm using only awt. I want to learn a lot, so I'm not using external libraries in this one.
I want to move my aliens on a 1280x800 field with no obstacles (except other aliens and player).
First I tried to move aliens on predesigned path constructed with Bezier curves, but I was unsatisfied with the result.
Solution lacks flexibility. So I decided to write AI for all aliens and program behavior that way. Unfortunately I didn't wrote
any pathfinding algorithm, and when I started learn about them I couldn't find anything appropriate to my situation. There is a
pathfinding algorithm for finding way in graph, but should I treat every pixel as separate node,
or create logical nodes (couple pixels on couple pixels each), and is it a good way?
Don't take me wrong mates, I'm not looking for fast to build, easy solution. I just need some pointing in right direction,
since my research didn't provide me with enough information.
Should I use a Dijkstra? If yes, how to solve node problem? Or maybe there is a better way?
If you know any good web materials on pathfinding or AI, I would be thankful if you share them with me.
Thanks for getting familiar with the issue mates!
First of all my english is rubbish, so please understand.
I have been asked to do a little simulation/animation in java.
I have a few cog on board one of the cogs rotates all the time on its axis. when I move any other cog close to the rotating one it has to start rotating and teeth can not overlap each other.
I think this link describes it quite well
http://www.csharphelper.com/howto_animate_gear.gif
I don't know how to make this cogs interact together, i will be really happy if some can show some code example
Many thanks for any help
If you know how to rotate the kog, you could cheat a bit, and hard-code the timing so that they rotate at the right time :P
This is a classic LCM (Least Common Multiple) problem: try to formulate a solution from the dimensions (radius or diameter or circumference) of the cogs.
I'm currently working on my 2D game project (Java), but so far any kind of game logic or AI has been crudely implemented. For instance, say I need to randomly position a bunch of sprites a long the top of the screen, I'd be using the Random class to do this. I'd simply use Random.nextInt( size of x axis on which to spawn ); Although this does work I'd be interested to hear how I should really be going about this kind of thing.
As a second scenario (this is why I put AI in the title, although it's not really AI), say I want to have my characters randomly blink in a life-like fashion. What I'd do here is use the Random class to calculate a % (say 20% chance) of blinking and call it every second.
Any suggestions on how I should really be going about this would be greatly appreciated.
Google for a paper titled "Steering Behaviors" by Craig Reynolds. It address just this and you'll find great ideas to start with specifically some nice ideas for giving groups of sprites the appearance of 'intelligent' movement. The key for him in his different behaviors, i.e. flocking, etc. is making properties of any given sprite dependent on those of some other sprite. You could even go so far as to say, like -- any given sprite will blink only if it's two neighbors just have blinked. Something or other along those lines.
Hope this helps!
Are you using an OOP (Object-Oriented approach)? If not, you should definitely look into it. It's really simple with java and can speed up your development time and neaten your code.
I would make a sprite class, and give them a function, say actionSpawn, or actionMove (I like to start my "action" functions with the word action so they are easily identifiable). In this function you would encapsulate the Random.nextInt function, to set the sprite's x and/or y position.
You could use the same approach to make them blink.
I've written a snake game in Java. What I also want to do is to create a demo for that (so snake would play by itself). I've written a simple demo, but snake dies pretty fast. So, is there any algorithms or something for that kind of problem? I believe it is a little bit similar to chess game problem? I want that snake would be alive as long as possible. Thank you.
The Google-sponsored AI Challenge ran a "Tron" game in 2010. You might get some good ideas from searching for solutions to that challenge.
If you just want a very simple strategy that makes a reasonable demo then you might try something like the following:
Never make a move that causes you to crash unless you have no other option
If your next move forces you to choose between two or more distinct (unconnected) spaces, always move into the larger of the two spaces. This will stop your snake from getting trapped too easily.
If you are moving along a wall, keep moving along the wall 98% of the time, following it around to the left or right as needed. This will help your snake look reasonably intelligent, and also conserve space in the playfield.
Otherwise move ahead 90% of the time, turn left and right randomly 5% of the time each (this will make your demo less boring).
Apart from that, I don't think a Chess-style AI approach (with a move search tree) would work very well. You wouldn't be able to easily search enough moves in advance.
This is not the answer you are looking for, but I post it because I would genuinely like to see you explore this algorithm further, modifying it until you find yourself with a pretty reasonable AI:
The simplest algorithm to solve this problem is the "go around the edge, and then squiggle downward" approach. Basically, you start out with a snake, get it so it is moving west, then hug the west wall, then the ceiling. Then you traverse over every possible square like a slinky until you get to the bottom, go west, and start all over again.
If you try, you can turn this into a really excellent AI :D
Without doing the work for you, I can tell you that the best way to start approaching a problem like this is to think about what the snake should do to survive as long as possible. What 'rules of thumb' should the snake follow in order to stay alive. For starters the snake should probably turn before it hits an obstruction, and towards a direction where it won't be boxed in. So, you can program the snake to turn when it is within one space of it's tail (or wall) and towards a direction with the greatest distance between it and other obstructions. Also, snake I believe is a game in which the computer can play perfectly and in your demo you may not want that so you can always throw in some randomness just to spice things up if things get too same-y.
So I'm currently working on some FPS game programming in OpenGL (JOGL, more specifically) just for fun and I wanted to know what would be the recommended way to create an FPS-like camera?
At the moment I basically have a vector for the direction the player is facing, which will be added to the current player position upon pressing the "w" or forward key. The negative of that vector is of course used for the "s" or backward key. For "a", left, and "d", right I use the normal of the direction vector. (I am aware that this would let the player fly, but that is not a problem at the moment)
Upon moving the mouse, the direction vector will be rotated using trigonometry and matrices. All vectors are, of course, normalized for easy speed control.
Is this the common and/or good way or is there an easier/better way?
The way I have always seen it done is using two angles, yaw and pitch. The two axes of mouse movement correspond to changes in these angles.
You can calculate the forward vector easily with a spherical-to-rectangular coordinate transformation. (pitch=latitude=φ, yaw=longitude=θ)
You can use a fixed up vector (say (0,0,1)) but this means you can't look directly upwards or downwards. (Most games solve this by allowing you to look no steeper than 89.999 degrees.)
The right vector is then the cross product of the forward and up vectors. It will always be parallel to the ground plane since the up vector is always perpendicular to the ground plane.
Left/right strafe keys then use the +/-right vector. For a forward vector parallel to the ground plane, you can take the cross product of the right and the up vectors.
As for the GL part, you can simply use gluLookAt() using the player's origin, the origin plus the forward vector and the up vector.
Oh and please, please add an "invert mouse" option.
Edit: Here's an alternative solution which gets rid of the 89.9 problem, asked in another question, which involves building the right vector first (with no pitch information) and then forward and up.
Yes, thats essentially the way I have always seen it done.
Yeah, but in the end you will want to add various other attributes to the camera. To spell it n00b: keep it tidy if you want to mimic Quake or CS. In the end might have bobing, FoV, motion filtering, network lag suspension and more.
Cameras are actually one of the more difficult parts to make in a good game. That's why developers usually are content with a seriously dull, fixed 1st/3rd person ditto.
You could use Quaternions for your camera rotation. Although I have not tried it myself, they are useful for avoiding gimbal lock.