Thursday 24 May 2012

Dream.Build.Play: Gameplay Complete




Its been a long week...so long in fact I've had almost two weeks worth of development since my last proper blog post. In that time I have been implementing the final part of the game that the players will interact with, and to some gamers this is the most important part. This is the part of the show where our host will tell the contestants the score they've accumulated over the course of the game and who came out on top. This part was time consuming. Not because it was difficult to implement, but because it lead me to recording a bunch of voice work and working on the visual aspect of this stage. The reason this stage is so important is because it's the only time in the entire game that the player will see their score, and with a valid reason behind it. When I have played games with visible scores with other people and they've not been doing so well, one of two things will happen. Either them seeing they are losing will drive them to try their hardest to do better and win or they decide they've already lost and give up. In order to counter act the latter group, I don't want to constantly remind them how well (or poorly) they are doing so they will continue to do their best.
The final part of the show that was implemented was the credits. This was implemented not because I have many people involved in the project nor because I want to be bragging that I did everything, but because it finalises that television presentation I am going for with the entire game. However this is very rough at the moment and will hopefully be polished before the submission.



So has this really taken me all this time? Well no. Once I completed the above stages, I thought I should play the game from start to finish to ensure it all worked together, and it did until it came to ask the questions. Due to a partial update there was an inconsitancy between the generating and processing of my round based network packets. It turns out my NetworkManager doesn't deal with my stupidity.

So what's planned for the next 19 (as of writing) days? Polish, polish and more polish. I have created a big list all in priorty order of what I would like to implement/polish before I submit and I will be burning through it as fast as I can. The tasks range from texturing my models to adding on-screen prompts. If only I had more time...

Tuesday 15 May 2012

Calling All Dream.Build.Play Contenders




To all Dream.Build.Play 2012 contenders, I have an exciting opportunity for your submission to be featured in my game! If you have been following this blog, you may remember my first couple of posts where I showed of screenshots of my UI. If you can't remember, allow me to refresh your memory...

Now, with this screenshot may I present you with the opportunity that will really show how close the XNA community can be. With time getting ever closer to the deadline, I will be starting the polishing phase of my submission very soon. One item on my list is to fill in the "timeslots" that will be randomly distributed among the mock television guide. However, I was thinking wouldn't it be great if the other time slots featured other DBP submissions.

So I present you, my fellow developers, with the chance to submit the title and a description of your submission, and you could feature in my game (as seen above). I will also be implementing an info screen on this page which will give further information for whatever has been selected. The only "requirement" I have is that your description tries not to mention gameplay features, but instead reads more like a synopsis for a television show. And also, if your game happens to be randomly selected to be after my game, it will feature in the mini planner that appears on the loading screen.

So think about it, and if you wish to take part or want more information visit my app hub post.

Sunday 13 May 2012

Dream.Build.Play: Actual Gameplay Now Included




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...