Programming Perceptions (WAS Absolute EASIEST Game System???)
Michael
easy and difficult IF design systems.
1.) Designing in Inform/TADS and designing in SUDS are both
programming.
I think the general consensus is that if, as Charles pointed out, you
do have to deal with global variables, various events, if/then
conditions, etc. in SUDS, then you are just as much a programmer as
the person writing out lines of code in Inform. The difference is
media.
2.) SUDS can be considered easier, to some, than Inform or TADS
because of its GUI.
Let's consider my first point. Say a beginner programmer wants to
create an if/then condition. Inform's way of doing this is "if (some
condition) {...}" Not really "guessable" if someone were to just dive
in. But in SUDS, you'd go to some menu, and see that option, and,
well, there it is. Now I know many of you are thinking RTFM, which
leads to my next point...
3.) Part of the "friendliness" of SUDS is its tutorials.
I don't know how many out there have actually tried SUDS. I had to
try, given the Easiest System thread. You know what the first thing
you see when you start it up is? It asks you if you want a tutorial.
Tutorials in general are considered by many people to be "easier" than
reading the manual. Consider the trend in mondern computer games.
Instead of providing a big-ass manual for the player to figure how to
play the game, players are given an in-game tutorial. More and more,
people want to just "dive in" for the software to work. Especially
non-programmers. Now, is the tutorial really "easier" than reading
the manual? I'd say, if it's a decent tutorial (I didn't actually go
through the tutorial), yeah. It's dumber, but it's also easier.
Last point. This whole debate relates alot to the Windows vs. *nix
OSes. For people who don't feel like reading the man pages and
figuring out that you need to type ls to get directory contents, it's
easier to just click on the pretty pictures. Many people in the
previous thread complained that SUDS was, in fact, harder to use for
them because of all the menus, but I'd bet they're pretty used to the
command line anyway and/or they didn't really bother to learn SUDS.
Andrew Plotkin
> 2.) SUDS can be considered easier, to some, than Inform or TADS
> because of its GUI.
> Let's consider my first point. Say a beginner programmer wants to
> create an if/then condition.
*Please* consider the distinction that everyone else in this thread
has noted.
2A) Learning to do this task, when you've never done it before, is
easier in <system>.
2B) Doing this task, when you've done it dozens of times before and
you need to do it another dozen right now, is easier in <system>.
> Many people in the previous thread complained that SUDS was, in
> fact, harder to use for them because of all the menus, but I'd bet
> they're pretty used to the command line anyway and/or they didn't
> really bother to learn SUDS.
And I'd bet you're wrong.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Michael Bechard
> Here, Michael <bilgepu...@yahoo.com> wrote:
>
>>2.) SUDS can be considered easier, to some, than Inform or TADS
>>because of its GUI.
>>Let's consider my first point. Say a beginner programmer wants to
>>create an if/then condition.
>
>
> *Please* consider the distinction that everyone else in this thread
> has noted.
>
> 2A) Learning to do this task, when you've never done it before, is
> easier in <system>.
>
> 2B) Doing this task, when you've done it dozens of times before and
> you need to do it another dozen right now, is easier in <system>.
>
Exactly. We're talking about what's easier for BEGINNERS.
Michael Bechard
Also, if you're not a beginner and are used to doing this task in a GUI
environment, it's easier in SUDS.
David Thornley
Michael <bilgepu...@yahoo.com> wrote:
>
>Last point. This whole debate relates alot to the Windows vs. *nix
>OSes. For people who don't feel like reading the man pages and
>figuring out that you need to type ls to get directory contents, it's
>easier to just click on the pretty pictures.
At first.
However, I find it easier to dig into directories with my Linux
machine over a telnet connection than on my Macintosh. With Linux,
I can just type "ls" (and any options I like) and the name of
the directory. If I want to burrow deeper, I can always hit
control-P and add another subdirectory onto the previous command.
On the Mac, I have to look where the thing is on my screen, and
then I have to double-click on it (or single-click on the arrow in
list mode), and I often have to deal with screen management when
I'm just trying to read a frippin' directory to find out what's
there.
The command line is a surprisingly efficient way to enter commands
into a computer. Its primary lack is that it's harder to look up
options than to have an option dialog box pop up. However, if
you've got to do something over and over again, you're better off
with a command line.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
J. J. Guest
> do have to deal with global variables, various events, if/then
> conditions, etc. in SUDS, then you are just as much a programmer as
> the person writing out lines of code in Inform. The difference is
> media.
ADRIFT doesn't have if/then conditions as such, but they can be
simulated by using a sequence of duplicate tasks (tasks with the same
required input) and different restrictions. This system still requires
you to think like a programmer, and as I stated in the previous thread
it is actually harder to program complex conditions in ADRIFT than it
is in TADS (the only other system I have used.) One puzzle in my first
game took three days (and one sleepless night) of head-scratching to
achieve in ADRIFT. I am now re-creating the same game in TADS as an
exercise, and the same puzzle, with proper if/then statements, took
half an hour. I was amazed, and was left wondering why I had been so
afraid to use TADS before. On the other hand, there are ADRIFT users I
know who claim never to have come up against the limitations of the
system. I guess it depends upon the 'style' of games you write.
davidw
"J. J. Guest" <jason...@hotmail.com> wrote in message
news:2782876b.03080...@posting.google.com...
It also depends how you write your games. I spent ages struggling over a
simple conversation system for one ADRIFT game and getting steadily more
frustrated at how nothing seemed to be working right. Turned out I'd missed
a few very basic restrictions out and the thing didn't work the way it was
supposed to. I fixed the restrictions and it worked fine.
Most times when people come along with the old "you can't do this in ADRIFT"
it's more likely to be a lack of understanding of the system on their part
than ADRIFT genuinely not being able to do it.
Seebs
davidw <dav...@shadowvault.net> wrote:
>Most times when people come along with the old "you can't do this in ADRIFT"
>it's more likely to be a lack of understanding of the system on their part
>than ADRIFT genuinely not being able to do it.
Well, "lack of if/then" sounds pretty bad.
-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / se...@plethora.net
http://www.seebs.net/log/ - YA blog. http://www.seebs.net/ - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/
Daniel Barkalow
But a game of any substance is probably going to involve more than 50
if/then conditions, so there will be dozens of them written with the
experience of having written dozens before. It's not useful to have a
system in which a beginner can get started, but in which even the beginner
will get fed up before having completed a game.
If someone is still a beginner when halfway through writing a game, the
system has too much obscure stuff. Otherwise, actually producing a
finished result involves not being a beginner for most of it.
Not to say that SUDS is necessarily not suitable for non-beginners (I
haven't looked at it to know), but this has to be an important
consideration, even when making suggestions for people who are currently
beginners.
-Iabervon
*This .sig unintentionally changed*
Gene Wirchenko
[snip]
>At first.
That does have its value.
>However, I find it easier to dig into directories with my Linux
>machine over a telnet connection than on my Macintosh. With Linux,
>I can just type "ls" (and any options I like) and the name of
>the directory. If I want to burrow deeper, I can always hit
>control-P and add another subdirectory onto the previous command.
>On the Mac, I have to look where the thing is on my screen, and
>then I have to double-click on it (or single-click on the arrow in
>list mode), and I often have to deal with screen management when
>I'm just trying to read a frippin' directory to find out what's
>there.
GUIs can be surprising user-hostile at times. The interface is
always there, even when you wish it would "Just go away, please".
>The command line is a surprisingly efficient way to enter commands
>into a computer. Its primary lack is that it's harder to look up
>options than to have an option dialog box pop up. However, if
dir /?
>you've got to do something over and over again, you're better off
>with a command line.
^^^^^^^^^^^^
ITYM "batch file".
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Michael Vondung
>At first.
It depends on the user. If you've grown up with GUIs, you are likely
to use them efficiently. People work best with the tools they are
familiar with. I've never understood the whole matter of narrow "one
way" advocacy. Individualism is a Good Thing.
>On the Mac, I have to look where the thing is on my screen, and
>then I have to double-click on it (or single-click on the arrow in
>list mode), and I often have to deal with screen management when
>I'm just trying to read a frippin' directory to find out what's
>there.
If you work in a shell, you are more prone to "typos" -- and if you
don't catch it before "ls: /a/misspelled/directory/: No such file or
directory" wakes you up, you waste more time than you would have if
you had performed a misclick in a graphical environment (especially if
you use one of the more primitive shells).
>The command line is a surprisingly efficient way to enter commands
>into a computer.
If you use a bash shell, yes. ;) I don't feel the MS-DOS command line
is particularly efficient.
>However, if
>you've got to do something over and over again, you're better off
>with a command line.
Personally, I'd use a script. Script and batch languages happen to
exist for Windows and Mac, too.
Don't get me wrong, I'm not claiming that GUIs are generally better
than shells (or a CLI) -- there are plenty of tasks that can be done
much easier and more efficiently in a decent shell (did I mention I
like bash?), but that isn't always the case. There are equally plenty
situations where a GUI achieves results faster.
Plus, as stated above, it also depends on the user, her skills and her
background. My not-so-young mother successfully uses a Windows PC, but
the chance is relatively small that she could befriend a FreeBSD
system. Or, perhaps more importantly, that she would even -want- to
work on a "plain" Unix platform.
-M.
KF
>
> Well, "lack of if/then" sounds pretty bad.
>
> -s
It sounds bad, but doesn't actually take into account the fact that a
task will run if (this restriction or that restriction) and the other
restriction are true, just not put in that way.
Seebs
KF <kf_a...@hotmail.com> wrote:
>It sounds bad, but doesn't actually take into account the fact that a
>task will run if (this restriction or that restriction) and the other
>restriction are true, just not put in that way.
Okay, I'm a bit curious now.
Let's take a pretty typical bit of Inform code.
print "You are looking at locker number ", self.number,
", which is ";
if (self has general) {
print "locked";
} else {
print "unlocked";
}
".";
How do I do this in a language which doesn't have an if/then?
It sounds like it's something like (no idea how to format it, so
approximating)
task print_locked_if_general
restriction: object has general
print "locked"
end task
task print_unlocked_if_not_general
restriction: object does not have general
print "unlocked"
end task
print "You are looking at..."
print_locked_if_general
print_unlocked_if_general
Is that about right?
davidw
"Seebs" <se...@plethora.net> wrote in message
news:3f2bf100$0$1099$3c09...@news.plethora.net...
I'd probably do it with a task, a variable and the ALR. Create a variable
called "locker" and set it to 0. Have a task called "x locker" which
displays "You look at the locker and see it is locker%locker%." In the ALR
you'd have:
locker0|locked.
locker1|open.
Whatever is typed on the right hand side of the | replaces the text on the
left hand side. In the case of locker%locker% this would display "locked" if
the locker variable was 0 and "open" if the locker variable was 1. Now if
you had a task which opened the locker, you'd set the locker variable to 1
and if you subsequently close the locker the variable is set back to 0.
Of course, it's a lot easier to create an object called "locker" and set its
state to closed but the above example allows for a lot for leeway.
Hey, that looks suspiciously like programming in ADRIFT! Now there's a weird
thought...
Seebs
davidw <dav...@shadowvault.net> wrote:
>I'd probably do it with a task, a variable and the ALR. Create a variable
>called "locker" and set it to 0. Have a task called "x locker" which
>displays "You look at the locker and see it is locker%locker%." In the ALR
>you'd have:
>locker0|locked.
>locker1|open.
>Whatever is typed on the right hand side of the | replaces the text on the
>left hand side. In the case of locker%locker% this would display "locked" if
>the locker variable was 0 and "open" if the locker variable was 1. Now if
>you had a task which opened the locker, you'd set the locker variable to 1
>and if you subsequently close the locker the variable is set back to 0.
Hmm. So, basically, for each string I might have that depends on this
state, I need to make a pair of variables.
The thing is, in my actual program, I have maybe 15 messages which depend
on the state of the locker.
>Of course, it's a lot easier to create an object called "locker" and set its
>state to closed but the above example allows for a lot for leeway.
Ahh, but the locker isn't really closed. My object "Locker" represents a bank
of 250 lockers, all but one of which are just simulated through clever
trickery.
e.g.:
LetGo:
switch (self.number) {
! other special cases up here, which I don't mention here because
! they're spoilers
251:
! The player's real locker. Normal library functions.
rfalse;
default:
if (self has general) {
"You can't take anything out of a locker which is currently
closed.";
} else {
"There's nothing in the unused locker."
}
}
Receive:
switch (self.number) {
! other special cases up here, which I don't mention here because
! they're spoilers
251:
! The player's real locker. Normal library functions.
rfalse;
default:
if (self has general) {
"You can't put anything into a locker which is currently
closed.";
} else {
"It would be foolhardy at best to store things in a locker
you can't even lock.";
}
}
and so on.
It really sounds like the lack of control structures would start hampering
my style after a while; I like to check for every possible circumstance
and deal with it as cleanly as possible.
J. J. Guest
No, in ADRIFT every object has an atributes tab in which it is
possible to select (using check boxes)whether an object is edible,
wearable, or is a container, etc. If it is a container you can select
whether it is openable, and if so whether it is lockable. A piece of
text describing whether that object is opened, closed or locked
appears *automatically* as part of the description when the object is
examined.
davidw
Okay. So you could have:
locker0|You examine the locker and see nothing special.
locker1|You examine the locker and see it standing open, its contents
displayed for the world to see.
>
> It really sounds like the lack of control structures would start hampering
> my style after a while; I like to check for every possible circumstance
> and deal with it as cleanly as possible.
>
I suppose the question that's begging to be asked here is: why would you
need 250 lockers? Would you expect the player to try and examine each and
every one of them?
Assuming you *did* want 250 lockers, you could simulate the dummy 249
lockers with tasks. One task would be the one that examined the sole
important locker and the other task would deal with the 249 unimportant
ones. Have a task called "x *locker" which displays "You examine the locker
and see nothing special." The * is a wildcard and ADRIFT ignores whatever is
typed there. So "x *locker" could work as "x the first locker", "x the
second locker" and so on.
Seebs
davidw <dav...@shadowvault.net> wrote:
>locker0|You examine the locker and see nothing special.
>locker1|You examine the locker and see it standing open, its contents
>displayed for the world to see.
So, I have to make an object like that for every combination of locker
and action... Hmm.
>I suppose the question that's begging to be asked here is: why would you
>need 250 lockers? Would you expect the player to try and examine each and
>every one of them?
Because I like to simulate my world *completely*.
>Assuming you *did* want 250 lockers, you could simulate the dummy 249
>lockers with tasks. One task would be the one that examined the sole
>important locker and the other task would deal with the 249 unimportant
>ones. Have a task called "x *locker" which displays "You examine the locker
>and see nothing special." The * is a wildcard and ADRIFT ignores whatever is
>typed there. So "x *locker" could work as "x the first locker", "x the
>second locker" and so on.
But that's not what I want. I want to correctly do things like
>x locker 23
[actually looks at locker 23]
>x locker 253
The lockers are numbered from 1 to 250.
>x locker 27
[looks at locker 27]
>x next locker
[looks at locker 28]
I want, in other words, to let the user do anything *remotely plausible*,
and have the game always respond intelligently. I don't want to have
a wildcard parser that allows abject nonsense without comment.
Seebs
J. J. Guest <jason...@hotmail.com> wrote:
>No, in ADRIFT every object has an atributes tab in which it is
>possible to select (using check boxes)whether an object is edible,
>wearable, or is a container, etc. If it is a container you can select
>whether it is openable, and if so whether it is lockable. A piece of
>text describing whether that object is opened, closed or locked
>appears *automatically* as part of the description when the object is
>examined.
You miss the point. This is a single object which *PRETENDS* to be each
of 250 lockers, some of which are locked, some of which are not. The object
itself is not what I'm checking when I print whether or not it's "locked".
J. J. Guest
> In article <2782876b.03080...@posting.google.com>,
> J. J. Guest <jason...@hotmail.com> wrote:
> >No, in ADRIFT every object has an atributes tab in which it is
> >possible to select (using check boxes)whether an object is edible,
> >wearable, or is a container, etc. If it is a container you can select
> >whether it is openable, and if so whether it is lockable. A piece of
> >text describing whether that object is opened, closed or locked
> >appears *automatically* as part of the description when the object is
> >examined.
>
> You miss the point. This is a single object which *PRETENDS* to be each
> of 250 lockers, some of which are locked, some of which are not. The object
> itself is not what I'm checking when I print whether or not it's "locked".
>
> -s
Well, that would be pretty difficult to implement in ADRIFT. I
wouldn't even attempt it. I have a puzzle in my new game that involves
numbered objects, and I couldn't find any way to do it in ADRIFT, so I
re-wrote the whole game in TADS.
davidw
> I want, in other words, to let the user do anything *remotely plausible*,
> and have the game always respond intelligently. I don't want to have
> a wildcard parser that allows abject nonsense without comment.
>
Easy. You'd create a variable called "locker" and set it to 0. Create a task
called "x locker*" and have it display "You examine locker %number% and see
nothing special." In the action part of the task have it change the variable
"locker" to expression %number%. This would then display:
> x locker 2
You examine locker 2 and see nothing special.
> x locker 95
You examine locker 95 and see nothing special.
> x locker 211
You examine locker 211 and see nothing special.
You could even have different responses by placing "You examine locker
%number% and see nothing special." in the ALR.
Michael Bechard
>>Exactly. We're talking about what's easier for BEGINNERS.
>
>
> But a game of any substance is probably going to involve more than 50
> if/then conditions, so there will be dozens of them written with the
> experience of having written dozens before. It's not useful to have a
> system in which a beginner can get started, but in which even the beginner
> will get fed up before having completed a game.
>
> If someone is still a beginner when halfway through writing a game, the
> system has too much obscure stuff. Otherwise, actually producing a
> finished result involves not being a beginner for most of it.
>
> Not to say that SUDS is necessarily not suitable for non-beginners (I
> haven't looked at it to know), but this has to be an important
> consideration, even when making suggestions for people who are currently
> beginners.
>
> -Iabervon
> *This .sig unintentionally changed*
>
I actually don't think SUDS is only for beginners; I shouldn't have
replied so soon to Andrews reply, and I tried to clarify this in a
followup to my own post.
If you're used to programming in SUDS, the you're going to be used to
doing if/then statements in it. 50 if/then statements in SUDS will be
easy for someone who's used to that system. Therefore, you can have an
"expert" IF programmer who uses SUDS and is perfectly happy with it.
It really all depends on what you're used to. And if you're a newbie to
IF, I think SUDS is a little easier to get into (see original post).
Charles A. Smith
news:ox9Xa.95610$X43....@clmboh1-nws5.columbus.rr.com...
visitors understand the limitations of each program as the writer/programmer
moves up in ease of use. I found SUDS to be incredibly rich in complexity
and fairly easy to use (once the role of "procedures" is fully understood)
but within its own constraints. I would have no problem encouraging anyone
to try SUDS as long as they understood what they were giving up (and
gaining). As I said before, any storyteller who places a high value on
character development through conversations will be in hog heaven with SUDS.
But there is no parser, so the reader is operating within the constraints of
the program. SUDS certainly reduces the frustration of readers who input
logical text into a parser-based program and get an error message.
All IF has constraints. SUDS makes them explicit. INFORM and TADS engage the
reader in a guessing game (what does the writer want me to say here so I can
make something happen).
Eventually, the constraints of SUDS and its limitations on the kinds of
actions offered to a reader is going to frustrate writers who want to
continue creating. That's my case. If SUDS had twice the hard coded actions
it offers, I might still be using it. Andy Elliot (creator of SUDS) is a
top-notch guy. Because he is no longer actively involved in updating the
program is another reason for me to move away from SUDS. I still marvel at
what he created and enjoyed the many hours I invested in programming Snow
Night.
So I'm moving up the complexity ladder by learning to use QUEST. The support
is excellent and I like the Windows interface. Eventually, as I become more
proficient, I'll stop using QDK and go directly to the underlying code. If I
find QUEST to be too constraining some day, I might be sufficiently grown up
to move to TADS. On the other hand, growing up with QUEST sounds fine to me
now.
Chuck Smith
Seebs
davidw <dav...@shadowvault.net> wrote:
>Easy. You'd create a variable called "locker" and set it to 0. Create a task
>called "x locker*" and have it display "You examine locker %number% and see
>nothing special." In the action part of the task have it change the variable
>"locker" to expression %number%. This would then display:
How do I make it correctly catch invalid locker names? e.g., how do I tell
it that "x locker 251" is invalid? Worse, what if there are special cases;
perhaps I'm a math geek, and I want to support
locker i
not to mention
my locker
Furthermore, I want to be able to have some of the 250 unused lockers appear
to be locked, and react as such, and others appear to be unlocked and open,
and react as such.
davidw
> In article <bS4Xa.52342$9C6.3...@wards.force9.net>,
> davidw <dav...@shadowvault.net> wrote:
> >Easy. You'd create a variable called "locker" and set it to 0. Create a
task
> >called "x locker*" and have it display "You examine locker %number% and
see
> >nothing special." In the action part of the task have it change the
variable
> >"locker" to expression %number%. This would then display:
>
> How do I make it correctly catch invalid locker names? e.g., how do I
tell
> it that "x locker 251" is invalid?
Have a restriction that the referenced number must be less than 251 or it
displays "There are only 250 lockers so you can't examine locker number
%number%." The bit in %% being whatever you tried to type, i.e. anything
from 251 onwards.
>
> Furthermore, I want to be able to have some of the 250 unused lockers
appear
> to be locked, and react as such, and others appear to be unlocked and
open,
> and react as such.
You *could* handle this with variables if you really wanted but it might not
work properly. In all honesty it sounds like more trouble than it's worth
unless you're planning on having a game devoted to the player opening 250
lockers.
Seebs
davidw <dav...@shadowvault.net> wrote:
>You *could* handle this with variables if you really wanted but it might not
>work properly. In all honesty it sounds like more trouble than it's worth
>unless you're planning on having a game devoted to the player opening 250
>lockers.
In other words, Adrift makes it prohibitively time-consuming to build
complicated things.
I guess that's sort of the point, no?
I suspect that my current project would be simply impractical to build *at
all* in Adrift. Unfortunately, descriptions of many of the things that are
technically interesting about it are probably spoilers, but to give a few
examples of things I'm currently doing:
* Most room descriptions are dynamically generated, and change
depending on circumstances.
* Many characters have long and involved conversations with each
other, but the game checks to make sure that someone isn't in two
conversations at once (normally, anyway).
* The rules of behavior for a given character may be changed
dramatically.
* There's at least one bug in the game which can be corrected from
within the game.
* As noted, a bank of 250 lockers, all of which appear to be, and act
like, unique objects.
* A variety of NPCs, using Inform's class/inheritance rules to define
rules for "proprietors" in only one place, implementing all of the
varied and different stores in the game in one common chunk of code.
* A room in which the game counts every word used to describe the
room or the NPC in it, and sends you a bill when you leave the room.
* A room which correctly indicates which door you came in through.
* Perhaps 40 or so locations which are generated dynamically by a
single piece of code.
* Dozens and dozens of conditional behaviors which change things only
slightly depending on input conditions.
Maybe it could be done, but right now, if I want to change the descriptions
of the 25 most-commonly-used locations, all of which share common traits, I
change *exactly one piece of code*. I do not have to cut and paste. It
sounds like I'd probably have to do some pretty complicated stuff to get these
results in Adrift.
(For the curious: Yes, the above are all in one game, and I'm omitting the
stuff I think would be spoilers. This game *MIGHT* be released in 2004.)
Mark J. Tilford
I doubt that the intention is to make the player go through all 250 by
brute force; instead, there's probably going to be a puzzle of figuring
the number out. Maybe it's just a matter of looking the appropriate
person up in the diretory. Maybe the player has to get the locker's owner
to put a ticking clock into it and then listen to see which locker makes
noise.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
davidw
> Maybe it could be done, but right now, if I want to change the
descriptions
> of the 25 most-commonly-used locations, all of which share common traits,
I
> change *exactly one piece of code*. I do not have to cut and paste. It
> sounds like I'd probably have to do some pretty complicated stuff to get
these
> results in Adrift.
>
> (For the curious: Yes, the above are all in one game, and I'm omitting
the
> stuff I think would be spoilers. This game *MIGHT* be released in 2004.)
Sounds like the sort of epic-sized game that dozens of people start to make
and then lose interest partway through. I probably would myself. My latest
game I've been working on since April and I expect to have it done by the
end of August and I think that's more than long enough to spend working on
*any* game.
Seebs
davidw <dav...@shadowvault.net> wrote:
>Sounds like the sort of epic-sized game that dozens of people start to make
>and then lose interest partway through. I probably would myself. My latest
>game I've been working on since April and I expect to have it done by the
>end of August and I think that's more than long enough to spend working on
>*any* game.
Depends. Janitor was occasional work over a period of close to a year, but
there were whole months during which nothing got done.
The new game has a staff of two, and we expect it to take a few months to get
to the point where most of the stuff is in place, a few months for basic
alpha-testing, and then a couple months of beta testing.
If we ignore the first few rooms and the refrigerator, Janitor was done on an
April-September time frame, just in time for IfComp 2002. It's fairly
complex and detailed, as such things go.
Note that we actually plan to revisit it, and fill in some of the "wouldn't it
be nice if..." things. I may even let people carry the portable mimesis
generator around through the entire game and play with it.
But no, the game described in the previous message isn't prarticularly epic,
and we don't expect to use dozens of people. I'd guess it's between two and
three times the size of Janitor; *maybe* four. But it *does* have a lot of
coding in it that really requires a full-fledged programming language, just
as Janitor did.
Seebs
Mark J. Tilford <til...@ugcs.caltech.edu> wrote:
>I doubt that the intention is to make the player go through all 250 by
>brute force; instead, there's probably going to be a puzzle of figuring
>the number out. Maybe it's just a matter of looking the appropriate
>person up in the diretory. Maybe the player has to get the locker's owner
>to put a ticking clock into it and then listen to see which locker makes
>noise.
Oh, nothing so complicated.
> unlock my locker
I kid you not.
Quintin Stone
> Sounds like the sort of epic-sized game that dozens of people start to
> make and then lose interest partway through. I probably would myself. My
> latest game I've been working on since April and I expect to have it
> done by the end of August and I think that's more than long enough to
> spend working on *any* game.
But does that include extensive beta testing and the fixing of the
problems they find? That's what really adds the time.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
Seebs
>and then lose interest partway through. I probably would myself.
I just realized, this clearly highlights the difference in approaches:
A good, structured language - frankly, more OO than anything - like Inform
makes this project *much smaller* than you probably think it would be. I've
put in maybe ten or twenty hours on building the framework I'm using now.
That's nothing; a few trips to a coffee shop spent sitting around with my
coauthor debating the best way to present a scene, mostly.
John Colagioia
news:3f2ab7b1$0$1100$3c09...@news.plethora.net:
> davidw <dav...@shadowvault.net> wrote:
>>Most times when people come along with the old "you can't do this in
>>ADRIFT" it's more likely to be a lack of understanding of the system
>>on their part than ADRIFT genuinely not being able to do it.
> Well, "lack of if/then" sounds pretty bad.
My limited experience with ADRIFT tells me that it has conditional
statements, but just doesn't call then "if/then."
It strikes me as doing everything (including, sometimes, parsing) in
an Inform react_before() Routine property, or maybe COBOL or SQL
"whenever" statements.
So, you might (in Inform) have an object that accompanies the player,
with a react_before() that catches parsing errors and "recovers" from
them by enacting the proper sequence of events.
I guess you could call ADRIFT "event-driven programming," and not be
far from the truth.
30otsix
> In article <2782876b.03080...@posting.google.com>,
> J. J. Guest <jason...@hotmail.com> wrote:
> >No, in ADRIFT every object has an atributes tab in which it is
> >possible to select (using check boxes)whether an object is edible,
> >wearable, or is a container, etc. If it is a container you can select
> >whether it is openable, and if so whether it is lockable. A piece of
> >text describing whether that object is opened, closed or locked
> >appears *automatically* as part of the description when the object is
> >examined.
>
> You miss the point. This is a single object which *PRETENDS* to be each
> of 250 lockers, some of which are locked, some of which are not. The object
> itself is not what I'm checking when I print whether or not it's "locked".
>
> -s
Perhaps if you could provide us with all the desired functionality of
the "lockers" along with the desired output for each anticipated
input, we could better show you how Adrift could (if at all)
accomplish this. I may be the only one, but I am having trouble
following how these "lockers" work from your descriptions.
If all you want is a wall of lockers that can be referred to by
number, some of which are locked, only one is yours, and can be open
with the input "Open my locker". This can be done fairly easily in
Adrift. But I believe there is more to it than that and I am just
missing it.
30
Seebs
30otsix <30o...@tsconnects.com> wrote:
>Perhaps if you could provide us with all the desired functionality of
>the "lockers" along with the desired output for each anticipated
>input, we could better show you how Adrift could (if at all)
>accomplish this. I may be the only one, but I am having trouble
>following how these "lockers" work from your descriptions.
The idea is this:
1. There are 250 lockers. About half of them are locked, and cannot
be opened by the player; about half are opened. None of them can be used,
*except* the one locker which is yours.
2. However, all of them provide meaningful responses to interaction.
3. Which one is "yours" may vary depending on circumstances.
4. You can refer to your locker as "my locker" or as "locker N", where N
is the specific number assigned to you.
5. Your locker opens and closes normally, and stuff can be kept in it.
6. Things like "next locker" or "previous locker" work correctly - including
the case where you do
> x my locker
You are looking at your locker, #215. It is open.
> x prev locker
You are looking at locker #214. It is open.
> x prev locker
You are looking at locker #213. It is closed.
7. Correct handling of boundaries:
> x locker 251
The lockers are numbered from 1 to 250.
> x locker 250
You are looking at locker #250. It is open.
> x next locker
There is not currently a "next" locker.
8. Works for all verbs, even new ones I haven't defined yet, automatically
because the game's standardized parser will generate sensible defaults.
>If all you want is a wall of lockers that can be referred to by
>number, some of which are locked, only one is yours, and can be open
>with the input "Open my locker". This can be done fairly easily in
>Adrift. But I believe there is more to it than that and I am just
>missing it.
Basically, I want it to be *impossible* for a player to tell whether or not
the other 249 lockers are "real" objects or just partially implemented. And
I've done it (mostly) in Inform, in maybe an hour and a half of futzing around
- it would have gone faster had I been paying more attention.
To get a feel for the kinds of things I do, check out the access
doors in Janitor. My current project is more technically interesting
than Janitor was. I do a lot of magic; I'm using Inform's inheritance
rules pretty heavily to provide for NPC's, some of whom are
proprietors - and at least one of whom can become the PC!
For best results, play around with the interactions of the mop and the dead
light bulb in Janitor. Maybe you can do stuff like that in Adrift, but it was
*EASY* in Inform.
J. J. Guest
I don't doubt that someone with enormous reserves of patience could
put something like this together in ADRIFT, but it would involve a
huge number of conditional tasks and hundreds of variables. As I said
before, I wouldn't even attempt it. A game I'm working on at the
moment has something similar. I started it in ADRIFT but switched to
TADS when I realised how difficult the puzzle would be to implement.
Seebs
>put something like this together in ADRIFT, but it would involve a
>huge number of conditional tasks and hundreds of variables. As I said
>before, I wouldn't even attempt it. A game I'm working on at the
>moment has something similar. I started it in ADRIFT but switched to
>TADS when I realised how difficult the puzzle would be to implement.
Well, as another example, consider the code in Flat to produce the warning
lights. Conditional operations nested many deep. One big fat section of
code. It's just under 100 lines. Sample code:
if (GloveCompartment has open) {
if (child(GloveCompartment))
"A periwinkle pigeon light flashes on the dashboard.";
}
if (Map notin GloveCompartment) {
print "An indigo ibex light flashes on the dashboard.^";
if (Map.folded == 2) {
if (Safety has on) {
"Immediately after the ibex flashes, an amber armadillo light
flashes urgently.";
}
}
rtrue;
}
In almost every case, after a possible error is detected, the routine stops.
So far as I can tell, in Adrift, I'd have to do something like:
Set a variable to zero
Have each task include a requirement that the variable is not
currently set to one.
Write about forty different tasks, each of which conditionally prints
a message and then sets the variable to one.
The manual was a lot of fun, though:
'puce', 'pig':
"The puce pig light indicates that you are trying to drive the
car while sitting on the right side, and you are not in the
United Kingdom. Please push the car manually to the United
Kingdom and try again.";
Handorobou
do any serious authoring--its interpreter is in great need of repair!
Over half of the bug reports coming back from my testers for a game I
recently wrote have turned out to be the fault of the interpreter.
J. J. Guest
What exactly is your point? As I said in several previous posts, the
locker problem would be extremely difficult to implement in ADRIFT.
There's no disputing that. The above problem would also be extremely
difficult to implement in ADRIFT. Yes, it would more than likely
require forty or more tasks. So what? Do you have nothing better to do
than sit at home and come up with things that can't be done in ADRIFT?
What exactly are you trying to prove, other than your own cleverness?
And how many cars do you know that have a light indicating when
there's no map in the glovebox? Do you have a light on top of your
head that indicates when you're about to be annoying? If not, you
should think about getting one.
Seebs
J. J. Guest <jason...@hotmail.com> wrote:
>What exactly is your point?
That "lack of if/then is a crippling weakness in a language".
>difficult to implement in ADRIFT. Yes, it would more than likely
>require forty or more tasks. So what? Do you have nothing better to do
>than sit at home and come up with things that can't be done in ADRIFT?
The above was something I came up with *the first time I thought of a
game*.
>What exactly are you trying to prove, other than your own cleverness?
That omitting basic flow constructs from a language doesn't make it easy
to use, it makes it *impossible* to use.
>And how many cars do you know that have a light indicating when
>there's no map in the glovebox? Do you have a light on top of your
>head that indicates when you're about to be annoying? If not, you
>should think about getting one.
It's IF. It's not always supposed to be realistic. It's *fun*.
davidw
>
> That "lack of if/then is a crippling weakness in a language".
>
As I proved in an earlier post, there are ways around this with Adrift that
are very easy to use (task restrictions). If you choose to ignore them just
to try and prove your point that's your problem.
The fact of the matter is that 99% of what you can do in Tads or Inform or
Hugo you could do in Adrift. Maybe there are some things that are impossible
in Adrift but of all the examples you listed, none of them are things I've
ever seen in a text adventure or would ever want to. A game involving 250
lockers which might (or might not) be open and might (or might not) be
closed and might (or might not) contain items strikes me as the biggest
yawnfest I've ever come across. Maybe you couldn't do this in Adrift but
then in all honesty why would you even want to?
But if it makes you feel better to spend all your time coming up with
pointless things that wouldn't be possible in Adrift you go for it.
J. J. Guest
> In article <2782876b.03080...@posting.google.com>,
> J. J. Guest <jason...@hotmail.com> wrote:
> >What exactly is your point?
>
> That "lack of if/then is a crippling weakness in a language".
>
> >difficult to implement in ADRIFT. Yes, it would more than likely
> >require forty or more tasks. So what? Do you have nothing better to do
> >than sit at home and come up with things that can't be done in ADRIFT?
>
> The above was something I came up with *the first time I thought of a
> game*.
>
> >What exactly are you trying to prove, other than your own cleverness?
>
> That omitting basic flow constructs from a language doesn't make it easy
> to use, it makes it *impossible* to use.
>
> >And how many cars do you know that have a light indicating when
> >there's no map in the glovebox? Do you have a light on top of your
> >head that indicates when you're about to be annoying? If not, you
> >should think about getting one.
>
> It's IF. It's not always supposed to be realistic. It's *fun*.
>
> -s
Sorry! Was in a bad mood last night for reasons totally unrelated to
IF, and you kind of got caught in the crossfire. Of course IF is
supposed to be fun; I didn't mean to be nasty. And your code is
perfectly valid as an example of something very difficult to do in
ADRIFT. The thing about ADRIFT is that it was the first IF creation
medium I came across, and at the time I had no idea there was this
huge community of people making adventure games. I used it happily for
a year and a half without ever considering any of the alternatives and
simply learned to work within its limitations. Eventually however, the
limitations (and the backward-compatibility problems) became
frustrating and I realised it was time to move on. I used to write
text adventures in BBC Basic as a kid so I'm picking up TADS quite
quickly. It certainly isn't *impossible* to write games using ADRIFT,
as many loyal users will attest, but as one former user put it, ADRIFT
is a template, not a language, and as soon as one tries to do
something not envisaged by its author, Campbell Wild, you quickly run
into problems.
L. Ross Raszewski
>As I proved in an earlier post, there are ways around this with Adrift that
>are very easy to use (task restrictions). If you choose to ignore them just
>to try and prove your point that's your problem.
>
>yawnfest I've ever come across. Maybe you couldn't do this in Adrift but
>then in all honesty why would you even want to?
He's already said multiple times that this is something he actually
wanted to do in a game. Are you sure it's a case of "we're trying to
come up with contrived examples of what you can't do in Adrift, when
all these things are things you'd never really want to do in IF
anyway" and not, as seems much more likely to me, "You are bending
over backwards to declare any of the myriad things you can't do in
Adrift to be contrived examples so as to avoid admitting that Adrift
isn't a very powerful IF language"?
Seebs
davidw <dav...@shadowvault.net> wrote:
>"Seebs" <se...@plethora.net> wrote in message
>news:3f35b1a6$0$1099$3c09...@news.plethora.net...
>> That "lack of if/then is a crippling weakness in a language".
>As I proved in an earlier post, there are ways around this with Adrift that
>are very easy to use (task restrictions). If you choose to ignore them just
>to try and prove your point that's your problem.
Will you guys make up your mind? The other guy admitted cheerfully that
it would be incredibly annoying and impractical to do this in Adrift.
Is it *possible*? Yes.
Is it "easy to use"? It's easy to use the same way a blunt stick is an easier
digging tool than a backhoe. Less training, but you can't *do* much with it.
>The fact of the matter is that 99% of what you can do in Tads or Inform or
>Hugo you could do in Adrift. Maybe there are some things that are impossible
>in Adrift but of all the examples you listed, none of them are things I've
>ever seen in a text adventure or would ever want to.
Well, okay, tell me how we do something like Janitor's doors in Adrift. Maybe
you personally don't like it, but I think it's clear that it's an interesting
feature for a game.
>A game involving 250
>lockers which might (or might not) be open and might (or might not) be
>closed and might (or might not) contain items strikes me as the biggest
>yawnfest I've ever come across. Maybe you couldn't do this in Adrift but
>then in all honesty why would you even want to?
I don't think you get it. This is just a single scenery object in one of the
hundred or so rooms. It's not what the game is *about*.
This is what we call "craftsmanship". Even though it's just a bit of scenery
in one room, and most of it is irrelevant, I want to implement it correctly
*ANYWAY*.
The point is not that the user has any particular reason to look at the other
lockers; the point is that, if the user happens to think it'd be interesting
to do so, the user should not get responses which make it obvious that this
is just a game, not a proper simulation of the world.
>But if it makes you feel better to spend all your time coming up with
>pointless things that wouldn't be possible in Adrift you go for it.
With a few exceptions, I doubt they're impossible; they're just *prohibitively
annoying*. That's the point; Adrift makes these tasks much harder than they
need to be, and as a result, they sound like "too much work" to you, and they
sound like "ordinary basic craftsmanship" to me. Net result? Inform games
are easier to polish. Net result? Better games.
Basic flow constructs are a huge convenience to the user. When a fairly
simple chunk of code in Inform becomes 40 "tasks" in Adrift, the user is
being discouraged from trying to write that program, *even if it's a good
story*. It's being made *too hard*. Not providing them is silly. Every
language, no matter how trivial, should always provide basic flow constructs.
Seebs
J. J. Guest <jason...@hotmail.com> wrote:
>Sorry! Was in a bad mood last night for reasons totally unrelated to
>IF, and you kind of got caught in the crossfire. Of course IF is
>supposed to be fun; I didn't mean to be nasty. And your code is
>perfectly valid as an example of something very difficult to do in
>ADRIFT.
Yeah. I hadn't even thought about that example until yesterday. Flat is
a little toy adventure, but it's sorta fun.
>quickly. It certainly isn't *impossible* to write games using ADRIFT,
>as many loyal users will attest, but as one former user put it, ADRIFT
>is a template, not a language, and as soon as one tries to do
>something not envisaged by its author, Campbell Wild, you quickly run
>into problems.
This is not the first time I've seen this pattern, and it won't be the last.
It goes like this:
I enjoy programming, but many people don't. Since their eyes glaze
over when I talk about flow control constructs, that must be what
makes programming hard. I will write a language in which you don't
need any flow control constructs, by building the things they're used
for into the system in some easy-to-use manner. Now people can learn
to program easily!
Unfortunately, what's hard isn't the syntax of if/then statements; what's hard
is realizing what conditions and dependencies you have, and once you've
figured those out, the resulting system is *HARDER* to use than a simple
programming language that provides flow control constructs.
This has probably happened at least a dozen times. AmigaVision gave up and
admitted that there were flow constructs, and was apparently actually usable,
albeit annoyingly structured.
And every time, there's a few people defending it saying it's "easier" - but
almost always, those are the people who have actually learned to do the hard
part, and would find other languages quite approachable if they tried 'em.
Roger Firth
news:NVnZa.828$z7.2...@wards.force9.net...
>
> The fact of the matter is that 99% of what you can do in Tads or Inform or
> Hugo you could do in Adrift.
David, you're digging yourself into a hole here. From what you've
said previously about your background and experience, I strongly
doubt that you're competent to make that statement -- no
disrespect intended, but I just don't believe you're knowledgeable
about the capabilities of those languages.
Also, you missed out the key adverbs: "what you can [easily|simply|
naturally] do ... you could also [laboriously|clumsily|with difficulty]
do in Adrift. And that really is the crux of the matter.
The first message that's come from this thread is that Adrift is an
interesting alternative way into IF, one that appeals to a certain
type of author. That's excellent; we need more ways to get folks
involved. But the other message is that Adrift has limitations
that make it a bit of a dead end for folks who wish to build more
advanced/sophisticated/rounded games. It's not so much that
you /can't/ create them, more that it seems a lot too much effort
(rather like trying to write a payroll suite in Inform: you could
probably do it, but why? there are better suited tools).
I don't think for a moment that Campbell would suggest that
Adrift was 99% equivalent to the big three, and you're not doing
the system any favours by pushing that viewpoint.
> Maybe there are some things that are impossible
> in Adrift but of all the examples you listed, none of them are things I've
> ever seen in a text adventure or would ever want to. A game involving 250
> lockers which might (or might not) be open and might (or might not) be
> closed and might (or might not) contain items strikes me as the biggest
> yawnfest I've ever come across. Maybe you couldn't do this in Adrift but
> then in all honesty why would you even want to?
And I'm afraid that paragraph displays the characteristic that seems
to distinguish you from many of the authors round here: a breathtaking
lack of imagination. D'you really imagine that ground-breaking
non-programmer writers like, say, Emily Short, or Adam Cadre,
or Paul O'Brian, or ... would be fighting with Inform, TADS or Hugo
if something like Adrift could do the job of instantiating their ideas
as easily?
The fact that you can't see the merits of in-depth implementation
doesn't make it unnecessary: I'd guess that in most good games,
/at least/ 50% of the code is there to add atmosphere, or to
cover unlikely eventualities, or because having it work Just The
Way You Want It To gives great satisfaction to author and a
thrill to the discerning player. The difference, if you like, between
a mass-produced loaf and a fresh crusty baguette from the village
bakery.
I think this thread has already gone on too long; can we all
agree that Adrift is fine, as far as it goes, and leave it at that?
Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://www.firthworks.com/roger/
Adam Thornton
The Adrift Central Scrutinizer just called, and he has a message for
you: Fun Is Not Allowed.
Adam