Since we exploited the first possibility and we didn't reach the goal, we take the other possible move: "R from 4 to 2". In this situation, there was only one possible move, so we must go one more step back and resume the situation: LL_LRRR. We have to resume the old situation: L_LLRRR. We don't have any possible move left and we didn't reach the goal. We can decide to take the first possibility in each step. In the starting position, there are two possible moves : "L from 2 to 3" and "R from 4 to 3". ![]() Each element has its position, its letter and new possible position. I decide to make a table containing 7 elements with indexes from 0 to 6. The solution of the problem is usually in the leaves of the tree or (in our case) the path to a leaf. The algorithm for solving the problem is a standard backtracking algorithm with which we review the nodes of a tree. If the move leads to a situation where no more "legal" moves are possible, the computer must discard the move and take the alternative. If the move is leading to the goal, the computer must remember the move and the path to reach this move. The computer must try all the possibilities in a situation. When it makes the first move, it isn't clear if this move will lead to a happy ending. The computer must make moves which lead to the goal. The problems begin when the computer solves the game. In this case, we notify the user and reset the game. It is also possible that no more moves are possible and the goal isn't reached. All we have to do is to validate the user move and check if he has reached the goal. Writing the code for playing the game is simple. The frog with an 'R' can move from right to left for one position or for two positions, if it jumps the frog with an 'L'. ![]() I thoroughly agree with that principle: learning how to learn is the most important skill that someone can learn, because once they know the key to that, they can do anything else with it.The frog with an 'L' can move from left to right for one position or for two positions if it jumps the frog with an 'R'. ![]() ![]() Michael does make a point of showing how to access the documentation of a class as he goes through his tutorials, emphasising that it’s more important to know how to find information that you need than to actually have it in your memory. Indeed, that’s my problem at the moment as well, in all these different programs! I think at this stage the problem can be to keep students focused on what they can do, and developing and practising that, rather than thinking about what they would like to do, and attempting things they’re not up to yet. Michael Kölling also has teacher commentary videos on his site, giving tips and advice to teachers who are introducing the concepts to their students, and these have some very good ideas. And here we come to the argument between teaching things that are useful and/or interesting and things that will get a qualification! For a computer club, however, it would be great. If Greenfoot gets easily to the point where it can be used for more procedural stuff as well, then it would be a good choice, but if that’s a direction it doesn’t move in very easily, then my impression is that it would be difficult to use it at GCSE level (although of course Java itself could easily be used, I would imagine). Indeed, for most of the assessment tasks a GUI is not necessary, and they could be built to use a console. What I’ll be interested to see is the point where the code can be used more generally the GCSE syllabus covers many of the basic code constructs, but not generally to use them in a games context. The game so far is already open to many variations, both in graphics and in behaviour, even at this early stage. Greenfoot definitely has a more grown-up feel than most of the other things I’ve looked at so far, while still being game-based.
0 Comments
Leave a Reply. |