Yup, they're finally here, the results from the contest that ended in July. So without any further stalling, here are the entrants:
CPlusPlus with Mortle
foamy3 with Platform Swapper
Igrek with Rubik's
JFabi82 with KeepAway
Keith J with CoinGrab, and
ZagorNBK with Link's Puzzle Challenge (LPC)!
So I know you're all itching to know who wins... do I care? Maybe just a little. Here are your winners:
In 6th place, we have JFabi82's KeepAway. Better luck next time there; but I just couldn't like this game. sorry!
5th place is none other than foamy3's Platform Swapper. A proven concept, but it was much too slow.
In fourth is Keith J, whose game was playable and even enjoyable, but not quite as good as the top three.
Third place is occupied by Igrek, whose Rubik's cube game was well designed, but it seems to be a game ill-suited to monochrome graphics.
In 2nd, we have ZagorNBK's LPC, which was a cleverly designed game, but lacked some pizazz.
And finally, in first place, we have CPlusPlus with Mortle! We both quite liked this game, which has a unique concept and good execution.
Discuss below, offer your congratulations/condolences/whatnot as you will, but keep it civil as always.
Detailed score breakdowns to follow (tomorrow, since it's late and I have band practice in the morning).
Congratulations to all the entrants; it was a well-fought battle, and all of the entries showed good programming skills, originality of concept, and a dedication to displaying the power of BASIC. My grading sheet covered five areas for each program, graded out of 10:
KeepAway by JFabi82
Documentation: 9/10
Gameplay: 4/10
Speed: 5/10
Graphics: 7/10
Other: 8/10
Overall: 33/50 = 66%
Rubiks by Igrek
Documentation: 8/10
Gameplay: 6/10
Speed: 7/10
Graphics: 6/10
Other: 7/10
Overall: 34/50 = 68%
CoinGrab by Keith J
Documentation: 7/10
Gameplay: 6/10
Speed: 8/10
Graphics: 3/10
Other: 7/10
Overall: 31/50 = 62%
Mortle by CPlusPlus
Documentation: 8/10
Gameplay: 9/10
Speed: 7/10
Graphics: 7/10
Other: 9/10
Overall: 40/50 = 80%
Link's Puzzle Challenge by ZagorNBK
Documentation: 9/10
Gameplay: 8/10
Speed: 7/10
Graphics: 6/10
Other: 7/10
Overall: 37/50 = 74%
Platform Swapper by foamy3
Documentation: 7/10
Gameplay: 8/10
Speed: 3/10
Graphics: 4/10
Other: 7/10
Overall: 29/50 = 58%
Bump by RthProg
[Disqualified, unfortunately: author forgot to attach program to email, never responded to requests for an updated version with attached program]
Where can we download these programs?
yoman82 wrote:
Where can we download these programs?
If none of the authors would mind, I'd be happy to upload them to the Cemetech archives.
I don't mind... and I'd be happy to try the other puzzles.
Sorry, but I prefer to keep my programs UnSS-exclusive
I wouldn't mind either.
*I was hoping to make a non-contest version with xLIB, but I'm too overwhelmed with work to do programing lately
*
I was talking to tari and it sounds like some of these games were quite fun I really hope cplusplus releases mortle soon it definitely sounded worth a try.
Sorry about the huge delay, my phones (and thus also internets) were dead for 3 days...
I'd upload the programs we have permission to now, but I'd rather someone with power to actually set the author field did it (hehe), so I don't magically get credit for creating anything.
And a bit late, but here's my impressions on the entries:
c_plus_plus: Mortle
Size: 5/5
Game is about 3k, the included level set is less than 1k.
Optimization: 5/5
I'm impressed. It's small (particularly the levels), and performs reasonably well.
Speed: 6/10
Loading is tolerable, but the actual projectile calculation seems really slow.
Graphics: 8/10
Rather spartan graphics, but not text sprites.
Gameplay: 12/20
-Novel concept, simple and well explained controls.
-Pressing a key while the projectile is in flight will be acted upon when it finishes- rather annoying when I accidently hit 2nd.
-Game was unplayable due to errors until I did a RAM clear.
-At times, I was frustrated by the rather coarse control I had.
Bonus:
+2 for including a fully functional level editor
Included a copy of lineridr.z80 in the archive. Has no effect on the scoring, but it made me giggle.
Total: 36/50
Great concept, but it's a little slow, and was sometimes frustrating.
Igrek: Rubik's Cube
Size: 2/5
Just a single program, but 8.1k is rather large.
Optimization: 1/5
Much of the display code is hard-coded (things like Text(22,43,sub(Str4,1,1)):Text(19,48,sub(Str4,2,1)):etcetc). I'm sure it could be made much smaller with some For loops and a slightly different cube storage scheme.
Speed: 8/10
-Responds to keypresses promptly, but a little slow to redraw. No big issue, since this game doesn't require any speed, just careful thought.
Graphics: 9/10
-Good interface, and the cube display is pretty intuitive, although letters to indicate the color are rather difficult (greyscale would be great).
-The menus look very nice.
Gameplay: 13/20
-It's a Rubik's Cube, of course it's fun. Slight difficulty with determining which button rotates the face you're on detracts a bit.
-Doesn't shuffle the cube or anything- you just have to hit buttons to shuffle the cube.
Bonus:
+1 for having 'cube' and 'flat' views
Total: 34/50
A faithful rendition of the classic puzzle.
Size: 5/5
-Less than 1k, I can hardly object to a game this small.
Optimization: 4/5
-It's small and fast, but I still found a couple optimizations that could be made.
Speed: 8/10
-Plenty responsive, and the AI makes its moves quickly.
Graphics: 7/10
-Nice looking title screen.
-Text based interface does the job, but its a little barren.
Gameplay: 8/20
-It's a good concept, and simple enough for anyone to pick up and play.
-Unfortunately, once you figure out the trick, it's impossible to lose. Having played a game like this before, I knew exactly how to win.
Total: 32/50
A fun little game, at least until you figure out the trick.
Size: 2/5 points
-The level pack seems inordinately huge, for only containing two levels.
Optimization: 5/5
Code looks well streamlined, with some minimal gotos due to use of the menu command.
Speed: 5/10
-A bit slow, with noticeable lag between pressing an arrow key and any action.
-Loading of the first level was rather agonizingly slow.
Graphics: 7/10 points
Clean, well explained text sprites.
Gameplay: 7/20 points
-Expected the player to move upon pushing a block, rather than just moving the block and keeping the player in the same place.
-Only included two levels.
-Never provided any explanation of controls, although it was rather obvious that movement was the arrows, but I had to flail around pressing things to figure out how to exit.
Bonus:
+1 for a bit of amusing 'plot', and thanking the user when they exit.
Total: 27/50
An amusing game, but it needs more levels.
Size: 5/5
Only a single program, at 1.8k.
Optimization: 3/5
Pretty well coded (good idea using strings), but it's still sloooow.
Speed: 2/10
-Too slow to be any fun. I began, and only kept playing because of some hope that it would speed up as I scored more.
-Keypresses were slow to register at best, and not caught at all at worst.
Graphics: 5/10
Fairly clear text sprites, but the various other things onscreen made it feel busy.
Gameplay: 8/20
-Too slow to be fun, although it's a sound concept
Total: 23/50
A good concept, but it's just too slow.
Size: 1/5
-5.2k is simply unacceptable for a game this boring.
Optimization: 1/5
-Most of the graphics are hard-coded. Just use a couple For loops and save kilobytes and kilobytes.
Speed: 5/10
-It performs fine, but the shuffling is so slow that it's too easy.
Graphics: 5/10
-Graphics are fine and understandable, but the menus look quite unprofessional.
Gameplay: 3/20
-I'm not sure this is really a puzzle game. It's more of a.. hustle.
-If it were any sort of challenge it would be more fun, but it's easy to track since the shuffling is so slow.
Total: 15/50
Not a bad concept, but 3-card monte is only fun if you're doing the hustling.
Hello all. Sorry for the slow reply (at least it was faster than the amount of time to judge.) I'll probably release my game on UTI or Ticalc.org.
Tari: I quickly grabbed files on my desktop and shoved them into an archive, so the presence of the linerdr.z80 is no surprise.
Im surprised at winning, but I admit it is a quite addicting game.
Tari: What "made the game unplayable?"
"Projectile calculation a little slow:" This is more animation than calculation.
If you want, I can clear the getkey buffer before the control loop in order to disallow pressing keys during the motion.
Finally: the initial announcement mentioned prizes?
Fear not, prizes are still pending. They shall be resolved when teh Kerm has a little more free time.
c_plus_plus wrote:
Tari: What "made the game unplayable?"
It errored out in a decidedly non-spectacular way. A quick look at the code yielded no hints as to the problem, but.. yeah.
Very much agreed. The frustration factor would be mitigated somewhat if it were faster.
The Tari wrote:
Very much agreed. The frustration factor would be mitigated somewhat if it were faster.
I didn't even find it frustrating, just a bit slower than I liked. The one that was slow enough to drive me mad was foamy3's entry; it was a great concept to work with, and functioned fine, but was mind-breakingly slow.
The Tari wrote:
Very much agreed. The frustration factor would be mitigated somewhat if it were faster.
Do you want the trajectory part faster or the control loop faster? Because if I bow to Kerm's wishes for a less course control, the control loop will slow down proportionally to the amount of fineness I add.
Also, even though I haven't looked at this recently, I'm not sure I can speed up the trajectory that much.
Also, the game is partially designed to get you addicted on the earlier, easier levels, and to cause you slight frustration on the later levels once you are addicted.
Definitely the trajectory part, since watching it slowly fail due to me missing the target by a pixel is quite frustrating.
Okay, while my attempt at optimization might have sped up the code. The change is not noticeable. I frankly don't know how to improve it significantly enough to your requests.
My method of colisioin detection is pixel testing. While pixel testing is slow, I believe the alternative is slower. Also, to keep me from needing extra code to check the side boundrys, I depend on the black boarder to stop the mortle at the edge. To keep the Mortle from "Hopping" the botom boarder, i needed to add a terminal velocity of -1 by adding "air resistance." If this is the reason it seams slow. I may try to find some alternative.
KermMartian wrote:
The one that was slow enough to drive me mad was foamy3's entry; it was a great concept to work with, and functioned fine, but was mind-breakingly slow.
Yeah, I think I might change that a little. I wanted it to start slow so you could catch on before you were screwed, but it takes 10 minutes before it gets interesting. I think I might just have it always be on the highest level's speed, then just have the left side come out to the right one character for each level. Then the smaller area to work with would be the difficulty factor instead of relying on BASIC for speed.
When can we expect Cplusplus's game? Or am I just ignorant and it's already available?