I love going to the cinema. There's something about watching the latest blockbuster (or sometimes in my case the latest flop) on a big screen in seats you would never dream of buying for your home with a cup of fizzy that is incredibly overpriced. OK, so maybe that last part I'm not so fond of. But still, the cinema is great. It's even better in the UK if you own a mobile on the Orange network as you can get 2 for 1 tickets for use on wednesdays. Unfortunately, my primary phone is no longer on the Orange network, but to overcome this problem I have kept my old Orange PAYG sim and an old phone and can continue to reap the benefits of this offer.
The problem with this is that I either need to keep this Orange phone on my person at all times (just in case I want to go to the cinema), or I need a phone that will allow me to swap sims over for when I want a ticket. This is clumsy and not ideal. If only there was a way for me to send a text message to my Orange phone, which would then make the request for me and forward the Orange wednesday ticket onto my non-orange phone. Wait a minute...I'm a programmer. Of course there's a way.
My first task was to find out if there was a already a way available to do the hard part of the process for me...sending/receiving text messages from\to a connected phone through a computer. Luckily, there's a bunch of these solutions. The two I tried were gnokii and it's child project gammu. Both solutions involve communicating with a connected phone through AT commands which seem to be implemented in some form or another with most modern day mobile phones. This means that connecting to non-smartphones are possible,even if the solution isn't advertised anywhere. Both gnokii and gammu also offer what's known as an sms-daemon, which is a service that polls a connected phone for inbound text messages and a given directory for outbound messages. These messages are saved in text format, which means that the messages can be easily parsed and processed. This service is the thing that would be the backbone of my project for the sending/receiving of messages; and due to better documentation, platform agnostic-ness and better support, gammu was the sms-daemon solution that I ended up using. After much faffing around I managed to get text messages being sent and received through a friends Sony Ericsson w580i phone.
So I had a facility for receiving and sending text messages, now I needed to process those messages and do something with them. In comes the programming part of the project. The concept was simple. To build an application that polled the inbound directory for inbound messages and process them based on message content and/or the number the message was sent from. The processing of the message content could then lead to subsequent messages being sent. It also needed to be built to allow easy extendability in case either a) I chose a different method/sms-daemon for retrieving/sending the text messages or b) I wanted to produce future services that were driven from sms content. This lead to the following process:
As you can see I have a concept of message processors and handlers. The processor is what translates the universal message to/from the message retrieval format (in this case gammu). The handlers (in this case just the Orange Wednesday Handler) is what processes the messages and decides what to do with it. The Orange Wednesday Handler when receiving a text message goes through the following process:
This logic was important as I didn't want to send text messages to Orange unnecessarily as each text costs money. As you can see to prevent this, a few checks are made before the text message is sent. I have also built into the handler the ability to re-ask for the code just in case it's accidentally deleted.
So I had the concept of the program boiled down, but what was I going to program the application in. The first language that sprung to mind was C#. I have been using the language for over three years both leisurely and for work. But this was quickly ruled out as one of the things I wanted the application to run on was one of these.
For those that don't know, this is a Raspberry Pi. A $35 ARM based, Linux run computer that is both low powered in energy and specs. But this was perfect for my little project as I wanted the application running all of the time without a power hungry PC having to be on. So as C# was out I falled upon the other language I had a bit of experience in. C++. This proved to be a bit of a challenge as the last time I used the language was in University and turns out I've been a bit spoiled by the niceties of C#.
I finished building the application about a week ago on a Windows environment, and the last week has been trying to get the application running on another friend's Raspberry Pi. It was hard. But this was due to a mixture of my Windows compilier (MinGW) compiling things a little differently to linux's default compiler (G++) and my lack of knowledge when using Linux itself. But it works as I intended. However this is not the end as some missing features need to be added that will make using the service more useable. A task it seems for the weeks ahead.
Wow...two weeks have passed and this blog has been awfully quiet. Well, that's because the combination of work and Dream.Build.Play took quite a lot out of me, so I decided to take a bit of time off. Played a few games here and there and tried to forget about Do You Know. But I find it very hard to unwind and forget about projects, so it wasn't too long before I was back working on it.
I started off by compiling a list of what I wanted to get done before I put the game into it's first playtest. This list consisted of mainly items I wanted to get done before I submitted to DBP and a few extras I thought would be nice. At the time of writing I've managed to get most of the list done, but in my opinion the game is still too rough to put into playtest. So my plan of putting it in at the end of the month (i.e. today) is not going to happen. But I will divulge some of the new features that have made it into the game.
The first as you can see is that the podiums now show the answer the players have decided on. This is how I'm going to convey the selected answers to the players. This is a feature that I wanted to include in my DBP submission, but as time slipped by this seemed like a very risky thing to implement. In the end though, through some in my opinion trickery, this didn't take too long to implement. To avoid cheating I've also included a spinning question mark which is displayed when a player answers, but is waiting for either time to run out or all other players to answer. This new feature is also complimented by the host speaking when getting to the point where the answers are shown. I however am not sure if this is done too much. I guess that first playtest will answer that ;)
I've also managed to implement the clapping animation into my audience members, which means no longer do I have an applause sound effect playing with no source of where it is coming from. Yes, I did submit this "feature" into my DBP submission. I've set it up so I can make them applaud on the fly, which I will hopefully be incorporating into gameplay in the future. For instance, when a player answers correctly, the camera cutting away to the audience clapping.
The past couple of weeks has also led me to finally installing some form of version control and automated back up on my computer. For version control I went with the Mercurial/HGTortoise combo and set up repos on an external hard drive. The main reason for this was because I use it on a daily basis at work so I am instantly familiar with it. But it couldn't have gone any better as the installation was simple and I was version controlled within minutes. I don't know why I hadn't done this sooner. Perhaps my initial commit message wouldn't have been so big if I had :p
For automated back up I was recommended CrashPlan by a work colleague. This tool allows you to schedule how often to backup and where to do it, with options including folders elsewhere on the oomputer (what's the point), other peoples computers or to their online servers (for a small fee). It also provides backup summaries by email if you so wish and will also send alerts if you data hasn't been backed up for whatever reason. This is all well and good, but the one place it doesn't support backup to is a networked drive, which means I can't stick my backup drive on my network. Boo!
So that's what has been happening. I hope to get some more done in the coming weeks that will give the game more polish and get that first playtest into action. I'm now off to do some "research"...
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 otherentriesinmycategory 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 firstcouple 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...
