I’ve only been fiddling with Inform 7 for two days, but already I see it gives you a lot of leeway when it comes to how you structure your code. With so little constraint on how things should be laid out, I’m finding my code quickly becoming a bit of a mess.
I was wondering what organisational methods you use to combat this potential chaos
I intend to write in a series of nested books, parts, and chapters, with each room being a separate chapter, each region being a separate part and overarching game-information being in it’s own book. I tend to write a higgledy-piggledy mess of ill-defined chapters, with sentences thrown into the source text wherever I happen to be looking whenever I think to write them.
I lean heavily on the provided Volume/Book/Chapter/Section thing … I tend to put general z-machine fiddles and under-the-hood crunch first … then new verbs and such … then a special volume for cheat/testing commands … then a volume for just stuff related to the Player Character, then either one or more (depending on the size of the project) volumes for the environment. Regions tend to be books; rooms chapters; important items or characters sections within their rooms … then, a volume for the random-atmospherics (I don’t think I’ve got any projects that don’t use random atmospherics, and I’m super-picky about 'em, so they get a stack of books and so on to themselves), then volumes at the end for things like scenes, score tables, dialogue tables, topic tables. If I have a variant version (ToaSK has a Glulx version; Ham House has a forthcoming “deluxe” version) then additions specific to that get yet-more-volumes at the end. Sometimes, it becomes necessary to put certain things near the end of the code for things to work right … that doesn’t seem to happen often, but sometimes, there are volumes devoted to special exceptions to actions, etc., that only work right when i stick them at the end (presumably due to Inform’s rules of precedence).
Since I have basically no programming experience apart from I7, my approach has just grown organically from the game-making process so far, and I doubt it’s “good practice” by anyone’s definition, but in the end, I can find everything
I think one of the things that defines Inform code is that each person’s code looks unique. All the leeway means that eventually you’ll start organising your code to convenience yourself, and that will define how it’s organised.
I know it’s annoying to start with no boundaries, but I’d say - just keep going. You’ll have a series of moments like - ‘It’s annoying that this bit of code is way down the bottom. I’ll cut and paste it up here so it’s next to that other thing!..’ And then you’ll do that. And then you might slap a heading over the now adjacent bits of code that somehow describes them both and lets you find them again later more easily. And as this goes on, structure and organisation tends to emerge organically.
Actually I’d say it’s a pretty interesting exercise in seeing how your own mind works over the longer term. But in the short term, just keep writing stuff, and occasionally group like things together under headings. Joey and Ghalev have already described some methods for that in detail.
It’s worth noting that if you ever find yourself working on a big project, with a lot of complex systems, it may be worth breaking (some of) them out into their own extensions. Even if you never publish them*, it still helps with organization. The “authorial modesty” use option was designed for precisely this.
[size=85]*Hey, you never know – someone else may be looking for some way to accomplish what one of the extensions does, and with a little polishing and documentation, you may be able to provide exactly what they need to move forward in their project.[/size]
I do this too, but more for saving future-me some work rather than organization. Sometimes, I’ll end up building a system and think “I’ll be using this again.” At that instant, I tear it out into either an extension, or as a new part of my master “house extension” (Cumberland House Rules) where all my favorite stuff lives.
I find it’s actually a pain in the butt in the short term (because it’s not right there in the IDE for fiddling-with) but saves a lot of trouble in the next project, when I want access to the same stuff and don’t want to perform surgery to remove it from the parent project.
That can have odd effects. For instance, adding this.
The whimper is in the cellar.
The Cellar is A Room.
Causes the room name to be decapitalised in the status bar.
Also, if you are co-writing a game, your poor old co-writer would have their work cut out trying to decipher your source code, probably to the point of banishing you from writing new source code straight in, especially if they’re extremely fussy about having well organised code!