{"id":767,"date":"2009-02-20T22:28:19","date_gmt":"2009-02-20T12:58:19","guid":{"rendered":"http:\/\/nexfinity.net\/?p=68"},"modified":"2014-06-23T17:08:45","modified_gmt":"2014-06-23T17:08:45","slug":"draughts-progress","status":"publish","type":"post","link":"https:\/\/cjohnson.id.au\/game-dev\/draughts-progress\/","title":{"rendered":"Draughts Progress"},"content":{"rendered":"
So far I’ve been working on the Draughts project<\/a> 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.<\/p>\n 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.<\/p>\n Drop and Drag<\/strong><\/p>\n 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<\/a> and Bookworm Adventures<\/a>. 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.<\/p>\n