tha ithela na me voithisete na kanw to exis.(terma katw exw ta arxeia pou tha xreiastei)
thanks gia to xrono sas...
1. Problem Description
Develop a graphical user interface to play the game of Nim as described at http://en.wikipedia.org/wiki/Nim. You should implement the game-theoretic solution for this two-person game within a playing program that plays perfectly correct moves when a forced win is possible and an arbitrary move otherwise. Ie the program should be one of the players, a human the other and the program should play perfectly against the human whenever possible. The program must also meet the more detailed requirements given below.
The demonstrations will take place as detailed below.
2. Basic Functionality and Coding Requirements
The program must be able to play under both the usual rule for Nim – that the last player to move wins and the "misere" version where the last player to move loses.
The program must enable the human player to choose the number of heaps, the number of matchsticks in each heap, whether the human or program should make the first move and whether the normal or misere rule should apply. The program must display each heap as a row of matchsticks that makes use of the supplied Matchstick.jpg file (edited if and as necessary to allow the image to fit in a component) to represent each matchstick.
Limits on the maximum number of heaps and matchsticks per heap are left to your discretion, but should not be unreasonably limited and should allow any reasonable length game to be played.
Do not write code to compute a winning move (when one exists) yourself. Instead your program must make use of the static Nim class, for which the object code is provided in file Nim.class. The Nim class documentation together with the source code for a test program (NimApp.java) are provided, but the source code for the Nim class is not. Note that the Nim class will not work on its own – you must compile NimApp.java and then run NimApp with Nim.class in the same directory as NimApp.class
The GUI must be hand coded and use the GridBag layout manager. The NetBeans form-designer may not be used.
4. Assessment Criteria
For basic functionality this is fitness for purpose which includes the usability of the interface.
Code should be maintainable. Thus variable names should be meaningful with the purpose of each given by a brief comment near its declaration. Appropriate programming constructs should be used – e.g. for loops, arrays and procedures should be used to avoid repetitive code and to make code clear and concise. The purpose of each subroutine (class method) should be provided as a comment at the top of its body – ie just after its signature. The same applies to any new classes introduced. Code should be indented to reflect its structure.
Advanced features may extend the application in any way natural and appropriate to the exercise. Every advanced feature should be tasteful and confer a tangible benefit to the user. However advanced features may not include animation or distracting graphical effects.
Κώδικας: Επιλογή όλων