best way to organize I7 source code/components?

18 views
Skip to first unread message

Tim

unread,
Nov 28, 2006, 6:00:09 PM11/28/06
to
I'm extremely new to I7. What is the best way to organize source
code? Put all locations in a chapter and all objects in another and
all rules in another etc. or organize by locations and put as much
together relating to rooms as possible?

If you segregate stuff wouldn't it be hard to test until the entire
game was coded?


Any ideas... thanks.


tim

Michael Martin

unread,
Nov 28, 2006, 6:40:41 PM11/28/06
to
Tim wrote:
> I'm extremely new to I7. What is the best way to organize source
> code? Put all locations in a chapter and all objects in another and
> all rules in another etc. or organize by locations and put as much
> together relating to rooms as possible?

My WIP I'm sorting mainly by time, but it sorts itself neatly into
scenes, so this is sensible. It wouldn't be so for, say, Adventure,
which might be better sorted by region.

Extremely complex objects tend to get their own sections in my work, as
do submaps specific to a scene. If there are multiple (complicated)
solutions to some puzzle, each solution would probably be a subsection
of a larger section that comprizes the whole puzzle.

> If you segregate stuff wouldn't it be hard to test until the entire
> game was coded?

Not really. Nothing says you can't go back and add to previous
sections.

--Michael

Andrew Plotkin

unread,
Nov 28, 2006, 7:00:28 PM11/28/06
to
Here, Tim <mefts...@yahoo.com> wrote:
> I'm extremely new to I7. What is the best way to organize source
> code? Put all locations in a chapter and all objects in another and
> all rules in another etc. or organize by locations and put as much
> together relating to rooms as possible?

I do the latter. There are usually some game-wide topics which get
their own chapter, too.

In _Wallpaper_, I have these chapters:

- Commonplaces ["use" options, common phrases, common kinds,
procedural rules]
- Message tables [big tables; they take up enough space that they
interrupt the flow of the code, so I stick them here]
- Debugging - not for release
- Introductions [just the game-intro text]
- Rooms
- - Courtyard
- - Foyer
- - ...etc...
- Sets
- - [subsections for various pieces of the second game part: bell,
knife, etc]
- Your Notes [the help system]
- - game part one
- - game part two
- Credits


> If you segregate stuff wouldn't it be hard to test until the entire
> game was coded?

That's a question of what order you write the code in, not how you
organize it.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.

Sami

unread,
Nov 28, 2006, 8:08:19 PM11/28/06
to

Since for practical purposes it doesn't much matter, I'd say it depends
on a combination of a) the nature of the game, and b) how your brain
works. For Labyrinth, I have separate chapters for:
1) all the tables, rules etc. relating to directions
2) rooms & doors
3) objects (separate section for each object)
4) people
5) action-type things (one section for each complex action I define, a
section for "when play begins" rules, a section on ending
messages/rules, and a section for miscellaneous rules (this is mostly
for special responses for typical actions, such as saying "You're not a
cannibal" if the player tries to eat a person), a section for
out-of-world actions, and a section for the hint system)

However, for a typical game I would probably use a chapter for each
location and put all the location's objects in that chapter, along with
any special rules for dealing with those objects.

Tim

unread,
Nov 28, 2006, 9:18:37 PM11/28/06
to
Thanks, everyone, for the feedback.

I've only used I7 for a few hours. I feel sort of dumb. hehehe But
I'm sure it'll grow on me. At least I never used I6 so I don't have
anything I miss from that.

Tim

Tim

unread,
Nov 28, 2006, 9:20:41 PM11/28/06
to
Oh, one other question...

Is the source available for "Wallpaper" and/or "Labyrinth"?


Thanks,
Tim

Andrew Plotkin

unread,
Nov 28, 2006, 9:34:34 PM11/28/06
to
Here, Tim <mefts...@yahoo.com> wrote:
> Oh, one other question...
>
> Is the source available for "Wallpaper"

No, I don't plan to release the source. Sorry.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're an American.

Sami

unread,
Nov 28, 2006, 11:50:40 PM11/28/06
to

Tim wrote:
> Is the source available for "Wallpaper" and/or "Labyrinth"?


Well, the original version was written in I6. I don't intend to
release the source for that. The new, I7 version isn't finished yet.
I am still undecided about releasing the source.

Blank

unread,
Dec 13, 2006, 9:58:20 AM12/13/06
to
Tim wrote:
> Oh, one other question...
>
> Is the source available for "Wallpaper" and/or "Labyrinth"?
>
>

If you're looking for examples of source code, here's a good place to start:

http://www.inform-fiction.org/I7/Worked%20Examples.html

Good luck!

jz

villagedweller

unread,
Dec 13, 2006, 10:56:58 PM12/13/06
to

I, too, am new to the inform system. As a newbie, I find the worked
examples are useful for specific bits of code (though they're
documented sketchily, so that makes them a bit harder to grok), they're
not so helpful for global organization issues. They are all
self-contained, and quite small.

I have been organizing by location, and moving things to "functional
chapters" like definitions, new actions, etc. as I begin to see how I
can make the code more efficient and better understand the conceptual
distinctions of i7. I figure my code is going to get reorganized at
least a couple dozen times, and that I'll learn from the process.

What I am finding the biggest obstacle is the inability to break the
code into multiple files. That is the way I am used to programming, so
maybe I will get used to this in time. But I find scrolling about even
in a small amount of code pretty daunting, and I'm really not looking
forward to bug hunts in the later stages.

Blank

unread,
Dec 14, 2006, 10:49:38 AM12/14/06
to
villagedweller wrote:
(snip)

> What I am finding the biggest obstacle is the inability to break the
> code into multiple files. That is the way I am used to programming, so
> maybe I will get used to this in time. But I find scrolling about even
> in a small amount of code pretty daunting, and I'm really not looking
> forward to bug hunts in the later stages.
>

Yeah, me too. I'd really like to be able to open multiple files as
'pages' in the IDE, or at least to be able to 'collapse' sections and
hide them from view. At the moment my projects just grind to a halt as I
get lost in the code - not a problem atm as none of them were intended
to see the light of day; they're just learning exercises - but it does
make me seriously wonder if I'll ever really be able to produce anything.

(Yeah, I know I could write the source code in some other text editor
that *does* offer that facility, but for me the biggest single advantage
of I7 is that the write-compile-test sequence is set up to work right
out of the box.

I've tried learning TADS T3 ALAN and HUGO and in each case the single
biggest stumbling block has been that I haven't been able to get the
compiler to talk to whichever text editor I'm using at the time and get
it to do that clever business where clicking on the error message jumps
you to the problem line in the source code.

I really only managed to get to grips with I6 because IF-IDE was simple
enough to set up that I could get it to work. Even the superb
documentation of the Beginners Guide + DM4 wouldn't have been enough in
the face of the sheer inefficiency of scrolling through the text looking
for line 3104.)

jz

Neil Cerutti

unread,
Dec 14, 2006, 10:54:21 AM12/14/06
to
On 2006-12-14, Blank <bl...@nowhere.com> wrote:
> villagedweller wrote:
> (snip)
>> What I am finding the biggest obstacle is the inability to
>> break the code into multiple files. That is the way I am used
>> to programming, so maybe I will get used to this in time. But
>> I find scrolling about even in a small amount of code pretty
>> daunting, and I'm really not looking forward to bug hunts in
>> the later stages.
>
> Yeah, me too. I'd really like to be able to open multiple files
> as 'pages' in the IDE, or at least to be able to 'collapse'
> sections and hide them from view. At the moment my projects
> just grind to a halt as I get lost in the code - not a problem
> atm as none of them were intended to see the light of day;
> they're just learning exercises - but it does make me seriously
> wonder if I'll ever really be able to produce anything.

Use one of the many built-in code browsers in the index to jump
very quickly to where you need to go.

I admit it isn't as nice as an outline view that's provided by
certain editors, but it neatly solves the problem of just hunting
for definitions with the paging keys.

--
Neil Cerutti
Any time I've taken the mound, it's always been the old Samson-and-Goliath
story written about me. --Randy Johnson

Jeff Nyman

unread,
Dec 14, 2006, 11:14:23 AM12/14/06
to
"Blank" <bl...@nowhere.com> wrote in message
news:458171d1$1...@news.kcl.ac.uk...

> Yeah, me too. I'd really like to be able to open multiple files as 'pages'
> in the IDE, or at least to be able to 'collapse' sections and hide them
> from view.

Definitely agreed. I could see having the "source tab" actually open another
little tab bar below it (perhaps?) that allows you to have multiple "pages"
that are part of your "book" (story, game). I think that would fit the
general metaphor that the design interface is going for.

Collapsing would be nice but even if you have that, once your source gets
long, you got spend a lot of time figuring out where your elements are
within all the collapsed and uncollapsed elements. I would agree, though,
that maybe being able to collapse the Volume, Book, Part, Chapter, Section
elements would be nice. (I'm not sure how easy that is to do. In my coding
experience with writing editors, I've found this works best with a Scintilla
editor component. CodeMax or CodeSense -- forget it! Rich Text can do it,
but it's sometimes trickier.)

I usually do what Neil suggested; go to the Index for the relevant elements.
Of course, as your game gets bigger and bigger, that, too, can become a
little unwieldy but I actually like having the Index auto-build itself as it
does.


> I've tried learning TADS T3 ALAN and HUGO and in each case the single
> biggest stumbling block has been that I haven't been able to get the
> compiler to talk to whichever text editor I'm using at the time and get it
> to do that clever business where clicking on the error message jumps you
> to the problem line in the source code.

For what it's worth, I use SourceEdit or TextPad for this (I actually prefer
TextPad) and I've found it works pretty well as far as jumping to lines. In
TextPad, you just have to set the regular expression to match the ouptut you
want. In SourceEdit it's largely the same: just change the Output Pattern
and Tagged Expressions.

- Jeff


Jeff Nyman

unread,
Dec 14, 2006, 2:57:39 PM12/14/06
to
"Jeff Nyman" <jeffnyman_nospam@nospam_gmail.com> wrote in message
news:QKydnZyA86_95RzY...@comcast.com...

> "Blank" <bl...@nowhere.com> wrote in message
> news:458171d1$1...@news.kcl.ac.uk...
>
>> Yeah, me too. I'd really like to be able to open multiple files as
>> 'pages' in the IDE, or at least to be able to 'collapse' sections and
>> hide them from view.

I should probably have added that if you're not using the IDE (and I know,
that's almost considered blasphemy) you can use multiple files. On Windows,
I basically have a batch file that sets everything up for me, in terms of
calling ni.exe and inform-631.exe.

Prior to that, however, I have a line like this:

copy *.ni Source\story.ni

So any *.ni files I have are combined into story.ni and then the compiling
part happens. This works pretty well for me. Of course, you're going to want
to name your *.ni files something that puts them in order.

I just call my ni.bat from TextPad and then I can have as many source files
as I need. Obviously what you give up, though, is the IDE with this
approach. However, my directory structure does match what the Inform IDE
requires so I can always open my game in the IDE when I want to.

Just another thought, for what it is worth.

- Jeff


JDC

unread,
Dec 14, 2006, 3:50:31 PM12/14/06
to

It is also possible to put some of your source into extensions, which
you can then include in your main file. You can open the extension
files in separate windows from the IDE, or even open them with your
favorite text editor separately. Compiler errors may be slightly more
work to track down, but it's not too bad.

One other thing (which I usually forget myself) is that you can display
the source in both sides of the IDE; this can be useful if you want to
copy code from one place to another, or look at earlier code while
writing something new.

Some sort of folding (for sections, say) would probably be nice,
though. And using gvim as the editor in the IDE ;).

-JDC

villagedweller

unread,
Dec 14, 2006, 6:21:23 PM12/14/06
to
All good ideas for working within the current system. Eventually, I'll
give up the IDE and use an editor, but as a newbie, being able to rerun
the code over and over with minor tweaks has been the best way to
figure out how it works. Once I do that, some of the problems will
disappear.

There's still the matter of debugging the code, though, once you put it
all together. And I am still uncertain about using extensions.
Initially, I thought I would just create lots of files by creating
extensions, thus solving all my problems. However, I noticed in several
threads that people who were much more familiar with IF and I7 than I
were saying that there could be only one code file.

That made me wonder if extensions are fundamentally different in some
way that I am missing. So, I decided to just ignore them for the moment
and work on the basics.

Can extensions function just like the project file? If so, shouldn't we
just make multiple files that way?

Andrew Plotkin

unread,
Dec 14, 2006, 6:27:27 PM12/14/06
to
Here, villagedweller <village...@googlemail.com> wrote:
>
> There's still the matter of debugging the code, though, once you put it
> all together. And I am still uncertain about using extensions.
> Initially, I thought I would just create lots of files by creating
> extensions, thus solving all my problems. However, I noticed in several
> threads that people who were much more familiar with IF and I7 than I
> were saying that there could be only one code file.
>
> That made me wonder if extensions are fundamentally different in some
> way that I am missing.

As far as the language, extensions are exactly the same as the main
file.

The IDE is not as handy with extensions. If it encounters an error in
an extension, it won't pop up the source with the offending line
highlighted. It might not even be exact about where the error lies
(although I haven't tried it to be sure).

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

"Bush has kept America safe from terrorism since 9/11." Too bad his
job was to keep America safe *on* 9/11.

Jeff Nyman

unread,
Dec 14, 2006, 8:16:07 PM12/14/06
to
"villagedweller" <village...@googlemail.com> wrote in message
news:1166138483....@80g2000cwy.googlegroups.com...

> Can extensions function just like the project file? If so, shouldn't we
> just make multiple files that way?

I personally find it a little unwieldy, but that's just me. Extensions
aren't meant to be separate parts of your own game source like that and
although they can be used that way, when I tried it I personally found it
more cumbersome to use my own source. That said, if you're dead set on using
the IDE, though, it's probably a better solution than most any other.

For myself, the reason I also like going outside the IDE (beyond having
multiple source files) is that I can set up tools that automatically open
the game in various interpreters like Filfre, Gargoyle, and Windows Frotz,
rather than just the internal Frotz of the Inform 7 IDE. (However, I can
easily imagine a future ability in the IDE to allow creating tools so that
you can do this.)

- Jeff

greg

unread,
Dec 15, 2006, 9:36:07 PM12/15/06
to
Blank wrote:
> Even the superb
> documentation of the Beginners Guide + DM4 wouldn't have been enough in
> the face of the sheer inefficiency of scrolling through the text looking
> for line 3104.

Does your editor have a Go To Line Number command?
If not, you should seriously consider looking for
one that does. Any decent programming-oriented
editor should have such a facility.

--
Greg

Richard Bos

unread,
Dec 17, 2006, 7:52:27 PM12/17/06
to
greg <gr...@cosc.canterbury.ac.nz> wrote:

> Blank wrote:
> > Even the superb
> > documentation of the Beginners Guide + DM4 wouldn't have been enough in
> > the face of the sheer inefficiency of scrolling through the text looking
> > for line 3104.
>
> Does your editor have a Go To Line Number command?

You mean, the one built into the Inform 7 system? No, it doesn't.

Richard

villagedweller

unread,
Dec 17, 2006, 8:02:33 PM12/17/06
to

Well, I7's "jump to" for the project file obviates the need for this.
That part is quite nice. I haven't had a chance to test how it works
with extensions, but from what Zarf said, I would have to scroll
through the code to find the bug.

However, I tend to make a lot of pretty small files, so I'm not sure
that'd really be a problem, for me. Guess it depends on your style.

greg

unread,
Dec 17, 2006, 8:40:41 PM12/17/06
to

No, I meant whatever external editor the OP was having
trouble finding line 3104 in.

If you're staying within the I7 IDE, it should be
able to find the line for you.

--
Greg

villagedweller

unread,
Jan 8, 2007, 5:48:17 PM1/8/07
to

Andrew Plotkin wrote:

> Here, villagedweller <village...@googlemail.com> wrote:
> >
> > There's still the matter of debugging the code, though, once you put it
> > all together. And I am still uncertain about using extensions.
> > Initially, I thought I would just create lots of files by creating
> > extensions, thus solving all my problems. However, I noticed in several
> > threads that people who were much more familiar with IF and I7 than I
> > were saying that there could be only one code file.
> >
> > That made me wonder if extensions are fundamentally different in some
> > way that I am missing.
>
> As far as the language, extensions are exactly the same as the main
> file.
>
> The IDE is not as handy with extensions. If it encounters an error in
> an extension, it won't pop up the source with the offending line
> highlighted. It might not even be exact about where the error lies
> (although I haven't tried it to be sure).
>

I thought I would follow up on this to let everyone know that zarf was
correct about not being able to jump to an error, but it does provide a
full error message that allows you to locate the problem code.

What I am now doing is getting code to a point where it seems to work
with all tests, and then putting it in an extension, to make the
project file easier to read. Doing it this way, I don't have to worry
about the error messages at all, because they only cover syntax issues.
Stable code is likely to break at run-time because of some conflict,
but the project file/extension file distinction doesn't matter for
those cases. So, the only real problem would be if I write new code
that I prefer and somehow conflicts with the old code, it might take
longer to track down. I think...we'll see...

Reply all
Reply to author
Forward
0 new messages