VS 2015 Intallation Tip

I spent a big chunk of today trying to get Visual Studio 2015 Community Edition onto my machine. It put up a bit of a fight, I kept getting an error saying I needed up upgrade my installation when I'd built a project. I've no idea what the problem was.

But I do know how to fix it.

I installed Visual Studio from the ISO image that I downloaded from here. For previous, failed, installations I'd used the web installer. I'm wondering if there were some network shenanigans causing problems during the install.

The wonderful news is that I took my entire Snaps framework (a bunch of programming aids you are going to hear a *lot" about soon) and ported it from Windows 8.1 universal app to Windows 10 in about six minutes. All I had to do was copy the source files into an empty Windows 10 project and it built first time. This is completely awesome.

Game Mechanics and Raspberry Pi's running Windows 10

I had a go at writing a game for Three Thing Game last week. Just to be different I thought I'd do a hardware game using Windows 10 on the Raspberry Pi. We had some fun and games getting the Raspberry Pi to work in the labs, mainly because the lab network didn't give them a network address when the Pi asked. That and the fact that for some reason Logitech USB mice just don't work on a Raspberry Pi running Windows 10. No idea why. They just don't.

Anyhoo, we got everything working and I started building the game. I connected two leds and two switches to the Pi and got them working. Then I built the game mechanic. This is the way that the game is supposed to work. My first idea was that the player would have to press the button when the light came on, but I decided that this was a bad idea because after a while the switch will get destroyed by people bashing it in a hurry.

So I switched it around. When the light goes off you need to release the button as fast as you can. I called the game "Lift Off" because that's what you are supposed to do, and I made it competitive. The idea was that two players would compete in a number of rounds over a 30 second period. They'd press the button, the light would come on for a random time and then go off. The game would then time how long it took the player to release their button and then add that time to the player's score. At the end of the time period the player with the lowest score wins.

I got the code working and it was OK. But then I came across serious flaw in the gameplay.

You could win by not pressing the button at all.

If you never press the button, the light never comes on or goes off, and you end up with an unbeatable score of zero points. So I'd invented a game where doing nothing was the absolute best winning strategy. Oh well.

I've now added a timer so that if you don't press the button you get a big penalty, and I'm tuning the gameplay at the moment. I'll blog how the code works a bit later, once I've got the gameplay mechanic properly sorted - something I should have thought about earlier. Another lesson learned.

The experience of writing a C# XAML application for Raspberry Pi was a bit strange, but in a wonderful way. Everything was exactly where I expected it to be, but I was targeting a tiny device. I had access to all usual development tools. I could step through code and view variables in Visual Studio, use all the libraries that I know and love, but I was targeting a device that costs around 25 quid. If you're running Windows 10 and you've got the Visual Studio 2015 preview running you should have a go at this. It is going to make it much, much, easier to create rich applications for cheap embedded controllers. Very nice.

Time Travel in C#

Imagine if you could control time. Wouldn't that be useful? Especially if you were writing a program to manage artwork in an art gallery, and you wanted to test the part where after two weeks the artwork must be returned to the artist. You could start the program running, add an artwork, hop into the time machine and move two weeks forward and then check that the code works correctly. Of course this is impossible. But fortunately we don't have to do it this way. Instead we can build a bit of cleverness into the way that our program uses dates and times.

Normally a C# program will get a date from the system clock by using DateTime.Now:

artwork.DisplayDate = DateTime.Now;

This sets the display date of my Artwork to the current date and time. My program can then compare the artwork date with future dates to see if more than two weeks have gone by. The snag is that i have to wait two weeks to find out if the code works. So I make something like this:

static class DateSource
{
    public static TimeSpan Offest = new TimeSpan(0);

    public static DateTime Now 
    {
        get
        {
            return DateTime.Now + Offest;
        }
    }
}

This can be used in exactly the same way as the system DateTime class, in that it provides a property called Now which gives a date and time value. But, and this is the useful bit, the date it sends back has an offset applied to it, which I can change. If my program uses DateSource rather than DateTime I can move my program forward (or even backwards) in time simply by changing the offset value:

Console.WriteLine(DateSource.Now.ToString());
DateSource.Offest = new TimeSpan(days:14, hours:0, minutes:0, seconds:0);
Console.WriteLine(DateSource.Now.ToString());

The first statement will print out the current date and time. The second will wind the clock forward 14 days as far as my program is concerned. When we are testing I can add a "wind forwards" button that changes the offset so that I can test my code. I could even change the offset value in a test harness that does this automatically.

This is all part of my "build yourself a nice place to work" philosophy. If your program has to do special things depending on location, don't test it by walking around the countryside. Instead make a program that feeds test coordinates into the location part of the code.

What Price Protection in Programs?

I got a lovely question from one of our students today. He is presently working on our "Pick Up the Crew" game coursework and is using objects to manage the items on the screen. The question concerned protection of the data members inside the game objects. If you are writing software for a bank you need to be careful to make sure to carefully manage access to data inside your objects, since you don't want naughty programmers fiddling with account balances. But in a game you don't care so much about this kind of protection. There is nothing particularly important about where on the screen a sprite is drawn.

The questioner was asking if it is OK for a sprite to expose its position information in public data so that other sprites could find out where it is on the screen and check for collisions with it. This is a good idea from a performance point of view (if we are really worried about such things) because it provides quick access to the position information. But is it a good idea from a programming point of view? Should we worry about protecting data inside things like game sprites?

To me this is the wrong question. I don't like using public properties like this because it can introduce dangerous dependencies. If I decide to change the way that I manage sprite position I'm going to break all the other objects that make use of this information directly to work out whether or not they have collided.

From a collision point of view I reckon it is best if each sprite exposed a method (perhaps called CheckCollision) which could be used to see if it has collided with something else. Then if you change how the sprite stores its position on the screen you can just update the behaviour of CheckCollision so that nobody outside your class is affected by the change. There may be a tiny performance hit with this approach, but the chances of introducing bugs are much reduced.

Making a Three Thing Game Auction Timer Unversal App

We are having the Three Thing Game thing auction next Monday. This is always a giggle. Teams bid "Bank of Thingland" money for things that they want to add to their games. This year all the things are student suggestions. What could possibly go wrong?

Anyhoo, one problem with the auction is that we need to get through over 120 lots in around half an hour, so the auction rate has to be frenetic. Last year I thought I'd solved the problem by fixing the auction length at 15 seconds and creating a countdown timer. Unfortunately, human nature being what it is, the result of this was that everyone sat waiting until the timer counted down and then tried to snipe with bids at the last minute.

So this time I'm trying something new. A random countdown timer that runs for between five and 15 seconds. Teams won't know when the auction is going to end, so they'd better get their bids in as soon as they can.

Of course this means I'll need a timer. I wrote one this evening and it took around half an hour. And for that I've got Windows Phone and Windows desktop versions.

These are the variables in the program. I use a DispatcherTimer to generate interrupts. I keep a flag to say whether or not the timer is ticking and I have a counter and a limit value which are used to manage the time outs.

This code sets up the timer. It ticks every second. The timer_Tick method is called each time the timer ticks. I also make a copy of the Foreground colour of the text so that I can put the timer digits back to the original colour when the timer is restarted.

This code sets the timer ticking. If the timer is already ticking the method returns straight away. Otherwise the timer is set up, the screen colour put back to normal, a random timeout between 5 and 15 seconds selected and the timer starts.

This is the third method. It runs each time the timer goes tick. If the timer is active we increment the counter and then display it. Next we check to see if we have hit our limit. If we have a sound effect is played and the counter text block is turned red. Then we stop the timer.

All this code is shared between the Windows Phone and Windows Desktop versions and it works a treat. Great stuff.

Free C# Course and a Shiny New Kindle C# Yellow Book

I've spent the last couple of weeks swearing at HTML files. Who would have thought that converting a Word document into nicely formatted markup could be so difficult. Anyhoo, I've finally managed to get the text into some sensible shape and it now has a proper Kindle table of contents.  If you have already bought my C# Yellow Book on Kindle,  then you might like to update your copy.  If you haven't you can get one here.  And why not?

Of course the original version is available at the usual place. And I've also added the entire content of our First Year programming course from last year. This includes over 100 slide decks, practical sessions and the assessed coursework. The content is free for anyone who wants to teach C# or learn it. Enjoy.

Failing Properly

There's nothing like writing a program to get you thinking about how to do things properly. My Magic Marker program is one such example. Turns it it is possible to use it incorrectly. If a file is open when you try to save it (because you've got the spreadsheet open in Excel for example) the save is doomed to fail. Above is the message that you see if you try to save in this situation.

private bool saveEverything()
{
    try
    {
       // write the file
        }
    }

    catch (Exception e)
    {
        System.Windows.MessageBox.Show("File error: " + e.Message,
            "Magic Marker");
        return false;
    }

    return true;
}

This the code that makes it happen. It catches files exception and displays it. It then returns false to indicate that the save has failed.

I've also written the program so that it automatically saves the data when you exit it, which seems sensible. It's what most people will expect to happen these days. But if the save fails when you exit you get this message:

This is the best (i.e. least worst) way I can come up with for dealing with this problem. At least it gives the user the chance to go back and fix the problem (for example they might not have entered a valid mark value which is stopping the save from working).

private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
    if (!saveEverything())
    {
        if (System.Windows.MessageBox.Show(
        "The file save has failed. Do you really want to exit?", "Magic Marker",
         MessageBoxButton.YesNo) != MessageBoxResult.Yes)
            e.Cancel = true;
    }
}

Here's the code that makes it happen. This is the event handler for the WindowClosing event for the application page. It tries to save everything and then, if the save fails, gives the user the option to cancel the exit. I've tried to make the answer options (yes or no) directly match the question. 

The only thing I'm not completely happy with is that it is possible for a programmer to use my saveEverything method and ignore the situation where the method doesn't work properly (you don't have to use the result of a method call).

Ideally saveEverything should rethrow the exception or not catch it and rely on the caller to deal with the problem. However, in this case I'm happy to keep things comparatively simple. 

Spell Checking in XAML applications

When I was writing my Magic Marker application I wanted to make my notes input box spell checked. Turns out that this is really, really easy. This is the XAML for the notes texbox. 

<TextBox Name="NotesTextBox" Width="500" Height="315" AcceptsReturn="True" ScrollViewer.CanContentScroll="True" TextWrapping="Wrap" SpellCheck.IsEnabled="True"></TextBox>

I just had to add the one extra property (that I've highlighted above) and it works a treat. 

json2csharp is magic

Json (JavaScriptObjectNotation) is a really popular way to pass information around on the internets. Lots of services will serve up lumps of json for your programs to munch on. It works very well with JavaScript (which is not surprising) but in the strongly typed world of C# (a great place to be in my opinion) it is a bit of a pain, because C# likes to have proper classes to back up the contents of the Json strings. 

That's where the wonderful json2scharp web page comes in. Grab the chunk of json that you get back from the service (in this case I pulled it straight out of the string in my app while debugging with Visual Studio) and paste it into the window at json2csharp.com and it will spit out all the class definitions that you need.

You can then paste these into your source code and hey-presto, you have all the types that you need to read and work with the json formatted data you just received.

Wonderful stuff.

Writing a Program is not a Fight

Our First Year students are busy at the moment working on their Assessed Coursework. They are implementing computerised versions of Tactical Space Cheese Racer, a board game that we've invented just for this year. 

One student came to see me today and told me that he was having problems getting the code to work. Each line of his breathless report was prefaced with "And then it does this...." as if the code was some kind of malign being that he was fighting against. 

After listening for a while I had to remind him that he is not in a battle here. The program is something that that he created, and therefore he really should focus on the steps that it follows and why it does what it does. Just poking the beast by moving code around and adding and deleting statements will not actually tame it. What you have to do is focus on the sequence of operations it goes through when it does these bad things. 

We started going through the code and finding stuff here and there that could be fixed, and by the end he was referring to the thing as "my program", which I think is progress. 

When to Explode

I think I've blogged on this one before, but think it is worth mentioning, since we touched on it during the First Year programming lecture today. 

Consider the ReadNumber method above. It is designed to make our lives easier, so that if I want to get the number of players for my game I can just call the method:

int noOfPlayers = ReadNumber ("How many players? : ", 2,4);

The idea is that the method prints the prompt and gets a number from the user in the range 2-4. If the user gives a value outside the range the method politely asks for another value.

This is a neat method. But what happens if I make a mistake when I call it:

int noOfPlayers = ReadNumber ("How many players? : ", 4,2);

This means that the minimum is now higher than the maximum. Which is wrong. During the lecture I mentioned this possibility and suggested this rather firm approach inside the method when it runs:

if (min >= max)
                throw new Exception("Invalid min and max range");

The code above makes the method fail if the minimum and maximum are incorrect. And by fail I mean stop the program from working. I suggested that in this situation the method can't do anything but fail, since it is operating under a failed premise. 

After the lecture one of the First Year (splendid bunch by the way) came up to me and suggested that one solution would be for the method to just swap the minimum and maximum values round if the method discovers that they are the wrong way round. The test is easy to make and swapping the values takes no time at all. And the method is then going to continue. So why not?

Because this is the kind of idea I call "Half way good and all the way bad". We are making a very, very, dangerous assumption, which is that the mistake was that the person using the method has got the min and max the wrong way round. Consider this code:

int coreTemp= ReadNumber ("Reactor core temperature? : ", 20,40);

This code is asking the user for the reactor core temperature (whatever that is). But what happens if when the method is written the programmer misses out a zero when typing it in:

int coreTemp= ReadNumber ("Reactor core temperature? : ", 20,4);

Now the minimum is much higher than the maximum. If my program swaps these values over it will be asking for a value between 4 and 20, which is much too low and might cause really bad things to happen. The clever swapping trick has now changed a typing error to produce a fault that is potentially very dangerous.

If the method stops the program when it is not used correctly the programmer is guaranteed to spot it. But if we do the swapping thing we could end up with strangely broken programs out there. So I'm very keen to cause the maximum damage when my methods are told wrong things. 

Actually, the best way to solve this problem is to use a lovely feature of C# which lets you name each argument to a method call:

NoOfPlayers = ReadNumber(prompt:"Age : ", min:10, max:100);

In this call of ReadNumber we actually identify each parameter by name, rather than using their position in the list to indicate what they mean. I'm a big fan of naming arguments like this, since it also makes it much clearer to someone reading the code what is actually going on.

Make Your Documents Work for You

I've spent a chunk of today performing Seed exit vivas. This is where students on our industrial placement module have to come along and explain why they should get 5 out of 5 for Project Management. Or whatnot. We discuss things for 45 minutes or so and finally agree on figures for each marking category. Sometimes the figure goes down, but in a surprising number of cases we end up delivering the happy news that we think that they have undervalued their work. Which is nice.

One thing I like to do is point at pages that have been supplied as part of the thick folder of documents and ask "What's that for?". This can be quite illuminating. For example:

"What's that for?"
"It's the Risk Analysis."
"OK, where did it come from?"
"Well, at the start of the project we wrote down all the risks we could think of, and that's the result."
"Did you ever look at it again?"
"No. Should we?"

.. at which point the conversation goes downhill a little bit. Risks should be identified and then tracked over the project. At regular intervals the document should have been produced and checked over to make sure that nothing has changed, and that none of the risks were becoming critical. 

If you are going to take the trouble to make a document that is part of your development then you are making an investment in your time. It is important that the investment pays off. Documents should "earn their keep".

The Risk Analysis document should be checked and updated at regular intervals to make sure that risks are managed. Minutes of meetings should record who was there, what was said, give people actions and check on actions from earlier meetings. Specifications should be signed off. Tests documents should be acted on and then the results of the tests recorded and used to drive future development. I could go on (and in fact I did - quite a bit). 

I got the feeling that some of the documents were shoved in "because we thought we had to write them". I also got the feeling that some folk thought that writing all this was a distraction from the proper job, which was creating the solution for the customer. However, this is very, very, important stuff. It can make the difference between success and failure in a project. And doing it right will definitely get you higher grades....

Publish and be Great

Most developers have them. Things that they have made, probably pretty much finished, but then other stuff came up and they never got around to shipping them.  And all it would take is a bit of effort just to get the thing out of the door and into the store. 

Publish is for these projects.  It's a worldwide event for Windows Store developers to get together and head for the finish line. It runs over the 16-17th of May and I'm nipping over to the event in Manchester to join fellow MVPs and developers in getting stuff finished. 

From my experience with Three Thing Game, Global GameJam and Hacked I know that it is amazing just how much you can get done in a short time if you just focus on a single task. Of course it also helps if you are surrounded by folks all doing the same thing, and that you get pizza and fizzy drinks (the fuel of champion developers the world over).

If you want to join us in Manchester you can sign up here. There are events planned all over the world, you can find a local event and take part here. You can even set up your own local event if you want, or just take part from the comfort and security of your own desk. 

I'm really looking forward to it. Perhaps that Windows 8 version of Cheese Lander might actually see the light of day.........

Of Garbage Man and Banjos

This year the first year students can create a game as part of their programming coursework. The game is "Alien Banjo Attack" and above you can see a screenshot of my demo version. At the top are various different types of evil banjo and your mission is to defend the earth using nothing more than your accordion which will shoot notes of music to destroy the incoming swarm.  If the banjos reach the bottom of the screen you lose the game. If you crash into a banjo you lose a life. Space Invaders with a banjo feel. What's not to love?

I want there to be loads of objects (notes, banjos etc) on the screen at the same time, which means a lot of instances of the various classes that represent the game objects. There has been some discussion about the best way to handle this, as banjos are destroyed and new ones appear.

I reckon the best way to do this is to make a banjo stateful. The banjo will contain a flag to represent whether or not it is involved in the game. If a banjo is destroyed this flag set to indicate that it is dead and the banjo plays no further part in the gameplay. When we need a new banjo we just have to find one which is marked as dead and "resurrect" it by moving the banjo to a new position and then changing the flag to bring it back to life. 

You might think that creating new instances of banjos to replace discarded ones would be another way to achieve this behaviour but I don't like that at all. If we start creating and destroying objects this will make work for the Garbage Collector who will have to come in and tidy up memory every now and then which might slow things down a bit. 

Another way to reuse objects would be to keep a list of "dead" banjos. Each time a banjo is killed we move it out of the "active" list into the list of dead ones. That way, if we need a new banjo we just have to look in the list. This is a bit more complicated than just searching for a banjo that can be resurrected, but it does have the advantage that the game never wastes time working through "dead" display objects, as these are no longer in the active list.  Many operating systems use this technique in what is called a "thread pool" where previously used threads are kept ready for use by processes that might need them.

Phil and Stuart talk iPlayer Transcoding

Phil Cluff and Stuart Hicks getting ready for the off

We love it when ex-students come back to the department to tell us what they've been up to. Phil Cluff graduated a few years ago and Stuart Hicks a couple of years after that. Since graduation they've both been working for the BBC on the iPlayer team.

If your'e not from the UK you might not appreciate just how wonderful BBC iPlayer is. It lets you consume BBC TV output on any device, in any place. All the output of the BBC channels, plus the content from BBC local TV, is made available shortly after broadcast so you really don't have to worry about missing things. The programmes are available for a number of days after transmission and they are also made available for download. It's awesome. Phil and Stuart  told us that 3% of the consumption of BBC output is now via iPlayer and it is growing rapidly. There have been around 28 Million downloads of the iPlayer apps across the various platforms,  they get around 10 million requests a day and release around 700 hours of new content a week.  Amazing stuff. 

Of course, getting all that content onto the internet is a tricky job. The original content has got to be converted into the different video formats and sizes that are consumed by the users, and this must happen as soon after broadcast as possible. Nobody wants to have to wait until tomorrow to see today's news. There are huge peaks and troughs in demand and this makes it tricky to manage the computing resource that you need for the task.

A little while back the BBC decided to move their transcoding (as this is called) activities into the cloud. Phil and Stuart described the cloud as "A collection of services that someone else runs for you, which lets you not care about hardware". Which is just what the BBC needed. So they put together a project to build a cloud based "Video Factory" from scratch in 18 months. And they did it. 

Large computing projects are notable for failing or being expensively late. The Video Factory was neither of these things. Phil put this down to the way the design was based on a number of small components, each of which performs one step in the process of getting the video into your iPhone or whatever. The workflow of the video data through the system is managed as a series of messages that are passed from one component to each other. Components take messages out of their input queue, perform their part of the process on the message and pass it on to the next component.  If things get busy and queues start to fill up the system can "spin up" extra processing resource in the form of further servers in the cloud which can run components to work on the extra elements. 

And because each component has very well defined inputs and outputs this makes testing much easier. Phil and Stuart talked about Behaviour Driven Development, which is where you express what you want to achieve in terms of business outcomes. They used a language called Cucumber which lets you express your requirements in a really easy to understand way, and will also produce a whole framework of tests you can use to prove the solution. This is very, very interesting stuff.

It was great to see Phil and Stuart again. It looks like they are doing very well. It was also really nice to hear them echo a lot of the things that we tell our students during the course.  They had some very useful things to say about the craft of development. You can find the slide deck of their presentation here. I strongly advise you to take a look at the last few slides, there are some lovely references there that you can use to find out more.

Making a quick Batch File

It's not often that I get to show off my Command Prompt smarts. But now and again they are useful. The Command Prompt is the place in Microsoft operating systems where you type, er, commands. In the days of MS-DOS it was the only way that you told the computer what to do and it has survived, mostly unscathed, all the way into Windows 8.1 

Of course, in these days of touch and windows you don't often have to give commands at the console, but every now and then you do, and today I got to show off a trick that I've used for years. We were typing in long commands to start up services in the Microsoft Robotics Framework and I suggested that we make a batch file rather than type everything in each time. You can use the "up arrow trick" (press up arrow to get the previous command) but that doesn't work if you close the command prompt and re-open it, as this clears the command buffer. 

A batch file is simply a sequence of console commands that are stored in a text file and can be executed just by giving the name of the file. It has the language extension ".bat". You can run them from within Windows too just by clicking on them. 

What you can see above is a way that you can take a long and complicated command that you have typed in and convert it into a batch file.  You use a few tricks. First trick:

copy con doit.bat

This connects the console (your keyboard and screen) to a file called doit.bat. Essentially, everything I type from now on will go into this file. 

Second trick:

(press up arrow to get your command)

Remember that I said you can press up arrow to get back things you have previously typed. This works when you are copying into a batch file too. So to my recover my echo command in the above screenshot I just pressed up a few times. Once I had the command on the screen I just had to press Enter to put the text into the batch file. Note that if you want to enter a sequence of commands that you have typed into your batch file you just have to recover each one in turn. 

Final trick:

^Z

This is CTRL+Z. It tells the command prompt you've finished entering stuff into the file and want to return to typing commands. The destination (in this case the file doit.bat) is closed and then you can just run the batch file by giving the name. 

The console is a powerful thing in the command prompt. You can copy things to it (which can gives a behaviour similar to typing a file) and you can copy things from it. You can also do stupid things:

copy con con

This works, I'll leave you to figure out what it does. And how to get out of it. 

Heading for London

Ian Livingstone playing the game that got us to London. He reckons we should set it in space, and I think he might just be onto something….

To start with, a bit of history. What seems like ages ago David, Simon, Lewis, David and me took part in Global Game Jam Hull. And we built a game. Then Microsoft offered a prize for the best Windows 8 game that came out of the Game Jam and made it into Windows Marketplace. So David and Simon took the game engine, made it marketplace ready and shipped it. And Heartotron won. At the time we weren’t sure just what we had won, but part of the prize turned out to be a trip to London to tour a game development studio and meet up with some of folks who made the game industry what it is. And so we found ourselves on a train at 8:00 am in the morning, speeding through the sunshine and looking forward to an interesting day.

Which we got in spades. It was great. First up was a look around Lift London, a shiny new Microsoft game studio with a focus on making games the Indy way. No big (or at least huge) teams, flexibility, appropriate technology and total commitment to the product are the order of the day. Lift London also sees incubating fledgling games developers such as Dlala as part of their remit, which is very interesting.

With people on the team who can say things like “..and then we went on to write Banjo-Kazooie…” or “..and then we did Singstar..” alongside folks who have grown up writing and pitching games any way they can I reckon we can look forward to some fun stuff in the future.

We got to look at some work in progress, which was fascinating for me. The transition from ideas to drawings to models on the screen was intriguing.. I get very jealous of people who can draw, and loved seeing these people in action, and how they can turn out lovely looking artwork with just a flourish of their Wacom pens. Most impressive.

Then it was time to move on to Modern Jago, a pop up venue in Shoreditch, for workshop with the gaming legends Ian Livingstone (Vice chairman of Ukie, Games Workshop founder, president at Eidos), Andy Payne (chairman of UKIE and CEO of Mastertronic) and Philip Oliver (TIGA board member and CEO of Blitz Games Studios).

Each had plenty of time to speak and plenty to say. Some things that I took away, in bullet form:

• There has never been a better time to be writing games. Cheap tools and an easy path to market give you amazing potential.
• There has never been a more competitive time to be writing games. The statement above is true for everybody.
• Put your monetisation in at the start. If you are going to sell your game, be up front about that (although recognise that very few people will part with cash to buy it). If you have a pay to play model, put that in the central game mechanic. It is impossible to add it later.
• Use metrics and feedback. Track downloads, watch for reviews and scores, use telemetry to be able to tell how far people get through the game, how long they play for, and when they give up. Phase your releases so that you get feedback from one part of the world (for some reason Canada and New Zealand are popular for this) before you go global.
• Look for the “soft” market. A big splash in a small pond with a future has more potential than trying to make an impression in a huge marketplace with scant resources.
• Get a following. Napoleon reckoned that with 1,000 followers you have an army of your own. He wasn’t on Twitter, but you can be. Give opinions and help to people out there and build a following of folks who like you. A crowd who like what you do and want to see what you do next are great to have around. Be loyal to them and they will replay you by supporting what you do.
• Get a job. You might plan to be a lone gunfighter releasing your fantastic stuff for the world to marvel at, but it much easier to do this with a roof over your head and a full stomach. One of the things you need to succeed is luck (everyone said this). Napoleon (him again) reckoned that he always preferred his lucky generals to his clever ones. If the luck isn’t there, and it may not be, you still need to eat. Make time for your development and go at it full tilt, but there’s nothing wrong with having a backup plan.
• Get some “skin in the game”. This kind of goes against the above but I still feel it is something to think about. If you feel that the stars are aligning and that this is “the one” then feel free to go for it every way you can. Living in a van for six months while you raise funds and build your product base might be the thing you have to do to achieve success. Worst case maybe your boss (see above) will have you back – particularly if you part on good terms.
• The three most important aspects of a game are playability, playability and playability. But graphics and high production values are a way to distinguish your product and get people in to discover just how good your game is. But this, of course, costs money and time. As does buying a place in the charts that gets you noticed, something else which might be a necessity.
• Put yourself out there. I was particularly pleased to hear this one, as it chimes with what I’ve thought for years. You need to be able to do the “front of house” stuff. This is really bad news for software developers, who tend not to be the most extrovert folks, but it is a necessary skill. Get yourself in front of people. Practise doing stand-up, meeting and greeting and networking. If you don’t have these skills other people will not compensate for your lack of them. They’ll just find someone else more interesting to talk to. Ian Livingstone himself said that this is one lesson he took a long time to learn. The great thing about computer folks is that they are used to picking up new tools and APIs. Treat this as just another thing you have to learn and get good at.
• Make a good story. The press is interested in you, but only if you are interesting to them. “I’ve made a fishing game” is not useful to them. But “I’ve made a fishing game that I wrote underwater whilst wrestling a Great White Shark on the Barrier Reef” is. Make sure that you have a good tale to tell. Use your followers (see above) to big you up and help you get noticed.
• If you are working as a team, set some ground rules (another favourite of mine). Have a plan for what to do if your lead developer gets a “proper” job and stops writing your game engine. Have a protocol and a policy for re-negotiating your arrangements when these events happen.
• You don’t need to be the best, or cleverest. Just there are the right time, in the right place, with the right thing. Try lots of things, in lots of places as frequently as you can. Don’t expect success to happen the first, second or perhaps even the third time. But as soon as you get a sniff of something that seems to be working, follow it, develop it and ride it, and you might be the next big thing.

All in all a fantastic day out. Thanks to Microsoft for setting it up.

Big Risk–Big Reward

I’ve spent a lot of the last few days sitting in on Seed exit interviews. These are actually great fun, although they are also very hard work. They are part of the assessment process for our MEng students. Essentially we get them to write a case for the marks that they think they deserve, and then they come to see us and try to justify them. For more details of the kind of things we are about, take a look at this blog post from Tom.

Anyhoo, the meetings take around an hour each and they can get pretty intense. Students put very strong arguments that they should get 5 out of 5 for a particular category, and we have been known to revise their scores up as well as down. One of the assessment categories has to do with planning. This is always an interesting issue. I made a point of heading straight for the Risk Assessments that we get the development teams to produce for their projects. These are supposed to set out the major risks to a successful outcome of the project.

Managing risk is a very good plan in a project, most of the projects that fail do so because of a failure to identify and track the things that could go wrong. But sometimes folks didn’t seem to quite get the whole story. Most of the Risk Assessments covered things like data loss, changes to personnel and the like, but some missed out the most important risk of all.

“What if we can’t get it to work?”

It is not unknown for a project in real life (and our projects are as close to real life as we can get them) to fail on this one. The system can have a beautifully crafted user interface, a carefully targeted audience and snappy marketing but if it doesn’t work, all this comes to naught. If you ever, ever, get into a development project you should make it your business to put this in the Risk Assessment and then track it. Maybe the Risk can be removed really quickly, once you’ve built a working prototype. Maybe it’s a slow burner, when you have to do a bunch of work and wait on other people before you find out whether it is a workable proposition.

I make this point as often as I can, and I often get the response “Well, Duh! The project is all about making this thing work, why would you add this as a risk?”. That’s true, but I know about projects, and people, and that defect in human nature that tends to push tricky things away into the distance where you don’t have to think about them too hard. Much easier to design that pretty user interface than work on that nasty interrupt handler code, or whatever.

With experience you learn to identify the “stoppers” in a project; the things that, if you can’t make them work, render the project a failure. These go onto the Risks and are tracked regularly to make sure that nothing in the project is built on sand. By the end of the meetings I think that the students we saw had taken this point on board, which I think is a one of the many really useful outcome from this part of the course.

Black Marble Wisdom

Steve Spencer and Rob (Boss) Hogg get down to business

We were very lucky enough to have Steve and Rob from Black Marble come over to Hull today to tell us about the business of software development. I think everyone should see talks like those, particularly people who think that creating software solutions is a technical problem. Because it isn’t. It’s pretty much an “everything else” problem with a bit of technology thrown in to make it work. Steve and Rob give about the best exposition of this that I have ever seen. They can talk about the mistakes that developers and managers make because they are candid enough to admit that they have made most of them over their time in business.

The staggering number of software projects that fail in the real world is down to human frailty as much as anything else, and what Steve and Rob do is point out the behaviours to watch for and the strategies that you can use to mitigate the problems.

My only regret about the talk was that we did not have more students there to get the benefit of it. Folks, if you thought about going but didn’t bother in the end, you have seriously missed out. With a bit of luck Rob and Steve will be back again next year, and you can get the benefit then.

Alien Invasion

Lindsay and David, standing against each other’s names.

Today a couple of ex-Hull bods came to see us. They now both work for Boss Alien down in Brighton and they came up to give a talk about working as a game developer.

Great talk guys. The thing that came out most strongly for me was that if you want to get into the game you must have a good portfolio of your work to show off. This should include not just coursework assignments that you’ve completed, but also things you have done of your own. Make sure that this is easy to find on your website or blog and keep adding to it. It looks like there is plenty of work out there for good developers, make sure that you do a good job of showing off your skills.