I wrote The Magician's Nephew  (TMN) more than 10 years ago now. By the time I released it, I was heartily sick of it.

It's a big, complicated game, and the code is such a tangled mess that I was well into the "fix one bug and introduce two" part of the project lifecycle.

I decided to write something small and simple, and got _The Photo Shoot_ done in a few months.

I thought "That wasn't so bad,' so I tried to write a sequel to TMN. About a year  in I realised it was much too ambitious and gave it up.

Then a year later I wrote another sequel. I dabbled with that for a couple of years, before it started getting out of hand too.

What did I learn from all this?

• Scope creep kills (you'd think I'd have learnt that from 20 years of software development, and yet).
• Inform 7 is easy to write small games without much software engineering, but large games require just as much as any other language.

So, I started another game, technically a prequel, with a very limited scope. It'd just be the show part of the game. Set in just the theatre, nothing more. Get that particular fetish out of my system.

Remember I said scope creep kills? After I started on the second (medium-sized-game) side-quest I realised I hadn't learnt that lesson *at all*.

I stopped; I broke the game up into three parts, and _Stage Magic_ is the first of those. Its scope is basically as described.

Breaking it up was easier because I'd already had to split the story file into multiple different parts just so the Inform 7 IDE was useable; so each person had their own file already. Sharing the characters was just a matter of including the right file.

So, what tips do I have for I7 development? These are my current rules. They won't mean much if you don't use I7, but I recommend you at least think about them if yo udo.

Rule 1: Make all names unique identifiers with just one word (things like 'Kati's-white-t-shirt' not 'Kati's white t-shirt') so there's no danger of accidentally using 't-shirt' somewhere and Inform helpfully finding something with a similar name.

Rule 2: Write regression tests. Use them. When you find a bug, add the test to catch it, then fix it. (this holds for all development, not just I7).

Rule 3: Turn on 'use unabbreviated object names` so Inform will complain if you accidentally have a name that breaks Rule 1 and try to use a short version of it.

Rule 4: Be really strict about how you use action rules. Decide how you're using them (before, instead, check, carry out, after, report) and stick to it. I prefer to use Report for all output, After for post-successful action state changes (tracking events for example), Before to stop things happening and Instead to handle weird special cases or little things actions (like smelling). You can obviously use them however you like, but if sometimes you put output in After , sometimes in Instead, sometimes in Before and sometimes in Report before long you'll struggle to work out what's going on.

Oh, and:

Rule 5: Don't choose a game name because you think it's amusing. The name of TMN is descriptive, but it makes it impossible to find any references to it because of the famous book of the same name!

That's it. So far, it's at least meant the code has come together fairly fast and I've spent a limited amount of time chasing down bugs that were due to me accidentally using the wrong garment (the game set in a water park has a lot of swimsuits in it…).