Call out to populate database tables (not static) in the initial game state.

[FastMahina]

So I understand about how the system loads the static game information on startup (well probably not all the details), but I was wondering if there is a call out where additional information can be loaded into the database from a file the game creator can upload at game creation, but before opening the game to other users. Is there such function before the game state?

[RicardoRix]

There is no such function. Game options are the traditional way to start a game with different setups.
There is nothing stopping you from creating (inserting) data in the DB after the game has started, but you would need to have predefined the tables in dbmodel.sql.
I presume you could create a JS file upload button and then pass data to the server. But loading data from a file doesn't sound great and has never been done before AFAIK.
I would suggest once the game has started, you could figure out which player is the 'Game Master' and provide some kind of interface to setup the game. Sounds like a friendlier interface than editing and uploading a file. But still try to do as much of this (if not all of it) through the traditional game options.

[gilthe]

Following RicardoRix, if you wanted to do something like this and have it fit more into the BGA framework, it should be possible to define a unique state (along with unique, selected player roles) that is entered on starting a new game. In this state, only the master can interact with the board, e.g., set up monsters, obstacles, etc. As mentioned, you would have to provide a UI for it, but that it is, presumably, preferable to having your game masters write custom input files to upload. It is straightforward to have this state be only visited once and never thereafter. Of course the complexity of the required UI is a concern (rules- and scenario-dependent).
I don't think it is feasible to create a custom combat scene through game options. You'll have better control managing it all in a custom database imo. Afaik, in the BGA framework, it is not possible to defer entry of players until later either. That's generally unnecessary because you can use a unique setup state as mentioned above. What is not clear to me is how much persistence you want to have, if any. If you isolate BGA involvement to combat or similar scenes and leave the rest outside of BGA, it might be a feasible project, essentially as a "fake" game with no meaningful ELO/stats. The downside is having to reenter character information repeatedly. For persistence, BGA supports a campaign-type setting but in a limited manner: the studio doc says only up to 64K per player. This part of the API makes functions like "retrieveLegacyTeamData" or "storeLegacyTeamData" available that would help transferring a party from a prior table to the next.

(Disclaimer: my inference of what you are trying to accomplish is based on the other question; apologies for any misunderstanding)

[FastMahina]

Thanks guys, this is the sort of information I need. And thanks for reading the other post and understanding that I'm not interested in doing the graphics on BGA, but more the action taking and sequencing of events. I think I can get most of the data as static (the monster) and that is where I want the persistence. That can all go into the game definition files. I assume there is way to identify the game initiator, and as gilthe suggests add a special state for monster selection, followed by a state to load player data, both with UI, Then a multiactive player state that lets the players and GM insert future events into a "deck", and then a couple of game states that pop events out of the deck based on class of event(move,adjust,defense, attack) and time the event should occur. Each player would just see their "character" and whether that character can take another action with legs, right arm, or left arm during the multiactiveplayer state.

The other use of persistence is for people that get disconnected. The session is still there when they are reconnected. So no persistence beyond the session. (Though I'll look into the team data stuff.) The combat is only a text based system and happens really fast. Your players take actions or they don't and when you've finished all the monster actions, you move to the next phase and the events generated by previous actions pop out. So "games" should be a 5-15 minute affair. As opposed to a D&D combat session that can last hours, as players dither on what incredible power they will take Instead everyone takes their action not knowing nor overly discussing options and at the same time, and then the chips(events) fall where they may. Plus each body part only has a limited number of actions (stab, swing, swing hard, parry, drop, sheath, draw, punch, adjust position, move 1/3, move 2/3, run or kick). So at most players take 3 actions for each character in a turn. 3 clicks and they are done. And later everyone sees what has happened. So this is the point - to have a fair, fast, and complex combat system. The fair and fast parts will drive D&D'ers crazy.

Time for me to start reading the configuration files on some other games. Anyone know how they implement private hands in Splendor? I guess hearts has a private hand too?

[RicardoRix]

Here is the BGA Studio:
https://en.studio.boardgamearena.com/welcomestudio

and the docs:
https://en.doc.boardgamearena.com/Studio

You may want to download a project or two to have a look around, or follow a tutorial.

You can use the php notifyPlayer to send private information to just 1 player.
Again In the getAllDatas()/gamedatas you need to load in private information specific to the player.