 |
.. (לתיקייה המכילה) | |
Can we assume any bounds on N and S?
|
You can only assume a lower bound of N>=1 and S>=0. You cannot assume any upper bound for any of these parameters. |
Can we use additional classes for our player, besides the one inherited from KalahPlayer?
|
You can supply additional classes to the code. Please make sure your classes names are unique, so that there won't be any name collisions with other players (e.g. your_name_Class). |
When sowing many stones, does one player sow stones to the other player's store?
|
Yes. Sowing stones places stones in all board cells, including both stores, regardless of the current player's color. |
Clarifications regarding the GameTimer class and time measurement:
|
1. There is only move time limitation. There is no game time limitation. 2. The KalahPlayer constructor receives a GameTimer::TimeParams struct containing the time per move limit. It is not a game timer. You should construct an internal GameTimer variable and initialize it with this TimeParams struct. 3. The only indication you get for the start of your turn is the call of KalahPlayer::makeMove. You should start the internal player's move timer as the first action of this function, otherwise it may report remaining time that is too far from the Game::playGame move timer, which can lead to your lose due to timeout. 4. Do not use GameTimer::isMoveTimePassed to check for remaining move time, as when it returns "true" it means you have already lost. As you can see in the code, it already contains the allowed time overhead. 5. An uninitialized move timer returns numeric_limits<double>::max() (that is: +infinity) if the timePerMove_limit flag is set to false, or an undefined value otherwise. 6. The GameTimer currently uses real world time to measure move times. It will perhaps be replaced with user-mode time measurement in CSL1, but not right now. Regarding the Windows way of checking user-mode time is too dependent on the operating system (2000/XP/Vista) and version of Visual Studio so I cannot provide a general enough method for doing it there. |
Why don't you just pass me the timer initialized in the first place to makeMove Function?
|
Because this implies a different time limit for each move. (This was the original design but we didn't want any ambiguities regarding the timer) |
In Player: I see that there is a private member named m_gameTimer which I inherited. I thought it is the times for the game. I started it during the MakeMove.
|
You are correct in doing so. This is actually a design flaw. It should have been a GameTimer::TimeParams struct rather than a GameTimer class. However, if you just let it initialize using Player's constructor (receives times from main()), and use m_gameTimer.startMoveTimer at the beginning of KalahPlayer::makeMove and check the time using m_gameTimer.getRemainingMoveTime, you should be just fine. I will not update the code to correct this flaw, so just be careful and use it correctly. |
Can we use multithreading?
| No. |
How do you compile your program? What optimizations settings do you use?
| This information is irrelevant to your implementation. |
Can we use machine dependent instructions or libraries?
|
Other than the most basic ones (e.g. timer, disk access) you may not use any such code. Anyone using such code will be automatically disqualified from the tournament . Anyone using virus-like actions (e.g. causing massive delays during the other player's turn, messing with the stack) will be automatically disqualified from the tournament and will have (at least) 20 points penalty on the exercise's mark. Please keep your code as simple as possible. |