Main game logic: yourgamename.game.php - História úprav

Pikiou: /* Game states and active players */ Precision on setPlayersMultiactive

2013-04-18T14:32:20Z

Game states and active players: Precision on setPlayersMultiactive

← Staršia verzia		Verzia z 16:32, 18. apríl 2013
Riadok 259:		Riadok 259:
	; $this->gamestate->setPlayersMultiactive( $players, $next_state )		; $this->gamestate->setPlayersMultiactive( $players, $next_state )
	: Make a specific list of players active during a multiactive gamestate.		: Make a specific list of players active during a multiactive gamestate.
			: Bare in mind it doesn't deactivate other previously active players.
	: "players" is the array of player id that should be made active.		: "players" is the array of player id that should be made active.
	: In case "players" is empty, the method trigger the "next_state" transition to go to the next game state.		: In case "players" is empty, the method trigger the "next_state" transition to go to the next game state.

Sourisdudesert: /* Zombie mode */

2013-03-06T15:35:34Z

Zombie mode

← Staršia verzia		Verzia z 17:35, 6. marec 2013
Riadok 498:		Riadok 498:
	}		}
	</pre>		</pre>

			Note that in the example above, all corresponding game state should implement "zombiePass" as a transition.

Sourisdudesert: /* Zombie mode */

2013-03-06T15:35:02Z

Zombie mode

← Staršia verzia		Verzia z 17:35, 6. marec 2013
Riadok 472:		Riadok 472:

	Most of the time, the best thing to do when it is zombie player turn is to jump immediately to a state where he is not active anymore. For example, if he is in a game state where he has a choice between playing A and playing B, the best thing to do is NOT to choose A or B, but to pass. So, even if there's no "pass" action in the rules, add a "zombiepass" transitition in your game state and use it.		Most of the time, the best thing to do when it is zombie player turn is to jump immediately to a state where he is not active anymore. For example, if he is in a game state where he has a choice between playing A and playing B, the best thing to do is NOT to choose A or B, but to pass. So, even if there's no "pass" action in the rules, add a "zombiepass" transitition in your game state and use it.

			Each time a zombie player must play, your "zombieTurn" method is called.

			Parameters:
			* $state: the name of the current game state.
			* $active_player: the id of the active player.

			Most of the time, your zombieTurn method looks like this:

			<pre>
			function zombieTurn( $state, $active_player )
			{
			$statename = $state['name'];

			if( $statename == 'myFirstGameState'
			\|\| $statename == 'my2ndGameState'
			\|\| $statename == 'my3rdGameState'
			....
			)
			{
			$this->gamestate->nextState( "zombiePass" );
			}
			else
			throw new feException( "Zombie mode not supported at this game state: ".$statename );
			}
			</pre>

Sourisdudesert na 15:32, 6. marec 2013

2013-03-06T15:32:43Z

← Staršia verzia		Verzia z 17:32, 6. marec 2013
Riadok 461:		Riadok 461:
	: Base class to notify a system exception. The message will be hidden from the user, but show in the logs. Use this if the message contains technical information.		: Base class to notify a system exception. The message will be hidden from the user, but show in the logs. Use this if the message contains technical information.
	: You shouldn't use this type of exception except if you think the information shown could be critical. Indeed: a generic error message will be shown to the user, so it's going to be difficult for you to see what happened.		: You shouldn't use this type of exception except if you think the information shown could be critical. Indeed: a generic error message will be shown to the user, so it's going to be difficult for you to see what happened.

			== Zombie mode ==

			When a player leaves a game for any reason (expelled, quit), he becomes a "zombie player". In this case, the results of the game won't count for statistics, but this is cool if the other players can finish the game anyway. That's why zombie mode exists: allow the other player to finish the game, even if the situation is not ideal.

			While developing your zombie mode, keep in mind that:
			* Do not refer to the rules, because this situation is not planned by the rules.
			* Try to figure that you are playing with your friends and one of them has to leave: how can we finish the game without killing the spirit of the game?
			* The idea is NOT to develop an artificial intelligence for the game.

			Most of the time, the best thing to do when it is zombie player turn is to jump immediately to a state where he is not active anymore. For example, if he is in a game state where he has a choice between playing A and playing B, the best thing to do is NOT to choose A or B, but to pass. So, even if there's no "pass" action in the rules, add a "zombiepass" transitition in your game state and use it.

Sourisdudesert: /* Game states and active players */

2013-03-06T15:09:55Z

Game states and active players

← Staršia verzia		Verzia z 17:09, 6. marec 2013
Riadok 230:		Riadok 230:
	: Check if action is valid regarding current game state (exception if fails)		: Check if action is valid regarding current game state (exception if fails)
	: The action is valid if it is listed as a "possibleactions" in the current game state (see game state description).		: The action is valid if it is listed as a "possibleactions" in the current game state (see game state description).
	: This method ~~should~~ be called in the first place in ALL your PHP methods that handle players action, in order to make sure a player can't do an action when the rules disallow it at this moment of the game.		: This method MUST be called in the first place in ALL your PHP methods that handle players action, in order to make sure a player can't do an action when the rules disallow it at this moment of the game.
	: if "bThrowException" is set to "false", the function return false in case of failure instead of throwing and exception. This is useful when several actions are possible in order to test each of them without throwing exceptions.		: if "bThrowException" is set to "false", the function return false in case of failure instead of throwing and exception. This is useful when several actions are possible in order to test each of them without throwing exceptions.

Sourisdudesert: /* Game states and active players */

2013-03-06T15:09:36Z

Game states and active players

← Staršia verzia		Verzia z 17:09, 6. marec 2013
Riadok 266:		Riadok 266:
	: Usually, you call this method during a multiactive game state after a player did his action.		: Usually, you call this method during a multiactive game state after a player did his action.
	: If this player was the last active player, the method trigger the "next_state" transition to go to the next game state.		: If this player was the last active player, the method trigger the "next_state" transition to go to the next game state.

			; $this->gamestate->checkPossibleAction( $action )
			: (rarely used)
			: This works exactly like "checkAction", except that it do NOT check if current player is active.
			: This is used specifically in certain game states when you want to authorize some additional actions for players that are not active at the moment.
			: Example: in Libertalia game, you want to authorize players to change their mind about card played. They are of course not active at the time they change their mind, so you cannot use "checkAction" and use "checkPossibleAction" instead.

	== Players turn order ==		== Players turn order ==

Sourisdudesert: /* Notify players */

2013-02-12T11:54:45Z

Notify players

← Staršia verzia		Verzia z 13:54, 12. február 2013
Riadok 322:		Riadok 322:

	You can use arguments in your notification_log strings, that refers to values defines in the "notification_args" argument (see below).		You can use arguments in your notification_log strings, that refers to values defines in the "notification_args" argument (see below).

			Note: you CAN use some HTML inside your notification log, and it is working. However:
			_ pay attention to keep the log clear.
			_ try to not include some HTML tags inside the "clienttranslate" method, otherwise it will make the translators work more difficult. You can use a notification argument instead, and provide your HTML through this argument.

	* notification_args:		* notification_args:

Sourisdudesert: /* Managing errors and exceptions */

2013-01-29T22:14:15Z

Managing errors and exceptions

← Staršia verzia		Verzia z 00:14, 30. január 2013
Riadok 428:		Riadok 428:

	== Managing errors and exceptions ==		== Managing errors and exceptions ==

			Note: when you throw an exception, all database changes and all notifications are cancelled immediately. This way, the game situation that were existing before the request is completely restored.

	; throw new BgaUserException ( $error_message)		; throw new BgaUserException ( $error_message)

Sourisdudesert: /* Notify players */

2013-01-29T22:12:43Z

Notify players

← Staršia verzia		Verzia z 00:12, 30. január 2013
Riadok 299:		Riadok 299:
	== Notify players ==		== Notify players ==

	To understand ~~notification~~, please read [http://www.slideshare.net/boardgamearena/the-bga-framework-at-a-glance The BGA Framework at a glance] first.		To understand notifications, please read [http://www.slideshare.net/boardgamearena/the-bga-framework-at-a-glance The BGA Framework at a glance] first.

			'''IMPORTANT'''

			Notifications are sent at the very end of the request, when it ends normally. It means that if you throw an exception for any reason (ex: move not allowed), no notifications will be sent to players.

	'''notifyAllPlayers( $notification_type, $notification_log, $notification_args )'''		'''notifyAllPlayers( $notification_type, $notification_log, $notification_args )'''

Sourisdudesert: /* Accessing database */

2013-01-29T22:11:07Z

Accessing database

← Staršia verzia		Verzia z 00:11, 30. január 2013
Riadok 60:		Riadok 60:

	'''IMPORTANT'''		'''IMPORTANT'''

	BGA is using [http://dev.mysql.com/doc/refman/5.0/en/sql-syntax-transactions.html database transactions]. It means that your database changes WON'T BE APPLIED to the database until your request ends normally. Using transaction is in fact very useful for you: at any time, if your game logic detects that something is wrong (ex: unallowed move), you just have to throw an exception and all the changes already performed on the game situation will be removed.		BGA is using [http://dev.mysql.com/doc/refman/5.0/en/sql-syntax-transactions.html database transactions]. It means that your database changes WON'T BE APPLIED to the database until your request ends normally. Using transaction is in fact very useful for you: at any time, if your game logic detects that something is wrong (ex: unallowed move), you just have to throw an exception and all the changes already performed on the game situation will be removed.