Why tutorials are a pain.

I'm revamping the code that powers the tutorial for Kudos 2. You might think that tutorials are a fairly easy thing to add to a game, but they are not.
If the game is really really simple, it's not a big deal, as witnessed by one famous game's entire instructions:

Avoid Missing Ball for High Score.

But Kudos 2 isn't pong, so it needs more than that. I'm using a similar approach to Democracy 2, which is a tutorial which highlights different GUI elements in turn and presents an overview of the game, whilst getting the player to make a few mouse clicks here and there. In addition, when you first play the game 'Hint' windows will pop up when new things happen to give you more information.

It's hard to code a tutorial without writing 'spaghetti' code. In other words, its tough to stick with the principles of Object-Oriented programming and not have lots of code spread around the place.
A tutorial, by definition, should cover the whole game. It should also prevent the player screwing it up with an errant keystroke or mouse click. In simple terms, you switch off player input at the tutorial start, and on again at the end, but that's not good enough if you want to support mouse clicks and other input during the tutorial itself.
So you end up writing 'hooks' into your input code to let the tutorial define what buttons can and can not be clicked at any point of time. This can get a bit annoying.

Fortunately my engine now has a better scripting system tan it used to, so it's pretty easy for me to 'label' buttons and windows in the code, and then let a script close them, allow or deny them, or highlight them. This means most of the real 'control' is done by scripts and thus easily edited and debugged.
It's taken most of the day to get it working the way I like, and that's without actually rewriting the new tutorial text, spell and grammar checking and so on.
But it's a step towards the far off goal of finishing the game. So hurrah!