introduction day setup about mozaic HOT 15 CLOSED

I vote for tournament day. Maybe cause I don't get how a ranker would fit into what we have now?

from mozaic.

@wschella about the same as a tournament, but we'd have to automate it as well. I think I'm also in favour of the tournament day, because of the event value.
Maybe we can do it on the same day as our Zeus-quiz?

from mozaic.

Not a fan, as to not overload the evening, we could help people underway after the quiz tho. Casually...

from mozaic.

Back to the setup!

We'll need:

• A functioning bot driver and game implementation, of course
• A browser setup running visualizer and bot code
• A bridge from the browser to the bot driver
• A way to start the bot driver from within the browser (begin a new game)
  Discussion point: Do we use an ad-hoc way to handle this for now, or do we handle this from within the bot driver (which would implement a primitive 'matchmaker')?

from mozaic.

I feel like ad-hoc is the way to go, trying to do it well will make us solve problems for a future that is based on logic that is riddled with inconsistencies anyway.

from mozaic.

What do you mean by 'based on a logic that is riddled with inconsistencies anyway'?

from mozaic.

As we found out with our implementation of the botdriver, actually having to write the code makes you discover holes in your logic, resulting often in a need for refactoring/remodeling. I assume the same will happen for the matchmaker; unfortunately we are not in a position to really push trough with refactoring now, since we have a limited usecase with our MVP. So trying to implement a non-ad-hoc version now will leave us with a bad middle grounds solution: over-engineered for our MVP use case, and under-engineered for further use cases.

from mozaic.

@wschella I kind of agree with you, but I don't see how this situation is more desirable than creating an ad-hoc solution that will have to be trashed afterwards.
To be clear: I didn't mean actually implementing a matchmaker, more like a logical component that would sit in the same place as where a matchmaker would go. In other words: a 'stub implementation', that already has bindings in place.

from mozaic.

@iasoon the ad-hoc solution will be a trivial amount of work, and a lot of the stub code will be trashed just the same.

from mozaic.

@wschella Keep in mind that we'll need a web server, and start games. Apart from actually matching people based on some criterion, that is exactly what a matchmaker would do.

from mozaic.

You might have a point, I wasn't taking into consideration that we can't just call executables from within a browser. Alternative: could we run blockly in electron?

from mozaic.

We could, but I don't know how desirable of a solution that is. We will need a tcp connection anyways to bridge to the bot driver (since it requires sub processes, which our browser/electron client will not be). The only alternative I can see is uploading the code generated by blockly and running it in nodejs, but that doesn't seem that 'fun' ...

from mozaic.

I think the nodejs solution isn't all that bad tho. It would allow for the following flow of control:

• Run electron app with blockly
• People code their bot
• When they run their code:
  • Blockly to JS
  • Electron saves JS somewhere
  • Electron makes a config file that sets node as an interpreter for the generated JS
  • Electron runs botdriver with above config
  • Electron visualizes the log
• Go to step 2

from mozaic.

Another option might be to let the visualizer and blockly run in a browser, and connect to a small python server running somewhere. This server would then start a bot-runner instance.
As a bonus, this would allow us to do networked play already - it might be fun to let two friends battle each other!

from mozaic.

This seems like an elegant solution. Although HTTP might get in the way some places. Websockets?

from mozaic.