David Kendall

It's been a few days since Dream.Build.Play closed its doors but not before I had submitted by entry, Do You Know?. While the game might not be finished and ready for launch, Dream.Build.Play marked an important milestone, one of which was that after three years of working with XNA I actually submitted something to the competition. Is it a winner? Well, I'm a realist and based on the other entries in my category I'm going to say no. Hell, before the last day I was hoping to be a top 20 finalist, but now I'm fairly confident even this is out of my reach. But where did my entry go wrong or rather where could it have been better?

I Knew What I Wanted...More Time

From the start of the project I outlined everything I wanted from my game. Not the game as it was submitted, but the game as it will hopefully be when I finally release it to market. From this list I tried to outline what features would be able to capture the essence of the game, while still being realistic about what I could include within the competition timeframe. Unfortunately due to certain circumstances, some unforeseen, I started running out of time and features got cut. For instance, at the start of the competition I wanted to include online functionality. The game has been built with this in mind and the single console experience I submitted is built using a local network session. However because I hadn't been able to test the online portion (mainly because my PC build would refuse to create a session), I removed the menu for this feature from the submission. However, possibly this was a blessing as it freed up more time for the polish phase at the end.

Testing - The Wrong Way

Testing was pretty much non-existent, mainly because in addition to programming up my list I was subjected to feature creep. I was testing the game in small parts, pretty much as I coded up each feature on my list, but it wasn't until a couple of weeks before that I tested it as a whole. That was a mistake! As at some point during the process I broke my packet logic which lead me to debugging for a couple of days. This process also led to a few bugs slipping through the net that I had realised were present when I went to bed the night of the competition closing. However I believe these bugs are edge cases and therefore the judges shouldn't end up in situations that will cause them to happen.

I also had planned to do a an AppHub playtest for the game to get some feedback from the gaming community. Unfortunately I never got to a stage where I was confident for an outsider to see the game, which lead me to resort my girlfriend's opinion when she ran through it. Well that was after she had stopped laughing over my voice overs in the game. Once she had, her feedback also led to more feature creep. Some of which was on the day I was submitting my entry. This has definitely brought home how important playtests are. It brought to my attention how important features that I personally had written off because I deemed them as unnecessary, but actually prevented players from being confused. This realisation has led me to aim for a playtest for the end of the month, so stay tuned developers.

Key Features Not Obvious Enough

I had written down a few key features that I wanted my game to include based on limitations I have found with existing trivia titles. I want a wide selection of questions. I want those questions to appear differently in some way every time they appear in the game. I want the presentation of the game to be different every time the users play the game to keep it fresh (there's that word again). While the core concepts of these features were included in the game, the data that drives them were not. This means that to the untrained eye (i.e. the judges), these features do not exist. For instance, a lot of the questions I was going to include in the submission got cut in the worry that I would be subjected to one of Dream.Build.Play's rules; 2.c.vi. In reality I don't think my questions fell into this rule, but at the same time I didn't want my entry to be disqualified over something that could have been avoided. This resulted in my game not having much of question databank, which sucks.

A Different Kind Of Submission

Microsoft guide you through the submission process so that anyone who tries to submit something can. So what possibly could have gone wrong here? Well, apart from the quite frequent server errors during the upload process there was also a section to upload media that showcased your game. Screenshots were easy with XNA Device Center's ability to take screenshots straight from the console. This resulted in me picking images that represented that actual gameplay as best as I could through a static image and without using a single screenshot of my menu system :p However the problem came with the video representation that was submitted. After looking at a lot of the videos associated with a lot of the submissions I'm fairly confident my video was unique...but not in a good way.

At the present time I have no way of capturing gameplay footage of my game through the Xbox, and because my game relies quite heavily on avatars, PC footage was out of the question. This led to my video entry being a slideshow representation. This is so disheartening after the amount of effort I've put into the game so far. It's so disheartening that I have not made my video publically listed because I don't want the first thing gamers to see of my game being a slideshow.

...Not As Bad As I Thought

After pin pointing the problems with my submission a lot of the problems all come down to one thing...time. This is not surprising for a competition and the chosen circumstances I had decided to work against. If I had more time a lot of these problems could have been avoided and my submission would have been that bit more stronger. But this is just one of many milestones for my games development and as long as I learn from my mistakes I will win when it matters most...when my game hits the marketplace.

At time of writing this post, the Dream.Build.Play competition officially has just under 7 hours left until the metaphoric competition doors are closed and every single game is ripped to pieces by the judging panel. Not wanting to leave it to the last minute, but still very late at night considering I had work the next morning, I submitted my project and it has been officially approved!

GO ME!

I have done what I had set out to do...actually submit something to Dream.Build.Play. Am I pleased? Could I have done better? Well, that's for another blog post. But what did I do in the last remaining weeks since my last blog post? I did what I said I would do...polish the crap out of the game (so to speak). Or at least try to. I started off by applying textures to all of my models and by also creating a studio that my gameshow would live in instead of a big black void of nothingness. This took forever. So long in fact, by the end the textures were more just slabs of colour to make everything not white. If you've been following me on twitter, you may have seen the following pics already, but these show the progress I made in the first week of polish.

It's amazing what a good, or perhaps average in my case, texture can do to make the game feel that much more complete. Once I got to the part of texturing the studio, I decided I wanted to have an interactive back-drop. I played around with scrolling questions, fading questions, but none of them worked as they became too distracting to the player, especially when answering questions. This meant I effectively lost a few hours work, but it needed to be done.

So I instead decided to have a wall of text which resembled questions that could be asked throughout the show, but this too was too distracting as this made the backdrop very busy, which took the players attention away from the game at hand. In the end I settled on a reduced version of this and had questions "splattered" on the backdrop.

The next thing that was needed was an introduction sequence to the show. I already had the host making his way down to the stage, but there was nothing to lead him into this position. This looked weird, especially with my loading screen supposedly representing a television channel's "splash screen". But for this I was drawing a complete blank for what I wanted. So in the end I salvaged some of the question fading code I had developed for the stage backdrop and created a logo for the show which fades itself in. The background then pans away and we have the scene of the studio in the background (as seen below). This would probably have been better to show in a video, but since I have no way of capturing my gameplay my brilliant descriptions will have to do.

And you can tell, this lead me to choosing a name for the game show (and the game). Do You Know? is the official title. I had chosen it a while ago, but didn't want to display until I was comfortable with what I was showing before "unveiling" it.

However, the game was still lacking something...music. So I scoured the web in search for free music that I could use in the game. I went immeditately to Kevin MacLeod's website, as half of the XBLIG community mentions it when talking about free music. But there was nothing there I could use, or at least for the game show. I managed to find something that was nice and relaxing which I ended up using for the main menu, but was still without some "theme" music. In the end I ended up spending around £20 on a theme pack that I found at Shockwave-Sound. To be honest, at this point in time I'm finding it a bit annoying, but that's because I've listened to it to death during debugging sessions. Despite this I'm really pleased with the sound, and it makes the game show feel that bit more complete.

Another part of the game that needed actually finishing was my start screen. You may remember I wanted my start screen to resemble a sort of infomercial, but until last week there was nothing informative about it. The end result is something that looks very budgety, but I think is still effective. Only a few playtests with other gamers will tell though. However, because the "host" needed a voice and I'm the only one to provide any voice work, I looked to Audacity for altering my voice. The end result is someone who sounds like Kevin McCallister using that voice recorder in Home Alone 2.

The final stages were finishing off voice work for the game, adding on screen prompts, and general bug fixing; along with a last minute addition that was introduced because my girlfriend was rightly confused by the highlighted correct answer thinking the game thought that was her answer. My bad. All in all, the game is further along than anything else I have produced. So what's next? Well, just because Dream.Build.Play is over doesn't mean that I will stop work on the game. The first port of call is having a week off because I have been a very bad boyfriend as of late. After that, I am going to go through the rest of my to-do list that I wanted to get done before I submitted the game, which still has over half of the original items left. Once they have been implemented I'm planning on putting the game into playtest to see what other people that don't have to say good things have to say. I'm also going to go through my code and clean it up a bit, as it got very sloppy during the end. I'm currently aiming to get this done by the end of the month. I've still got a long way to go, but at least I've passed one major milestone.

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

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.

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

This week saw a version of the introduction sequence being completed. However, as I don't own any video recording equipment and a screenshot wouldn't really show anything, you'll just have to take my word for it. It also saw the completion of two components that will help to make every game different to the last one.

The first of these components is my camera director. Whenever you watch a television based game show they very rarely have the same camera angles frame by frame between shows. This is usally because a different director is probably directing each show. In order to replicate this, I have created a camera direction system which takes a collection of camera angles from an Xml document which can be used throughout the show. Throughout gameplay I can then ask the camera director for a camera angle, for which it will randomly pick one and use it when drawing other objects. However, just obtaining a random camera angle wouldn't be very good as I may want to look at the contestants and instead get an angle showing the audience. To avoid this each camera angle is associated with one or more camera categories (e.g. audience). This results in me requesting a category and being given a random angle within said category. The first place this is used is in the show introduction where it will show the audience at the beginning. Although this addition will proabably go unnoticed to the average player, I'm hoping it will help keep things fresh.

The second component is a similar component to keep things fresh, but is associated with the game's host and the things that come out of his mouth. In the game, the game show's host will introduce the show, explain the rules of each round, compliment/insult the participating contestants depending on their progress and sign off the show. In order to keep things fresh again (I already hate how much I'm using that term) by having different introductions, different insults, etc, a similar component with a similar structure (audio clips associated with a given voice category) has been created. I can then ask said component for a given category of voice overs and I will get a random audio clip every time. This component then links to a more generic component that plays the audio clip and moves the hosts mouth to give the illusion that he is talking. I'm hoping that the combination of these two components, along with future features, will help keep the experience different game after game.

This week also saw me attempting to test the online code in preparation for the week ahead's tasks, but unfortunately I'm unable to test the code due to my PC version (used for testing) <techtalk>causing InvalidOperationExceptions</techtalk> <non-techtalk>breaking</non-techtalk> whenever a new online session is created. At the moment I'm creating online code hoping it will work and will then do a playtest nearer to the deadline. If however I can't fix my PC build or the playtest shows my online code just doesn't work, I will have to leave online play out of my submission which will be very dissapointing.

So what's next? This week I will be implementing the first (of many) rounds for my game show. This means that the actual gameplay is now actually being implemented. Not bad when I have 6 weeks left...

Two weeks have passed since my last entry. As you may have known (if you read said post) I had been on holiday, and therefore work on my dream build play project hadn't happened for a long time. Last week I returned, and therefore a week of progress should have occurred. Unfortunately this wasn't the case as I got back into playing games every day which resulted in me buying a PS3, playing Uncharted and finally completing Mass Effect 3; the ending to which wasn't as bad as the internet had made out, but still wasn't brilliant.

However at the end of the week I did make some progress on the game. I started looking at the environment that the player will be spending the majority of their time in. This led to me to start designing it and I ended up building the core structures.


As you may have realised with both this image and images shown in previous posts, my game will have a game show style. This is because my game is a trivia based game, with a selection of rounds designed and ready to be implemented. The image you see above is audience that will be watching the player(s) play the game show who will hopefully applaud and cheer during the game. The image does showcase however the limitation I have when design things around the Xbox avatars as all have to be designed around a limited animation pack that is provided by the AppHub. For those that don't know why, this is because custom animations can only be created in expensive bits of software (see Maya and 3DS Max).

The player you see at the top of the stairs is the host of the game and will introduce the show and provide quips throughout it. As this guy will probably be voiced by me, there will be a feature to turn him off.


The reason for the host being at the top of the stairs is because he will walk down and onto the stage (pictured above) before he introduces the show. I'm really wanting to capture every moment of a game show you would see on television and this goes down to the little details.

So that's the progress I've made so far. The next stage is to get the host to actually reach the stage and to get avatar voice work implemented. Only seven weeks to go, so I better get a move on.

This week I have been contemplating whether to start implementing online play into the game or if I should wait until further in the development to start implementing it. After reading various posts on my phone on a very long train ride over the weekend, it was recommended that it would be easier to implement online play from the beginning instead of shoe-horning it in further in the development cycle. So over the week I have designed and developed a generic solution for wrapping XNA's network session to help with the sending and reading of online based packets. It was also recommended that the same code base should exist for both on and offline gameplay. However, this possed a problem with what I wanted to implement.

My idea was to have players drop in and out of the online "lobby". This is fine as when players join the network session they are added to an accessable collection. However my idea was to have a number of players on the same console the ability to join a given online session, so online play could consist of a mixture of remote and local players. This is fine when players want to join a session on a given console, as a method for adding local players exists. But what happens if that said player then decides they don't want to play? This wouldn't be a problem if a RemoveLocalPlayer method existed, but it doesn't. Local play is fine as there is only ever going to be local players (maximum of 4 in the session and maximum of 4 on a console), so I can look at other variables to determine which players are actually "active" in the session. But for an online game I can't leave that now gone local player attached to the session because this will stop new players from being able to join, as according to NetworkSession it has the maximum number of players. The reasoning behind this needed method not existing according to shawn was because of only two scenarios existing for a player leaving. He says usually either a single player wants to leave so they sign out (which NetworkSession then removes said player from the session), or all parties on the console want to leave and hense they destroy their session. Becuse of this limitation I have had to come up with a disjointed solution between offline and online play. In the offline scenario players can join and leave as they please with their presence still being attached to the session. This is fine as I have other means to determine active players. In online play, when a player attempts to leave they will be greeted with a message saying that they need to sign out in order to leave. NetworkSession will then deal with this and remove the local player freeing up space for other players to join. Yuck!

Having online and offline play joined by a single code base has also lead me to another design choice. In the beginning I wanted players to be able to join a game without having to sign in. Unfortuantely in order for a player to join a NetworkSession, that said player must be signed into a profile (local or live enabled). So now my game requires the player to sign into any profile for offline play and a live enabled profile (even if it's as a guest) for online play. On the plus side I have still managed to keep the ability for players to choose a random avatar if their own avatar is really that bad :)

So that's what progress has been made this week. No new screenshots unfortunately as it all looks pretty much the same as last week. Also, no further progress will be made this week as I'm away from my computer for the Easter holidays. Hope you all have a good Easter.

Another 7 days have depleted from the Dream Build Play counter and I've been working on my entry over the weekend. Did I accomplish what I said I was hoping to in my last post? Not quite. But I did accompish something.


To the untrained eye, this screenshot would appear that I have done nothing. But this is not the case. I have moved the programme slots up by a bit and made the button prompts smaller :) I have also made it so the correct button prompts appear based on what programme the user has currently selected. I still need to add the additional information panel, but the menu is coming along.

But what good is a menu if you have no game to play, which brings me onto my next screenshot.


They say a picture says a thousand words, but with this picture I don't think that's the case. This is my loading screen for when loading up the main game. Following my television theme, I have gone for a loading screen that represents a network splash screen. These are the things that appear just before a programme begins. On this screen, the different coloured bars move from side to side while loading, but then slide into position once the game has loaded. I think it's nice and effective in motion, but this screenshot does not do it justice.


The last screenshot is the beginnings of my character selection screen. As you can see I've started designing my assets. This was a right pain as Blender (my modelling program of choice) as changed its interface since I last used it, so a lot of time was spent getting to grips with that. The functionality on this screen is basically in place with the signed in user being able to choice random avatars or their own (as long as they're signed in). The next step will be to produce the rest of the game assets and produce some on screen prompts so the user knows what to do on this screen. I also want to make it so that the user who initialised the game is already signed up.

The result of this weekends progress has lead to me realise that I will need to be doing more work on the game than initially wanted. This will take effect as of next week, as this week I'm hoping to do a bit more work on my platformer and I will not be present at my computer this weekend. However, I hope to have the character selection stage finished by the end of next week, with perhaps starting to code the main game. Only 78 days to go :)

Dream. Build. Play. It comes and goes every year. Since I started XNA a few years ago I've registered for every one. All of them have past, none of them have I submitted anything for. This will all hopefully change this year. This year I have made a promise to myself that I will submit something, and to make things even harder I've given myself the task to create it from the date of registration to the date of submission to complete it. This means that when the submission deadline comes around I will be submitting whatever I have done. No matter what!

Will I end up with a good project? I sure hope so. I have picked a concept that I have been spec'ing for a little while now (both in my head and on paper). The concept is simpler to my other project, which will mean I have more of a chance of finishing it. But it will be every bit as fun and interesting. I'm also making things harder by only giving myself the weekends to work on it (freeing up the weekdays for relaxing or working on my platformer still). Of course, when time inevitably starts to run out this will probably change.

So that's the plan and registration has been open for a couple of weeks. So how far am I in the project? To every bit ensure that I finish this project I have started off by making the part that usually makes me stop working on a project. The menu system.

I have an idea about what features I want to include along with a given theme. My game will have a television styled presentation, and I want this to be present from the moment the game loads


This first screenshot is my version of the traditional "press start" screen. At the moment it's not much, but my vision is to have a info-mercial styled intro, based on the channels you get on set-top boxes that explain to their users how to use a remote. I'm hoping this will be enough of a hint to my users in what is expected of them.


This is the main menu. I've based it on a set top box menu system to give the impression you are picking a show. This screenshot is a bit outdated as there really is only a planner and settings screen. But the idea is there.


This is how my planner started out. A simple screen that showed a handful of "shows". Each show would represent a different mode of play. But I felt that this didn't show enough information to the player. It also had a bit more of a metro twist feel that I felt might not go down so well with the big M.


And this is how, near enough, the main planner will look. As you can see it is more feature rich. I'm planning on adding an info screen, which will display more information about the selected show. The first four shows on the first four channels will now represent the different game modes that can be played and the rest of the shows will contain a mixture of fake mockery shows and possibly other Indie games.

So there's a glimpse into what I've developed so far, but there's still a lot more to do. It's not got quite the polish I'm wanting at the end, but the main functionality is there which is the main thing.

This weekend I hope to design my loading screen and the player select screen. So you could say the menu isn't finished. But to me it's definitely a step in the right direction.