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.
Related
I wasn't sure if this was the correct forums to post this on; I was considering the Game Development site.
I'm developing a game in LibGDX (Java) and I've set up a btKinematicCharacterController to control the player. This handles the jumping, walking, and everything else.
However, I've come across a problem. Imagine that the character is standing on a slope -- even a very gradual one. The character will slowly slide down the slope, which is very annoying for the purpose of my game (and, I imagine, most.) This is because if a player wants to just stand on a slope, they can't.
I think this is happening because of the collision detection resolution. The player may very slightly fall through the floor, and since it's on a slope, would then be pushed out along the normal of the slope. This would mean, simply, they'd be pushed along slightly.
My actual player model is a capsule, and I use a ghost object for the btKinematicCharacterController.
So how can I make sure that my character doesn't slide down slopes? Of course, it needs to still have physics so that it can jump, and collide with other objects.
One of the popular approach is to disable gravity when there are >=1 platforms under the character's foot.
It can be done by :-
sensor (setSensor(true) + collision callback)
For more information about collision callback : http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Collision_Callbacks_and_Triggers
ray test : http://bulletphysics.org/mediawiki-1.5.8/index.php/Using_RayTest
Another approach is to hard code it (link to a short discussion - 2D Metroid related), but it is a hard work and heavily depend on the stage design.
This video may help. It is Unity, not related to Bullet, but seems applicable.
I am also very interested in this problem. Please don't accept if it doesn't solve.
To reader, if there are better answers, feel free to share.
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.
Yesterday I came across Craig Reynolds' Boids, and subsequently figured that I'd give implementing a simple 2D version in Java a go.
I've put together a fairly basic setup based closely on Conrad Parker's notes.
However, I'm getting some rather bizarre (in my opinion) behaviour. Currently, my boids move reasonably quickly into a rough grid or lattice, and proceed to twitch on the spot. By that I mean they move around a little and rotate very frequently.
Currently, I have implemented:
Alignment
Cohesion
Separation
Velocity limiting
Initially, my boids are randomly distributed across the screen area (slightly different to Parker's method), and their velocities are all directed towards the centre of the screen area (note that randomly initialised velocities give the same result). Changing the velocity limit value only changes how quickly the boids move into this pattern, not formation of the pattern.
As I see it, this could be:
A consequence of the parameters I'm using (right now my code is as described in Parker's pseudocode; I have not yet tried areas of influence defined by an angle and a radius as described by Reynolds.)
Something I need to implement but am not aware of.
Something I am doing wrong.
The expected behaviour would be something more along the lines of a two dimensional version of what happens in the applet on Reynolds' boids page, although right now I haven't implemented any way to keep the boids on screen.
Has anyone encountered this before? Any ideas about the cause and/or how to fix it? I can post a .gif of the behaviour in question if it helps.
Perhaps your weighting for the separation rule is too strong, causing all the boids to move as far away from all neighboring boids as they can. There are various constants in my pseudocode which act as weights: /100 in rule 1 and /8 in rule 3 (and an implicit *1 in rule 2); these can be tweaked, which is often useful for modelling different behaviors such as closely-swarming insects or gliding birds.
Also the arbitrary |distance| < 100 in the separation rule should be modified to match the units of your simulation; this rule should only apply to boids within close proximity, basically to avoid collisions.
Have fun!
If they see everyone, they will all try to move with average velocity. If they see only some there can be some separated groups.
And if they are randomly distributed, it will be close to zero.
If you limit them by rectangle and either repulse them from walls or teleport them to other side when they got close) and have too high separation, they will be pushed from walls (from walls itself or from other who just were teleported, who will then be pushed to other side (and push and be pushed again)).
So try tighter cohesion, limited sight, more space and distribute them clustered (pick random point and place multiple of them small random distance from there), not uniformly or normaly.
I encountered this problem as well. I solved it by making sure that the method for updating each boid's velocity added the new velocity onto the old, instead of resetting it. Essentially, what's happening is this: The boids are trying to move away from each other but can't accelerate (because their velocities are being reset instead of increasing, as they should), thus the "twitching". Your method for updating velocities should look like
def set_velocity(self, dxdy):
self.velocity = (self.velocity[0] + dxdy[0], self.velocity[1] + dxdy[1])
where velocity and dxdy are 2-tuples.
I wonder if you have a problem with collision rectangles. If you implemented something based on overlapping rectangles (like, say, this), you can end up with the behaviour you describe when two rectangles are close enough that any movement causes them to intersect. (Or even worse if one rectangle can end up totally inside another.)
One solution to this problem is to make sure each boid only looks in a forwards direction. Then you avoid the situation where A cannot move because B is too close in front, but B cannot move because A is too close behind.
A quick check is to actually paint all of your collision rectangles and colour any intersecting ones a different colour. It often gives a clue as to the cause of the stopping and twitching.
I need to make a text-based RPG game with java. The first part of the assignment is super simple. we just use vertical lines and underscores to make a little rectangle and then add symbols inside the rectangle as things move, act, die, etc.
I've never done this before, so I want to run my idea by you:
What do you think about doing something like angry birds but with flying moving targets? There would be a little "bird tank" at the bottom left of the screen that would shoot birds. Another question: I'm not entirely sure how I would create a gun that shoots at different angles in a text-based format. And how would it work with aiming and shooting and timing, and such?
Update:
I think I'm going to try out a tank game. But I'm confused about how to implemenent the angle of the turret.
I would put the tank in the bottom left corner, put I only have text symbols at my disposal. I don't see how its possible to let the user control the turret, and make it move up and down by small amounts (at least, not until we start using images/gui's.)
Any ideas?
First, in order to make your idea meet the criteria of an RPG, you would have to add a few components. Your gun would need to gain experience as you hit your targets, and would have to level up after enough time. It could gain better speed or accuracy. It could also earn upgrade points that you could spend on different birds to shoot. It would probably also be cool if your targets had hit points and you had to hit some of them multiple times to kill them. You could show the damage by changing the color of the text. These elements will give it more of an RPG feel so that you can meet the criteria of the assignment.
As for the mechanics of the game, you're going to have to write some sort of physics engine. It doesn't have to be very complicated, just enough to be able to calculate or modify a trajectory and determine if there was a collision. This engine would have some sort of a tick() method on it where it would advance the positions of the birds and targets and then you could call a getCollisions() method and handle each one. That's the simple way. The more complex way would involve giving the engine its own thread where it runs constantly, as fast as it can. Then, when there is a collision, it fires off an event to a listener, and you set up some sort of handler to apply the damage to the target, award points, etc.
I would recommend you model the world in finer resolution than your text console. Make the text console simply mark the birds and targets by rounding them to the nearest 80x25 console location, but internally use a much higher resolution. This will keep it looking more realistic, even in an environment with such a poor resolution.
For the controls of the game, I would recommend putting a target reticule on the screen. The user can move it around with their arrow keys to aim and press the space bar to shoot. They wouldn't hit the target because gravity should pull the bird downward, or perhaps because the bird is a special shot that splits into pieces. Regardless, they would learn how to lead their targets appropriately, and that would be the skill of the game.
It's a complicated project. Good luck!
Firstly, this is AI for PacMan and not the ghosts.
I am writing an Android live wallpaper which plays PacMan around your icons. While it supports user suggestions via screen touches, the majority of the game will be played by an AI. I am 99% done with all of the programming for the game but the AI for PacMan himself is still extremely weak. I'm looking for help in developing a good AI for determining PacMan's next direction of travel.
My initial plan was this:
Initialize a score counter for each direction with a value of zero.
Start at the current position and use a BFS to traverse outward in the four possible initial directions by adding them to the queue.
Pop an element off of the queue, ensure it hasn't been already "seen", ensure it is a valid board position, and add to the corresponding initial directions score a value for the current cell based on:
Has a dot: plus 10
Has a power up: plus 50
Has a fruit: plus fruit value (varies by level)
Has a ghost travelling toward PacMan: subtract 200
Has a ghost travelling away from PacMan: do nothing
Has a ghost travelling perpendicular: subtract 50
Multiply the cell's value times a pecentage based on the number of steps to the cell, the more steps from the initial direction, the closer the value of the cell gets to zero.
and enqueue the three possible directions from the current cell.
Once the queue is empty, find the highest score for each of the four possible initial directions and choose that.
It sounded good to me on paper but the ghosts surround PacMan extremely rapidly and he twitches back and forth in the same two or three cells until one reaches him. Adjusting the values for the ghost presence doesn't help either. My nearest dot BFS can at least get to level 2 or 3 before the game ends.
I'm looking for code, thoughts, and/or links to resources for developing a proper AI--preferably the former two. I'd like to release this on the Market sometime this weekend so I'm in a bit of a hurry. Any help is greatly appreciated.
FYI, this was manually cross-posted on GameDev.StackExchange
If PacMan gets stuck in a position and starts to twitch back and forth then it suggests that the different moves open to him have very similar scores after you run your metric. Then small changes in position by the ghosts will cause the best move to flip back and forth. You might want to consider adding some hysteresis to stop this happening.
Setup: Choose a random move and record it with score 0.
For each step:
Run the scoring function over the available moves.
If the highest score is x% greater than the record score then overwrite the record score and move with this one.
Apply the move.
This has the effect that PacMan will no longer pick the "best" move on each step, but it doesn't seem like a greedy local search would be optimal anyway. It will make PacMan more consistent and stop the twitches.
Have a way to change PacMan into a "path following" mode. The plan is that you detect certain circumstances, calculate a pre-drawn path for PacMan to follow, and then work out early exit conditions for that path. You can use this for several circumstances.
When PacMan is surrounded by ghosts in three of the four directions within a certain distance, then create an exit path that either leads PacMan away from the ghosts or towards a power up. The exit situation would be when he eats the power up or ceases to be surrounded.
When PacMan eats a power up, create a path to eat some nearby ghosts. The exit situation would be when there are no ghosts on the path, recalculate the path. Or if there are no ghosts nearby, exit the mode entirely.
When there are less than half the dots left, or no dots nearby, enter a path to go eat some dots, steering clear of the ghosts. Recalculate the path when a ghost comes nearby, or exit it entirely if several ghosts are nearby.
When there are no situations which warrant a path, then you can revert back to the default AI you programmed before.
You can use Ant Colony Optimisation techniques to find shortest visible path that leads to many icons to eat or can get many score.
I don't know a lot about AI or specific algorithms, but here are some things you could try that might just get you close enough for government work :)
For the problem with ghosts surrounding him quickly, maybe the ghost AI is too powerful? I know that there's supposedly specific behaviors for each ghost in classical Pacman, so if you haven't incorporated that, you may want to.
To eliminate backtracking, you could create an weight penalty for recently traversed nodes, so he's less inclined to go back to previous paths. If that's not enough to kick him in one direction or another, then you can logarithmically increase the attraction penalty, so one path will become significantly more attractive than the other at a very quick rate.
For the problem of him getting caught by ghosts, you might be able to change from a general goal-based algorithm to an evasive algorithm once the ghosts have reached a dangerous node proximity.
You might benefit of knowing how the bots "reason" (as explained in this excellent dossier). For example, knowing the chase/scatter pattern of the ghosts will allow you to get the dots in "dangerous" locations, and so on.
I am adding this answer knowing that it's not the best solution you were looking for (since you wanted to deliver next week..) but maybe will be of use to somebody reading this in the future. Sortof a time capsule :)
You should check out this description of Antiobjects, which is the technique used by the Pacman ghosts to traverse the maze. In particular, note:
Each of these antiobjects or agents
has an identical and simple algorithm
which it runs at every turn of the
game. Instead of making Ghosts smart
enough to solve "shortest path"
problems around the maze, a notion of
"Pac-Man scent" is created instead and
each tile is responsible for saying
how much Pac-Man scent is on its tile.
So you consider a similar scent-based technique to control Pacman, perhaps where Pacman preferred traversing a path with a smaller amount of scent; this would reduce the chance of him going over old ground.