i think you should look into optimizations before you finish everything, because there's probably a lot of good optimizations that would require redesigning some things, and get harder the more stuff in in the game since it would all need to be changed.
I'm not sure I agree with this. Maybe if you're very confident that you've fully designed the user interface and are able to code it you can jump right in with optimization. But usually what happens with new software is that you write it, and then the users tell you everything you did wrong, or didn't do at all, and so you fix those things, and then they tell you more things to fix, etc.
And then, when the user complaints slow down, you start over again and think about optimization. You have to start writing version 0 with the attitude that none of its code will make it into version 1. (Because you're right that optimizing one part of the program is likely to require changes all over the rest of it.)
"It's easier to optimize a working program than to debug an optimized program." (In quotation marks because I know I learned that maxim from someone else, but I forget who.)
P.S. This is also why smart programmers write the first version in a high-level language such as Lisp even if they're super worried about optimization and therefore intend to write the second version in C or something.
this isn't commercial software, it's extremely unlikely there's going to be much feedback or that a large amount of it will be followed.
i can't quite express why but i don't think that quote applies to this situation, and here it would be the exact opposite. all i can really say is it's a snap project, it isn't going to be that complicated. (not that the project isn't complicated, but it's still one person on something that they're calling "the bad 2d minecraft clone")
what i've heard most about any hobby project is that any proposed massive rewrites simply won't happen, and are more likely to just kill the project.
I'd say that for most Snap! projects, optimization is the last thing on the programmer's mind. It sounded to me as if you were stating a general principle and then applying it to this project specifically. I agree with you that a Snap! programmer doesn't necessarily have to think about user feedback at all, but if it's an interactive project then maybe they do.
Whatever, didn't mean to start an argument, sorry!