David Kendall

Another two weeks of "work" has passed since I last updated you guys on my Dream.Build.Play progress and another milestone has been reached. The reasoning behind the lack of update last week was because I was fixing the code that handled players joining and leaving the game, which was essential before I went onto creating my first round of the show. The logic I had wasn't quite there and supporting code I had created had a few bumps to sort out. The entire backend of the game runs on network packets, regardless of if you are playing locally or online (which has yet to be tested :p). This is mainly because it was recommended in an MSDN article (altough I can't find the link) to work this way if you have local and network gameplay. All packets are then sent through my generic NetworkManager which allows me to bring object orientation into the developing of my network code as well as setting up custom callbacks for when certain network packets are receieved. The benefit of this is that it makes maintaining the code that little bit more easier and the reading and writing of packets that bit more pleasent. The downside is that each packet that is sent has an additional overhead that describes what packet is being sent, but luckily this is only a bytes worth of data.

I also implemented my QuestionManager, which deals with the generating and distributing of the questions that will be answered throughout the show. All questions are loaded into memory the first time you play a game from an Xml document, which during the process splits the questions into different collections depending on the type of question. When a round is loaded, it will make a request to the QuestionManager which will randomly pick a question from the relevent collection and generate a question from it. I say "generate", because the question manager will pick the correct answer and three random wrong answers associated with the question (our of a possible seven). It will then randomly distribute theses answers to the different face buttons. This is to provide more replayability by having different answers associated with different buttons, even if the player receieves the same question every time you play. I'm hoping that this will lead to players remembering answers instead of button presses.
This weeks task was to get the first version of the actual round complete (hense the actual gameplay being implemented). At the moment the round has the general structure in place, ready to have introduction sequences, round explainations from the host and sign off comments from the host which will all be added in the coming weeks. The round's actual gameplay has also been implemented. With time whittling on, I went for the easiest round that I had come up with. Fastest Finger. The contestants will be presented with five questions (retrieved from the question manager) and they will have 10 seconds to answer each one. The faster they get the correct answer, the more points they will receive. A very simple, yet competitive round which was one of the easiest to implement. If I have time at the end I will possibly implement some more rounds, but with the deadline getting closer, this isn't looking likely.

The following weeks task is to get the final state of the game implemented, where our host will announce the winners of the show and the scores they came out with. I have a few ideas in mind of how this will be implemented (one sticking out more that the others), so I will hopefully have something to talk about next week. Better get cracking...