Restructuring code

I’ve been very judicious about using the built in heading (Volume - Book - Part - Chapter - Section) but even though I can still find what I want when I want I feel like it’s getting away from me a bit. I don’t like the order of some things and some stuff that is grouped together could be split up and other things could get merged together. I am at almost 11,000 words and maybe getting close to half done. Is it worth taking the time to restructure my code to get it to a place that I like better and find more manageable (saving a back-up, of course) or to keep pushing ahead and restructure later?

1 Like

Do you feel like it’s slowing you down or causing you to make mistakes? Then it might be worth restructuring your code. Generally I try to avoid anything large scale while I’m in the middle of something as I find it confusing to remember what I broke by moving things around vs what just didn’t work before I started moving things around.

I can’t tell you what organization is best for your particular project, but I can mention what works for me. I try to maintain a hard separation between “content” and “mechanics” – or in other words, things like room definitions etc, vs. rules and such that make things run, that I might reuse later. It helps me to think. I find the best way to do this is by making lots of extensions – each separate geographical area is an extension, each different kind of thing (like the rules for taping things together) get their own extension. This is, I’ll admit, a lot easier in VS Code, which I use, than in the IDE. But until a future version of Inform enables multiple source files, extensions are all we have to keep one file from getting unworkably large.

My punt is if you’re having that ‘I want to restructure’ feeling, it’s a genuine inclination for your temperament and way of working, and probably will help.

Yes, definitely back up first, and make the restructure a distinct version of the project. And test the result thoroughly. It doesn’t have to be a massive phase, just a distinct one. You may find that the process goes easier than you thought it would in theory; that’s often my experience.

Restructures are often when you find bugs, too. You find code you’re not using any more, orphaned variables, etc. So doing it halfway through isn’t a bad time to have it double as taking stock.



@Jason - For my first Inform 7 game I came up with the following structure for my code:

  • Volumes - To indicate major areas
  • Books - For individual settings, characters, things, and scenes
  • Parts - For specific rooms, characters, things
  • Chapters - To subdivide areas under a specific object


You can find more screenshots here.

The structure evolved over time as the source code increased. The whole section on Things was not in version 1.0 (objects were scattered throughout the code in the Settings) but when I added fire and the ability to burn objects I created the Things volume.

When I added Figures, i.e. images, to the game I just had to add a new volume for them in the appropriate place and follow my original taxonomy.



For my first game, I ended up writing 127,049 words (only 45,459 words remain in the current version). Using this hierarchy enabled me to keep a large code base organized and find specific sections of code without too much effort.

1 Like