introduction day setup

[iasoon]

Some plumbing has to be done to join everything together and actually let people play a game at the press of a button.

Ideally, we would have 'stages', which lets your bot fight against progressively stronger opponents (or harder maps).
This way, we would have a nice intro-day minigame, which we can then follow op with an intro-week competition for new students.

Plug: Do we need a ranker for the competition, or do we organise a 'tournament day' on which we let the bots battle in single/double elimination style, shown on a large screen?

[wschella]

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

[iasoon]

@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?

[wschella]

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

[iasoon]

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')?

[wschella]

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.

[iasoon]

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

[wschella]

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.

[iasoon]

@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.

[wschella]

@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.

[iasoon]

@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.

[wschella]

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?

[iasoon]

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' ...

[wschella]

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

[iasoon]

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!

[wschella]

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