Board Game Arena - User contributions [en]

Gamehelpturingmachine

2024-01-11T15:01:03Z

Mike Crosley: /* Overview */

===Overview===

The objective of the game is to be the first player to correctly solve the code, and with the fewest questions asked, or be the only player not eliminated.

===Turn===

A turn consists of four or five stages, with each stage carried out simultaneously/ The stages are:

# '''Compose'''
# '''Question'''
# '''Deduce'''
# '''End'''
# '''Verification''' (Not in all rounds)

===Compose===

In this phase, each player decides on a number for each colour/shape. A number may be used for multiple shapes (e.g. three triangles three squares, two circles).

===Question===

Players pick up to three of the '''Verifiers''' and see how their '''Proposal''' meets their criteria.

'''Two Important Notes:'''

# The '''Verifiers''' do NOT correspond to colors and/or shapes. For example:
## ''Two '''Verifiers''' may contain criteria towards the same '''colour/shape''''', ''or''
## ''A single '''Verifier''' may ask if '''Yellow/Square''' is '''Even''',''
## ''Another '''Verifier''' may ask if '''Yellow/Square''' is '''greater than''' '''three''''')
# The '''Correct''' and '''Incorrect''' answer received does NOT mean the number is right or wrong, but whether or not your proposal passed for that the '''Verifier.'''

===Deduce===

After completing the '''Verification''' step, take some time to figure out (but not declare) if you have found the answer.

===End===

At the end, count to three, then reveal either a '''thumbs up''' (if think you know the code) or a '''thumbs down''' (if you are not sure of the code)

If everyone pointed down, return to Compose Phase

If at least one person pointed up, move to the Verification Phase

===Verification===

The correct code will pass the test of ALL verifiers

If one person is correct, they win!

If more than one person is correct, the person who asked the fewest questions wins!

If no one is correct, they are eliminated!

If the second to last person is eliminated, the final player, even though they did not participate in Verification, will win!

=== Mode ===

==== Classic ====
1 card for each verifier.

==== Extreme ====
2 cards for each verifier but only one valid criterion.

==== Nightmare ====
You do not know which verifier is associated with which verification card.

Gamehelpturingmachine

2024-01-11T13:11:55Z

Mike Crosley: A number of grammatical corrections and a small amount of reformatting.

===Overview===

The aim is to solve the code correctly, first, and with the fewest questions asked (Or be the only player not eliminated)

===Turn===

A turn consists of four or five stages, with each stage carried out simultaneously/ The stages are:

# '''Compose'''
# '''Question'''
# '''Deduce'''
# '''End'''
# '''Verification''' (Not in all rounds)

===Compose===

In this phase, each player decides on a number for each colour/shape. A number may be used for multiple shapes (e.g. three triangles three squares, two circles).

===Question===

Players pick up to three of the '''Verifiers''' and sees how your proposal meets their criteria.

'''Two Important Notes:'''

# The '''Verifiers''' do NOT each correspond to a colour/shape (''i.e. two '''Verifiers''' may contain criteria towards the same '''colour/shape''''', ''or a single '''Verifier''' may ask if '''Yellow/Square''' is '''Even''' and another '''Verifier''' may ask if '''Yellow/Square''' is greater than the '''number three''''')
# The '''Correct''' and '''Incorrect''' answer you receive does NOT mean your number is right or wrong, but rather that in relation to the '''Verifier'''. whether or not your proposal passed that '''Verifiers''' test

===Deduce===

After completing verification, take some time to figure out (but not declare) if you have found the answer.

===End===

At the end, count to three, then reveal either a thumbs up (think you know the code) or a thumbs down (not sure of the code just yet)

If everyone pointed down, return to Compose Phase

If at least one person pointed up, move to the Verification Phase

===Verification===

The correct code will pass the test of ALL verifiers

If one person is correct, they win!

If more than one person is correct, the person who asked the fewest questions wins!

If no one is correct, they are eliminated!

If the second to last person is eliminated, the final player, even though they did not participate in Verification, will win!

=== Mode ===

==== Classic ====
1 card for each verifier.

==== Extreme ====
2 cards for each verifier but only one valid criterion.

==== Nightmare ====
You do not know which verifier is associated with which verification card.

Game database model: dbmodel.sql

2022-09-11T09:45:13Z

Mike Crosley: /* Default tables */

{{Studio_Framework_Navigation}}

In this file you specify the database schema of your game.

This file contains SQL queries that will be executed during the creation of your game table.

'''Note:''' you can't change the database schema during the game.

__TOC__

== Create your schema ==

To build this file, we recommend you to build the tables you need with the PhpMyAdmin tool (see BGA user guide), and then to export them and to copy/paste the content inside this file.

'''Note:''' you must not use for a column the same name as for the table, as the framework replay function relies on regexp substitution to save/restore a previous state in a clone table with another name.

Example: Deck component, see [[Deck]]

<pre>
CREATE TABLE IF NOT EXISTS `card` (
`card_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`card_type` varchar(16) NOT NULL,
`card_type_arg` int(11) NOT NULL,
`card_location` varchar(16) NOT NULL,
`card_location_arg` int(11) NOT NULL,
PRIMARY KEY (`card_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
</pre>

Example: Euro Game. See details on database design for euro game at [[BGA_Studio_Cookbook#Database_for_The_euro_game]]
<pre>
CREATE TABLE IF NOT EXISTS `token` (
`token_key` varchar(32) NOT NULL,
`token_location` varchar(32) NOT NULL,
`token_state` int(10),
PRIMARY KEY (`token_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
</pre>

Rules you should follow:

* Do not overcomplicate, you are dealing with games with 50-500 pieces!
** If you have 5 tables for a card game with 30 cards - it is overkill
* Database should only be storing dynamic data, all static data should be stored in material.php.inc
** Example: if you have cards that have power, color and special abilities. In the database you only need to store the card type, all the other properties should not be there. Only exception being if it changes during the game.
* Columns should be permanent, independent of game data, i.e. location, type, position, row, etc
** Example: do not create columns like Country1, Country2, Country3, ...
* Do not store translatable string in the database, use integer number of "ident" to access properties
** I.e. card type should be "22" or "bob_cat", instead of "Bob's cat"
* Create separate module in php to handle all database queries, do a lot of type checking to prevent SQL injections

Example of method handling database query:

<pre>
// Set token state
function setTokenState($token_key, $state) {
self::checkState($state); // ensure state is number
self::checkKey($token_key); // ensure key is alphanum
$sql = "UPDATE " . $this->table;
$sql .= " SET token_state='$state'";
$sql .= " WHERE token_key='$token_key'"; // don't need to escape anymore since we checked key before
self::DbQuery($sql);
return $state;
}
</pre>

== Default tables ==

By default, BGA creates four tables for your game: '''global''', '''stats''', '''gamelog''', and '''player'''.

You '''MUST NOT MODIFY''' the schemas of the '''global''', '''stats''' or '''gamelog''' tables (and you must not access them directly with SQL queries in your PHP code).

=== The '''player''' table ===

You may add columns to the '''player''' table. This is very practical to add simple values associated with players. '''NB:''' you must not alter existing columns created by the framework.

Example:
<pre>
ALTER TABLE `player` ADD `player_reserve_size` SMALLINT UNSIGNED NOT NULL DEFAULT '7';
</pre>

The commonly used columns of default "player" table are:
* player_no: the index of player in natural playing order (starting with 1)
* player_id (int)
* player_name: (note: it is better to access this data with getActivePlayerName() or loadPlayersBasicInfos() methods)
* player_score: the current score of the player (displayed in the player panel). You must update this field to update player's scores.
* player_score_aux: the secondary score, used as a tie breaker. You must update this field according to tie breaking rules of the game (see also: [[Main_game_logic:_yourgamename.game.php#Manage_player_scores_and_Tie_breaker|Manage_player_scores_and_Tie_breaker]])

* player_table_order: gives an indication of the rank of the player by order of arrival in the lobby (starting with 1). It is not the same as player_no (which is the player order within the game). player_table_order is useful for setting custom teams if desired in a game option (for instance, 1st-2nd vs 3rd-4th). Note: player_table_order ''only exists during game initialization'' (in the '''setupNewGame''' function). It is not added as a column in the '''players''' Db table.

CAUTION: '''player_table_order''' is not guaranteed to be equal to the rank of the player in the table. For example, in a four-player game, if the table was full but the third player leaves before the game starts, the fourth player becomes the third on this table but their player_table_no is still equal to four! If another player then joins, their player_table_no will then be 5... Thus, it is essential to normalize these values first in the game setup if you wish to use them to prevent bugs at game launch. For example, if the set of player_table_order are <player A>: 3, <player B>: 2, <player C>: 5, <player D>: 7, you see that you can't read that values as ranks directly, but you can still deduce that <player B> was first on the table, then <player A> then <player C> then <player D> 😉

See [https://en.doc.boardgamearena.com/BGA_Studio_Cookbook#Assigning_Player_Order Assigning Player Order] in the '''BGA Studio Cookbook''' for an example.

== CREATE TABLES ==
You can create tables, using engine InnoDB.
See examples above on how to create tables.
Pay attention to the following:
* Always add IF NOT EXISTS
* Always set ENGINE=InnoDB DEFAULT CHARSET=utf8
* Define primary keys
* If you create NOT NULL fields after game in production, make sure you took care of database migration

'''Note''': if you put comments, you cannot do it in the same line as code.

Example:

<pre>
`activated` BOOL NOT NULL DEFAULT 1, -- activated or not
</pre>

will also comment out whole column `activated` BOOL, and that code will not be executed.

== PHP ==
Database initialization should be in function setupNewGame() in 'gamename.game.php'.

Database schema migration should be in function upgradeTableDb(), see below.

Warning: all CREATE/ALTER tables and view should be in dbmodel.sql. Do not call these queries from php to avoid implicit commits https://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
which will cause issues. The only time you can do such queries from php is in the upgradeTableDb method.

== Errors Log ==
To trace Database creation check the logs that you can access in /admin/studio.

== Post-release database modification ==
If you want to modify your database schema after the first release of your game in production, you should implement upgradeTableDb method, see [[Post-release phase#Updating the database schema|Updating the database schema after release]]

[[Category:Studio]]