Dang, I'm surprised nobody responded.
Well, I'm not the best at making programs, but I think I can do well even if the coding is a mess.
Since you're already aware of arrays, here's some other things to keep in mind:
Always begin programs with ACLS. It clears any alterations to SmileBasic before if affects the program.
Experiment. Since there aren't many guides about anything other than the basics, you're going to have to try to figure things out on your own. Even if what you learned isn't usable in your program, you should share that information because to be honest few seem to know/share much of this knowledge.
Learn from other's programs. Even if you don't understand what the heck is going on, use what you do know to reverse engineer the game. See what happens when something's gone or stripped down to the bare bones and how you can apply this information to your program.
Use DEF. Define your own functions to make things clean and simple. You could also do things like apply a command to a phrase, but I've had issues with that (for example, BB=BUTTON(0)==#B never works for me if I use "BB" to shorten it.)
As for game ideas, I think a realistic start would be something like a matching game. Since you make music, you could use RND, arrays, and REPEAT to play a clip of your song. You'd use RND to randomly select a track, use the array to remember the previous track, and REPEAT to keep randomising until the track number does not match what's in the array. This way, nothing will play twice in a row.
After that, you could use the d-pad to guess which song played. For example, #UP would make another array hold a track's number. If the "last song" array (which could update as the current track plays) and the "guessed track" match, you win.
Sorry if this is too specific/hard or something. Got the idea from a Luigi's Mansion boss, haha.