Hmm, not sure how to ask this question, but how do people keep track of their code, things neat and tidy so they can find what they need at a whim? I’m interested in both inform 7 and Tads 3 methods. I started with Inform UnknownPreviousNumber [few years ago] but use Tads 3 now to help me keep familiar with languages that I have to use in school. One problem I am having is just keep track of rooms and objects when writing IF. How do people do that here?
In general you should choose one system for organisation – generally either geography for a exploration heavy story, or scenes/time for an event heavy story. You can then subdivide the top level divisions if that makes sense: regions/groups of rooms, then the individual rooms, or chapters/acts and then scenes.
For Inform 7 make sure you use the Index. With its shortcut links you won’t need to remember where most of the things are anymore.
I use Hugo, but I imagine some of the tips can be applied to TADS 3 (not being familiar with the TADS IDE, I don’t know if it has built-in features promoting certain methods of code organization):
Use your language’s file-inclusion capabilities to your advantage. I like to put rooms and objects in one file, while other files may consist of characters, grammar, library replacements, and new verb routines. I find that the compartmentalization helps me keep a handle on the code.
Organize from within the files themselves. Even though my text editor provides a nice way to jump to various points of code quickly, sometimes I’ll also add bits of comments that list everything to be coded in a room (or in scope), like a little table of contents:
[code]!\ Bowling alley objects-
- Bowling alley
- cigarette butts
- broken glass
- cement
- park?
- path through woods, woods
- convenience store parking lot
![/code]I find that this reminds me of my original thinking better than just seeing objects listed by my editor’s function list feature.
With I7 I just make sure I use the heck out of headers and subheaders, which makes the “Contents” portion of the Index super-fast to use. Beyond that, the rest of the Index (especially the Scenes and World tabs) do a ton of heavy lifting without additional help. Outside the game, I build and organize all of my tables, most of my game-structure, and even portions of re-usable code in Excel, in a project-specific workbook.
File-Inclusion, thank you. That keyword helped me a LOT. Everything makes sense now.
Thank you all for the great tips! It’s been a really great help.
In inform7 there is no simple way to do this. You could use extensions and include them but my guess is that that’s not going to simplify your workflow (unless you are writing code you intend to reuse across several projects).
As noted above the use of headings (book, part, chapter, section) helps you split up the code logically and you can use the source view in the IDE to see just the relevant part of the code.
On a tangent, another really helpful thing is using a proper version control tool like git, svn or mercurial.
As people above mentioned, I7 doesn’t have file inclusion, but the outline is quite nice, and you can choose its scope. At least in Windows. The volume/book/part/chapter/section outlining has no ‘right’ way to do it and is a decent replacement for I7 allowing only one source file–technically, you could create extensions that contain items or rooms or whichever for your game, but extensions are meant to be general.
First, for examples that show and don’t tell,
ifdb.tads.org/search?searchfor=t … 0available
And pull them up in an Inform IDE to see how the volumes etc. are organized.
For a quick and dirty explanation, my basic outline starts like this.
[code]Volume 1
Book inclusions and global variables
Book rooms
Part region-1
Chapter start-room
Part region-2
Chapter end-room
Book items
(organize items alphabetically)
Book irregular verbs
Book regular verbs
Book rules
Book function stubs
Volume 2 - not for release
Book testing commands for programmer
Book testing/cheating commands for player
[/code]
The IDE allows you to page through the outline, which helps–or you can search for “chapter (room name)”
And of course the sooner you organize this, the less fiddling there is later.
This is just an example, and only for I7. Your own coding style should dictate how you organize things, though.
That’s a shame, it might have been nice to discuss how you might organise things in other systems…
If you have a large project, it certainly helps. (Kerkerkruip consists of about 15 extensions.)
It’s a little bit like how I am with everything else in my life:
I’m particularly interested in Inform and Tads, however as always I am open and curious to other systems as well, but I thought it would be fair to let people know that I specifically orient towards Tads 3 and Inform 7.
(Hehe had to bold some things that made me chuckle inside my head because they reminded me of how I describe my sexuality, or foods I orient towards or away, the italics are removeable in a different context–me being nerdy please ignore 
)
Of course I’d love to know any method of having cleaner code if it can carry over to Tads 3 or Inform 7 or is even just Programming Specific, like the Keyword File Inclusion, Tads has it, Inform doesn’t, but it has something else that is very useful for me to know.
In particular I am new to programming, I’m not good at it, but I have a passion for it because I view it as a tool. Some things fly right over my head, but keyword specifics I understand because I can type them in. My background at the moment is novice-C# programming I use a lot of Classes and was learning how to organize with classes. I learned I really like Text Based Games and so decided to pick up Tads 3 to both keep the C-languages familiar to me when I go back to class Spring semester and to write the Games I want using IF. My original question that I didn’t post but had filed away was a question I wrote down which was Tads 3 specific at the time:
But because I had a history with Inform #somenumber, I assumed that writing IF with the different languages didn’t have that same kind of file organization. Or that they DID have the ability to #include, but that it was different from calling methods and functions and I don’t know. I mean I had never seen multiple source files with Inform and my logic is a bit warped hence why I do so bad at puzzles, so I simply figured there had to be a common thread to how people organized their IF across languages if they had to keep everything in one massive file that went on and on, especially for a game where lists of objects and rooms can get particularly large. I didn’t know if it was with #include, if it was with methods, or functions, or basically creating a table of contents–I didn’t want to make things more complicated for myself, and genuinely didn’t even know if #include was the right question to ask, as you can only imagine where searching “#include file organization” in google gets me haha. But File-Inclusion definitely unleashed a lot of information for me.
But Campbell, I would absolutely love to know how you organize in other systems and that would be a great topic. I will rephrase:
How do people organize code across the different systems used?
Note: The original question I had (quoted) thanks to the help from you all here, led me to learn some things that were very useful for me. I discovered for instance http://www.tads.org/howto/t3inc.htm and was able to narrow my search, and learned a different way to both think about and do what I was trying to do. I also learned something key in relation to Inform 7, that is definitely good for me to know as I do plan to use Inform 7 as well and knowing what I can and can’t do but how others do it is crucial. Again you have been a great help.
I’m very curious to see how things can get organized in ADRIFT. Are there any documents for this? As I understand, there’s no source a person can meddle with.
Quest’s latest update seems to have added stuff too. I suppose the big draw of TADS/Inform is, they’re closest to a traditional programming language where you can organize source. Having a GUI and text editor to create something seems like the best of both worlds, and perhaps Adrift could do that–but it’d be a pain to implement & GUI changes could override text changes and vice versa. I wouldn’t have any specific design advice, sadly.
Re: Inform 7, I released the very clean and commented source for a new I7 game the other day:
ifdb.tads.org/viewgame?id=6kko9va64c4o5jan
The point of this source is that I tried to make it explicitly helpful for people asking the ‘What are some ideas for organising your source?’ question, and the game itself is small and comprehensible.
- Wade
Now, I’m not a programmer and have never used C# so I have forgotten what classes and such means in that context (I say “forgotten” since I’m pretty sure I’ve heard people explain them), but their mention reminds me of other types of code organization.
Grouping and efficiency:
When you want several objects or rooms to behave the same, each language provides ways to group them. In Hugo, you can declare object classes, so that every object created of that class shares the properties and attributes of the original class (you can also “inherit” from multiple classes). I think Inform 7 does this with kinds. I don’t know what TADS 3 calls it. I really like Inform 7‘s concept of “regions,” too, which is a way to further specify which rules should be applied to where. Hugo doesn’t have this concept built into its library, but I have applied that logic to some of my WIPs.
Anyhow, these things save you time so you don’t have to recreate-the-wheel for each object and can help readability, too.
Using constants to your advantage:
In Hugo, everything can be boiled down to a numerical value. When my code refers to an object, as far as the engine is concerned, it’s just a number. Attributes such as openable, light, and unfriendly can only have a value of 1 or 0. If I have to keep track of several states of an object or character, constants can be nice way to do so.
In Hugo, I could declare a bunch of constants like this:
enumerate start = 1
{
HAPPY, SLAPPY, SAD, FUNKY
}
That’d set HAPPY to 1, SLAPPY to 2, and so on.
Now, if I made up a “mood” property for my characters, I can alter them like so:
dwarf.mood = SLAPPYIn actuality, I’m just setting the mood to 2, but hey, as far as I’m concerned, that is one slappy dwarf! So, constants like that can be a good way of keeping track of a lot of stuff but keeping readability. In Hugo, there’s the added bonus that while attributes and global variables have finite limits, constants and properties do not. It’s very likely that the similar functions in TADS 3 and Inform 7 are much better represented, but for me and Hugo, this was very much a coding revelation.
Well now, since you both ask… 
Code (or item/logic/whatever you want to call it) organisation was a huge problem with ADRIFT 4 as it was just a set of lists (one for locations, one for objects, one for tasks etc). You could order the lists alphabetically or by creation date, but this made it very difficult to find things as the game got larger.
ADRIFT 5 introduced a folder structure. It works very much like any directory tree structure, and you can have any number of folders within folders. So this makes it easy to organise your game however you want. Typically you might create folders within the root node (Desktop) for each chapter or scene in the game. Then within each chapter folder you might create a folder for each location. And within each location folder you might store the location definition itself, plus any tasks or objects specific to that location. I think this approach works well. Of course, there are other ways to do this and it is up to the author.
As for finding things at a whim, ADRIFT 5 has a Find and Find All function (as I’m sure most systems do), which lists all items matching the search criteria, and displays which folder the items are members of.
Items can be dragged and dropped between folders, making changing the organisation a cinch.
That is one slappy dwarf. Thanks, Roody.
I’ve been trying to take advantage of the one-big-file approach of I7 by putting the most general stuff first, and the most specific stuff last. Ideally, if I need to comment everything out to find a bug, I start at the end and just lop off blocks until I get to the beginning. I never get it perfect, but it seems like a good goal to work towards.
The most general stuff eventually finds its way into extensions.
After a while, even the Contents got too big to navigate and I found myself zipping around the source mostly by using the Find feature. So I started putting little “hashtag” comments into the code. Any object or scene or bit of functionality that got worked on frequently got a little hashtag…
[code]Chapter - Body Parts
[#body parts #parts #bodyparts]
[TODO: turning body parts]
The carrying capacity of the player is 2.
Definition: A person is two-handed rather than one-handed if the carrying capacity of it is at least 2.
[change carrying capacity message?]
Attachment is a kind of value. The attachments are detached, loose, firm, and healed.
Understand “severed” as detached. Understand the attachment property as referring to a body part.
A body part is a kind of thing. The description is usually “[The item described] is [right where the item described should be].” A body part has an attachment. The attachment of a body part is usually firm.[/code]