You are logged in as: Eric log out

Rules

See below for all the standard rules.

additional requirements

And yes! here they finally are. The rule-o-matic has decided and this is the result;

genre requirement

**** There will be 1 genre rule

genre rule #56
"Time" should be the theme of your game.

Comment:
Time should be the most important theme of your game. For example: think of the endless possibilities of Time Travel. While almost all games use time in one form or another (for example a time limit to complete a certain task), your entry will be judged on how pervasive this theme is in your game.

Artistic requirement

**** There will be 1 artistical rule

artistical rule #82
the game should feature (a) railway(s) and / or train(s).

Comment:
Trains and railways are very common in games. Resource management games where you have to build railroads: sim city, railroad tycoon. There are platform games where whole levels are situated on a train, or war sims where you can ride trains through a battlefield. Note that you don't have to use both railways AND trains, using either will satisfy this rule. If you can think of an interesting use for railways other than having trains run on them, go right ahead.

technical requirements

**** There will be 2 technical rules

technical rule #29
Provide a help function, that can be accessed during the game.

Comment:
Complicated games can require a very extensive help system, to mind comes the "Civilopedia" of the Civilisation series. But even the simplest platformer usually has a help screen which lists the various powerups and enemies.

technical rule #14
Provide a good example of ascii-art. 

Comment:
A display of ascii-art can give a game a nice little touch of retro. Note that the characters don't have to be displayed in text mode, drawing them in graphics mode using the allegro text routines is fine. Also you may render them in any font you like. Bonus points if you can do the whole game in ascii mode (not unheard of, there are text-only first person shooters in existence), but this isn't required.

bonus

**** There will be 1 bonus rule

Bonus rule #1: Act of Dog

Comment:
This is a classic. The Act of Dog is designed as a get-out clause for not implementing one or more of the requirements - providing that the entrant can come up with a extremely good explanation for not doing so. And when I mean good, I'm talking watertight. If I can find a way through it, then I will. Lame excuses will be not be accepted, and may result in public embarrassment for the entrant concerned. Successful attempts at 'social engineering' will give you a waiver. All 'Acts of Dog' must be negotiated with me via Email before the entry is submitted on Monday morning. Humour (of all grades) may be employed in your argument. Other techniques (underhand or otherwise) will have varying levels of success. Send all petitions to amarillion@yahoo.com with good reasons, bribes, incriminating evidence and pitiful pleading. Judgement will be as swift as the organiser sees fit.

That was is it far as the additional requirements are concerned. Below are all the regular rules.

Standard rules

1. time: The competition is from Friday March 3, 12.00 pm GMT to Monday March 6, 12.00 pm GMT. You are not allowed to write code for your entry before or after these times. All entries must be submitted before Monday March 6, 12.00 pm GMT to an address that will be provided later (if you know in advance that you won't have an internet connection at that time, perhaps because you have internet at work and not at home, in that case you can get an exemption for this deadline. Please let me know in advance if this is the case for you).

2. size: the entry may not be larger than 400 kb, zipped. Assuming an average compression ratio of 50%, This gives you roughly 800 kb of uncompressed files.

3. source: the complete source code must be included with the entry. You don't have to include the source of allegro add-ons, as long as they are easily found on the web. (For a list of common add-on libraries, see the allegro.cc resource directory). And of course you don't have to include the source to Allegro.

4. code reuse Because reusing code is an essential hacking skill, You can re-use any code that:

1. You are legally able to do so (your own, GPLed, giftware, public domain or any other Free Software licence) AND
2. Was available and easily accessible online at least four weeks before the start of the competition This means that until four weeks before the start of the competition you may still upload your own code (e.g. initialization code, utility classes) that could come in handy during the competition.

5. Allegro & other libs. The game may make use of Allegro add-on libs or other libs as long as they are portable. The game must make use of Allegro.

6. programming language you may use any programming language that Allegro supports.

7. portability. Your entry should be trivial to port to any platform that Allegro supports (that means including Windows, Linux and Mac OS X). This means that you are not allowed to use any OS-specific features in your game (Essentially you should aim to make your entry compile out of the box on all platforms, but this can be hard to realize for people who don't have access to those platforms).

8. additional rules. There will be additional rules that are announced at Friday March 3, 12.00 pm GMT. These rules come in four categories: Genre Requirements, Technical requirements, Artistic requirements and Bonus rules.

9. reviewing and deciding a winner. To ensure that each entry will be reviewed, each entrant will be assigned two entries to review and six entries to grade. Awards will be assigned based on these grades. There will be awards in the following categories:

• Best overall

• Best implementation of technical requirements

• Best implementation of artistical requirements

• Best implementation of genre requirements

Other Important Info

You can assume that everyone will have a copy of the latest stable Allegro library (standard installation) installed. You do not need to supply one. You should consider uploading binaries for people who have problems compiling the source onto your own website. I will be checking that the binary and source match up, so adding enhancements to the 'competition binary' is not permitted..

If source code is reused from legal sources (your own, GPLed, public domain) you should declare this and what changes have been made, so that your work can be properly assessed for the voting.

People should keep a informative and interesting account of their development through the competition. This can be sent after the competition for those people with no Email over the weekend. This does not affect your space requirement.

There will be a mailinglist for participants, where you can easily drop a message to all participants. The mailinglist will be closed a few months after the competition. Experience has taught that there are always last minute bug fixes after the competition, this mailinglist will be the place to announce them.

As always, a web-based speedhack log facility will be available during the competition.

You can make use of all information sources, mailing lists as you see fit. This is not an exam! :-)

Any other questions? Send mail to me and keep working! I'll get back to you as soon as I can.. :-)

Link provided by the allegro banner network: