Comments (15)
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.
Related Issues (20)
- Protect client ids against German tanks
- Proper request/response abstraction HOT 3
- Rust networking client
- Port the electron client to the new event system
- Implement an event-driven matchmaker
- Time out connections
- Strongly typed requests
- Event-driven routing HOT 1
- Proxy server
- Multiple "tasks"
- The role of network events
- Event-driven typescript bot driver
- Migrate from error-chain to failure
- gameserver logging HOT 5
- Latency information HOT 1
- Request errors HOT 1
- Allow standalone visualizer to take logfile path as CLI
- Consistent formatting for typescript HOT 2
- Gitlab migration - repo reorganisation HOT 5
- dependencies have security issues
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mozaic.