GameAPI needs updating

[michaelmilakovic]

The startGame functions needs to be updated to supply the game with a communication medium (MVars, channels, etc.)

[Kalior]

Exactly what does the game need?

[michaelmilakovic]

A channel for receiving GameAction and one for sending. I believe the easiest way is to use MVars

EDIT: of course besides what is already supplied to the function.

[Kalior]

Can you give the type of the startGame function as you want it?

[Tejpbit]

I would recommend using channels because of their duplication feature. With MVar the server would need to write and read from a pair of MVars for each client.

It looks to me that a games communication works very similar to that of how a the chats currently are implemented.

Each game needs channel which the server can hold in it's state with a list of game channels. All clients who is going to join the game then gets to hold a duplicate of the game channel in it's state which the client then activly reads from.

This is exactly how the chat works. In fact, chat is interchangeable with game in the previous paragraph.

[michaelmilakovic]

My initial thought was the following: startGame :: [String] -> Elem -> MVar GameAction -> MVar GameAction -> Client ()

Due to the Control.Concurrent.Chan not working with Haste when the code is compiled to JavaScript the seemingly easier solution would be using MVars from the Control.Concurrent package.

When I looked at the Haste.Concurrent package I could only find MBox as a viable option, and I believe it is implemented with MVars.

[Tejpbit]

Control.Concurrent.Chan can't be compiled with haste. We solved this by adding an api method from which the client can tell the server to listen on its channel an return when it reads a new value. The client then runs this api function in a new thread.

Sidenote, i think just about everything is implemented with MVars in some way. I know the Chan type is aswell.

Can the MBox be duplicated? I'm still thinking about how the implementation of passing the game-actions around on the server is to be made.

[michaelmilakovic]

Ok, I will look into that API.

I don't think the MBox can be duplicated.

[Tejpbit]

Clientside function which listen to Server, if you haven't already found it. https://github.com/DATx02-16-14/Hastings/blob/development/src/Views/Chat.hs#L110-L123

[Kalior]

As a side note: wouldn't it be more proper to use Haste.App.Concurrent for MVars? http://haste-lang.org/docs/haddock/0.5.4/Haste-App-Concurrent.html

[michaelmilakovic]

I think it shouldn't be a problem from the games perspective, its just a matter of what the lobby supplies

[Kalior]

As far as I'm concerned, we can give you exactly what you want :trophy:

[Tejpbit]

So far we've used Control.Concurrent.MVar throughout the project. I think this is because they were used in the examples we examined at the start of the project.