$r$ determines the sequential read size. This should only be changed if you have custom hardware that has a memory subsystem with different characteristics. It takes time to pull data from main memory, and the sequential read size allows the memory latency and CPU processing to be well-balanced on your system. Treat it like a constant unless you know what you're doing. Too large and your hash could be weaker than you expect as it allows an attacker to use a slower, cheaper memory system; too small and your computer will process it inefficiently. May be any positive number. $16$ is probably good today. Also note that $r = 1$ disables a mixing step.
$N$, with $r$, determines the memory block size and hashing iterations ($128\cdot N\cdot r$ bytes, $2\cdot N\cdot r$ rounds of hashing). This is the one you change, and you should make it as big as your usage can handle. Some implementations of the scrypt algorithm only allow powers of $2$, but could be any value greater than or equal to $2$ theoretically.
$p$ determines the number of parallelizable iterations. It allows you to increase hashing power over $N$ alone. Best if you are memory restricted and can't increase $N$ more, or if you want to use multiple processors to compute more hashes in the same time (if you can afford $p$-times more bytes). But you should prefer larger $N$ over larger $p$ in general, as $N$ is responsible for the memory-hardness that makes scrypt unique. May be any positive number.
There are maximum limits to these numbers, but they almost don't need to be worried about because the memory requirements would be astronomical.
Sadly there isn't a lot of discussion or analysis of the parameters, and even fewer about $r$, leading to many misconceptions.