Download Commodore Free issue 7

Transcript
Commodore Free
Mini Games Competition
http://www.minigamecomp.org.uk/
FAQ
Q: What's this about a "moderator"?
shouldn't have to type any special commands to start
(like SYSxxxx on a C=), and so on. Autostarting
executables are OK. This makes life much, much
easier on those trying to run (and judge) the
programs.
A moderator is responsible for verifying that the
program meets submission/size requirements, that it
works in an emulator, and so on. If you would like to
see a platform represented (or would like to
volunteer! Yeah!) please email the organizer and
we'll work something out!
Q: My platform has a big header and is at a
disadvantage.
Q: Can moderators submit entries?
Actually, the header losses are all about the same.
More broadly,
every platform
has some dead
weight in the
executable,
including
differences in
sprite
Absolutely. As
long as a
submission
meets the
requirements, it
may compete.
Q: I'm writing a
game for multiple
platforms. How
should it be submitted?
sizes, bitmaps, screen clearing, CPU architectures,
system resources, etc. The competition will never be
"fair". The computers are so different in their
capabilities that it's impossible to create a perfectly
level playfield. The computers have different
strengths, and different weaknesses. Be creative,
use nasty tricks, and make as good a game as you
can in 1K or 4k.
The general idea is one game, one vote. Therefore,
please pick a version that you'd like to compete, and
place the rest in the "extras" area.
Q: I'm concerned about 24/7 voting. Will people vote
consistently over time? What if someone updates an
entry? As a competition, should we even be able to
download games early, let alone vote?
Q: But...
The votesheet is just a piece of paper for keeping
notes. You still have to submit it, at the end of the
contest, when you're satisfied with it. If someone
updates an entry -- well, after you play that updated
entry, you can update your votesheet. Finally, as to
being able to download, I believe that downloading
games during the contest stimulates interest in the
contest, and I don't believe it has caused any issues
the last two years. And, of course, there are just too
many entries. So, I suggest trying the votesheet this
way, and if we find it causes problems we can do
something different next year.
It's a nightmare. Consider the CPC AMSDOS header
-- 128 bytes. Most of that, however, is empty, and
programmers routinely store code and data in it.
Checking that this header doesn't contain code/data
is a truly awful prospect; by contrast, including
headers gives around a 10-byte penalty -- just like
pretty much every other platform. Let's say you take
away the header restriction. Commodore 64 and
Speccy files do not autoboot, so they need a BASIC
program to start with RUN.
Now you need to either not count the BASIC header,
or else remove the RUN restriction. Now life is
tougher on users, so maybe external loaders should
now be allowed -- can we put a title or other
information in the loader? Then, of course, C64
programs also store a two-byte load address in the
file, so maybe that shouldn't be counted. And in the
first contest MV stored the score in the BASIC line
number, so maybe that should be counted after all.
But if you want to get really technical, then the file
structure includes... But then this obscure computer
has... But compared to this other computer it... And
remember, this makes life much, much easier on
those trying to run (and judge!) the programs,
especially on unfamiliar platforms.
Q: Please clarify the rule about starting with RUN.
The general idea is that the game should be started
in the standard way for the platform, whatever that
may be. On a Commodore machine and the speccy,
it's LOAD followed by RUN, on a CP/M or MS-DOS
machine you'd just type the name of the executable
on the command line.
So no loaders (they count toward the size), the user
Q: But...
It's like representative democracy: it's not that it's the
best system, it's that it's the least worst system.
Q: How do I determine file size?
Commodore 64: Extract from a .d64 if necessary,
then ls -l (unix) or dir (dos) -- i.e. memory plus two
- 21 -