Closed drewish closed 6 years ago
I went ahead and put that up at https://github.com/drewish/scottbot I'll work on getting a proper readme in there to make it a little clearer how to get it up and running.
It's nice to see this progressing. The changes to ScottKit itself are obviously benign, and I will merge them momentarily. A couple of questions about your client code, though ...
Why does MyGame
need to be a subclass of ScottKit::Game
? So far as I can see, it merely uses stuff from a ScottKit::Game
, so delegation seems more appropriate than inheritance?
Why do you call game.decompile(StringIO.new)
?
The only reason I'm subclassing at this point is to replace $stdout
with my object. We could make that an option that defaults to the current value.
Good note on the decompile
. I think it was copy pasta'ed from the play method in the binary that runs from source. I'd switched to an .sao at some point and never removed it.
I was going to say "the only reason ever to call decompile is if you want to get a SCK". But I see from my own bin/scottkit
that that's not quite true:
def play(game)
# Decompile (and discard result) to get entity names resolved in
# right order. This ensures that debugging output that uses these
# names will use them in the same way as decompiler output.
dummy = StringIO.new
game.decompile(dummy)
game.play
end
Right, that's exactly where I'd gotten it. I didn't realize it still came into play with the compiled files as well.
Well, it doesn't really. I should wrap that use. New issue incoming.
Just a note that this isn't capturing output from instructions so output from actions that call print will be lost. #32 starts to address this issue.
This "Fixes #8" but is really just a conversation starter. It's currently rebased on #15 so we can ensure the specs pass.
Here's the hacky script I'm using so you can get and idea of how the input and output are handled: