Provide a way to play games in ScottFree-like split-screen mode

[MikeTaylor]

Either using the broken-apart play method that @drewish created in PR #16, or by introducing the notion of a driver which provides input and output methods for some specific device.

[drewish]

I think one thing that would be worth examining as part of this is separating out the play functionality into its own object. Right now it’s nice having it in its file but since it’s mixed into the game class it doesn’t have a clear boundary between the two pieces of functionality. I got tripped up by this trying to extract some of the input output because the compiling and decompiling are all sharing the same object with the play methods.

My gut instinct would be to get a data structure for the game, and one for the save state, then have functions that return modified copies of those structures. But that idea exists on a continuum so we could have more of an object oriented approach.

[drewish]

If you do go down the driver route I think you'd want to make a sleep method part of that interface. It would give a the driver a clear spot to flush any output before sleeping.

[MikeTaylor]

Good idea on the sleep method.

I am less attracted to the idea of a Play object. I'm not seeing that it brings us much, and it materially increases the complexity of the code. The Game object represents a game (duh), and play seems a perfectly reasonable method on it.

More generally, I am more inclined to invest time in fixing bugs and adding functionality than in restructuring already-existing working code. Of course, when we need to do the latter in order to achieve the former, that's great -- as with your separating play out into sub-methods that it calls. But restructuring for its own sake is not exciting.