Weeeeell. It’s not so much that we won’t accept it. But I’m something of an ornery individual, especially when it comes to the submission of Hosted Games projects. And there are a list of common mistakes that are made that we’ve discussed at length in various places (maybe we need to collate those somewhere?). When someone submits a game that has three or four of those mistakes in the first game file, I get very testy very quickly.
For example, I’m going back and forth right now with an HG author who’s game doesn’t pass quicktest, but he keeps sending it to me, saying it’s done. It’s very hard to not start screaming at him for so blatantly wasting my time.
The back-end of ChoiceScript is in Javascript, and in Javascript–to the best of my understanding–capitalization matters. So, as long as you’re consistent, it shouldn’t be a problem. But most people make mistakes and aren’t consistent. Therefore, it’s easier to just make all variables lower-case. And even if you do include upper-case variables, it may not produce an error, or maybe it produces an error that you don’t even detect. The point being, it’s better to be safe.
And even more so when it comes to String variables.
eg:
*set solution "Compassion"
#option1
*if solution = "compassion"
Right answer!
*goto youwin
*else
Wrong answer! You're thrown from the bridge and die!
*goto_scene death
In that instance, the player would die/lose, because “Compassion” =/= “compassion”, but if you weren’t super-careful, you wouldn’t even notice, because the *else catches everything else. And a player might not know to report that as a bug!
Similarly with the variables, we’re often trying to export to new platforms. While we have the whole variable thing pretty well sorted for iOS and Android, what if we put your game on Windows8, and it does matter that the variables are all consistent?
I hope you see what I’m driving at here.