BGA Studio Guidelines - Historial de revisións

Amadannabriona: /* II-6 Avoid move confirmations */

2018-10-06T20:20:02Z

II-6 Avoid move confirmations

← Revisión máis antiga		Revisión como estaba o 6 de outubro de 2018 ás 22:20
Liña 124:		Liña 124:
	* Use synchronous notifications handlers to slow down the execution of automatic actions,so that players can understand what is happening.		* Use synchronous notifications handlers to slow down the execution of automatic actions,so that players can understand what is happening.
	=== II-6 Avoid move confirmations ===		=== II-6 Avoid move confirmations ===
	As a rule of thumb, don't ~~provide a way to confirm a~~ move. Confirming a move slows down the user interface and thus, the game flow. You can ~~eventually~~ allow a player to confirm a move if this is a very critical step in a game, and if it is possible ~~that a player triggers the~~ action by accident. If client ~~interaction is~~ very complex and ~~allows~~ cancellation, final move can be confirmed with "Done" button.		As a rule of thumb, don't require move confirmation. Confirming a move slows down the user interface and thus, the game flow. You can allow a player to confirm a move if this is a very critical step in a game, and if it is possible to trigger an action by accident. If client interactions are very complex and allow cancellation, the final move can be confirmed with a "Done" button.

	Hawaii: ~~ending~~ a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.		''Hawaii'': Ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.

	Hive: ~~each~~ move ~~have~~ to be confirmed with click on the location because it very easy to click by accident		''Hive'': Each move has to be confirmed with click on the location because it is very easy to click by accident.

	Russian Railroads: move involves multiple interactions and can contains dozens of subactions~~, when~~ player is done "planning" he ~~pressed~~ "Done" button to submit move to server.		''Russian Railroads'': Each move involves multiple interactions and can contains dozens of subactions. When the player is done "planning" he presses a "Done" button to submit the move to the server.

	=== II-7 Translatable interface ===		=== II-7 Translatable interface ===

Victoria la: /* II-3 Make your interface intuitive */

2018-01-06T02:09:40Z

II-3 Make your interface intuitive

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:09
Liña 100:		Liña 100:
	If your testers have different opinions about « how to trigger some game action », maybe		If your testers have different opinions about « how to trigger some game action », maybe
	the best is to make several options possible for this game action. In the case there is a complex action to do by the player (ex: select some cards, then click on an action button), design your error messages in order they can guide the player(ex : « please select some cards first »).		the best is to make several options possible for this game action. In the case there is a complex action to do by the player (ex: select some cards, then click on an action button), design your error messages in order they can guide the player(ex : « please select some cards first »).
	Tips: For complex games, it is simple and useful to highlight the area of the interface where player should focus his attention (using onEnteringState/onLeavingState and CSS).
			''Tips: For complex games, it is simple and useful to highlight the area of the interface where player should focus his attention (using onEnteringState/onLeavingState and CSS class, i.e. 'active_slot').''

	The Boss: when a player clicks on a card with no selected cubes, the interface tells us to select some cube first.		The Boss: when a player clicks on a card with no selected cubes, the interface tells us to select some cube first.

Victoria la: /* II-1 Use tooltips */

2018-01-06T02:07:52Z

II-1 Use tooltips

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:07
Liña 85:		Liña 85:
	* What happens if I click on it?		* What happens if I click on it?
	However, tooltips should NOT be used to display dynamic information about the current game to save space on the game interface.		However, tooltips should NOT be used to display dynamic information about the current game to save space on the game interface.
	Typically, regular players should be able to card tooltip play with no tooltips.		Typically, regular players should be able to card tooltip play with no tooltips.
	Tips : you can place any HTML element in tooltips. So you can make them as rich and beautiful as you need :)		However you can display some dynamic stuff if its available otherwise but just annoying to calculate. For example in Lewis and Clark author asked to put
			tooltips of how many river space available ahead of explorer.

			Tips: you can place any HTML element in tooltips. So you can make them as rich and beautiful as you need :)

	=== II-2 Use left click only ===		=== II-2 Use left click only ===

Victoria la: /* I-2 Make it fluid */

2018-01-06T02:04:25Z

I-2 Make it fluid

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:04
Liña 40:		Liña 40:
	* To allow players with a screen of just 1024px		* To allow players with a screen of just 1024px

	Tips: for each element of the game, answer this question « how many times during a game do I need to check/use this element? ».Less frequently used elements can be placed below		Tips: for each element of the game, answer this question « how many times during a game do I need to check/use this element? ».Less frequently used elements can be placed below.
			You can listen on display resize in JS to do more sophisticated layouts.

	Examples:		Examples:
Liña 46:		Liña 47:
	Caylus: when we have a 1024px small width to play the game – even if they have to screen, available buildings are placed scroll on the the right and below the board.		Caylus: when we have a 1024px small width to play the game – even if they have to screen, available buildings are placed scroll on the the right and below the board.
	On larger screen, these tiles are placed on the right of the board. This is a very basic usage of the others. « float:left » CSS property.		On larger screen, these tiles are placed on the right of the board. This is a very basic usage of the others. « float:left » CSS property.


	=== I-3 Use whiteblocks ===		=== I-3 Use whiteblocks ===

Victoria la: /* I-1 Don't hide game elements */

2018-01-06T02:02:57Z

I-1 Don't hide game elements

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:02
Liña 22:		Liña 22:
	But you are lucky: your game will be on a webpage with a scrolling functionality.		But you are lucky: your game will be on a webpage with a scrolling functionality.
	Basically, you always have some more space available .		Basically, you always have some more space available .
	Don't hide game elements behind menus, submenus, dialogs, … but display them directly on the main page.		Don't hide game elements behind menus, submenus, dialogs, etc, but display them directly on the main page.

	Tips: eventually, you can use HTML anchor link to jump between the different elements of the page if the page height is very big.		Tips: eventually, you can use HTML anchor link to jump between the different elements of the page if the page height is very big.

Liña 28:		Liña 29:

	In Amyitis, characters cards are elements you don't have to check all the time. Thus, we placed them at the bottom of the page and you have to scroll to see them.		In Amyitis, characters cards are elements you don't have to check all the time. Thus, we placed them at the bottom of the page and you have to scroll to see them.

			In Madeira, additional game board are shown at the bottom, but when player needs to use it it moved up.

	=== I-2 Make it fluid ===		=== I-2 Make it fluid ===

Victoria la: /* II-6 Confirm a move */

2018-01-06T02:01:32Z

II-6 Confirm a move

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:01
Liña 116:		Liña 116:
	* Use the game log to trace all actions performed automatically.		* Use the game log to trace all actions performed automatically.
	* Use synchronous notifications handlers to slow down the execution of automatic actions,so that players can understand what is happening.		* Use synchronous notifications handlers to slow down the execution of automatic actions,so that players can understand what is happening.
	=== II-6 ~~Confirm a~~ move ===		=== II-6 Avoid move confirmations ===
	As a rule of thumb, don't provide a way to confirm a move. Confirming a move slows down the user interface and thus, the game flow. You can eventually allow a player to confirm a move if this is a very critical step in a game, and if it is possible that a player triggers the action by accident.		As a rule of thumb, don't provide a way to confirm a move. Confirming a move slows down the user interface and thus, the game flow. You can eventually allow a player to confirm a move if this is a very critical step in a game, and if it is possible that a player triggers the action by accident. If client interaction is very complex and allows cancellation, final move can be confirmed with "Done" button.

	Hawaii : ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.		Hawaii: ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.

			Hive: each move have to be confirmed with click on the location because it very easy to click by accident

			Russian Railroads: move involves multiple interactions and can contains dozens of subactions, when player is done "planning" he pressed "Done" button to submit move to server.

	=== II-7 Translatable interface ===		=== II-7 Translatable interface ===

Victoria la: /* I-3 Use whiteblocks */

2018-01-06T01:54:35Z

I-3 Use whiteblocks

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 03:54
Liña 46:		Liña 46:

	=== I-3 Use whiteblocks ===		=== I-3 Use whiteblocks ===
	White blocks are « div » HTML element with the « whiteblock » class (white and transparent background). This is the recommended way to gather game elements together in your game interface when they are not directly on a board.		White blocks are '''div''' HTML element with the '''whiteblock''' class (white and transparent background). This is the recommended way to gather game elements together in your game interface when they are not directly on a board. Whiteblocks helps you to organize the space in order it can be easily understood by players.
	Whiteblocks helps you to organize the space in order it can be easily understood by players.

	~~Tips:~~ you ~~can use a <h3> title~~ inside the whiteblock ~~to help players to understand what is inside or to who it belongs~~.		If game contains individual player boards with distinct colors or marking you don't need these boards inside the whiteblock.

	In The Year of the Dragon game interface, with whiteblocks and h3 titles /picture here/		''Tips: you can use a '''h3''' title inside the whiteblock to help players to understand what is inside or to who it belongs.''

			In The Year of the Dragon game interface, with whiteblocks and h3 titles /picture here/

	=== I-4 Use player panels ===		=== I-4 Use player panels ===

Victoria la: /* Game usability */

2018-01-06T01:43:11Z

Game usability

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 03:43
Liña 77:		Liña 77:
	=== II-1 Use tooltips ===		=== II-1 Use tooltips ===

	With BGA Studio its very easy to associate ~~atooltip~~ on any element of the game.Each time this is possible : add a tooltip ~~toexplain~~ to the players :● What is this game element?● What happens if I click on it?However, tooltips should NOT be used ~~todisplay~~ dynamic information about the ~~currentgame~~ to save space on the game interface. ~~Seasons : a~~ Typically, regular players should be able to card ~~tooltipplay~~ with no tooltips.Tips : you can place any HTML element in tooltips. So you can make them as rich and beautiful as you need :)		With BGA Studio its very easy to associate a tooltip on any element of the game. Each time this is possible: add a tooltip to explain to the players:
			* What is this game element?
			* What happens if I click on it?
			However, tooltips should NOT be used to display dynamic information about the current game to save space on the game interface.
			Typically, regular players should be able to card tooltip play with no tooltips.
			Tips : you can place any HTML element in tooltips. So you can make them as rich and beautiful as you need :)

	=== II-2 Use left click only ===		=== II-2 Use left click only ===
	● The whole game should be playable with only simple left button mouse ~~clicks~~.● Context menus should not be used.~~●Dragndrop~~ should be avoided (if you want to use it anyway, you should make a click ~~basedalternative~~ available).● Mouse icon must change on ~~cliquable~~ elements (« cursor:pointer » CSS property)..		* The whole game should be playable with only simple left button mouse click.
			* Context menus should not be used.
			* Drag-n-drop should be avoided (if you want to use it anyway, you should make a click based alternative available).
			* Mouse icon must change on clickable elements (« cursor:pointer » CSS property).

	=== II-3 Make your interface intuitive ===		=== II-3 Make your interface intuitive ===
	If your testers have different opinions ~~about«~~ how to trigger some game action », maybe ~~The Boss : when a player clics on a card~~ the best is to make several options possible for ~~with no selected cubes, the interface tell~~ this game action~~. us to select some cube first~~.In the case there is a complex action to do ~~bythe~~ player (ex : select some cards, then ~~clickon~~ an action button), design your ~~errormessages~~ in order they can guide the player(ex : « please select some cards first »).Tips : For complex games, it is simple and useful to highlight the area of the interface where player should focus his attention (using onEnteringState/onLeavingState and CSS).		If your testers have different opinions about « how to trigger some game action », maybe
			the best is to make several options possible for this game action. In the case there is a complex action to do by the player (ex: select some cards, then click on an action button), design your error messages in order they can guide the player(ex : « please select some cards first »).
			Tips: For complex games, it is simple and useful to highlight the area of the interface where player should focus his attention (using onEnteringState/onLeavingState and CSS).

			The Boss: when a player clicks on a card with no selected cubes, the interface tells us to select some cube first.

	=== II-4 Use the gamelog ===		=== II-4 Use the gamelog ===
	With BGA Studio it is very easy to place sometext (or HTML code) in the gamelog.~~Dont~~ hesitate to use the game log.Players are not always in front of the ~~gamepage~~ when their opponents are making ~~theirmoves~~.In addition, the computer manipulates ~~gameelements~~ faster than you usually do with ~~thereal~~ board game and even regular players ~~canget~~ behind of what happened sometimes.You should be able to understand the « ~~gamestory~~ » by reading the game log. ~~Caylus : game log extract~~		With BGA Studio it is very easy to place sometext (or HTML code) in the gamelog.
			Don't hesitate to use the game log.
			Players are not always in front of the game page when their opponents are making their moves.
			In addition, the computer manipulates game elements faster than you usually do with the real board game and even regular players can get behind of what happened sometimes.
			You should be able to understand the « game story » by reading the game log.

	=== II-5 Tell players about automatic actions ===		=== II-5 Tell players about automatic actions ===
	Very often, during a game you are in ~~asituation~~ where :● Only one action is possible for the activeplayer, ~~or●~~ A series of action has to be done (~~accordingto~~ the rules) without any players actions.In these situation, you must or you may ~~triggerthese~~ actions automatically.In any case, you must make sure that ~~playersunderstand~~ what is happening, ~~otherwisetheyll~~ probably report a bug. Stone Age : people are fed automatically at the end of the turn, ~~● Use the game log to trace all actions~~ but players can always see what ~~performed automatically.~~ happened exactly in the gamelog.● Use synchronous notifications handlers ~~toslow~~ down the execution of automatic actions,so that players can understand what ~~ishappening~~.		Very often, during a game you are in a situation where:
			* Only one action is possible for the activeplayer, or
			* A series of action has to be done (according to the rules) without any players actions.
			In these situation, you must or you may trigger these actions automatically.
			In any case, you must make sure that players understand what is happening, otherwise they will probably report a bug.

			Stone Age: people are fed automatically at the end of the turn, but players can always see what happened exactly in the gamelog.

			* Use the game log to trace all actions performed automatically.
			* Use synchronous notifications handlers to slow down the execution of automatic actions,so that players can understand what is happening.
	=== II-6 Confirm a move ===		=== II-6 Confirm a move ===
	As a rule of thumb, ~~dont~~ provide a way ~~toconfirm~~ a move.Confirming a move slows down the ~~userinterface~~ and thus, the game flow.You can eventually allow a player to confirm ~~amove~~ if this is a very critical step in a game,and if it is possible that a player triggers ~~theaction~~ by accident. Hawaii : ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.		As a rule of thumb, don't provide a way to confirm a move. Confirming a move slows down the user interface and thus, the game flow. You can eventually allow a player to confirm a move if this is a very critical step in a game, and if it is possible that a player triggers the action by accident.

			Hawaii : ending a turn is a critical action that happens only 5 times per player in a game. In this case, it is acceptable (and a good idea) to have a confirmation dialog.

	=== II-7 Translatable interface ===		=== II-7 Translatable interface ===
	With BGA Studio its very ~~easyto~~ translate your game in ~~anylanguage~~, using ~~BGAcollaborative~~ translation system.Check the FAQ and the ~~examplegames~~ to learn how to ~~declareyour~~ strings so that ~~everymessage~~ in your code can ~~bemanaged~~ by ~~theinternationalization~~ system. Diams 100 % translated in Polish		With BGA Studio its very easy to translate your game in any language, using BGA collaborative translation system. Check the FAQ and the example games to learn how to declare your strings so that every message in your code can be managed by the internationalization system.

			Diams 100 % translated in Polish

	== Original game representation ==		== Original game representation ==

Victoria la: /* Game layout */

2018-01-06T01:33:39Z

Game layout

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 03:33
Liña 42:		Liña 42:

	Caylus: when we have a 1024px small width to play the game – even if they have to screen, available buildings are placed scroll on the the right and below the board.		Caylus: when we have a 1024px small width to play the game – even if they have to screen, available buildings are placed scroll on the the right and below the board.
	On larger screen, these tiles are placed		On larger screen, these tiles are placed on the right of the board. This is a very basic usage of the others. « float:left » CSS property.
	on the right of the board. This is a very basic usage of the others. « float:left » CSS property.

Victoria la: /* Original game representation */

2018-01-06T01:33:22Z

Original game representation

@@ Liña 93: / Liña 93: @@
 == Original game representation ==
-=== III-1 Use the original artThe less you are modifying the original artof the game, the better.Its important for publishers that a board gameadaptation looks like the real board game.Sometimes it can be useful to modify someelements of the game to save some space onthe screen – but try to avoid it.Tips : if you have not enough space on the screen, reduce the size of the game elements. Try to make sure they are recognizable for players who played regularly, and add a tooltip to help beginners to figure out what they are. Gosu : the original cards are used,  with tooltips.
+=== III-1 Use the original art===
-. III-2 Be careful about player assistanceAs a rule of thumb, in order to respect theoriginal board games, you shouldntintroduce any player assistance feature.An assistance must not be introduced if itdirectly helps the player to figure out if hismove is good or bad.An assistance may be introduced if it canhelps the payer to figure out what moves areavailable. Gygès : the assistance shows you  available moves, but is not alerting  you about stupid moves (like the  upper left one).
+The less you are modifying the original art of the game, the better.
-. III-3 Cancel a moveAs a rule of thumb, dont allow players to cancel one of their moves.Cancelling a move can cause many issues, including allowing players to reveal some privateinformation intentionally.You can eventually allow a player to cancel a move if he is in the middle of a multiple steps gameaction and if no private information has been revealed yet.
+Its important for publishers that a board game adaptation looks like the real board game. Sometimes it can be useful to modify some elements of the game to save some space on the screen – but try to avoid it.
-. III-4 Available informationEvery information visible by players in thereal game should be accessible in theadaptation.Pay attention to some information like thenumber of cards in the opponents hand, or thenumber of remaining cards in the deck. Dominion : as specified in the rules,  number of cards in the hand of  players and number of cards in the  deck are public information. It is explicitely forbidden to count  cards in the discard pile, so this  information is not available.
+Tips: if you have not enough space on the screen, reduce the size of the game elements.
-. BGA Studio GuidelinesIV – Game technical quality guidelines
+Try to make sure they are recognizable for players who played regularly, and add a tooltip to help beginners to figure out what they are.
-. IV-1 Dont use exotic stuffBGA Studio provides a set of useful tools tobuild board games adaptations (ex : cardmanagement, confirmation dialog, tooltips,…).Use them, and dont use exotic libraries,plugins or tricks.Why ? Because BGA Framework willevolve in the future to provide new featuresto players, and it could make your gameincompatible with the new version.On the contrary, if you are using standard Haggis using BGA standard card stuff, you will enjoy these enhancements management system.without any effort.If you feel that you really need stome exoticthing: dont hesitate to ask us.
+Gosu : the original cards are used,  with tooltips.
-. IV-2 Write in (simple) EnglishSome other person than you may have tolook on your code :● We (BGA team) to help you if you need.● Some other BGA developer wanting tohelp you.● …For all these reasons, your code must bewritten in English (variables, methods,comments...).If English is not your mothertongue dontbe afraid : the whole idea here is to be Reversi : sourcecode extractunderstood, not to write an essay :)
-. IV-3 Page refreshA page refresh (F5) must allow players to reset the game interface to a stable state at anymoment of the game.BGA Studio framework allows you to do this with the « getAllDatas » PHP method and the« setup » Javascript method.Note : this « refresh » feature is also quite useful during the development process:)
+=== III-2 Be careful about player assistance ===
-. IV-4 Private informationA private game element must be visible only tothe player owning it. It must not be visible byhis opponents, by any means.In particular :_ getAllDatas PHP method mustnt return anyelement that are hidden from current player,even if the Javascript « setup » methodignores them._ you mustnt send via the « notifyAllPlayers » Hearts : each player is alerted about his function some information that is hidden from new cards using notifyPlayer, and cards one player (use « notifyPlayer » instead). from the other players remains secret.
+As a rule of thumb, in order to respect the original board games, you should not introduce any player assistance feature.
-. IV-5 Game progressionGame progression should be as accurate aspossible.Of course, its not always easy (or evenpossible) to compute game progression, but avague approximation is better than nothing. Stone Age : there are 2 different end game  conditions (building cards and civilization  cards). Both are taken into account to  increase the accuracy of the game  progression.
+An assistance must not be introduced if it directly helps the player to figure out if his move is good or bad.
-. IV-6 Game statisticsUsing BGA Studio you can define a set ofstatistics for your game.Statistics will be displayed at the end of thegame, and help players to figure out whythey win/loose a game, and what they shouldimprove.Try to choose interesting statistics thatdistinguish the different strategies for yourgame, in order it can help players tounderstand their game. Seasons : statistics
+An assistance may be introduced if it can helps the payer to figure out what moves are available.
-. SummaryThese guidelines are here to help you to make sure that the players, the gamepublisher and the game author are going to enjoy your adaptation of the game.We created these guidelines based on our personal experience (which includes manymistakes along the way) implementing a lot of games on BGA platform.Dont hesitate to contact us if you feel uncomfortable with one of these guidelines insome particular context with your game: these guidelines are here to help and not toprevent you to do smart things, and have fun while programing your game ;)
+Gygès : the assistance shows you  available moves, but is not alerting  you about stupid moves (like the  upper left one).