Well, no one is going to spend the entire time playing the games, but if we force people to wait before voting, they might go back and try the programs more, and possibly change their mind about which ones are the best. Also, the amount of code doesn't really determine how much gameplay there is. I've played games like Tetris for hours, and I bet that could fit in about 1 page of code. (I'm not making tetris though) I remember in the first contest I voted for one entry, then ended up playing a different one a lot more. If I had spent more time playing them before voting, I might have picked the better game. Allowing multiple votes has reduced this problem, but maybe not completely eliminated it.I think for a contest, having more gameplay isn't as important since most people aren't going to test the games for very long before voting (Maybe we should wait a few days between the end of the submission period and the beginning of the voting period, so people might spend more time playing the games rather than making a quick decision.)How much gameplay can someone possibly fit into one screen of code? I'd say one or two days would be enough.
Summer Programming Contest 2017
Root / Site Discussion / [.]
LacksCreated:
what do you mean by WIDTH 8 and line wrap?
in case you somehow didnt notice, that was meant to be lighthearted too as a joke reeee. stop taking everything so personally*Sigh* Since you somehow missed it, it was a lighthearted pat-on-the-back, not serious...I mean, my intentions should have been kind of clear with the "=D".Showoff. =DIsn't that the point of the contest though
A couple questions:
First, how long is the voting period? I'll be gone until the 30th, so I want to know if I'll have time to vote.
Second, are we allowed to use text compression? In other words, are we allowed to use the CHR$() and ASC() commands to compress two characters into one? This kind of takes away the challenge of the contest.
A couple questions: First, how long is the voting period? I'll be gone until the 30th, so I want to know if I'll have time to vote. Second, are we allowed to use text compression? In other words, are we allowed to use the CHR$() and ASC() commands to compress two characters into one? This kind of taks away the challenge of the contest.My humble opinion is if you know the trick, and can make it work.... DO IT. I don't see how that compression saves space. (HORRAY for the bliss of my ignorance!) I've asked for a tip earlier today, and I found this and I want to share this noobtip: E=DIALOG("instructions on button to press",-1,"TITLE",0) is a nice cheap (space ways) for a simple button input command. The command is not a catch all, as nothing else can run while in use. But it helped me reduce the total character count by 45.
My entry is not a game. It is a simple starfield for both 3DS and WiiU.
The program will detect system type (3DS or WiiU) and set screen size and number of stars.
public key : RRREV3AE
source code
Here is screenshot of 3DS starfield. (512 stars are used)
Here is screenshot of WiiU starfield. (4096 stars are used)
Woah, my first contest entry (somehow.)
Micropaint
A half-res limited paint tool in spirit of chatdraw. Features six tools, a rainbow of eight colors, and an undo function (up to 3 times back; no redo though.)
Key: S34XHF
I'm not exactly amazing at minification, but I don't think any space was absolutely wasted. A fair effort went into feature choice and presentation, so even if I don't win I'm rather satisfied. (Also I really like making paint tools for some reason.) I wanted to add things like redo but I simply don't think there is space permitting unless I somehow do a full rewrite.
If you have any suggestions, tips for shrinking etc. do let me know. There's still time to improve my entry (and yours!)
images
First place winner should be required to explain their code, and or break it into parts so everyone can have an idea to what methods they used. (That or I need to put my beginner badge back on, and stop pretending to know anything)