So far I’ve been working on the Draughts project for several hours over the last week and I am happy with the progress that has been made. I am right on target to meet both deadlines that I have set. One thing that I have underestimated is the amount of planning that was required. Initially the overall game structure was planned out. This included things such as the data structures used, object orientated models and code structure. There are two things that I didn’t plan for and I want to talk about them today.
The first issue I found is how the player should move their pieces. I wanted to make this process as intuitive as possible, so intuitive that the user wouldn’t need the controls explained to them. I came up with two strategies to solve this issue.
Drop and Drag
The drop and drag method involved the player clicking on the piece and then dragging it to the location they desired. My first thought was that this approach was rather intuitive since it mirrors the movements that someone would take in real life. I then thought back to my experience with other games that required you to move pieces such as Puzzle Quest and Bookworm Adventures. Both of these games don’t make you drag pieces across the screen and there is a good reason for it. After a while it becomes a tedious process. Other issues arise such as collision detection between pieces and squares as demonstrated below. Technically it also ads to the code complexity and processing oomf that is required.
Refresh five times or twice?
Click and Select
This method is the one I used in my version of Draughts. It is simple to program and simpler for the user. You simply click on the piece that you want to move and then click where you want to move it. One of the greatest benefits compared to the previous approach is that you are required to update the screen less often. You only need to refresh the screen once the player has made a choice and then refresh the squares that are modified in that choice which tends to be two squares. The square where the piece existed and the square where the piece moves to. Whereas with the drop and drag approach you have to update the screen every time you incrementally move the mouse, in order to create the result of the piece following the cursor. What makes this worse though is that you also have to refresh the squares that the piece moves over.
The second issue that I came across was how to handle the multiple jumps in draughts. Initially I wanted to show all of the possible moves a player could make in one turn and highlight the respective squares. This became impossible when you think about trying to represent it on the screen. What struck me though was that by showing all of the possible moves to a player was that I was showing them too much. So I decided to limit the scope of what was shown. This was restricted to a domain of one jump. Since most players would naturally recognise one jump moves I decided that there was no real advantage of showing them the potential moves. To handle multiple jumps I decided to break the moves up into single jumps in which subsequent jumps are still highlighted and forced the player into not being allowed to revert their previous jump. I also allowed the player to choose to not undertake a subsequent jump if they choose not to.
Double meaning
By the time you read this I should have finished the base functionality. I was intending on posting my current progress online but I am requesting permission to use some music and haven’t received that yet so I will hold off until I finish it. Will be done soon.
