Results: September 1, 2002
Sorry for dragging by heels on this issue. I'm the only judge because the other two couldn't make it.
Source code should be posted at the web site soon, assuming I get ftp access back soon. (domain problems...)
note: Graphics criteria only go up to 3.
elegance: 1.5. There's no consistant indentation scheme. Many numbers are used without a comment or clue as to what they mean. The function names, while simple, don't really express what they do. (Can you tell the difference between screen() and screen1()?) I gave him .5 points for making things modular in the main() function.
portability: 1. It's compilable only under the turbo c borland 3.0 compiler.
Interface: 4. It uses the arrow keys to move and the escape key to quit. User-definable keys would have been better, but these suffice well. It shows the keys used at the intro screen for the doubtful or stupid.
Features: 3. It includes the ability to pause, the ability to change the speed, and scores the game based on how many fruits the snake eats.
Graphics efficiency: 3.
Graphics library: 3. Functions of the API were used effectively. (ie: gothic lettering, rectangle borders.)
Graphics portability: 1. While the DOS graphics interface is used very often in older games, a better option would have been through Windows. The mode that the program sets the graphics card to is unusual and could cause problems in a Windows dos box. (The program worked in a linux DOSEMU box, though.) A DOS graphics interface also limits the resolution and color depth to around mode 0x13 levels. (Though color depth and resolution weren't major concerns in a pretty-much detail-less program like nibbles.) Another issue: many of the program's options are hard-wired. This prevents portability.
Overall graphical choic: 3. The BGI is a good library to write a nibbles clone with. It provides close to the same interface that text-mode nibbles had.
Graphical Creativity: 1. There isn't much. It's all either alternating lines for walls, solid lines for the snake, and text. The snake can turn back into itself, an impossibility.
elegance: 4.5. The use of comments really clears things up. Although the eight-space indention scheme is a bit ugly to me, at least he used one.
portability: 2. It's portable across all platforms with the SDL. Unfortunately, it seg-faults in both Windows and linux in areas like joysticks and full-screen control. It even stalls randomly.
Interface: 2. While technically correct, the interface isn't fun to use. The keyboard interface must be inputted the first time it is used. Illogical input will cause the console to spiral downward, repeating the same question over and over, without a possibility of a ctrl-break.
Features: 1. Nothing extra.
Graphics efficiency: 3. All functions call an appropriate graphics API function.
Graphics library: 3. The SDL's features were used extensively.
Graphics portability: 2.5. The SDL is portable, with a few exceptions: the linux framebuffer, dos.
Overall graphical choice: 1.5. The SDL is a bit of an overkill for a simple nibbles program. A better solution using the SDL would be to spruce up the game with bitmaps and alpha-blending.
Graphical Creativity: 2. Aside from the objects the snake was chasing, nothing is really done creatively. I'll give credit for the random lines, though
My biggest issue with vasanth's entry is its inability to accept changes. A game that doesn't change gets old quickly. Even the replacement of the numbers with #defines would be a big improvement.
My biggest issue with Silentstrike's entry is the interface and the stability. Ideally, it looks great, but it can't play past 2 levels without stalling. It would have also been nice if the keyboard changes were set to the default of up,down,right,left and there was an option asking if there was a departure from the norm about the keyboard options.
vasanth: 3+1.5+1+4+3+3+3+1+3+1 = 23.5
silentstrike: 3+4.5+2+2+1+3+3+2.5+1.5+2 = 24.5
so close, vasanth! sorry, better luck next time.