There is one restriction: The compiled game file (.z5, .z3, .gam, etc.) must
be no more than 50KB.
Deadline for entries is June 1.
Anyone wishing to be a judge must email me by May 1.
Judges are not eligible to submit games.
Flames by email only, please.
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
b...@hayscaplan.org
A minimal TADS .gam file with only one room and no objects other than those
defined in std.t is over 50k.
In tads 2.5.7, for example, if your game consists only of:
----------
#include <adv.t>
#include <std.t>
startroom : room ;
----------
The resulting .gam file is 52661 bytes, nearly 1.5k over the limit. I
would suggest different file size limits for each system and, no, I don't
know what a good limit for Hugo would be.
-markm
> Ben Caplan <b...@hayscaplan.org> wrote:
>
> > There is one restriction: The compiled game file (.z5, .z3, .gam, etc.) must
> > be no more than 50KB.
> > Deadline for entries is June 1.
>
> A minimal TADS .gam file with only one room and no objects other than those
> defined in std.t is over 50k.
>
> In tads 2.5.7, for example, if your game consists only of:
> ----------
> #include <adv.t>
> #include <std.t>
> startroom : room ;
> ----------
So don't use adv.t, or use a simplified version. Do you really need
tables? Darkness? Clothing? (Assuming you're not a table-dancer in a
dimly-lit nightclub or something.)
> The resulting .gam file is 52661 bytes, nearly 1.5k over the limit. I
> would suggest different file size limits for each system and, no, I don't
> know what a good limit for Hugo would be.
I think that would be too complicated. 50KB is a good limit.
--
Iain Merrick
ia...@diden.net
> A minimal TADS .gam file with only one room and no objects other than
> those defined in std.t is over 50k.
And the equivalent TADS 3 game (the skeleton game provided by the
Workbench) is almost 350k.
In fact, the smallest I can get an Inform 6.21 6/10 game to come out to is
49,664 bytes. There's a whole 1.5K left for a game.
Any entrants for this comp are going to have to roll their own libraries.
Too much work for me! Good luck to anyone who tries, though.
--
R. N. Dominick -- ur...@bookmice.net
Coffeehouse Software -- IF non-productivity in spades!
http://www.bookmice.net/coffeehouse/
No one's saying you have to use the Big Three-or-Four either.
I was able to write a text adventure in 4K of ROM last year.
The SA games were 16K, almost all of it in ROM.
Adam
For those willing to do this, I believe, after very slight testing,
that the smallest legal program output by the inform 6.21 compiler is
1,536 bytes.
Personally, I'd have made the limit 64k, but that's just me.
Well... I, for one, would probably not bother to enter any contest
if I couldn't use my favorite environment (Inform).
> I was able to write a text adventure in 4K of ROM last year.
Hw U do tht? Abbrv8?
> The SA games were 16K, almost all of it in ROM.
On the VIC-20, maybe. I don't recall much ROM being in use when we
played them on the Apple II. The first IF I ever played was "Pirate's
Adventure" on the PET - in BASIC! If you counted the Kernel and BASIC
ROMs in the PET as part of the game, there was 20K of ROM code and well
over 20K of data and game code.
I'm not opposed to a size constraint, but libraries, parsers, etc., have
all progressed well beyond "TAK SNE". There's also the effort factor: if
I have to write my own parser, I'm a lot less likely to take the time to
code up an entry. When I was writing IF in BASIC, long ago, the games
tended to take a back seat to the game infrastructure - coding containers
and adjective detectors and special exceptions to verbs, etc. One of the
things I *love* about Inform (and its library) is that I can focus on
the story and the people/places/things, not how to physically communicate
with the player (not to dis TADS, ALAN and friends; they all do fine, too).
I'm much more interested in participating in a speed-comp some day, than
something where the *output* size is regulated. I can see, for example,
restricting a game to no more than 20 total objects, or three pages of
source code (presuming something complex like Inform or TADS) *not* including
the library - the game author's code.
How's this? The compiled file must be no more than 30K larger than a
representative "hello, world" program. Focus on how large the game is,
not the library.
-ethan
I'm sure this number can be bettered with some effort to ReplaceSub
a bunch of stuff with empty functions, but how much of the library
do you want to discard? There's also the option of using an older
version of the library that would be much smaller (but potentially
cause problems by exposing the author to long-fixed bugs in the library).
> Any entrants for this comp are going to have to roll their own libraries.
Most likely.
> Too much work for me! Good luck to anyone who tries, though.
Agreed.
-ethan
Probably some stuff in verblibm.h can be jetisonned without too
much hassle. For example, the list writer can be replaced with a
much less capable one, so long as your game is simple enough so
that a simple list writer suffices.
Most will have no need of the vestigial menu system.
I've got the minimal Inform game down to 45KB, including a room,
the player, and one other simple object.
Careful pruning of useless actions and grammar is the next
obvious step.
--
Neil Cerutti
I still think 50KB's too small. I don't know what kind of IF game will
be possibly made within that limit, but I'm certainly interested in
the results, and _how_ it can be done, especially with TADS 2 or 3.
BTW, would that include "z-machine abuses" as well?
--Arnel
In another "for what it's worth", the three gemstone games are all
under 50k; the largest, Space InvaderZ, is about 22k.
It's probably worth noting that Zarf's 'Space Under The Window'
weighs in at only 31k.
Steve
This is exactly how, and why, I set the limit. The idea is to force authors
to rethink what they really need in a game, rather than implementing their
fiction in terms of a library.
Funny how that works.
I'm curious: why do you see this as desirable?
--Mike
mjr underscore at hotmail dot com
Well, at the very least, there shouldn't be too many Inform games
submitted with Debugging options left on.
Steve
> This is exactly how, and why, I set the limit. The idea is to force authors
> to rethink what they really need in a game, rather than implementing their
> fiction in terms of a library.
If you're talking about building a game from scratch -- which is
(mostly) what I did in _The Space Under the Window_ -- this is a good
constraint.
But if you're talking about a standard IF parser game, I don't think
the constraint will go where you want it to, because "what you really
need" is a standard parser. That's 75% of the library already.
Going in to dissect out individual verbs from verblibm.h, or
individual features -- each_turn support, disambiguation, the
list-writer, whatever -- is not mindful focussing. It's a distraction
from game design. It's also tedious.
Basically, I think you're focussing on the wrong metric. Nothing in
the standard Inform library is going to obscure the essential features
of my game.
Except, possibly, for some standard verbs. I *do* often chop out verbs
from the standard library, precisely because they're not "what I
really need"... but I do this with a few lines of grammar replacement.
It doesn't affect game file size.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
> This is exactly how, and why, I set the limit. The idea is to force authors
> to rethink what they really need in a game, rather than implementing their
> fiction in terms of a library.
I like the idea of a comp for very small works, but having to do the paring of
the
libraries would be a major drag. Can't you find some other way to say "be
small"?
If you had a stripped game to start with, some Hello World skeleton with the
verbs commented out so everyone started at the same base value, and could
then add 50K (or 10K or 1.42K) that would be better.
Of course, it's your comp. :)
Kathleen
>Basically, I think you're focussing on the wrong metric. Nothing in
>the standard Inform library is going to obscure the essential features
>of my game.
Well, maybe. If Ben's goal is to encourage authors to rethink the
very fundamentals of IF-as-we-know-it, forcing them to ditch the
standard Library *may* be a Good Thing. It would raise questions like
"Do we need the (somewhat) simulationist world model?" or "Do we need
a verb-noun-object parser with disambiguation?" (Of course, the most
obvious answer to the latter question - trying to do the same thing
with a simpler parser - has already been explored ad nauseam. But there
are non-obvious answers, like _SUTWin_).
But I agree that game size is the wrong metric. Especially an absolute
game size in kB which doesn't take the different space requirements by
different systems into account. Even if we restrict ourselves to, say,
Inform games shorter than 50 kB, people are likely to try to shrink
the size of a traditional adventure game rather than come up with
entirely new concepts. Not that there's anything wrong with that (it
would, for example, be itneresting to see how small you could make an
alternative Inform Library while still being able to produce
Infocom-like IF), of course, but that's a totally different kind of
goal.
If you want authors to rethink what they mean by IF, I think you need
to be more explicit about your motivations.
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
May I ask at this point what "the three gemstone games" are?
Thanks,
--
Jess K.
>May I ask at this point what "the three gemstone games" are?
>
The three games that say "Powered by Gemstone" when you start them:
Zassball, Paint and Corners, and Space InvaderZ.
> Andrew Plotkin <erky...@eblong.com> wrote:
>
> > Ben Caplan <b...@hayscaplan.org> wrote:
> >
> >> This is exactly how, and why, I set the limit. The idea is to force authors
> >> to rethink what they really need in a game, rather than implementing their
> >> fiction in terms of a library.
>
> >Basically, I think you're focussing on the wrong metric. Nothing in
> >the standard Inform library is going to obscure the essential features
> >of my game.
[...]
> But I agree that game size is the wrong metric. Especially an absolute
> game size in kB which doesn't take the different space requirements by
> different systems into account.
I think it would be a bad idea to set different limits for each system,
because then there's no way to avoid making a list of permitted systems,
which strikes me as a bad thing.
Using the size of a 'minimal' game including the library as the size
limit would also be bad, because people could then make their games
arbitrarily larger by removing bits of the library. It seems like that
would miss the point of allowing games with the full library to sneak in
under the size limit in the first place.
However, if game file size is the wrong metric, here's a possible
alternative: how about setting a limit on the size of the source code,
not including library? 5000 bytes, say. That has the disadvantage of
requiring people to make their source code available, but I think it
would smooth out the differences between systems reasonably well.
Verbose languages like Alan might suffer, but hopefully not by much.
I still think the original idea, of a hard 50KB limit on the game file
size, is pretty good and could make for a fun minicomp. Another way to
smooth out the differences between systems might be to check the size of
a compressed zip file, rather than the raw game file. (This would also
help to deal with systems which produce multiple files, like Alan and
AGT.)
--
Iain Merrick
ia...@diden.net
Assume I wanted to enter a game written with Adrift and spare myself
the excitement of having to learn a tedious programming language,
would that be okay? You can get a pretty big game in 50 KB with
Adrift.
> Well, maybe. If Ben's goal is to encourage authors to rethink the
> very fundamentals of IF-as-we-know-it, forcing them to ditch the
> standard Library *may* be a Good Thing. It would raise questions like
I didn't have any particular result in mind; I just thought, "This would be
interesting, let's see what happens," and posted.
> "Do we need the (somewhat) simulationist world model?" or "Do we need
> a verb-noun-object parser with disambiguation?" (Of course, the most
> obvious answer to the latter question - trying to do the same thing
> with a simpler parser - has already been explored ad nauseam. But there
> are non-obvious answers, like _SUTWin_).
Non-obvious answers are what I was looking for, if anything, and the more
diverse, the better. The chances of a 'fundamentally different' game being
better than what we've got are low, but if it occurs in large quantities
(and someone takes the time to compare them, like in a minicomp) then
wonderful things could happen.
>
> But I agree that game size is the wrong metric. Especially an absolute
> game size in kB which doesn't take the different space requirements by
> different systems into account. Even if we restrict ourselves to, say,
> Inform games shorter than 50 kB, people are likely to try to shrink
> the size of a traditional adventure game rather than come up with
> entirely new concepts. Not that there's anything wrong with that (it
> would, for example, be itneresting to see how small you could make an
> alternative Inform Library while still being able to produce
> Infocom-like IF), of course, but that's a totally different kind of
> goal.
>
> If you want authors to rethink what they mean by IF, I think you need
> to be more explicit about your motivations.
In retrospect, rethinking the Inform library is probably even more conducive
to wacky ideas than TADS, although when I originally posted I was only
thinking of TADS.
To summarize, the more controversy, the better (barring flame wars.) The
rules will stay the same. At worst, we'll gain nothing. At best, we'll gain
a future full of incomprehensibly good IF. More likely, we'll gain more
minicomps.
Live long and prosper.
The more variety, the better. There are no right or wrong ways around the
size limit.
>The chances of a 'fundamentally different' game being
>better than what we've got are low,
I think it's not so much about being *better* as about offering new
ways of looking at things, and so on. And if your minicomp can
lead to this, I'm all for it.
And I didn't really want to rain on your party - it's just that I
(apparently) misinterpreted your intentions with the minicomp.
In geneneral, I think any challenge to authors to produce something
under some hard constraint can be both fun and interesting.
In that case, make it clear that other systems than those on the list
are permitted, and add a new size limit when somebody expresses their
intent to submit a game written using a different system.
Of course, all this assumes that you can find "equivalent" size limits
for different systems, which is not at all a simple thing to do.
Doesn't it make more sense to use metrics "internal" to the game: Number of
rooms, objects, actors; that sort of thing? Metrics in KB are not only
dependent on game system, but on the library/library extensions used by the
game. For instance, a game using TADS adv.t is going to be smaller than one
using TADS WorldClass. And yet the author's code may be, object-for-object
equivalent.
--Kevin
Fifty thousand characters of text should be
enough for any CYOA that I'm likely to undertake.
.. Roger Carbol ..
Who'd have thought this thread to have such legs? And isn't it great!
Although I'm also against the unusualness (is that a word?) of the
limitation, it's fascinating to see what it produces, especially given
the reams of 'small' games people have so far suggested.
Nice one.
.ed
/==================\
www.edmundkirwan.com
"It's not very good."
Remember, it's never too late for speed-IF...
> As part of a futile attempt to pupate out of newbie-itis, I am holding my
> own mini-competition.
>
>
> There is one restriction: The compiled game file (.z5, .z3, .gam, etc.) must
> be no more than 50KB.
> Deadline for entries is June 1.
>
> Anyone wishing to be a judge must email me by May 1.
> Judges are not eligible to submit games.
>
>
> Flames by email only, please.
>
> ----------------------------------------------------------------
>
> Ben Caplan -- philosopher, linguist, and thaumaturge
I'm think that's impossible. I can compile a minimal Inform source (i.e. one
room and an initialise routine, plus the library), and it comes out to around
70 KB. Are you asking entrants to do without the library, or is there something
I don't know?
--
Email: Daniel Dawson <ddawson at icehouse.net>
(Please include my name (as above, but change ' at ' to '@') in To: field
when emailing me.)
Web: http://www.icehouse.net/ddawson/
I think you're compiling with debugging verbs. I can compile a skeletal Inform
game to about 49K. If I strip the heck out of the library, to less. My
minigame is only about 15k at the moment, though, as I just dropped the whole
library altogether.
--
rjbs
> I think you're compiling with debugging verbs. I can compile a
> skeletal Inform game to about 49K. If I strip the heck out of the
> library, to less. My minigame is only about 15k at the moment,
> though, as I just dropped the whole library altogether.
I like that 'at the moment' when it's nearly midnight here already.
Mine's currently at 22K including a multi-word parser, and nowhere near
finished. :(
BTW Ben said 'Central Time'. Didn't say central what.
CK
A month to go, right?
http://groups.google.com/groups?selm=BAFE8378.21D0%25ben%40hayscaplan.org
--
rjbs
Doh... is this some confused April 1 trick? I've just submitted
something. In a email to me dated 31 May, the organiser said 'entries
must be timestamped at or before midnight between the first and the
second of June, Central time.' which agrees with the original post
further up the thread.
Do I have a month to debug or was there some point in staying up most of
the night? Could Ben please clarify his clarification? (Guess the
deadline's going to have to be extended now.)
CK
Which is correct?
> Doh... is this some confused April 1 trick? I've just submitted
> something. In a email to me dated 31 May, the organiser said 'entries
> must be timestamped at or before midnight between the first and the
> second of June, Central time.' which agrees with the original post
> further up the thread.
>
> Do I have a month to debug or was there some point in staying up most of
> the night? Could Ben please clarify his clarification? (Guess the
> deadline's going to have to be extended now.)
Is Ben alive? I emailed an entry to him on June 1 and have yet to
receive a reply.
Ben is taking those entries he received and grafting them together into
a super-micro-game, which will be let loose to loot and terrorize July 1
entries. Ia ia! Ben ftaghn!
--
rjbs
Sorry about that.
Actually I did not receive an entry from you (not to say you didn't send it
- I'll keep checking my inbox.)
In light of the relatively small number of entries I _have_ received (two),
I will extend the deadline to Saturday (cutoff midnight, Saturday night
counts, Sunday morning doesn't, blah blah pedantics).
I seem to be having this incredible difficulty with my lifestyle.
Ben Caplan
Er, the day after tomorrow?
Right, I'm out.
--
rjbs