How To Split Files
Shiny Sword
most of us), but anyway, in the spirit of good design, how do you split
it up? Two approaches come to mind:
#1) Seperate file per type. One file of rooms, one of objects, one of
actors, etc.
#2) Seperate file per room. And each room includes all relevant
defintions--actors, objects, and so on. #2 also supports that awesome
style of using + in your templates.
Let's not start a flame war. Is there a preferred style? Thoughts?
Haarfagre
Shiny Sword:
Some reflections on my own WIP:
I've split the story-file in roughly 8-10 different files:
1. Main .inf with all rooms, objects, grammar definitions and
Initialize.
2. All NPC's
3. Topics (for Ask about)
4-x. Certain large chunks of methods are singled out in their own files
for easier access + Borrowed code (ie: Scenic.h,etc..)
I've not found an ideal way, but this prevents me from drowning in
masses of text while trying to find certain key parts of my code.
Nikos Chantziaras
> #1) Seperate file per type. One file of rooms, one of objects, one of
> actors, etc.
> #2) Seperate file per room. And each room includes all relevant
> defintions--actors, objects, and so on. #2 also supports that awesome
> style of using + in your templates.
#2 seems more natural. It also makes mapping easier. And "+" is a plus. :)
(You're talking about Tads 3, right? Or does Inform also have that "+"
notation?)
Poster
If you look at the source code for Christminster, you'll see that a game
of any real size pretty much has to use multiple files, if only to save
the author from scroll, scroll, scrolling his way to madness. I know I
used 10+ game files for Building (not including library files of course).
Rooms (3 or so areas) -- each with own file
Base classes
Objects in multiple rooms
Memory objects
Main file (which had the statements to include all the others)
Specialty verb grammar
Custom routines
Initialization, daemon, each_turn routines
I'm not at the machine with the source right now, but you get the
picture. Whenever something comprises a large enough section to make
scrolling through it unpleasant, I split it off into its own file.
-- Poster
www.intaligo.com/ -^-^-^- Inform libraries and extensions!
www.intaligo.com/building/ *- B U I L D I N G -* Dark IF.
Andrew Plotkin
> If your IF becomes significantly large enough (not that it will ... for
> most of us), but anyway, in the spirit of good design, how do you split
> it up? Two approaches come to mind:
>
> #1) Seperate file per type. One file of rooms, one of objects, one of
> actors, etc.
> #2) Seperate file per room. And each room includes all relevant
> defintions--actors, objects, and so on. #2 also supports that awesome
> style of using + in your templates.
I always divide up games by area. (Usually a handful of rooms per area
file.) Then there's a separate file for "global" code -- the stuff
which is equally relevant (or irrelevant) to every area.
That just turns out to be the way to minimize the number of times I
have to jump from one file to another.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Ashiq Alibhai
In general, I guess you don't reuse IF code anyway, so whatever makes
it easier to edit is cool.
Poster
Hmm. I do reuse code from game-to-game. That's one of the reasons why
you break code out into separate sections, so that when you need to use
it again, there it is.
Kevin Venzke
"Shiny Sword" <shiny...@gmail.com> wrote in message
news:1135383135.2...@g14g2000cwa.googlegroups.com...
I guess I'm in the minority; I don't see how it makes it easier to
split the source into multiple files. My last game is one 16000-line
file.
My other game had a third of the code split off in an NPC file.
In hindsight I'm not sure why/whether this was useful, though.
I do reuse code, but only code that modifies the library, which I
do put elsewhere.
If I want to find something (using EditPad), I do:
Ctrl+Home (go to top of file)
Ctrl+F (find or replace)
what I want to find
Enter
If I had to find something in a different file, I'd either have to
maneuver to that file, or check the flag under search/replace to
search in all open files.
Kevin Venzke
Mike Snyder
From: "Kevin Venzke" <step...@yahooo.frr>
> I guess I'm in the minority; I don't see how it makes it easier to
> split the source into multiple files. My last game is one 16000-line
> file.
Yikes! Even a small game like Distress has nine source .HUG files, plus two
related to grammar extensions. A larger program, like the point-of-sale
system
written for my day job, has a good 60 or so source files, but IMO most of
these
are too large and should be split into several.
I have no idea how anybody could write just one huge program. Just editing
it
would impact system performance. :)
> My other game had a third of the code split off in an NPC file.
> In hindsight I'm not sure why/whether this was useful, though.
I grew into the concept myself. When I first started writing games, source
code
couldn't be very large anyway, and it was all interpreted BASIC. By the time
I
got to QuickBASIC, it supported multiple source files in a single project,
and I
never looked back. :)
> I do reuse code, but only code that modifies the library, which I
> do put elsewhere.
I group stuff together by usage. Utilities, Objects-A, Object-B, Scenery,
Rooms,
Start-Up, Messages, Miscellaneous, etc. It sometimes helps me know which
parts
of the program have changed, and I can make changes to one area without
thinking
I might have touched the others (even if by accident).
> If I want to find something (using EditPad), I do:
> Ctrl+Home (go to top of file)
> Ctrl+F (find or replace)
> what I want to find
> Enter
>
> If I had to find something in a different file, I'd either have to
> maneuver to that file, or check the flag under search/replace to
> search in all open files.
I tend to use EDIT.COM, if for no other reason than I've used it for so many
years that it's simple to the point of being transparent. Plus, it will open
files at once (selected via ALT+1 ... ALT+9). There are better options, and
one
of these days, I'll go for something else. But, with a quick little batch
file I
can set up things like E1.BAT that opens all the main files, E2.BAT that
opens
all the utilty files, etc.
--- Mike.
L. Ross Raszewski
Really? I find that no matter *how* good your editor is, it's easier
to navigate a bunch of shortish files than to navigate one huge file.
I split my IF source the way I split most of my source.
Heavily-connected code goes together.
For what it's worth, my current project is 73 source files plus the
libraries 39 for the five major geographic areas, 3 for the 3 minor
geographic areas, and the rest for the UI and game mechanics.
Samwyse
> If your IF becomes significantly large enough (not that it will ... for
> most of us), but anyway, in the spirit of good design, how do you split
> it up? Two approaches come to mind:
>
> #1) Seperate file per type. One file of rooms, one of objects, one of
> actors, etc.
> #2) Seperate file per room. And each room includes all relevant
> defintions--actors, objects, and so on. #2 also supports that awesome
> style of using + in your templates.
I have a moderately large work written in Inform. As a professional
programmer, my style may be a bit different from other peoples.
I try really hard to have one file per group of related objects, which
usually works out to one per class. So, I have small (less than 10KB)
but complete files for NPCs, rooms & props, furniture, televisions,
telephones, computers, and a few others. Each has one class definition
(occasionally two or three), some supporting functions, and some grammar
for specialized commands (e.g. TUNE for televisions, DIAL for
telephones). Each file tries to be a complete and separate from the
others, so I can hypothetically re-use them in future works. To that
end, each is written as an Inform extension.
To this, I add a file that was mechanically generated from a map, a
second file for objects that are too complicated to mechanically
generate, and finally, a small master file that defines Initialise and
includes all of the others. The mechanically generated file uses lots
of -> syntax, which is Inform's version of TADS' + syntax. Since I
occasionally re-generate that file, I keep the other objects separate in
that second file, which means I can't use the -> syntax there.
Fortunately, there aren't too many of those objects, so I can keep track
of what goes where fairly easily.
Adam Thornton
Samwyse <sam...@gmail.com> wrote:
>Shiny Sword wrote:
>> If your IF becomes significantly large enough (not that it will ... for
>> most of us), but anyway, in the spirit of good design, how do you split
>> it up? Two approaches come to mind:
>>
>> #1) Seperate file per type. One file of rooms, one of objects, one of
>> actors, etc.
>> #2) Seperate file per room. And each room includes all relevant
>> defintions--actors, objects, and so on. #2 also supports that awesome
>> style of using + in your templates.
I do #1.
>I have a moderately large work written in Inform. As a professional
>programmer, my style may be a bit different from other peoples.
>
>I try really hard to have one file per group of related objects, which
>usually works out to one per class. So, I have small (less than 10KB)
>but complete files for NPCs, rooms & props, furniture, televisions,
>telephones, computers, and a few others. Each has one class definition
>(occasionally two or three), some supporting functions, and some grammar
>for specialized commands (e.g. TUNE for televisions, DIAL for
>telephones). Each file tries to be a complete and separate from the
>others, so I can hypothetically re-use them in future works. To that
>end, each is written as an Inform extension.
This is more formal than what I did in SMTUC, but thematically rather
similar (although I do not try for explicit reuse).
imac-g5-wired:~/Documents/IF/SMTUC adam$ ls -l *.inf
-rw------- 1 adam adam 51036 Oct 5 23:17 smtuc-characters.inf
-rw------- 1 adam adam 34114 Oct 5 23:17 smtuc-characters2.inf
-rw------- 1 adam adam 10977 Oct 5 23:17 smtuc-glk.inf
-rw------- 1 adam adam 12475 Oct 5 23:17 smtuc-infrastructure.inf
-rw------- 1 adam adam 19277 Oct 5 23:17 smtuc-routines.inf
-rw------- 1 adam adam 36731 Oct 5 23:17 smtuc.inf
imac-g5-wired:~/Documents/IF/SMTUC adam$ wc -l *.inf
1502 smtuc-characters.inf
944 smtuc-characters2.inf
328 smtuc-glk.inf
402 smtuc-infrastructure.inf
713 smtuc-routines.inf
1249 smtuc.inf
5138 total
As you can see, one file per category, but I split "Characters" into two
files because it was getting long. I use Emacs as my editor, and a
plain old Unix Makefile to build the game, so I can just compile from
within Emacs.
Adam
Samwyse
> In article <nf1sf.5932$oW....@newssvr11.news.prodigy.com>,
> Samwyse <sam...@gmail.com> wrote:
>>
>>I try really hard to have one file per group of related objects, which
>>usually works out to one per class.
>
> similar (although I do not try for explicit reuse).
Well, I'm not spending time trying to make the classes reusable, but if
in some future work I ever need, say, a television then I've got a good
start already put together that doesn't have to be teased apart from the
telephone.
> As you can see, one file per category, but I split "Characters" into two
> files because it was getting long. I use Emacs as my editor, and a
> plain old Unix Makefile to build the game, so I can just compile from
> within Emacs.
I use a homegrown IDE:
while true
do
vim $1.inf
make $1.z5 && frotz $1.z5
done
Arguably, starting and stopping vim wastes a bit of time, but what-the-hey.
Damian Dollahite
As you can see from the other replies, everyone has their own style for
splitting sources. Myself, I break the sources up into two logical
groups, the system group and the world group.
The system group includes one file for base classes and other low-level
support code; one for parser-related stuff like Topics and VerbRules;
one for Actions classes, default action handlers, library messages,
global action overrides, etc.; and a "stylesheet" containing custom
style tags, global formatting overrides, etc. I wrap these up in a .tl
file instead of adding them to the project directly, so I can keep them
hidden in Workbench's project window.
The world group contains the simulation-level stuff the player actually
sees. I divide the game up into logical regions and give each region
it's own source file (this might not work so well for a spagetti-ball
map like Zork II, but is quite appropriate for maps with natural section
boundaries). Minor NPCs with little behaviour go in the region maps, but
each major NPC gets a source file all to itself, as those quickly reach
code sizes rivaling an entire map region. The PC also gets it's own
file, mainly because it doesn't really "belong" in any of the others
(though in the my current project the PC's source file is getting rather
large as well, because it also includes a pet with a lot of special
behaviour). I also have one extra file where I put important and/or
densely-coded portable objects, one "master" file that includes my
GameInfo and GameMain objects along with any other code related to
startup and shutdown, and a master include file included by every source
file.
The rule for splitting up source files is basically to arrange it so
that you can find what you need as quickly as possible. The arrangement
that best accomplishes that depend on how you personally visualize your
project.
--
Ryukage
rui...@lycos.com
taste) is that any global tweaks -- classes that let you do a bunch of
stuff, the kind of thing like you'd find in the libraries -- should be
seperate from the more specific code. That way, it's easy to find if
you want it again in another game. Over time and multiple, you may end
up with a new library extension of your very own.
Thus progress marches on.