Inform Programming Tips
colyer
start a IF programming tips sort of thing. How's about it, has the
project died or what?
Would any of the more experienced Informers out there be willing to
start up a general Inform programming thread. You know, tips,
clarifications, etc.
Well that's all for now...
Jim
--
#include <std_disclaimer.h> "33"
James E. Colyer INTERNET:col...@nickel.ucs.indiana.edu Lovecraft
\\ "Surfin' the InterNet in style..." Amiga 1000/1200 //
\X/ |/-\| / - \ | / - \ | / - \ \X/
colyer
How does one create such effects as boldface, and underline in Inform
within a line of text.
Where in a Inform program is the best place to put the code for a pretty
title bar?
Thanks
Jim
S.P.Harvey
: I seem to remember a few months (weeks?) back that someone was going to
: start a IF programming tips sort of thing. How's about it, has the
: project died or what?
Jim:
I had posed the idea about, oh two months or so ago. Since then, Graham
has redone the designer's manuals for the v5.4 upgrade, and many of the
niggling little inconsistancies were cleared up. Still not
picture-perfect, but Inform is essential a one-man project, and for my
money, he's doing one hell of a good job.
As for your question on font effects and title bars, I'm afraid I can't
be much help there. I'm forcing myself to stay within the confines of a
version 3 game, which doesn't allow any font changes.
As for general programming tips, I recommend the following:
- print out and digest "Balances", "Toyshop", and "Advent"
these contain about one of everything you'll ever need to construct
- memorize the Designer's manual and do the exercises.
some of the exercises are harder than some of the classes I took at
college, but it pays off.
- print out the verblib.h and parser.h files
these will give you a clear insight into how the parser functions and
how to make it do Stupid Parser Tricks (tm)
- Read "The Craft of the Adventure" by Graham Nelson
an excellent discourse on IF game-design techniques
- also read "Whizzard's Authorship Guide" or something like that
a more tongue-in-cheek (but v.good) guide to game design
- for programming questions, well... you can ask me directly and I'll try,
or post your question on the group for all to see and think about.
Scott
--
----------------------| S.P. Harvey |--------------------------
"Everything I leave behind me, in the way of diaries, manuscripts,
letters, sketches, and so on, to be burned unread."
- last request of Franz Kafka (1883-1924)
----------------------| sha...@interaccess.com |--------------------------
Mathematical Institute, (0865) 2-73525
> Actually I just thought of a couple of questions...
>
> How does one create such effects as boldface, and underline in Inform
> within a line of text.
>
As I remember, style bold; print "Bold!"; style roman; print " and so on ";
and similarly for style underline;
The within a line of text remarks only really apply to going into a
fixed-pitch font mid-line (which might look odd on some machines depending
on how they implement things, but is seldom wanted anyway). Oh, and
if you allow the screen to scroll in inverse video, it may make the new
blank line inverse video too.
> Where in a Inform program is the best place to put the code for a pretty
> title bar?
>
Anywhere you like! I usually gather routines together at the end of the
code, with the first 90% being the objects and their rules, but that's
just me. There's an exercise with a solution provided on how to write
such a title bar routine in the Designer's manual.
> Thanks
>
> Jim
>
Graham Nelson
Oxford, UK
Richard Barnett
I seem to remember a few months (weeks?) back that someone was going to
start a IF programming tips sort of thing. How's about it, has the
project died or what?
Would any of the more experienced Informers out there be willing to
start up a general Inform programming thread. You know, tips,
clarifications, etc.
i've been playing around with inform for a while, and here are
a few tips and a few questions:
tips:
* an object's <describe> routine should return non-zero if it
has printed an appropriate description of the object; other-
wise, it will be listed in the "you can [also] see..." text
(see Locale() in VerbLib.h)
* when coding doors in which the location on one side of the
door may be dark, remember that in this case <location> will
be set to <thedark> & the door's <door_to> and <door_dir>
routines will need to take this into account.
you could implement a routine RealLoc() to take account of
this and enterables
* you can't assign values to <GamePreRoutine>; in particular,
setting it to 0 is a bit fatal (unix zip core dumped on me),
at least at 5.2. i think you're meant to use <player.before>
et al
* to move scenery about (eg an initially-hidden door), use some-
thing like:
object roomOne "room one"
with s_to door;
object roomTwo "room two"
with n_to 0;
object door "door"
with found_in roomOne roomOne,
has scenery;
and on "finding it" in <roomTwo>, execute
move door to roomTwo ! move it to roomTwo for now
door.&found_in-->0 = roomTwo; ! update found_in for future
! moving (see MoveFloatingObjects)
roomTwo.n_to = door; ! **DANGER** (see below)
(this works because MoveFloatingObjects is only run when the
player's location changes, or possibly on a 'look' as well).
this last tip leads me on to the questions
* compiling the door of the last tip as a v3 game produces the
error "object has changed in size between passes"; it
compiles ok as a v5 game. is this something to do with
<long> properties?
* what's the best way of viewing one room from another? (eg
'look down' from a wall could print a description of the base
of the wall) -- is it just to use
PlayerTo(baseOfWall)
<Look>
PlayerTo(topOfWall)
* how do you change the width of general printed text? i've
tried playing around with 0->33, but that just changes the
status line's width
-- richard
--
_______________________________________________________________________________
richard barnett ric...@wg.icl.co.uk
_______________________________________________________________________________
Mathematical Institute, (0865) 2-73525
> In article <CxsCv...@usenet.ucs.indiana.edu> col...@nickel.ucs.indiana.edu (colyer) writes:
>
> I seem to remember a few months (weeks?) back that someone was going to
> start a IF programming tips sort of thing. How's about it, has the
> project died or what?
>
> Would any of the more experienced Informers out there be willing to
> start up a general Inform programming thread. You know, tips,
> clarifications, etc.
>
> i've been playing around with inform for a while, and here are
> a few tips and a few questions:
>
> tips:
>
> * an object's <describe> routine should return non-zero if it
> has printed an appropriate description of the object; other-
> wise, it will be listed in the "you can [also] see..." text
>
> (see Locale() in VerbLib.h)
>
> * when coding doors in which the location on one side of the
> door may be dark, remember that in this case <location> will
> be set to <thedark> & the door's <door_to> and <door_dir>
> routines will need to take this into account.
>
> you could implement a routine RealLoc() to take account of
> this and enterables
>
course you're right.
> * you can't assign values to <GamePreRoutine>; in particular,
> setting it to 0 is a bit fatal (unix zip core dumped on me),
> at least at 5.2. i think you're meant to use <player.before>
> et al
>
Yes you can, but it's not a variable, it's an "entry point" -
in other words, if you want a GamePreRoutine routine, just
code a routine called "GamePreRoutine". Sticking a rule onto
player.before is probably more elegant. (The Adventureland
port has an example of a GamePostRoutine, which is similar.)
> * to move scenery about (eg an initially-hidden door), use some-
> thing like:
>
> object roomOne "room one"
> with s_to door;
>
> object roomTwo "room two"
> with n_to 0;
>
> object door "door"
> with found_in roomOne roomOne,
> has scenery;
>
> and on "finding it" in <roomTwo>, execute
>
> move door to roomTwo ! move it to roomTwo for now
> door.&found_in-->0 = roomTwo; ! update found_in for future
> ! moving (see MoveFloatingObjects)
> roomTwo.n_to = door; ! **DANGER** (see below)
>
> (this works because MoveFloatingObjects is only run when the
> player's location changes, or possibly on a 'look' as well).
>
> this last tip leads me on to the questions
>
> * compiling the door of the last tip as a v3 game produces the
> error "object has changed in size between passes"; it
> compiles ok as a v5 game. is this something to do with
> <long> properties?
>
Would you email me more details? But I suspect this is a slight
library bug which is now removed, actually. The above code is
certainly "morally" correct!
> * what's the best way of viewing one room from another? (eg
> 'look down' from a wall could print a description of the base
> of the wall) -- is it just to use
>
> PlayerTo(baseOfWall)
> <Look>
> PlayerTo(topOfWall)
>
This is probably the simplest way of doing it, yes: though actually
just
PlayerTo(baseOfWall);
PlayerTo(topOfWall, 1);
is enough, as PlayerTo automatically performs a Look unless the second
argument is given as 1.
You might conceivably avoid this by calling certain library
internals directly but I can't actually think why the above wouldn't
be what you want.
> * how do you change the width of general printed text? i've
> tried playing around with 0->33, but that just changes the
> status line's width
>
Ordinarily I'm afraid you can't (not if you want automatic folding
of lines, anyway): indeed the interpreter is at liberty to vary its
width without you knowing (the player might be resizing an X-window,
for instance). Of course you can always print things out in the form
you want explicitly, though that's hardly an elegant solution!
> _______________________________________________________________________________
>
> richard barnett ric...@wg.icl.co.uk
> _______________________________________________________________________________
Graham Nelson
Oxford, UK
Charles Briscoe-Smith
Richard Barnett <ric...@wg.icl.co.uk> wrote:
> * how do you change the width of general printed text? i've
> tried playing around with 0->33, but that just changes the
> status line's width
I don't think this can be done. The text generated by the game is a
continuous stream which is then broken up into lines by the
interpreter. If the interpreter checked the value of 0->33 in the
games header before printing text, it would work, but I don't think
any interpreters do this. Zip doesn't.
So, I think the only way to do it would be to alter the interpreter.
--
Charles Briscoe-Smith
3rd Year student of Computer Science
University of Kent at Canterbury, United Kingdom, European Union.