CodeCraft #2

Categories, rules and dates

Categories:

Whereas CC #1 only had two competitions CC #2 has three:

• 1K Game and demo
• 8K Game and demo

• 2K Tool

The reason for a seperate tool competition is that a lot of people will vote for the entry they think looks/sounds best even though a tool might have taken more coding craftsmanship than a colourful demo. It's just plain unfair to put them alongside games and demos in one competition.

Rules:

Please, don't be scared off by the length of the rules descriptions. There really isn't that much to it and the second half of the rules are mostly examples, clarifying the rules.

There are two lists with rules. The first one lists rules for each of the categories while the second one contains rules applying to all categories.

• 1K Game and demo:
  • Type: game or demo
  • Final executable size: 1024 bytes (max)
  • User input allowed: keyboard, mouse, joystick
• 8K Game and demo:
  • Type: game or demo
  • Final executable size: 8192 bytes (max)
  • User input allowed: keyboard, mouse, joystick
  • Can have max 32K of external music
  • External music file must only contain music, i.e. no other data or code used by the program
  • Music player must be an unaltered standard player
  • Code to load and unload the player must be included in your executable
  • Music player must be included in the entry's archive
  • Music must stop playing when the entry is quit
  • More on the music and player below!

• 2K Tool:
  • Type: tool (see "More details..." further on)
  • Final executable size: 2048 bytes (max)
  • User input allowed: files, keyboard, mouse, joystick

General rules applying to all categories:

• Entries can be written in any language
• Entries must not have been released before.
• The final executable must consist of only one file.
• Programs must exit without crashing the system.
• Programs must be able to run without external data.
• Full sources must be included with your entry. For BASIC entries this means the uncompressed version.
• Entries and their sources must be freeware.
• Entries can be modified after they have been submitted.
• An unlimited number of entries per person is allowed.
• No limitation is set on the hardware/RISCOS configuration needed to run the program.
• Your entry is only allowed to use modules/applications that are inlcuded in the RISCOS roms.
• Obscene or discriminating entries will be refused

More details on some of the above rules:

• Written in any language: you can write your program in BASIC, ARM assembly, C or whatever. However, your program must be able to run without needing any third party libraries/modules installed on the user's machine. So, if you were to write a Pascal or Fortran program which would need some runtime libraries to be installed on the user's machine then your entry would not be valid.
• Tool: with a tool program we mean: a program that clearly has a more serious application and purpose than just entertainment. Let's clarify this through a couple of examples:
  
  • 16 bit sound emulator: tool.
  • Program that prompts for confirmation when a file is about to be deleted: tool.
  • Wimp-based stopwatch with "basic" graphics: tool.
  • Wimp-based fancy looking clock: NOT a tool.
  • Program that generates an 'uh-oh' when an error-box pops up: NOT a tool.
  • Wimp-based memory game: NOT a tool.
  Once again, the usefulness must really outweigh the entertainment value.
• Not needing external data: the program is not allowed to load any external data other than RISC OS Operating System data. The exception to this is the 2K Tool category which allows entries to load data from files, but only when told so by the user
• Modification of entries: you can send us updates of your entry any time you want, but do remember that after the deadline it's very unlikely that people will download the updates anymore and others may already have based their votes on your previous version.
• Configuration: people won't vote for what they can't run! Please remember this. You can write something that only runs on a RiscPC but then you'd most probably miss out on a number of votes. So, keep your system requirements as low as possible. We're always very happy to test out your entry on a number of systems. See below for more details.
• Unaltered music player in 8K: we should be able to delete your copy of the player and replace it with a copy we download from the Internet. We will of course make sure the version we download will not be older than the version you use.
  If you want to supply a music player module that you've written yourself then you have to ask our permission. We just want to check that there's only player code in there, not any "demo" code.
  
• Music: some extra notes on the music:
  
  • Music file may be compressed and then invisibly decompressed by your entry at runtime (decompressed to memory, or if to file then the compressed music file must not be overwritten)
  • Games can use the music file to store sound effects as well of course. However, you must use the player to play these sound effects (IIRC some of the tracker players can be told to insert sound effects into the music currently being played)
  • Music author has to be credited! If the author of the music is known then (s)he must be credited. Always in the ReadMe and if you have your own name in the final executable then the music author must be credited there as well. If you don't know who the author is then explicitly say so in your ReadMe (and in the executable as well if you also credit yourself there).
• Load, unload player in 8K: your executable must load and also unload the music player. That is, unless it was already loaded, in which case you should not unload it afterwards. You can find out the location of your executable and hence the location of the player and music you included in the archive by using SWI "OS_GetEnv" and examing the result.
  Look at the Support page for an example of an 8K program loading, using and unloading music and player.
• Non RISCOS modules/applications: the main reason for this rule is to prevent people from writing something like a 3d engine, putting it in a module, spreading it and then have a very fancy 1K program that for the largest part runs on this 3d engine module.
  If you want to use any module/ application/ utility that is not included in the RISCOS roms then please contact us and we will try to let you know whether we will allow its use as soon as possible.
  Note that we're talking here about what your entry needs to run. For development you can of course use any module/ application/ utility you need.
  
  Currently these are the 'external' modules/ applications/ utilities that we allow:
  • None at the moment.

• All donations would be used to increase the prizes for the entry's category.
• All participating entries in the same catagory would be considered an indivisible unit for redistribution purposes.
• The distribution would be clearly stated to be a service for a non-profit organisation.
• Your rights to distribute your own work individually would be unaffected.
• All arrangements would be non-exclusive so distribution can be maximised.
• All donations from a deal made after the voting deadline of the competition will be used to increase the prizes of future CodeCraft competitions. If no new CodeCraft competition is organised within 1 year after this competition then such donations will be given to charity.

No more coding after Sunday, 4 June 2000, entries must be in before 18:00 GMT Monday, 5 June 2000.

The last day we'll accept votes is 15 July 2000 (inclusive). Note that you can only start voting from 5 June 2000 onwards.