[minicomp] Minigames
Ben Caplan
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
b...@hayscaplan.org
Mark J Musante
> 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 ;
----------
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
Iain Merrick
> 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
R. N. Dominick
news:b83git$aqb$1...@pcls4.std.com:
> 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/
Adam Thornton
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
L. Ross Raszewski
>
>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.
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.
Ethan Dicks
> No one's saying you have to use the Big Three-or-Four either.
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
Ethan Dicks
> Mark J Musante <olo...@shell01.TheWorld.com> wrote in
> news:b83git$aqb$1...@pcls4.std.com:
>
> > 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.
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
Neil Cerutti
Dominick wrote:
> Mark J Musante <olo...@shell01.TheWorld.com> wrote in
> news:b83git$aqb$1...@pcls4.std.com:
>> 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.
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
Arnel Legaspi
> There is one restriction: The compiled game file (.z5, .z3, .gam, etc.) must
> be no more than 50KB.
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
L. Ross Raszewski
>
>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?
In another "for what it's worth", the three gemstone games are all
under 50k; the largest, Space InvaderZ, is about 22k.
Steve Evans
It's probably worth noting that Zarf's 'Space Under The Window'
weighs in at only 31k.
Steve
Ben Caplan
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.
Mike Roberts
[a comp with a 50k limit on compiled games]
> 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'm curious: why do you see this as desirable?
--Mike
mjr underscore at hotmail dot com
Steve Evans
>
> 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.
Well, at the very least, there shouldn't be too many Inform games
submitted with Debugging options left on.
Steve
Andrew Plotkin
> 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.
MFischer5
> 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
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Here, 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.
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
Jessica Knoch
> Arnel Legaspi wrote:
> >
> >I still think 50KB's too small.
>
> under 50k; the largest, Space InvaderZ, is about 22k.
May I ask at this point what "the three gemstone games" are?
Thanks,
--
Jess K.
L. Ross Raszewski
<jessicakn...@mindspring.com> wrote:
>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.
Iain Merrick
> 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
davidw
to be with one of the Big Three?
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.
Ben Caplan
> 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.
Ben Caplan
The more variety, the better. There are no right or wrong ways around the
size limit.
Magnus Olsson
Ben Caplan <b...@hayscaplan.org> wrote:
>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.
Magnus Olsson
Iain Merrick <ia...@diden.net> wrote:
>m...@df.lth.se (Magnus Olsson) wrote:
>> 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.
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.
Kevin Forchione
news:b8asem$7s9o5$1...@ID-178465.news.dfncis.de...
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
Roger Carbol
> be no more than 50KB.
Fifty thousand characters of text should be
enough for any CYOA that I'm likely to undertake.
.. Roger Carbol ..
Edmund Kirwan
> news:b83git$aqb$1...@pcls4.std.com:
>
> > 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.
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."
Ben Caplan
The exact deadline for submission of entries is midnight between the first
and second of July, Central time. Entries marked as sent later than this
will not win, will be played, and may or may not receive reviews.
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
Daniel Dawson
>> There is one restriction: The compiled game file (.z5, .z3, .gam, etc.) must
>> be no more than 50KB.
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/
Ricardo SIGNES
> 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?
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
Cedric Knight
> 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
Ricardo SIGNES
> Ricardo SIGNES wrote:
>
>> 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. :(
A month to go, right?
http://groups.google.com/groups?selm=BAFE8378.21D0%25ben%40hayscaplan.org
--
rjbs
Cedric Knight
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
davidw
first post it states 1st/2nd June (if so, too late I missed it!) but
further on down it states 1st/2nd July.
Which is correct?
Josh Vanderhoof
> 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.
Ricardo SIGNES
>
> 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
Ben Caplan
> Is Ben alive? I emailed an entry to him on June 1 and have yet to
> receive a reply.
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
Ricardo SIGNES
> 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).
Er, the day after tomorrow?
Right, I'm out.
--
rjbs