Saturday, 28 December 2013

Learning 2D in Unity3D

In the past few months I’ve been teaching myself how to use the Unity3D game engine, partly because I’ve always wanted to write a game and partly because I wanted to learn something very different from web development. I thought it would be useful to share the resource helped me. My focus has been on 2D games and iOS devices so the links reflect that.

Tutorials and tips

  • Unity best practices - An assortment of useful tips
  • Unity3D Student - A large number of free, short tutorial videos. Typically 5-10 minutes which is great for picking up things quickly
  • 2D in Unity - A short overview of working with 2D in Unity 
  • Created 2D games with Unity (part2part 3part 4part 5video) - A much more in depth tutorial with covers making a simple 2D game
  • Setting up version control - Essential if you’re doing a project of any size. It’s also worth setting your Asset Serialization mode to Force Text in Edit -> Project Settings -> Editor as binary files cannot be merged
  • Coding standards in Unity - I don't agree with all of these but it's a good overview
  • Unity3D wiki - It's worth digging around on this site. There's a wealth of information and useful links. In particular the scripts is packed full of useful code 

Useful plugins

  • iTween (free) - The de-facto tweening framework. It’s very simple to use and the documentation is great
  • 2D Toolkit (paid) - This plugin provides a lot of features to make creating 2D games in Unity much more straight forward. With the release of version 4.3 Unity comes native 2D tools. There is considerable crossover in functionality but, as you would expect, some of the native tools are Pro only so I’m sticking with 2D toolkit for the time being
  • NGUI (paid) - A popular framework for creating GUIs. In my experience it’s easy to create basic GUIs and has some great features, but it's not cheap


  • TestFlight - An incredibly useful way of distributing your app to multiple devices for testing. That’s all I’ve used it for and I’ve barely scratched the surface of what it can do

iOS specific


  • Unity3D blog - It's worth keeping an eye as to find out about details of future work, new features and releases


Tuesday, 15 October 2013

DDD North 2013

The third ever DDD North was every bit as good as the first two. I saw five great talks, chatted to lots of people but unfortunately didn't win anything.

Making 3D Games With MonoGame - Richard Garside (code)

This was an introduction to MonoGame, an open source implementation of XNA which is also cross platform. It covered importing models, setting up cameras and basic animation. After about thirty minutes or so I decided that MonoGame was too much like hard work for my liking. I've been attempting to learn Unity3D recently and it's possible to achieve the same results with significantly less code. Admittedly MonoGame is massively cheaper than the pro version of Unity3D but I think I'll stick with Unity3D free for now.

Scaling Systems Architectures That Grow - Kendall Miller

In this talk Kendall managed to simplify a very complex problem, scalability, into four simple points. He said to enable scalability you must:
  • Use asynchronous processes. If it's not critical, do it later
  • Cache. Don't do work you don't have to. The fastest query is the query you don't run
  • Distribution. More servers, more computing power. This is not easy so should be attempted after the first two points
Kendall also highlighted that the most significant problem when scaling is consistency, ensuring all users see the same state. 

Obviously this is a simplification of a sixty minute talk but the bullet points are worth remembering.

Cross Platform Mobile Development in C#  - Ross Dargan (code)

Xamarin was the subject of this talk. Xamarin is a framework for creating cross platform mobile applications. One of the pain points when developing cross platform is the lack of shared code. In this talk Ross demoed several ways of sharing code between platforms and highlighted their pros and cons. Essentially all business logic can be shared and much of the view model code as well. Primarily only the view code can't be shared. Each view must be created natively. So Android apps views are created using XML, WPF apps use XAML, etc. Useful stuff.

MongoDB for the C# Developer - Simon Elliston Ball (slides)

NoSQL is something I've been wanting to play with for a while and this talk showed how easy it is to start using MongoDB  Setup, basic queries, replication, storing large documents and database structure were all covered. Interestingly Simon also included a comparison with RavenDB  I think at this point I'd still favour RavenDB as the in memory database sounds useful and transactions are ACID.

Testing Crap in Web Applications Like ASP.Net MVC - Rob Ashton (slides)

Sixty minutes of rant from Rob, I expected no less! You have to concentrate hard otherwise you'll miss something. To be honest I'll still not 100% sure how to do fast UI tests in my day job, but when I left I was damn sure I wanted to try. At some point, when I find the time, I want to check out PhantomJS and coypu that were mentioned. Rob and others have convinced me that UI tests can be incredibly useful since each one covers so much code. Unfortunately in my experience they aren't easy to set up. One day I'll get it right. 

Saturday, 25 May 2013

A few things I've learnt about TortiseSVN

I've been using TortiseSVN for a few years now so thought it would be a good idea to list some useful bits and pieces I've found out in that time. It's also a good excuse to have a poke around and look for any other useful features I've missed.

Reverted files go into your recycle bin 

Reverted files go into your recycle bin, there's not much else to say. It's incredibly handy if you revert by accident (it can happen). I tend to use AnhkSVN in Visual Studio and annoyingly it doesn't have this feature.

The small downside is that reverts take longer. If you are bothered just turn it off. 

TortoiseSVN -> Settings -> General -> Dialogs 1 -> Use recycle bin when reverting.

Recycle bin settings

The context menu is configurable

The context menu is the menu you get when you right click on a file or folder in File Explorer. I use the SVN show log view all the time so I want it visible without having to click into a sub menu.

TortoiseSVN -> Settings -> General -> Context Menu

Context menu settings

Updated context menu

Show merged revisions in the log viewer

Ever wanted to see what revisions were included in a merge? Easy. Just tick the include merged revisions checkbox in the log viewer. 

Include merged revisions checkbox in the log viewer

Repair move

Have you every moved or renamed a file without using the appropriate TortiseSVN command? That's me pretty much every time. Turns out there's an easy way to fix this from the commit dialog box. Simply select the two files you're interested in by Ctrl clicking, right click one of the files and select "Repair move". You must select exactly two files and their statuses must be missing and non-versioned otherwise the repair move command will not be visible.

Quick select multiple revisions to merge

In the merge dialog click the first revision to be included in the merge then shift click the last revision to select a block. You must click somewhere to the right of the checkboxes. Confusingly shift clicking on a checkbox doesn't work.

Block selecting multiple revisions

Automatic merge commit messages

When committing a merge if you click on the "Recent messages" button it's auto populated with a message containing the revision numbers you chose plus all their commit messages.

Recent messages

The commit message includes all revision numbers and commit messages from the merged revisions.

Visual Studio integration without a 3rd party plugin

It's possible to add some TortoiseSVN commands to Visual Studio without a plugin. If you use Visual SVN or AnkhSVN then most of the features you can get won't be very useful. I use AnkhSVN and one handy feature you don't get integrated into Visual Studio is blame  (update: my colleague told me it is actually available but is called annotate and it isn't quite as helpful as the TortoiseSVN blame view). This guide shows how to add commands like blame, diff and log to the document context menu. 

Context menu

One step the guide misses is that there's no need for trial and error when adding the external command to the Tools menu, which is nice as I had over twenty. Simply add External Tool X where X is the postion of the blame tool in the External Tools list as shown below. In this case it was 3.

SVN blame command in the External Tools

Avoid using reintegrate a branch

This has probably caught out quite a few people including myself; reintegrate a branch is a one time operation. The only time you want to use reintegrate a branch is when you have finished work on your branch and are ready to merge it back into trunk. After this no more work should be carried out on that branch, if you do bad times will ensue. Ninety nine percent of the time merge a range of revisions is what you want. 


If you use one repository, like I do, most of the time then setting up log viewer and commit shortcuts is really useful. There's is almost certainly more than one way to do it but I like using AutoHotkey. It's an incredibly useful app that allows you to create shortcuts for almost anything. You simply create a script specifying the shortcut keys and the programme you want to run. This Stack Overflow post shows the steps to setup the shortcut.

Shelving (kind of)

As far as I'm aware shelving is not possible in SVN. Shelving allows you to put some work to one side without committing it, then come back to it later. Very handy if you're in the middle of something and your boss asks you to fix a production bug ASAP. It helps reduce the risk of accidentally committing the wrong files.

While shelving is not possible, like in Git or Mercurial, you can kind of fake it by creating a patch. Instead of committing, in the TortoiseSVN context menu select create patch which creates a patch file that encapsulates all your changes. You can then revert your uncommitted files, do whatever work that needs doing, commit, then apply the patch file again by selecting TortoiseSVN -> Apply patch and continue where you left off.

Friday, 22 March 2013

Making your code easier to review

Code reviews are great. Personally I believe there are many good reasons to do code reviews regularly. Fortunately where I work they are actively encouraged. Unfortunately we don't have a nice tool, like Crucible, to make things a bit easier. SVN log viewer is as good as it gets. This makes code reviews a bit more difficult, so I was wondering, how can I make it easier for others to review my code?

1 - Keep commits small

Seems pretty obvious this one, but it makes a big difference. In a perfect world (i.e. this doesn't always happen) I like to break some my work into a series of steps and commit each step. The smaller the commit the easier it is for the reviewer to see what you were trying to do. Or to put it another way 50 lines of code is much easier to understand than 500.

Ideally a commit can be summarised in a short sentence. If there's paragraphs in the commit message there's probably too much in there. But I have to hold my hands up and say I don't manage it all the time.

2 - What and why

Something else I find helpful in commit messages is the why. What has been done is nearly always covered but the why is often missed. Few things are more frustrating than reading a commit message that says something like "removed xyz from system". That's nice, I can see what you've done but why did you do it? I can't see the reason! Tell me! Why tells you if the work actually needed to be done. Why explains the reason behind an obscure code change. Why tells you the motivation behind the work. Why is important when you're reviewing code.

3 - Avoid noise

Code changes are easier to review if they only contain the important stuff. For example, changes to the logic of a method or the changes to a LINQ query or a bug fix. Unfortunately commits often contain lots of noise. By noise I mean anything that isn't directly related to the piece of work being undertaken. This includes things like lots of white space changes, code alignment, variable renaming, method renaming or any other refactoring. This stuff should definitely still be done, but ideally in a separate commit so the reviewer doesn't have to work out what is noise and what is not.

4 - Check your changes

I'm always surprised, not sure why, by the number of daft mistakes I pick up when I check my code changes before each commit. By this I mean view the diff for each individual file I'm committing. Going back to my first point, this is much easier if the commit is small. Typically I will find unnecessary comments, debugging print statements, test code, files I forgot to revert, code I temporarily commented out etc. etc. If you spot these problems the reviewer doesn't have to.

Saturday, 23 February 2013

Book review - Rework

Short, simple, to the point, positive and full of practical advise. I liked it.

Tuesday, 15 January 2013

Serious creativity

Here are some interesting ideas; what if creativity was a logical, analytical process? What if creativity could be learned, or your existing creative skills practiced and improved? Edward De Bono says all of this is possible and in Serious Creativity he tells you how. For me, a logical, analytical kind of person who doesn't consider himself creative, this is a fascinating idea.

Please note than De Bono has been writing for many many years on creativity and other subjects, but this is the first time I've encountered some of his work. Without a doubt, it won't be the last time.

My misconceptions about creativity

I've had a few misconceptions about creativity for most of my life. Some stem from school. Subjects like science and maths, subjects I was good at, weren't considered creative. Art and music, subjects I wasn't good at, were considered creative. What left me with this perception? I really can't remember.

Are some people more creative that others? I've always thought so. Loud, outgoing, eccentric, extrovert people like art, dance, music, acting and things like that. Clearly they are more creative. They must be as those subjects aren't logical or analytical, they require mystical skills that I don't possess.

If you're not creative, tough, you're stuck with it. There's no way forward, creativity can't be learnt. Just give up and stick to non creative things. Basically you're either born creative, or you're not. Again with the mystical skills.

After reading Serious Creativity

My perception of creativity has changed considerably after reading Serious Creativity. What I had assumed was a creative activity isn't necessarily so. For instance, you could consider me musical. I play the guitar. But do I do it creativity? No. I enjoy learning riffs note for note. Rocking Metallica riffs is fun! How did I learn the guitar? Hours and hours of fairly boring repetitive practice. Not creative. The same applies to things like art and dance. They can be extremely creative, but it's unfair to assume that they are.

A big factor that helped change my perceptions is that De Bono suggests there are two types of creativity; artistic creativity and idea creativity. Artistic creativity can't be taught, it isn't logical. Genius artists and musicians and such like will have it. This is what most people think of when you ask them to describe creativity. The other type of creativity, idea creativity, De Bono suggests is available to everyone. Idea creativity is about changing concepts and perceptions and is what Serious Creativity is concerned with. It is formal, logical, serious and can learnt. You can practice and improve your skill. 

Another factor is the realisation that most people are creative in some way. Ever made someone laugh? Then you're creative. Humour is the essence of creativity.

What it's about

Serious Creativity is split into three parts; the need for creativity, tools and techniques and the application of creative thinking. 

Part 1, the need for creativity is an introduction to creativity including why we need it, where it comes from and it uses. De Bono provides a model to explain how the brain organises information which he calls a self organising information system. He says our brains fit what we see into existing perceptions and we need creativity to break away from these perceptions and form new ideas. This is the essence of lateral thinking, a term he invented.

Part 2 details the tools and techniques De Bono invented for creative thinking. To mention a few; the six thinking hats, creative focus, the creative pause, provocation and random input. I'll talk about some of these later.

Part 3 is concerned with the application of creative thinking. It details which techniques are appropriate for particular situations and provides a formal structure for each creative session. Interestingly he advises creative effort should be applied for a short period of time. Around five minutes using the technique, then another five minutes harvesting any ideas generated. The benefits of this approach is that you train your brain to work quickly and there's no pressure to keep working until you come up with a great idea. 

How can it be applied to software development?

The title of this section is misleading. De Bono's techniques can be used anywhere creativity is required, not just in software development. There are numerous ways his techniques could be applied, but I found a few particularly interesting.

The six thinking hats is a particularly fascinating idea. Have you ever had a discussion with another developer where you were explaining the advantages of a certain course of action and the other developer was pointing out all the disadvantages? I have, many times. The six thinking hats aims to move away from this attack and defence style of discussion. De Bono claims, and I believe him, that it isn't very constructive. It's not a helpful mechanism. The six think hats is an approach that calls for particular style of thought according to the chosen hat. This can be applied individually or in groups. For example if a group of people was being overly negative you could ask for less black hat thinking and more yellow hat thinking (optimistic).

De Bono talks about the creative challenge. The essence of this is questioning everything. Why do we do it this way? Is there a better way to do it? This applies even if there seems to be nothing wrong with a particular process. In fact De Bono suggests that more focus should be applied in this situation. Just because nobody sees any problems with a process doesn't mean it can't be improved significantly. Potentially significant improvements can be missed if you assume something is as good as it can be.

Coming up with new ideas is a difficult but useful skill in any line of work. Surely you need to be a creative type of person to do this? De Bono says not. It can be another formal, methodical process. How? Several techniques are included in Serious Creativity, I'll only mention about a couple. 

Firstly there's random input. As the name suggests you use a random word to generate new ideas. It doesn't sound logical does it? The principle behind the technique is that the random word can trigger new ideas or new directions in relation to a concept for which you want to generate more ideas. Or to put it another way it stimulates lateral thinking. In theory, by practicing this technique you can improve your brain's ability to make this kind of new connection. 

The second technique I'll briefly talk about is provocation. Apologies for the terrible explanation of this technique. It's a tricky idea for me to grasp. Essentially the principle is to use a deliberately provocative statement to stimulate new ideas. There are several ways to create a provocative statement. For example, come up with a situation which isn't possible, or exaggerate a measure or dimension, or reverse the usual way of doing things. Once the provocation is stated you seek new ideas from the statement. An example given relates to the problem of waste being dumped into rivers from power plants. The provocation is "what if the power plant was downstream of itself". Clearly this isn't possible but the provocation contains the idea that a power plant must use it's own polluted water. Apparently this actually became law in some countries. Power plants must have two sites, one downstream of the other.

Summary bit at the end

I'm not sure why but I alway feel the need to write some kind of conclusion rather than just end the blog post. So here it is. Hopefully what I've written makes some kind of sense and conveys why I find this subject so interesting. To say I've just scratched the surface is a huge understatement. There is a huge amount more to this subject than I've covered. If it sounds interesting, then check out Serious Creativity.