Wizard Tower integration

[mgale456]

Somehow we need to integrate the wizard towers into the gameserver. Possibly as a separate python script.

In order to score it, it can just update the Db directly and wouldn't have to mess with Django. Once we figure out how we are dynamically updating the score on the screen, we may need to adjust this.

[lpulley]

I think, theoretically, the game elements should run in separate containers and manually apply changes to the database, not touching Django.

[mgale456]

I agree they should be separate. Probably easier to do for future game elements too, since it would be software independent, and anyone could do it anyway they want as long as it can edit the Db.

Any ideas how we would have it also tell Django to update the score so it is up to date? Probably something we'll have to figure out later.

[lpulley]

I'm working on this. I successfully have the serial-to-USB devices connecting to the new Docker container (from the new Compose service) in the towers-service branch, and a Python program that parses the input from the IR transmitters.

The remaining work on this part is to:

• generate secret words (spells) for each team for each round, prompted somehow by the judge system "match setup"
• store the spells in the database where the judge interface can access them (to inform the teams)
• check each input word to determine if it matches a team's spell
• assign points to teams based on time owned per tower

This will be spring break work for me as well, I imagine.

[mgale456]

Communicating with Django through websockets in Python seems like it should be pretty doable, and then the Django side is easy as well, since it would be built in.

So we're on the same page, this is what I see as the necessary ideal communications to/from this container:

To:

1. Django tells it to prepare a game whenever a game has its teams (put magic words in the database)
2. Django tells it when a specific game starts (container begins listening for words, and adding actions for scoring to the db)
3. Django tells it when a specific game ends Django sends an end_time with the start game messages. (stops listening for words, or at least stops scoring in the db)
4. Django tells it to pause a game, but we could probably do this with the other two if necessary
5. Django tells it the game is finalized (this one is not necessary for the wizard tower, but could be sent)

Note: The game could conceivably be paused until after the old end_time has passed. The unpause message (sent as a start message with a speific end_time) will send the new end_time. We need to make sure this doesn't cause issues.

From:

1. Puts magic words in the db when given a game ID
2. Puts scoring actions in the db per the rules (1 every 9 seconds for each tower) (we could potentially store this some other way, but I think this is best for any future electronically scored task)
3. (If we have time) Tells Django when it updates the db, so Django can update the score

[lpulley]

With more experienced eyes, I think now that we need to have a small API that allows external apps (e.g. wizard towers) to POST scoring events, GET current scores, etc. I recommend looking into Django REST Framework. It can be a new Django app inside the Django project we already have.

This way, the current match state doesn't have to be kept in multiple places. If a tower submits a score event to e.g. POST /api/score/<match-id>/, then the server can decide whether or not to accept the score event (and return a 2XX or 4XX response code to indicate whether it has accepted it).

This strategy can also extend to other things. We can even use this API in our own apps; manual scoring can just be buttons that send POST requests. This way, there's one way to control and read the score: the API. Everything (both the web interface and external scripts) could use the same API, and if we want to make changes, we only have to make them in one place.

[mgale456]

Neat. How much of the websocket communication would this replace? All, scoring, timing, score updates? I used it primarily since we needed the clients to update dynamically, and it's an easy way I found to do that, but idk if it's the right way.

I'm familiar with the concept of APIs, but haven't used them much at all, so I'm not super sure of all the capabilities, or exactly how to use them. We can't communicate back out to clients, right? Also, would we use Ajax requests for the scoring POST requests from the judges? I've heard of that as an option for sending requests without changing the page.

[lpulley]

Let's talk about this at the meeting.

…

On August 2, 2020 22:35:43 mgale456 ***@***.***> wrote: Neat. How much of the websocket communication would this replace? All, scoring, timing, score updates? I used it primarily since we needed the clients to update dynamically, and it's an easy way I found to do that, but idk if it's the right way. I'm familiar with the concept of APIs, but haven't used them much at all, so I'm not super sure of all the capabilities, or exactly how to use them. We can't communicate back out to clients, right? Also, would we use Ajax requests for the scoring POST requests from the judges? I've heard of that as an option for sending requests without changing the page. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.