Practice round

[lexbailey]

(Moved from old repo)

A lot of groups end up having two goes through spacehack - one where they fail on the first round, and then another where they actually manage through a few. These are currently either separated by the 'game over' and 'game start' sequences (and holding the buttons again), or someone needs to forcibly restart the server process to expedite it.

We were musing around this idea, and figured that maybe just a round where there aren't any lives to track, and maybe with just two instructions each - one untimed, and one with a long timeout - just to get folk to see how it operates. Players who are returning should find this such a simple round it would be over quickly, while new players would have a chance to pick up the mechanics.

(Nick yorkhackspace/ConsoleGame#20)

[lexbailey]

After giving this some thought, this makes sense and I would do it like this: I would have the first round have really long instruction time outs and ensure that all instructions issued are inter-console instructions to avoid people thinking their console is isolated.

I would have the game not track any lives until each person has completed one of these inter-console instructions, then it can start tracking lives and go to the proper speed for the first round and then introduce single-console instructions. In general I think that single-console instructions should be rare. The probability of single-console instructions can increase on each round if it needs to (to make it easier) but should be limited to something well below a half. Perhaps a quarter?

[aquila12]

A very long (possibly infinite) timeout during the first round, coupled
with a low number of instructions plus infinite lives sounds reasonable.

I think it's probably wise not to have single-console instructions in that
round as you mention.

As to normal play, I'm not sure whether or not inter-console instructions
should be biased. What you suggest would be the case for 4-player games
anyway; I think it being completely random (for a given number of players)
potentially makes it slightly more difficult, for example if you've not
fully read your own console. To do biasing, it's likely that different
numbers would be best for a given number of players.

The only way to really find out is to try it; the difficulty is in getting
meaningful results.

Although we're getting a bit off on a tangent with regards to "difficulty";
would it be worth isolating all the difficulty-related variables (lives,
time, same-console probability), and rather than assigning them directly at
the start of a round, feed a difficulty rating into a function which sets
them up appropriately for the number of players?

Depending on the implementation, it might then be easy to write difficulty
profiles, and set up the game to use a different profile on-command - for
example, use the "practice" profile during the first round, or change
profile after N rounds (or after a certain time threshold); or even
manually (via MQTT from a command-line tool).

I have a notion on how to make profiles "work", but I think in Rubyisms, so
I'd need some time to figure that bit out in Python.

I'd like to contribute some actual code to SpaceHack, but I need to do some
practice work in Python to be useful at anything other than code analysis.

On 25 October 2015 at 14:46, Daniel Bailey notifications@github.com wrote:

After giving this some thought, this makes sense and I would do it like
this: I would have the first round have really long instruction time outs
and ensure that all instructions issued are inter-console instructions to
avoid people thinking their console is isolated.

I would have the game not track any lives until each person has completed
one of these inter-console instructions, then it can start tracking lives
and go to the proper speed for the first round and then introduce
single-console instructions. In general I think that single-console
instructions should be rare. The probability of single-console instructions
can increase on each round if it needs to (to make it easier) but should be
limited to something well below a half. Perhaps a quarter?

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[lexbailey]

Github has been helpful and thrown my replay away, perhaps it can't handle inline responses.
Here it is again:

On Sun, Oct 25, 2015 at 2:59 PM, Nick Moriarty notifications@github.com wrote:

A very long (possibly infinite) timeout during the first round, coupled
with a low number of instructions plus infinite lives sounds reasonable.

I think it's probably wise not to have single-console instructions in that
round as you mention.

As to normal play, I'm not sure whether or not inter-console instructions
should be biased. What you suggest would be the case for 4-player games
anyway; I think it being completely random (for a given number of players)
potentially makes it slightly more difficult, for example if you've not
fully read your own console. To do biasing, it's likely that different
numbers would be best for a given number of players.

Hmm. I'm fairly sure that spaceteam is biased towards inter-console instructions.
I thought this was to maximise the need for [time-consuming] communication between players.

The only way to really find out is to try it; the difficulty is in getting
meaningful results.

Second.

Although we're getting a bit off on a tangent with regards to "difficulty";
would it be worth isolating all the difficulty-related variables (lives,
time, same-console probability), and rather than assigning them directly at
the start of a round, feed a difficulty rating into a function which sets
them up appropriately for the number of players?

Depending on the implementation, it might then be easy to write difficulty
profiles, and set up the game to use a different profile on-command - for
example, use the "practice" profile during the first round, or change
profile after N rounds (or after a certain time threshold); or even
manually (via MQTT from a command-line tool).

Yes, this sounds good. Not so sure about a command line tool, but some kind of tool maybe.

I have a notion on how to make profiles "work", but I think in Rubyisms, so
I'd need some time to figure that bit out in Python.

I'd like to contribute some actual code to SpaceHack, but I need to do some
practice work in Python to be useful at anything other than code analysis.

I'm currently trying to refactor bits of spacehack so that it is more robust and easier to maintain.
I'm going to try and make it testable. (And then write some tests.) So anticipate changes.