[nddrylliog]

I try not to blame players - although it might not show I've already done quite a bit of user testing (esp. with non-coders to make sure it's relatively easy to follow.

In this case, the 'numans' part was the last one I added, in a hurry, and only had 2-3 iterations on this part of the dialog/instructions.

Which goes to show: testing matters, iterations makes things better.

Thanks for the feedback!

[rajahafify]

with regards to numan parts, its not creative. just plain code repeat. Get a condition going. like numan and borg where borg will eat numan if numan is less than borg or something

[nddrylliog]

It's merely a setup for a more creative problem which I didn't have time to include. Here's the actual problem: numans have different weights, which incurs a speed penalty on the transport vehicle - numans[i] has a penalty of 2^i - the goal is to write code to carry them all in the minimum possible time (15 units).

For a coder, the numan part is easy and boring and repetitive - then again, it fits with the universe. For a non-coder, it's their first or second encounter with a piece of code that's more than 4 lines long, with a detailed log so that they can go back and forth to see where they went wrong. They have several rules that they need to pay attention to (capacity, 1 passager minimum required, auto-unload, be very precise with station names) - which, again, seems trivial to you as a coder, but isn't to everyone.

There's already so many instructions for this problem, I wanted to add the time penalty part as a second problem, e.g. "your solution would work, but we can't afford to spend N time units on this transfer - (insert additional instructions here)". I'm sure you understand the need for a consistent difficulty curve.