Inform 7 -- Long Ol' Source Code
zyl...@hotmail.com
nuts.
How are people organizing their source *as they write*?
It's easy to see how to do it when you're done. But as you write, I
find Inform's single source code file to be a major annoyance.
I did some searching on the group here and I found talk about using
extensions for your source text but that strikes me as incredibly
clumsy. I tried it just to see and while it does work, sort of, it's
more annyoing than not, at least when your work starts getting pretty
long and involved. Or do people just really like having one
gigantically long piece of source text? I know you can use the Index
but if you use a lot of headings the Index becomes its own issue. Plus
its then just one more thing I have to tab over to if I also use other
tabs.
So anyone who's writing a long game that wants to relate their tips
and tricks for keeping things organized? I was actually doing my own
version of "MockInform", using stubs for some game elements that I
already coded but then took out in the interests of space. That worked
about as well as you'd probably guess.
S. John Ross
> How are people organizing their source *as they write*?
Constantly, but enjoyably :)
I have one opening Volume dedicated to preliminary code that has to come
before the other stuff to prevent compiler confusion. Then the next
Volume is for other foundational code (modifications to common verbs,
that kind of thing). The next volume is dedicated to the
player-character, the next volume to the environment, the next volume to
scenes that aren't specifically attached to a location, and then the
remaining volumes are after-code "support" stuff like the Help menu. In
theory at least, if I ever do a sequel, the way I've got it organized I
should be able to just rip out the environment and scenes volumes and
replace them with new material, while leaving the rest largely intact,
fiddling only at need.
Each volume is (of course) carefully subdivided into
books/chapters/sections as per the regular I7 hierarchy, which makes the
Index a joy to use, since then it behaves a lot like the side-navigation
panel in Word, letting me jump quickly to a heading.
> It's easy to see how to do it when you're done. But as you write, I
> find Inform's single source code file to be a major annoyance.
I've found it almost exactly like writing a longish book, so it's been
fairly comfy and familiar for me. The only disturbing thing about it is
that I get this odd nagging sensation that I could have, in fact,
written another longish book with the effort I've put into it, and that
some of my readers would lynch me if they knew :(
Oh, another thing I'm doing a LOT is writing any long infodumps
separately in Word and saving them 'til I need them (since I fiddle
constantly), and it was a snap to do a Macro that translates normal
paragraphs and punctuation into I7-friendly stuff. I also develop and
keep master-copies of all my tables in Excel.
Zylon
news:PICdnWbILKNS0Yva...@io.com...
> I've found it almost exactly like writing a longish book, so it's been
> fairly comfy and familiar for me.
Yeah, see, this is what I'm trying to reconcile. As I thought on it, if you
were writing a short story or a novella or something, you'd probably just
have one big ol' honkin' Word doc and that usually doesn't cause people
problems. On the other hand, though, you're probably not navigating back as
much into your previous text when writing a book whereas you are with
Inform. Part of the problem for me I think is that I come from a long line
of programming editors that, without exception, allow you to have multiple
files that you can use to segregate your code, which helps compartmentalize
my thinking.
Do other programmer-types face this hurdle with Inform 7? Maybe it's just me
but the ability to break source up into literal separate "sections" rather
than virtual separate sections (demarcated by "headings") is critical. Plus
if I rely on the index that forces me to use a heading structure just to
more easily navigate my code, rather than letting me do what I find
effective.
> Oh, another thing I'm doing a LOT is writing any long infodumps separately
> in Word and saving them 'til I need them (since I fiddle constantly), and
> it was a snap to do a Macro that translates normal paragraphs and
> punctuation into I7-friendly stuff. I also develop and keep master-copies
> of all my tables in Excel.
That's interesting! I'm doing pretty much the same things. I'm finding the
best way to keep the source text bloat down initially is just set up the
most basic aspects of the situation I need. So I might have my room with its
locked door or whatever but I don't include too many descriptions or
anything. I just start writing up the basic puzzle structure that I want to
achieve. (This also works because half the time I'm not even sure I'm going
to be able to do what I want.) I will say I do find this a bit effective
because it means that I don't just rush into giving things descriptions. It
lets me come back later, after I've got implementation down, and really
consider how I want to word things.
I haven't done much with tables yet but I can see the Excel format being a
good approach for that. Handy tip.
S. John Ross
> were writing a short story or a novella or something, you'd probably just
> have one big ol' honkin' Word doc and that usually doesn't cause people
> problems. On the other hand, though, you're probably not navigating back as
> much into your previous text when writing a book whereas you are with
> Inform. Part of the problem for me I think is that I come from a long line
> of programming editors that, without exception, allow you to have multiple
> files that you can use to segregate your code, which helps compartmentalize
> my thinking.
I can grok that. I need that when doing graphic production (When I'm
Quarking or InDesigning, I lay out books in separate chapter files), but
(by luck, I guess) the way Inform looks at the code dovetails
conveniently with the way I usually write.
> That's interesting! I'm doing pretty much the same things. I'm finding the
> best way to keep the source text bloat down initially is just set up the
> most basic aspects of the situation I need. So I might have my room with its
> locked door or whatever but I don't include too many descriptions or
> anything. I just start writing up the basic puzzle structure that I want to
> achieve. (This also works because half the time I'm not even sure I'm going
> to be able to do what I want.) I will say I do find this a bit effective
> because it means that I don't just rush into giving things descriptions. It
> lets me come back later, after I've got implementation down, and really
> consider how I want to word things.
Yeah, same here. I've also fallen in love with being able to separate
large SAY things into ... appendices, I guess. :) Later sections, so I
can have an easy-to-read bit of code that includes things like "say
"[DevilWarning]" and then later in the Book or Chapter, devote a whole
section to how-to-say-devilwarning, which I can revise independently and
still leave the actual code very terse and readable, without any long
blocks of description mucking up the works.
> I haven't done much with tables yet but I can see the Excel format being a
> good approach for that. Handy tip.
It doesn't require macros or any fiddling, either, which is a bonus. If
you arrange it right in the spreadsheeet, you can copy and paste
directly into Inform, and compile a single click later. Very very
useful, especially since the funkiness of tabbing makes large tables
difficult to read directly in the Inform window.
Adam Thornton
<zyl...@hotmail.com> wrote:
>It's easy to see how to do it when you're done. But as you write, I
>find Inform's single source code file to be a major annoyance.
Me too.
I really want code folding. The headings seem to get confused in the
Mac OS IDE fairly regularly, so the heading navigator is not a reliable
guide, and at 72,000 words and counting, it really takes quite a bit of
time to move from one part of the code to another with the scrollbar or
PgUp/PgDn.
If this were I6, I'd have each Volume in its own source file, but it's
not and I don't.
Adam
Zylon
news:e55iu4-...@quicksilver.fsf.net...
>
> I really want code folding.
Yeah ... maybe. My concern with folding though is it can often lead to just
as much work to fold and unfold the parts you want and, with Inform, you'd
still be using the index to navigate around. Now the index would presumably
have to open up the fold when you clicked on something. But what if that
fold contained other folds (or was part of a much larger fold)? Does all
that open up too? Then you're right back where you started. Then I could see
people asking for individual functionality that can "collapse all", "expand
all", "collapse last node", "only open sub-nodes to one depth", etc.
> If this were I6, I'd have each Volume in its own source file, but it's
> not and I don't.
Yup .... and I'd add that each person may like to conceptually break up
their work in some ways. Like, for me, I would like to have general rules in
one source file, new grammar additions in another, etc. and that would be
the case regardless of whether I had them in a "Volume" or not.
Adam Thornton
Zylon <zyl...@hotmail.com> wrote:
>Yeah ... maybe. My concern with folding though is it can often lead to just
>as much work to fold and unfold the parts you want and, with Inform, you'd
>still be using the index to navigate around. Now the index would presumably
>have to open up the fold when you clicked on something. But what if that
>fold contained other folds (or was part of a much larger fold)? Does all
>that open up too? Then you're right back where you started. Then I could see
>people asking for individual functionality that can "collapse all", "expand
>all", "collapse last node", "only open sub-nodes to one depth", etc.
Well, maybe if it were possible to split the main window into more
panes?
You can already put the source in both halves if you really want (which
helps a lot). If I could have three or four sections simultaneously
visible that would help even more.
Adam
Ron Newcomb
As I write, barely. I'm an old-school programmer, from the days of C
#include, who really, really dislikes breaking up my code across
multiple files. Multiple files increases mouse-ing around, which
strains my wrist. Multiple files are harder to keep synced across my
desktop & computer. OO languages frequently have problems with code
"seeing" another file's code. It's just a lot of headache.
I use the IDE's FIND command a lot to hop around. I never nav by
heading because of the mouse-work involved. Command-F and typing is
much faster. I still have yet to learn any shortcut-keys to jump up/
down a heading.
Since I7 is mostly declarative, I try to clump together all the bits
of a code problem I'm working on so I don't have to scroll around so
much. Prose and brainstorming go into a plain text editor's
document(s) and are only copy-pasted into I7 when "done". I only
really start organizing stuff in any fashion after whatever problem is
solved.
I did recently put a few huge chunks of long-ago completed code into
an extension just to get it out of the way. I may start putting some
huge prose chunks into there too for the same reason.
Sections-wise, the biggest sections are typically named something like
Places, People, Verbs, Notable Events, Major New Feature(s), Help/
Hinting, and Technical.
On Oct 17, 11:54 am, "S. John Ross" <sj...@io.com> wrote:
> I've found it almost exactly like writing a longish book, so it's been
> fairly comfy and familiar for me. The only disturbing thing about it is
> that I get this odd nagging sensation that I could have, in fact,
> written another longish book with the effort I've put into it, and that
> some of my readers would lynch me if they knew :(
Hm. Thank you for the insight into a writer's life.
> constantly), and it was a snap to do a Macro that translates normal
> paragraphs and punctuation into I7-friendly stuff.
Now that's what I need! I wonder if SimpleText or TextEdit can do
macros. Thanks for the tip!
Michael Martin
> So anyone who's writing a long game that wants to relate their tips
> and tricks for keeping things organized? I was actually doing my own
> version of "MockInform", using stubs for some game elements that I
> already coded but then took out in the interests of space. That worked
> about as well as you'd probably guess.
My format when writing WS was basically this:
Book I : World model modifications
Part I: New uses for old stuff
Part II: New stuff
Book II: The game
Part 1 - Epsiode 1
(similar for all other episodes)
Book III: Externalities
Part 1 - Hints
Part 2 - Beta testing commands - not for release
WS was very strongly episodic, though, so the layout of Book II
matched this. I also, when setting up maps for each episode, would
usually have Chapter 1 be "the map", with Section 1 being the
connections between the rooms, Section 2 being the descriptions of the
rooms, and Section 3 being scenery in the rooms.
Earlier in the source I'm less systematic about this, and it shows.
--Michael
Zylon
news:1192654323.4...@t8g2000prg.googlegroups.com...
>
> As I write, barely. I'm an old-school programmer, from the days of C
> #include, who really, really dislikes breaking up my code across
> multiple files.
It's funny since this just shows you how we can all have our own tastes.
Like you, I come from the long ago days of just C coding but everything I
did was broken up over multiple source files unless the program I was
working on was very small or, as you indicate, most everything was stored in
libraries.
> Multiple files increases mouse-ing around, which
> strains my wrist. Multiple files are harder to keep synced across my
> desktop & computer. OO languages frequently have problems with code
> "seeing" another file's code. It's just a lot of headache.
There's definitely some truth to this. (Although the only language I've had
trouble seeing another file's code on is Java, with its package structure,
which is often a real pain and one I tend to avoid.) When I worked with TADS
3 I had a bunch of source files but the makefile helps keep track of all
that so you basically just save everything in one directory and only update
the makefile with changes. I would think Inform could have something like
that. The "guts" of how the makefile works could be hidden in the mechanisms
of how I7 compiles. Plus if you use an editor with tabs, there's really not
too much mousing around since all the open source files show up in the same
editor.
> Since I7 is mostly declarative, I try to clump together all the bits
> of a code problem I'm working on so I don't have to scroll around so
> much. Prose and brainstorming go into a plain text editor's
> document(s) and are only copy-pasted into I7 when "done". I only
> really start organizing stuff in any fashion after whatever problem is
> solved.
This is pretty much the approach I've started taking and I suppose it's not
all that bad of one because I've found it does let me concentrate on the
nature of the puzzle or area of the game I want and then later fill that in
with the necessary details. The problem is I would then rather have those
successful sections as part of another file so they're out of sight, but not
out of mind. (Here's were I know the extensions can be used but that just
seems really clunky to me because I have to open the extension to look at it
in a separate interface window.
I don't know. I guess I can see both sides of this issue and I don't
necessarily have a solution. I just feel Inform 7 could do something a
little better in this regard, if for no other reason than to accomodate
people who do work better with multiple source files. Maybe there's a cap on
the number of source files you can use? Like maybe one is a "fold-out" of
the main source panel where you can store code that you want .... you know
... out of sight for now but, again, not out of mind.
To get some historical data, such as it is, I went to the archive and looked
at the source that was available for I6 games and while there were clearly
exceptions, the vast majority of games were made up of multiple source
files. Since I7 may try to cater to people who also wrote in I6, there might
at least be some argument for some provision for this. Likewise, I note
games written in languages like Hugo and TADS 2/3 also tended to have
multiple source files. That would at least suggest people who write text
adventures like this ability since in all those languages the authors
clearly could have written their games in one source file.
Michael Martin
> and tricks for keeping things organized? I was actually doing my own
> version of "MockInform", using stubs for some game elements that I
> already coded but then took out in the interests of space. That worked
> about as well as you'd probably guess.
My format when writing WS was basically this:
isd
> "Adam Thornton" <a...@fsf.net> wrote in message
>
> news:e55iu4-...@quicksilver.fsf.net...
>
>
>
> > I really want code folding.
>
> Yeah ... maybe. My concern with folding though is it can often lead to just
> as much work to fold and unfold the parts you want and, with Inform, you'd
> still be using the index to navigate around. Now the index would presumably
> have to open up the fold when you clicked on something. But what if that
> fold contained other folds (or was part of a much larger fold)? Does all
> that open up too? Then you're right back where you started. Then I could see
> people asking for individual functionality that can "collapse all", "expand
> all", "collapse last node", "only open sub-nodes to one depth", etc.
>
instead of folding I would like a good incremental search accessible
easily with a single key/hotkey/or even Ctrl-F
This may be the faster way to navigate for me... I'd like it
implemented.
Since I always write all my objects and actions definitions at the
place the first time I need them (the first room they appear), I
remember their place well, but I can't access them quickly with the
current IDE design.
George Oliver
>
> instead of folding I would like a good incremental search accessible
> easily with a single key/hotkey/or even Ctrl-F
I'm not sure if this is what you mean, but you can Ctrl-F (in the
Windows I7 at least), and F6 to change the focus of what you're 'Ctrl-
Fing'.
Emily Short
> instead of folding I would like a good incremental search accessible
> easily with a single key/hotkey/or even Ctrl-F
>
> This may be the faster way to navigate for me... I'd like it
> implemented.
The best way to submit a specific feature request is to email it to
Graham; we try to track suggestions made on the newsgroup, but it's
easy to miss things, whereas email can be added into the database of
things to consider.