I am implementing Othello game in Prolog. The game board is represented as list of lists.
I am facing a problem with flipping pieces after making a move.
My strategy is to look in all 8 directions from position where I placed my piece (say black),
and find the enclosing black piece and flip every white piece between my pieces.
So, I have 8 separate predicates to do that.
The problem is I call them sequentially after I make a move, and if any one of these predicates fails, the whole thing fails.
Is there any way to get around this? Or maybe my approach is wrong?
Maybe you should try to OR the predicates?
I know I wrote this for a CS class when studying at uni, I hope your not using stackoverflow to cheat on your assignments... ;)
As suggested by Cari Norum I just make my predicates never fail. So if one fails, I just make it return the current board state. That seems to work.
Related
I'm a relatively inexperienced programmer, and recently I've been getting interested in making a Checkers game app for a school project. I'm not sure where I can start (or if I should even attempt) at creating this. The project I have in mind probably wouldn't involve much more than a simple AI & a multiplayer player mode.
Can anyone give some hints / guidance for me to start learning?
To some extent I agree with some of the comments on the question that suggest 'try something simpler first', but checkers is simple enough that you may be able to get a working program - and you will certainly learn useful things as you go.
My suggestion would be to divide the problem into sections and solve each one in turn. For example:
1) Board representation - perhaps use an 8x8 array to represent the board. You need to be able to fill a square with empty, white piece, black piece, white king, black king. A more efficient solution might be to have a look at 'bit-boards' in which the occupancy of the board is described by a set of 64-bit integers. You probably want to end up with functions that can load or save a board state, print or display the board, and determine what (if anything ) is at some position.
2) Move representation - find a way to calculate legal moves. Which pieces can move and where they can move to. You will need to take into account - moving off the edges of the board, blocked moves, jumps, multiple jumps, kings moving 'backwards' etc. You probably want to end up with functions that can calculate all legal moves for a piece, determine if a suggested move is legal, record a game as a series of moves, maybe interface with the end user so by mousing or entering text commands you can 'play' a game on your board. So even if you only get that far then you have a 'product' you can demonstrate and people can interact with.
3) Computer play - this is the harder part - You will need to learn about minimax, alpha-beta pruning, iterative deepening and all the associated guff that goes into computer game AI - some of it sounds harder than it actually is. You also need to develop a position evaluation algorithm that measures the value of a position so the computer can decide which is the 'best' move to make. This can be as simple as the naive assumption that taking an opponents piece is always better than not taking one, that making a king is better than not making one, or that a move that leaves you with more future moves is better than one that leaves you with less choices for your next move. In practice, even a very simple 'greedy' board evaluation can work quite well if you can look 2-3 moves ahead.
All in all though, it may be simpler to look at something a little less ambitious than checkers - Othello is possibly a good choice and it is not hard to write an Othello player that can thrash a human who hasn't played a lot of the game. 3D tic-tac-toe, or a small dots-and-boxes game might be suitable too. Games like these are simpler as there are no kings or boundaries to complicate things, all (well most) moves are legal and they are sufficiently 'fun' to play to be a worthwhile software demonstration.
First let me state, the task you are talking about is a lot larger then you think it is.
How you should do it is break it down into very small manageable pieces.
The reasons are
Smaller steps are easier to understand
Getting fast feed back will help inspire you to continue and will help you fix things as they go wrong.
As you start think of the smallest step possible of something to do. Here are some ideas of parts to start:
Make a simple title screen- Just the title and to hit a key for it to
go away.
make the UI for an empty checkerboard grid.
I know those sound like not much but those will probably take much ore time than you think.
then add thing like adding the checkers, keeping the the gameboard data etc.,
Don't even think about AI until you have a game that two players can play with no UI.
What you should do is think about: what is the smallest increment I can do and add that, add that and then think about what the next small piece is.
Trust me this is the best way about going about it. If you try to write everything at once it will never happen.
I'm trying to solve the Sokoban puzzle in Prolog using a depth-first-search algorithm, but I cannot manage to search the solution tree in depth. I'm able to explore only the first level.
All the sources are at Github (links to revision when the question was asked) so feel free to explore and test them. I divided the rules into several files:
board.pl: contains rules related to the board: directions, neighbourhoods,...
game.pl: this file states the rules about movements, valid positions,...
level1.pl: defines the board, position of the boxes and solution squares for a sample game.
sokoban.pl: tries to implement dfs :(
I know I need to go deeper when a new state is created instead of checking if it is the final state and backtracking... I need to continue moving, it is impossible to reach the final state with only one movement.
Any help/advice will be highly appreciated, I've been playing around without improvements.
Thanks!
PS.- ¡Ah! I'm working with SWI-Prolog, just in case it makes some difference
PS.- I'm really newbie to Prolog, and maybe I'm facing an obvious mistake, but this is the reason I'm asking here.
This is easy to fix: In sokoban.pl, predicate solve_problem/2, you are limiting the solution to lists of a single element in the goal:
solve_dfs(Problem, Initial, [Initial], [Solution])
Instead, you probably mean:
solve_dfs(Problem, Initial, [Initial], Solution)
because a solution can consist of many moves.
In fact, an even better search strategy is often iterative deepening, which you get with:
length(Solution, _),
solve_dfs(Problem, Initial, [Initial], Solution)
Iterative deepening is a complete search strategy and an optimal strategy under quite general assumptions.
Other than that, I recommend you cut down the significant number of impure I/O calls in your program. There are just too many predicates where you write something on the screen.
Instead, focus on a clear declarative description, and cleanly separate the output from a description of what a solution looks like. In fact, let the toplevel do the printing for you: Describe what a solution looks like (you are already doing this), and let the toplevel display the solution as variable bindings. Also, think declaratively, and use better names like dfs_moves/4, problem_solution/2 instead of solve_dfs/4, solve_problem/2 etc.
DCGs may also help you in some places of your code to more conveniently describe lists.
+1 for tackling a nice and challenging search problem with Prolog!
I have been trying to write a platformer engine for a few times now. The thing is I am not quite satisfied with my implementation details on solid objects. (wall, floor, ceiling) I have several scenario I would like to discuss.
For a simple platformer game like the first Mario, everything is pretty much blocks. A good implementation should only check for necessary collision, for instance, if Mario is running and at the end of the way, there is a cliff, how should we check for collision efficiently? Should we always check on every step Mario is taking to see whether his hitbox is still on the ground? Or is there some other programming way that allows us to not handle this every frame?
But blocks are boring, let's put in some slopes. Implementation details-wise, how should slopes be handled? Some games such as Sonic, have this loop structure that the character can go "woohoo" in the loop and proceed.
Another scenario is "solid" objects (floor, ceiling, wall) handling. In Megaman, we can see that the player can make himself go through the ceiling by using a tool to go into the solid "wall". Possibly, the programming here is to force the player to go out of the wall so that the player is not stuck, by moving the player quickly to the right. This is an old "workaround" method to avoid player stucking in wall. In newer games these days, the handle is more complex. Take, for instance, Super Smash Brawl, where players can enlarge the characters (along with their hitbox) The program allows the player to move around "in" the ceiling, but once the character is out of the "solid" area, they cannot move back in. Moreover, sometimes, a character is gigantic that they go through 3 solid floors of a scene and they can still move inside fine. Anybody knows implementation details along these lines?
So here, I know that there are many implementation possible, but I just wanna ask here that are there some advanced technical details for platformer game that I should be aware of? I am currently asking for 3 things:
How should solid collision of platformer game be handled efficiently? Can we take lesser time to check whether a character has ran and completely fell off a platform?
Slope programming. At first, I was thinking of physics engine, but I think it might be overkill. But in here, I see that slopes are pretty much another types of floor that "push" or "pull" the character to different elevation. Or should it be programmed differently?
Solid objects handling for special cases. There might be a time where the player can slip into the solid objects either via legal game rules or glitches, but all in all, it is always a bad idea to push the player to some random direction if he is in a wall.
For a small number of objects, doing an all-pairs collision detection check at each time step is fine. Once you get more than a couple hundred objects, you may want to start considering a more efficient method. One way is to use a binary space partitioning (BSP) to only check against nearby objects. Collision detection is a very well researched topics and there are a plethora of resources describing various optimizations.
Indeed, a physics engine is likely overkill for this task. Generally speaking, you can associate with each moving character a "ground" on which he is standing. Then whenever he moves, you simply make him move along the axis of the ground.
Slipping into objects is almost always a bad idea. Try to avoid it if possible.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
This is not a homework question, but rather my intention to know if this is what it takes to learn programming. I keep loggin into TopCoder not to actually participate but to get the basic understand of how the problems are solved. But to my knowledge I don't understand what the problem is and how to translate the problem into an algorithm that can solve it.
Just now I happen to look at ACM ICPC 2010 World Finals which is being held in china. The teams were given problem sets and one of them is this:
Given at most 100 points on a plan with distinct x-coordinates,
find the shortest cycle that passes through each point exactly once,
goes from the leftmost point always to the right until it reaches the
rightmost point, then goes always to the left until it gets back to the
leftmost point. Additionally, two points are given such that the the path
from left to right contains the first point, and the path from right to
left contains the second point. This seems to be a very simple DP: after
processing the last k points, and with the first path ending in point a
and the second path ending in point b, what is the smallest total length
to achieve that? This is O(n^2) states, transitions in O(n). We deal
with the two special points by forcing the first path to contain the first
one, and the second path contain the second one.
Now I have no idea what I am supposed to solve after reading the problem set.
and there's an other one from google code jam:
Problem
In a big, square room there are two point light sources:
one is red and the other is green. There are also n circular pillars.
Light travels in straight lines and is absorbed by walls and pillars.
The pillars therefore cast shadows: they do not let light through.
There are places in the room where no light reaches (black), where only
one of the two light sources reaches (red or green), and places where
both lights reach (yellow). Compute the total area of each of the four
colors in the room. Do not include the area of the pillars.
Input
* One line containing the number of test cases, T.
Each test case contains, in order:
* One line containing the coordinates x, y of the red light source.
* One line containing the coordinates x, y of the green light source.
* One line containing the number of pillars n.
* n lines describing the pillars. Each contains 3 numbers x, y, r.
The pillar is a disk with the center (x, y) and radius r.
The room is the square described by 0 ≤ x, y ≤ 100. Pillars, room
walls and light sources are all disjoint, they do not overlap or touch.
Output
For each test case, output:
Case #X:
black area
red area
green area
yellow area
Is it required that people who program should be should be able to solve these type of problems?
I would apprecite if anyone can help me interpret the google code jam problem set as I wish to participate in this years Code Jam to see if I can do anthing or not.
Thanks.
It is a big mistake to start from hard problems. Many World Finals problems are too hard for lots of experienced programmers, so it is no surprise that it is also too hard for someone new.
As others have said, start with much easier problems. I am assuming you know the basics of programming and can write code in at least one programming language. Try problems from Division-2 problemsets on TopCoder, and Regional/Qualifying rounds of ACM ICPC. Find out the easy problems from sites like SPOJ, UVa and Project Euler (there are lists of easy problems available online) and solve them. As you solve, also read up on the basics of algorithms and computer science. TopCoder is a great resource since they have lots of tutorials and articles and also allow you to view other people's solutions.
IMHO, becoming a better programmer in general takes a lot of practice and study. There is no shortcut. You cannot assume that you are some sort of hero programmer who can just jump in and solve everything. You just have to accept that there is a long way to go, and start at the beginning.
You should start with much easier problems. Try looking for regionals, or even get the problems from the local schools contest.
You need to have a large view of general programming, from data structures to algorithms. Master a basic programming language, one that the answers are accepted.
You cannot start learning programming by doing competitions. If you don't know any programming at all, the first programs you will write are things like "hello world", fibonacci and ackermann. Starting with things like TopCoder is like learning to drive using a formula one car. It doesn't work that way.
In short, you have to know some basic techniques that are used to develop this kinds of problems. Knowing dynamic programming, backtracking algorithms, searching, etc, helps you a lot when solving the problems.
This one from Google Code Jam is actually pretty hard, and involves computational geometry algorithms. How to solve it is detailed here: http://code.google.com/codejam/contest/dashboard?c=311101#s=a&a=5
I've been working Google Code Jam problems for the past week or so, and I think they are great exercises. The key is to find problems that stretch your abilities a little, but aren't the ones that make you want to give up. Google Code Jam problems range widely in difficulty!
I recommend starting with the ones under "Where should I start" here:
http://code.google.com/codejam/contests.html
And then explore all of the competition round 1 problems. If those are too easy move up to the other rounds.
The thing I really like about code jam is that you can use pretty much any language you want, and you can get feedback from their automated judge. If you run out of Code Jam problems check out some of the other sites that others have mentioned.
You are very right JesperE. JPRO, go back to the basics and get it settled from there. Your ability to compete and win programming contests depends on just two things:
Your deep understanding of the language you are using and
your mental flexibility with the language.
Read Problem Solving Through Problems by Larson.
It's for mathematics but I find it extremely useful for solving algorithm problems.
Can someone give me some pointers on how I should implement the artificial intelligence (human vs. computer gameplay) for a Puyo Puyo game? Is this project even worth pursuing?
The point of the game is to form chains of 4 or more beans of the same color that trigger other chains. The longer your chain is, the more points you get. My description isn't that great so here's a simple video of a game in progress: http://www.youtube.com/watch?v=K1JQQbDKTd8&feature=related
Thanks!
You could also design a fairly simple expert system for a low-level difficulty. Something like:
1) Place the pieces anywhere that would result in clearing blocks
2) Otherwise, place the pieces adjacent to same-color pieces.
3) Otherwise, place the pieces anywhere.
This is the basic strategy a person would employ just after becoming familiar with the game. It will be passable as a computer opponent, but it's unlikely to beat anybody who has played more than 20 minutes. You also won't learn much by implementing it.
Best strategy is not to kill every single chain as soon as possible, but assemble in a way, that when you brake something on top everything collapse and you get lot of combos. So problem is in assembling whit this combo strategy. It is also important that there is probably better to make 4 combos whit 5 peaces that 5 combos whit 4 peaces (but i am not sure, check whit scoring)
You should build big structure that allows this super combo moves. When building this structure you have also problem, that you do not know, which peace you will you get (except for next peace), so there is little probability involved.
This is very interesting problem.
You can apply:
Dynamic programming to check the current score.
Monte Carlo for probability needs.
Little heuristics (heuristics always solve problem faster)
In general I would describe this problem as optimal positioning of peaces to maximise probability of win. There is no single strategy, because building bigger "heap" brings greater risk for loosing game.
One parameter of how good your heap is can be "entropy" - number of single/buried peaces, after making combo.
The first answer that comes to mind is a lookahead search with alpha-beta pruning. Is it worth doing? Perhaps as a learning exercise.