Discussion:
[Hugo] Why so few recent HUGO games?
(too old to reply)
Marno
2003-11-01 21:19:51 UTC
Permalink
I have been experimenting with various authoring tools, and have come
down to three: TADS, Hugo, and ADRIFT. I don't want to go into why I
have narrowed it down to these particular three, but one of the
criteria I am looking at is the system's popularity and use in the IF
community.

Hugo looks like a very good system. But I found no Hugo entries for
the past several years' comps, and no recent (2003) games at the IF
archive. I have to wonder... why not?

Any ideas?

Mike
Mark J. Tilford
2003-11-01 23:13:53 UTC
Permalink
Post by Marno
I have been experimenting with various authoring tools, and have come
down to three: TADS, Hugo, and ADRIFT. I don't want to go into why I
have narrowed it down to these particular three, but one of the
criteria I am looking at is the system's popularity and use in the IF
community.
Hugo looks like a very good system. But I found no Hugo entries for
the past several years' comps, and no recent (2003) games at the IF
archive. I have to wonder... why not?
Any ideas?
Mike
I think the main reason is that it came later, and didn't have anything to
outdo the status quo (TADS and Inform), so it never attracted a big
userbase. The secondary reason is that nobody wrote a must-play game in
Hugo.

When TADS first arrived, it had the advantage of being a powerful language
which was tooled to IF. There were a number of classic games written in
TADS fairly early on. (Unkuulia and the other Adventions games)

Inform had the gimmick that it compiled to the same VM format as the
Infocom games did, that Inform games will run on just about anything,
similar power to TADS, and that it was freely available. (TADS had a $40
pricetag at the time.) Also, two early (the first two?) Inform games
(Curses! and Jigsaw) are very well regarded.

Hugo, I believe was originally an attempt to make a language with a
cleaned-up version of the Inform syntax. But it didn't offer enough to
get people who'd already learned Inform or TADS to switch over, so it
didn't get many veterans, and the lack of a good sample game prevented it
from getting many newbies. And without a good sized developer community,
it didn't grow as much.
--
------------------------
Mark Jeffrey Tilford
***@ugcs.caltech.edu
Adam Cadre
2003-11-02 03:58:11 UTC
Permalink
Post by Mark J. Tilford
I think the main reason is that it came later
and didn't have anything to outdo the status quo (TADS and Inform)
It most certainly did. Hugo's multimedia was way ahead of TADS
and Inform for a while there.
Post by Mark J. Tilford
The secondary reason is that nobody wrote a must-play game in
Hugo.
To the extent that anything in IF is a "must-play game," Guilty
Bastards is certainly right up there.
Post by Mark J. Tilford
Hugo, I believe was originally an attempt to make a language with
a cleaned-up version of the Inform syntax. But it didn't offer
enough to get people who'd already learned Inform or TADS to
switch over
Yes and no. I switched, very briefly; Varicella was initially
intended to be a Hugo game. But I found the whitespace-matters
aspect grating, and when I discovered that I was going to have to
use a workaround to get something like Inform's react_before to
work, I decided to scrap the multimedia, go back to what I knew,
and develop the game as a .z8 file.
Post by Mark J. Tilford
the lack of a good sample game prevented it from getting many
newbies
Guilty Bastards was a pretty damn good sample game, I'd say.
Good enough to convince me to give Hugo a whirl, at least. I
just couldn't get over the lack of semicolons.

-----
Adam Cadre, Holyoke, MA
http://adamcadre.ac
Arnel Legaspi
2003-11-03 07:51:59 UTC
Permalink
Post by Adam Cadre
Yes and no. I switched, very briefly; Varicella was initially
intended to be a Hugo game. But I found the whitespace-matters
aspect grating, and when I discovered that I was going to have to
use a workaround to get something like Inform's react_before to
work, I decided to scrap the multimedia, go back to what I knew,
and develop the game as a .z8 file.
Hmm. I wonder how Varicella would look like as a multimedia IF game.
Do you still have any plans of making it so?
Post by Adam Cadre
Post by Mark J. Tilford
the lack of a good sample game prevented it from getting many
newbies
Guilty Bastards was a pretty damn good sample game, I'd say.
Good enough to convince me to give Hugo a whirl, at least. I
just couldn't get over the lack of semicolons.
Same goes for me. Something about not putting in the semicolons made
me feel that what I put in there wasn't finished yet. I read somewhere
it had BASIC influences, so...

However, I find Hugo's use of "windows" for pictures (from screenshots
of Guilty Bastards) very neat, which is why I continue to dabble in
Hugo. Aside from TADS, Hugo is very very useful if you plan to release
a multimedia game.

I guess the same advice still applies: if you plan to learn IF
programming, go for either Hugo or TADS. If you find it a bit complex,
switch to ADRIFT.

Hope it helps!

--Arnel
Adam Cadre
2003-11-03 16:04:45 UTC
Permalink
Post by Arnel Legaspi
Hmm. I wonder how Varicella would look like as a multimedia
IF game. Do you still have any plans of making it so?
Yes, I've already started on the adaptation. Look for it in
the first half of 2004.

-----
Adam Cadre, Holyoke, MA
http://adamcadre.ac
davidw
2003-11-02 10:26:28 UTC
Permalink
Post by Mark J. Tilford
I think the main reason is that it came later, and didn't have anything to
outdo the status quo (TADS and Inform), so it never attracted a big
userbase. The secondary reason is that nobody wrote a must-play game in
Hugo.
"Guilty Bastards" was a must-play game. I even tried to write my own Hugo
game after trying that but got disheartened by the complexity of it all and
went to Adrift instead. Unfortunately an authoring system can't survive on
just one game and I guess that's why Hugo has failed.
Steve Evans
2003-11-02 11:16:15 UTC
Permalink
Post by davidw
"Guilty Bastards" was a must-play game. I even tried to write my own Hugo
game after trying that but got disheartened by the complexity of it all and
went to Adrift instead. Unfortunately an authoring system can't survive on
just one game and I guess that's why Hugo has failed.
I think "failed" is overstating things a bit.

While there've been relatively few Hugo games of late, you only have
to go back to 2001 to find one that was nominated for multiple XYZZY
awards (including "Best Game") and that actually won a couple
(including "Best Writing"). I'm talking about Robb Sherwin's "Fallacy
of Dawn" here.

So at the very least you'd need the thumbs of both hands to count the
number of "must play" Hugo games.

--Steve
Marno
2003-11-03 16:14:51 UTC
Permalink
Thanks to everyone for your thoughtful and knowledgable replies. You
have helped me reduce my choice to two: TADS and ADRIFT. I say TADS
*and* ADRIFT because I am attracted to each of the different strengths
of the two: the power of TADS and the ease of ADRIFT.

Presently I have one game in me that I just have to get out, and I
began work on it a couple of years ago in ADRIFT but became
discouraged by its limitations -- expecially my inability to do
anything about game-crashing bugs. Once they were in there, I
couldn't get at them to fix them! Lately, however, with the recent
4.00 ADRIFT, and with the support available from the forum and
Campbell Wild, I have set myself to get this game finished and
released in ADRIFT.

My interest in TADS is high, but at the same time somewhat mitigated
by the idea that I might have only the one game in me, and that once I
get it done, I won't have the wherewithal to write another. So I
might not have any use for TADS once I learn it, if I don't have it in
me to write any more IF.

But I love to learn new things, and TADS looks like a worthwhile and
fun challenge. And maybe I *do* have more than the one game in me.
So I am dabbling in TADS, writing room and object descriptions, but
again running into strange bugs I can't seem to identify, though the
format seems identical to the examples I have been following in the
tutorial. Hmm.

Anyway. Thank you. TADS and ADRIFT it is.

Mike
z***@search26.com
2004-12-07 09:20:16 UTC
Permalink
http://www.ardice.com/Games/Video_Games/Developers_and_Publishers/A/Adventions/
i***@gmail.com
2019-08-11 06:27:42 UTC
Permalink
Post by Marno
I have been experimenting with various authoring tools, and have come
down to three: TADS, Hugo, and ADRIFT. I don't want to go into why I
have narrowed it down to these particular three, but one of the
criteria I am looking at is the system's popularity and use in the IF
community.
Hugo looks like a very good system. But I found no Hugo entries for
the past several years' comps, and no recent (2003) games at the IF
archive. I have to wonder... why not?
Any ideas?
Mike
n***@zzo38computer.org.invalid
2019-08-12 02:34:47 UTC
Permalink
Post by Marno
I have been experimenting with various authoring tools, and have come
down to three: TADS, Hugo, and ADRIFT. I don't want to go into why I
have narrowed it down to these particular three, but one of the
criteria I am looking at is the system's popularity and use in the IF
community.
Hugo looks like a very good system. But I found no Hugo entries for
the past several years' comps, and no recent (2003) games at the IF
archive. I have to wonder... why not?
Any ideas?
Mike
Since you have quoted a message without adding anything more, I guess that
you might just have the same question, almost sixteen years later.

As far as I know, TADS, Hugo, and ADRIFT are not "Free VMs" (although I see
some conflicting information; also, Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems, and if the license says the
file cannot be modified, that is problematic). (Free VMs include Glulx,
Z-machine, OASYS, and possibly some others. Note that this is unrelated to
whether the authoring system is Free software; ZILF is, but I think Inform7
isn't Free software.)

Of course, just because many other people do not use it, does not mean
that you do not have to use it yourself.

(I wonder if you can convert a Hugo story file to other VMs or implement
it in other VMs? For example, I implemented Z-machine in Glulx; maybe it
is possible to implement Hugo in Glulx?)
--
Note: I am not always able to read/post messages during Monday-Friday.
Anthk
2019-11-10 18:15:01 UTC
Permalink
Post by n***@zzo38computer.org.invalid
Post by Marno
I have been experimenting with various authoring tools, and have come
down to three: TADS, Hugo, and ADRIFT. I don't want to go into why I
have narrowed it down to these particular three, but one of the
criteria I am looking at is the system's popularity and use in the IF
community.
Hugo looks like a very good system. But I found no Hugo entries for
the past several years' comps, and no recent (2003) games at the IF
archive. I have to wonder... why not?
Any ideas?
Mike
Since you have quoted a message without adding anything more, I guess that
you might just have the same question, almost sixteen years later.
As far as I know, TADS, Hugo, and ADRIFT are not "Free VMs" (although I see
some conflicting information; also, Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems, and if the license says the
file cannot be modified, that is problematic). (Free VMs include Glulx,
Z-machine, OASYS, and possibly some others. Note that this is unrelated to
whether the authoring system is Free software; ZILF is, but I think Inform7
isn't Free software.)
Of course, just because many other people do not use it, does not mean
that you do not have to use it yourself.
(I wonder if you can convert a Hugo story file to other VMs or implement
it in other VMs? For example, I implemented Z-machine in Glulx; maybe it
is possible to implement Hugo in Glulx?)
Inform 6 and the 6/12 are under an Artistic license since a few years.
Tristano
2020-01-18 17:03:42 UTC
Permalink
Post by n***@zzo38computer.org.invalid
As far as I know, TADS, Hugo, and ADRIFT are not "Free VMs" (although I see
some conflicting information; also, Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems, and if the license says the
file cannot be modified, that is problematic).
The above statement is a bit confusing.

TADS is the only one of those three systems that actually uses a VM (the T3-VM), which is documented here:

https://www.tads.org/t3doc/doc/techman/t3spec.htm

As to those systems being not free, I'm not quite sure what you mean, for all three are open source (although TADS doesn't allow derivative works, it allows porting the T3-VM to other systems).

ADRIFT has become fully open source since quite a while, and the full source code is available on GitHub under BSD-3-Clause:

https://github.com/jcwild/ADRIFT-5

Hugo has also been released under BSD-2-Clause since quite some years, the full code being available in various places, including the IF Archive. Here's my own repository for Hugo sources:

https://github.com/tajmone/hugo

Possibly the confusion with Hugo being open sources is that the copyright notice was never changed in the source files, mainly for historical preservation reasons. But the license prevails on these copyright notices, and you are free to change Hugo as you like.
Post by n***@zzo38computer.org.invalid
Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems
Could you please expand on that? I'm interest in learning more about these limits, since I'm working on/with Hugo right now.

Since under Windows I'm not experiencing any problems with these, I'm assuming that you are referring to limits applying to other architectures (which I'm interested in learning about).

Best regards,

Tristano
n***@zzo38computer.org.invalid
2020-01-18 23:41:30 UTC
Permalink
Post by Tristano
Post by n***@zzo38computer.org.invalid
As far as I know, TADS, Hugo, and ADRIFT are not "Free VMs"
The above statement is a bit confusing.
TADS is the only one of those three systems that actually uses a VM (the
https://www.tads.org/t3doc/doc/techman/t3spec.htm
I was using a broader meaning by the term "VM", since I was talking about a
different consideration than normally is considered by "VM".
Post by Tristano
As to those systems being not free, I'm not quite sure what you mean, for all
three are open source (although TADS doesn't allow derivative works, it
allows porting the T3-VM to other systems).
OK, so I was mistaken about Hugo and ADRIFT. However, since TADS does not
allow derivative works that does not qualify as open source or Free software
(although perhaps a new implementation could be made by reading the
documentation about the T3-VM and implementing that, maybe).
Post by Tristano
ADRIFT has become fully open source since quite a while, and the full source
https://github.com/jcwild/ADRIFT-5
OK, so that is good.

However, it seems to be written in VB.NET and doesn't use Glk. (Fortunately,
there is Mono to run .NET executables on non-Windows systems, and I read the
documentation and it says there is a Mono Runner, so that will work, so that
is good. I personally would prefer in C or Glulx, but Mono works too.)

I also see no mention on the web site about the source code; it is found
only in GitHub as far as I can tell. (Maybe I missed it, but I cannot find it
so easily, if it is there.)

I also cannot find documentation about the file format.
Post by Tristano
Hugo has also been released under BSD-2-Clause since quite some years [...]
https://github.com/tajmone/hugo
Possibly the confusion with Hugo being open sources is that the copyright
notice was never changed in the source files, mainly for historical
preservation. But the license prevails on these copyright notices, and you
are free to change Hugo as you like.
Yes, it is confusing, but thank you for clarifying that.

Still I would want to see if Glk Hugo can be compiled into Glulx code. (I
thought of some ideas about compiling C to Glulx, and there are some
difficulties with some programs, such as dynamic local allocation within
reentrant functions. Some other things would likely have to be altered too,
such as the file handling into the Glk file handling. There is also the
difficulty that the Glk "S" type does not correspond to C strings in Glulx;
although most functions also have versions that use address/length which can
be used instead (this can be done automatically, so the program need not be
altered to use this), this is not the case for file handling functions.)
Post by Tristano
Post by n***@zzo38computer.org.invalid
Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems
Could you please expand on that? I'm interest in learning more about these
limits, since I'm working on/with Hugo right now.
Last time I checked I thought I noticed something like that, but I cannot
find it now. It looks like it is designed to work with 16-bit integers but
allows the system to use larger integers, and would not malfunction on a
system with 32-bit or larger integers. I suppose I must have made a mistake,
because what I wrote before seems to be wrong (either that, or it was the
case in some older version that is no longer in use, but has been fixed now).

So, I was mistaken. Sorry for my mistakes, and thank you to clarify!
--
Note: I am not always able to read/post messages during Monday-Friday.
Tristano
2020-01-21 22:07:31 UTC
Permalink
Post by n***@zzo38computer.org.invalid
However, since TADS does not
allow derivative works that does not qualify as open source or Free software
(although perhaps a new implementation could be made by reading the
documentation about the T3-VM and implementing that, maybe).
Indeed, these restrictions are somewhat limiting, especially now that
many OSs are officially abandoning 64-bit support. I wish the author
might re-license TADS under a more permissive license, to ensure its
survival in time. His original intention was to prevent the
proliferation of TADS variants incompatible with themselves, but this
goal can be achieved by any FOSS license that requests changing the
name of derivative software.
Post by n***@zzo38computer.org.invalid
Post by Tristano
ADRIFT has become fully open source since quite a while, and the full source
https://github.com/jcwild/ADRIFT-5
OK, so that is good.
However, it seems to be written in VB.NET and doesn't use Glk. (Fortunately,
there is Mono to run .NET executables on non-Windows systems, and I read the
documentation and it says there is a Mono Runner, so that will work, so that
is good. I personally would prefer in C or Glulx, but Mono works too.)
The main problem with ADRIFT source code is that it relies on
commercial third party components for the GUI, without which it won't
compile. These are rather expensive components, and to keep the
project FOSS they would have to be replaced by native VS controls
somehow.
Post by n***@zzo38computer.org.invalid
I also see no mention on the web site about the source code; it is found
only in GitHub as far as I can tell. (Maybe I missed it, but I cannot find it
so easily, if it is there.)
The new was broken out in a single brief post on the ADRIFT forum:

http://forum.adrift.co/viewtopic.php?f=14&t=11875
Post by n***@zzo38computer.org.invalid
I also cannot find documentation about the file format.
There isn't one unfortunately, and the ADRIFT 5 Manual isn't complete
either. But the source code is well documented enough to allow
re-implementing various modules in other languages if required. I had
a brief look at the file format to understand better how it compresses
XML files, etc., and my first impression is that it's quite doable
even without an official specs documentation — but of course, writing
one would make the whole endeavour easier.
Post by n***@zzo38computer.org.invalid
Post by Tristano
Post by n***@zzo38computer.org.invalid
Hugo seems to have other problems such
as assuming 16-bit integers on 32-bit systems
Could you please expand on that? I'm interest in learning more about these
limits, since I'm working on/with Hugo right now.
Last time I checked I thought I noticed something like that, but I cannot
find it now. It looks like it is designed to work with 16-bit integers but
allows the system to use larger integers, and would not malfunction on a
system with 32-bit or larger integers. I suppose I must have made a mistake,
because what I wrote before seems to be wrong (either that, or it was the
case in some older version that is no longer in use, but has been fixed now).
So, I was mistaken. Sorry for my mistakes, and thank you to clarify!
You're right about Hugo using 16 bit data types internally, either
signed or unsigned (depending on need), and in a recent email exchance
with Hugo author (Tessman) he mentioned that in case Hugo were to see
a new edition the first thing he'd be changing was dropping the 16-bit
integers in favour of a wider words (he even mentioned 64-bit data
types).

So chances are that these 16-bit integers might be a problem on some
platforms, I'm just no aware which ones since I work mostly on x86
machines, and Hugo has been ported to so many platforms in the course
of the years that it's hard to keep track of them.

Anyhow, if you do stumble on the 16-bits limitation again, by chance,
please do buzz me for I'm interested in following it, since I'm
planning to work on a Hugo port in Rust sometime in Spring. Since
Rust can compile to multiple hardwares, I'll have to keep into account
the 16-bit issues.

Thanks again,

Tristano

Loading...