Board Game Arena

Hi, I would like to use this topic to suggest to the admin some possible changes to the framework.
I got some expertise about realtime application and BGA framework because I'm developing a new non-trivial game.
I started with only 2 proposals but I do not exclude that there may be others in the near future.

Better file organization
It's really hard to define all the game mechanics inside 2 file (xxx.game.php and xxx.js). It would be better if I could include some external file, creating indipendent and reusable game components without having a huge single PHP or JS object (with the risk of overwrite methods).

"Hidden" notification
Sometimes I had the need to send some inhomogeneous data to the client through notification and I decided to split in some atomic "single-action" messages (like cardDrown, cardPlayed...) in a way that would allow me to have some generic notification handler on the client detaching game logic from game interface. It would be better if I could send a two type of notification: a single visible full notification (player XXX has drown 1 cards, has played 3 tokens and got 10 score point) ignored by js with only display purpose and some hidden logic notifications that would have been managed only by the js engine. Without this chance I was forced to show a lot of little notification to the players.

Developers, what do you think about this two proposals? Are you agreed with me or I'm totally wrong?
I would like to discuss with you

Hi,

About the first one : it's a good idea, but this is not ideal to do as the file structure should be identical from one project to another for building & management purpose. I know it's not ideal, but you can define all your constants in material.inc.php so that your "game.php" only have pure code. But I understand your point.

About the second point: this is totally feasible. The notification text is not mandatory, so you can:

• Send a notification without any text and execute some action on JS client side.
• Send a notification with a text without any handler on JS client side (just to display a text notification).
• Send a notification with a text AND an handler on JS client side (most frequent situation)

Hope this answer your question

sourisdudesert wrote: Send a notification without any text and execute some action on JS client side.

What a beautiful answer

Another proposal about notification:
notifyAllButPlayers($exceptPlayerId, $notificationType, $notificationDescription, $notificationData)

It will be useful in some context, for example when a player draws a card. We could send a personal notification to the active player ("You draw Black Lotus") and a generic notification to all but him ("tarini draws a card").

What do you think about this?

I would use it all the time, but I got over the idea a long time ago
How the communication works on BGA is players register to channels, and when the server sends a message to a specific channel, only registered players of that channel get it.
Making notifyAllButPlayers work without changing the communication system (CometD) would be impossible on tables with many players (2^X-X-2 more channels on a table with X players). You could make it work by having only one player ignored by the notification though (only X more channels).

In the meantime, having your private player ignore the generic notification data is the best solution I know even if it means polluting his/her chat logs with the generic notification description.

I cannot understand. CometD works having a "always opened" connection with server for every connected client (I can see this using various developer tools in firefox).
On server side, I guess, there is a sort of map with playerIds as keys and "request objects" as values. If you need to send a single notification, you will retrieve request object looking up inside this map; if you need to send a broadcast notification you will loop over all the requests.
Why you could not loop discarding a particular playerId?

Well maybe does this channel system come from something else than CometD then. But it's there
I do want your suggestion to pass, I'm merely trying to explain why the system would need lots of changes and therefor need time (maybe even forever).

pikiou wrote:Well maybe does this channel system come from something else than CometD then. But it's there
I do want your suggestion to pass, I'm merely trying to explain why the system would need lots of changes and therefor need time (maybe even forever).

Just to know, have you accesso to framework souce code? You speak as you know something that we don't know

I did have access and I don't anymore.

I was thinking...
what about a WebSockets version of BGA?