Hey, wadda you know? Looks like that update did more than add a screenshot function!
Summer Programming Contest 2018
Root / Site Discussion / [.]
After over 170 days since the last contest... it's finally time to try one of these again.
One Screen Program Contest the Second
SUBMISSION DEADLINE: July 8th, 2018 11:59pm EST
VOTING DEADLINE: July 15th, 2018 midday (12:00pm) EST
About OSP:
An OSP, or "one-screen program" is a program that fits within one editor screenshot (1334 characters).
For eligibility in this contest, the intent of the restriction is that your program will run if typed in by hand from a single screenshot of the built-in editor at WIDTH 8 on a 3DS system.
This means:
You can't submit a pre-existing program, it must be an original submission. Novel adaptations of existing projects may be acceptable. One entry (key) per user. Using sockpuppets to get around any rules or cast extra votes will result in bad things such as disqualification entirely.
Submission: Submit entries by uploading a code screenshot and (temporary) key to http://smilebasicsource.com/osp/. This step is REQUIRED for all entries. You must also provide a unique filename matching the filename in the key. To make it easier, we suggest using a prefix based on your username (for example, LU_PLANTS might be mine). You can also provide gameplay screenshots and a short description at this point -- if you need more, you can always create a real page or reply to this thread.
If you do not have your program submitted to the OSP section, it will not be counted. Please be sure to do it correctly!
Additional Information: Because this contest is held to test the viability of future official contests, there is no monetary prize offered, and the format is thus a less demanding one. Please treat it as a challenge of your programming skill in a small space. Even if you dislike the format, participation will provide valuable data for contest staff.
(Badges are still offered)
There is no required theme.
At the end of the submission period, voting will be conducted as normal. Please try your best.
For tips on reducing code size to fit within the available space, please check out https://smilebasicsource.com/forum?ftid=1775
- Only unambiguous characters typeable on the default keyboard are legal
- No other files may be included, including graphic assets. WRITING to files is acceptable: the initial state must only be the single file.
- You must be able to provide an actual screenshot of your code at submission.
Standard Rules
optional inspiration
Although there is no theme specified because most theme components will come from graphics and text, which are very expensive in OSP, some patrons prefer to have one for inspiration. For those patrons, we suggest the broad theme of "global warming" and the people and environments it affects.
How strict are we on the type-in rule? Are only characters which are present on the keyboard valid? Are kanji symbols thusly illegal?
Rule could be more specifically realized as "characters you can type in on the keyboard or obtain from a sample resource" to allow KANJITBL but disallow any wiley symbols which are assigned but unvailable without CLIPBOARD CHR$ tricks.
Is the intent that the source needs to be unambiguously readable as a text representation in SB's character set? This raises other issues involving character duplicates.
How strict are we on the type-in rule? Are only characters which are present on the keyboard valid? Are kanji symbols thusly illegal? Rule could be more specifically realized as "characters you can type in on the keyboard or obtain from a sample resource" to allow KANJITBL but disallow any wiley symbols which are assigned but unvailable without CLIPBOARD CHR$ tricks.Yeah anything that can be typed from the keyboard is what we mean. Like even if the character is kinda hard to find, as long as it's there it's fine.
We expect to be able to deal with "theoretically reproducible" on a case-by-case basis, including for duplicate characters.
The rules do not forbid kanji.
...It might forbid blank non-space characters if such characters exist.
The rules have been updated.
Legal characters are those available on the default keyboard.
I have compiled a list of all unique characters, without having checked for any "visual dupes", that you can type in. There seems to be a few that you otherwise couldn't tell apart when looking at them, including an "invisible" one, but I'm going to write a program to determine this is actually true and I'm not seeing things.
The results will be published so we may continue this endeavor, and potentially write a machine validator for submissions.
How do you bring up the kanji table? If it's too hard I'm thinking kanji won't be allowed (remember, kanji is different than kana). I was hoping only characters you can see on the keyboard that are unambiguous will work, and I feel like this rule will only be ACTUALLY important for programs that are compressed. I don't think we need to be so particular about EXACTLY which characters, since the "keyboard only" rule should deter most compression anyway.
The rules have been updated to reflect a change in the definition of the legal character set.
Only unambiguous characters that can be typed on the default keyboard are legal.
This includes all "pages" of the keyboard.
This excludes kanji and unreadable characters.
Hopefully this does not compromise any possible Japanese entries.
I feel like the restrictions shouldn't apply to unused parts of the program
I think that all valid, unique characters should be legal, even if they can't be typed on a keyboard. So if someone wanted to compress their entire program they would have to generate each and every "valid" character before they could decompress it. This process takes about 30 minutes without DLC, which is pretty pointless and in no way worth it. And if you're concerned about recreating the program (even though it takes far less time just to download the key) I generated all the valid, unique characters (4KY5Z37D).
My opinion is that the contest should be fair. This should mean that for the few that want to be really creative (Like 12ME21) can use valid characters that can't be typed on a keyboard for aesthetic purposes. But, this should also mean that compression is restricted to the point that it has to be readable.
Right, which is why kanji were allowed at first, but random argued that most everyone here can't actually identify the kanji at 8x8. If only a few showed up, that would be fine, but under a compression system the entire program would be a block of kanji. It's not feasible to copy 1000 characters one-by-one that you can't even recognize, so it's not legal. Because the rule has to be general and not filled with exceptions, this means restricting legal characters to those on the keyboard.
*The spirit of OSP is that it could be reproduced from a single screenshot.
If a program includes comments with otherwise unavailable characters that do not have any effect on program execution, this may be acceptable... but I'm not sure I want to introduce such an exception here, as they should be irrelevant anyway.
I think that all valid, unique characters should be legal, even if they can't be typed on a keyboard. [...] And if you're concerned about recreating the program (even though it takes far less time just to download the key) I generated all the valid, unique characters (4KY5Z37D).
Right, which is why kanji were allowed at first, but random argued that most everyone here can't actually identify the kanji at 8x8. If only a few showed up, that would be fine, but under a compression system the entire program would be a block of kanji. It's not feasible to copy 1000 characters one-by-one that you can't even recognize, so it's not legal. Because the rule has to be general and not filled with exceptions, this means restricting legal characters to those on the keyboard. *The spirit of OSP is that it could be reproduced from a single screenshot.This. I know that any character that's visible and identifiable from a screenshot can technically be typed through some means, but I want people to be able to just look at the screenshot and easily type it. It's hard to identify, for instance, a particular kanji out of the block of 1000 available on SB, even if you have a program that displays them all. People usually don't keep around their OSP keys, which is why we require the screenshots so they can be retyped. As lumage said, the spirit of OSP is that it's not dependent on the transfer method; the program should be able to be retyped from a screenshot. If THIS osp contest turns out to be too restrictive, we can experiment with extended (identifiable) character sets for future ones. We're planning on doing lots of these.
So... would it be fine if I use one character (CHR$(57711)) that's not located on the keyboard and has no negative effect on the game if someone trying to recreate it couldn't find it?For this contest, don't add it (I'm sorry). We'll figure out how to handle this stuff in the next contest. I don't want people trying to retype it go "I can't find this symbol so I give up". Edit:Now, if you want to make a real page for your game, feel free to use whatever character you want in that one.Maybe I should just remove it. That wold solve all my problems.