The 4th Contest of Cemetech is now under way. The theme of the contest is platformer/sidescroller. Beyond this, you are open to do as you wish for programming. The contest will go for two months, and all entries will be due to
contest@cemetech.net by July 31, 2007 @ 11:59:59PM CDT. Any entries received after this time will be considered late and not graded. You may submit multiple times, but only the latest one that is in by the deadline will be accepted and graded. The contest is open to 83+, 83+ SE, 84+, and 84+ SE graphing Calculators. All entries will be graded on an 84+ SE, so keep this in consideration. The contest is open to pure BASIC and pure ASM (no BASIC + ASM libraries).
The contest will be graded on Originality, Speed, Size, Playability, Graphics, Gameplay, and Replay value. The exact importance of these will be released at a later date. The program that recieves the highest score will be declared the winner. Do not worry, BASIC and ASM will be graded separately so there is no advantage one way or another.
I (rivereye) will be the main judge, and Kerm Martian will be the secondary judge. Any attempts to persuade our decision will result in disqualification.
Good Luck, and I hope to see some great programs.
I probably won't be participating unless I get a reallllly good idea, although I would be happy to help judge (or just help declare the winner incase of a tie)
EDIT: Idea for those doing it in asm: Ngame clone, get points off for originality, but if you manage to implement it well, then you have a good shot!
Man, that would be great. I wonder how fast it would run with all those trig functions running around, though (lasers, homing missiles, rounded objects).
Oh, just a few quick questions:
- Are we allowed to preannounce our programs, or would this disqualify our game?
- The grade of size is directly linked to the replay value, right? So if there was a huge program but it was totally addicting, it'd get a 8-10?
Harrierfalcon wrote:
The grade of size is directly linked to the replay value, right? So if there was a huge program but it was totally addicting, it'd get a 8-10?
Not necessarily... Some programs could be 3 kb and have an incredible replay value (like a chess program with good ai), while others could take all the ram but only be played once or twice (such as a linear rpg)
I'd say the size score is more based on what you do with that space. If your program doesn't do much but takes up a whole lot of your RAM, you'll definitely score lower.
Optimization is a huge factor on calculators. I assume they base the size score on how optimized the program is.
yeah, optimizations (Kerm will do ASM based ones), and do I think the space justify what is there.
haveacalc hurries to get his calc working again.
I thought you said you found one
I'd join, but I have no motivation whatsoever.
For those of you who don't want to find out what that tiny text says, haveacalc needs to find a calc, and Xphoenix thinks haveacalc already found one.
Gaining experience in programming? Contributing to the already gargantuan list of calculator games out there? Living off of appreciation from people you don't know? Writing games for calculators that will be outdated in 6 months? Learning to hate TI's floating-point number system?
No, there are plenty reasons to feel motivated.
I don't have any bad thoughts on TI's floating point system, really.
A few things:
1. Try i^(a large numberth power). The answer should be i, -1, -i, or 1, but it's not.
2. Ever notice how graph screen calculations are hardly ever rounded properly? A lot of the time it's (x-1).999 or x.002.
3. Argh! I don't remember this one, but trust me: it was convincing.
4. It's slow, which is a large factor in why TI-BASIC is so slow.
5. Number variables always have an imaginary coefficient, even when the calc isn't in Imaginary mode. If they changed this, lists would be half the size they are right now.
using int() on things like 3(X/3) can when X is an integer will occasionally return X-1. iPart is ridiculously slow.
haveacalc wrote:
A few things:
5. Number variables always have an imaginary coefficient, even when the calc isn't in Imaginary mode. If they changed this, lists would be half the size they are right now.
I believe that's wrong. There are REAL lists (type 01h) and complex lists (type 0Ch). One is 9 bytes for every number, one is 18.
Whoops, my mistake. Only lettered number variables are 18 bytes regardless of their content.
brandonw wrote:
haveacalc wrote:
A few things:
5. Number variables always have an imaginary coefficient, even when the calc isn't in Imaginary mode. If they changed this, lists would be half the size they are right now.
I believe that's wrong. There are REAL lists (type 01h) and complex lists (type 0Ch). One is 9 bytes for every number, one is 18.
correct, although I think he's half right, I do seem to recall A-theta always being 18bytes regardless of complexity
No, those are REALs as well (and become complex if necessary). There are REALs, complex numbers, real and complex lists, and real matrices.
I'd like to try making a platformer for the contest, but I', in the middle of making a RPG, and I haven't really looked into sidescrolling or being able to do things like jumping...
I can't wait to see what games will be made for this contest.