Create a game in BGA Studio: Complete Walkthrough - Historial de revisións

Victoria la: /* Implement One time game model synchronisation */

2019-01-03T02:13:12Z

Implement One time game model synchronisation

← Revisión máis antiga		Revisión como estaba o 3 de xaneiro de 2019 ás 04:13
Liña 254:		Liña 254:
	have to alter it to return all other data from database visible to the "current" player.		have to alter it to return all other data from database visible to the "current" player.

	After that on the client side we should display this data, so in your .js file in setup function (which is the receiver of getAllDatas) you add that ~~handles~~ data send by server, usually by calling animation function such as "placeToken" or "placeCard".		After that on the client side we should display this data, so in your .js file in setup function (which is the receiver of getAllDatas) you add calls that handle data send by server, usually by calling animation function such as "placeToken" or "placeCard".

	== Create State Machine ==		== Create State Machine ==

Victoria la: /* Update game infos and box graphics */

2019-01-03T02:00:34Z

Update game infos and box graphics

← Revisión máis antiga		Revisión como estaba o 3 de xaneiro de 2019 ás 04:00
Liña 108:		Liña 108:
	Details about images can be found here: [[Game art: img directory]].		Details about images can be found here: [[Game art: img directory]].

	Now important step. You have to LOAD these files in studio website through control panel. So go to Control Panel -> Manager Games -> ~~heartsYOUNAME~~		Now important step. You have to LOAD these files in studio website through control panel. So go to Control Panel -> Manager Games -> YOURPROJECT
	and press Reload for 'Reload game informations' and 'Reload game box image'		and press Reload for 'Reload game informations' and 'Reload game box image'

Victoria la: /* Introduction */

2019-01-03T01:55:01Z

Introduction

← Revisión máis antiga		Revisión como estaba o 3 de xaneiro de 2019 ás 03:55
Liña 10:		Liña 10:


	If you stuck or have questions about this ~~tutorial~~ post on [https://forum.boardgamearena.com/viewforum.php?f=12 BGA Developers forum].		If you stuck or have questions about this page post on [https://forum.boardgamearena.com/viewforum.php?f=12 BGA Developers forum].
	If you uncomfortable posting on public forum you can send message directly to developers who post answers on that forum but NOT the BGA admins.		If you uncomfortable posting on public forum you can send message directly to developers who post answers on that forum but NOT the BGA admins.

Victoria la o 18 de abril de 2018 ás 02:05

2018-04-18T02:05:07Z

@@ Liña 30: / Liña 30: @@
 If you want to take over existing project first ask on forum to see if project is abandoned, then get read only access (via project list) and see if this worth using it, if it has no code or graphics just start from the scratch, don't worry about project name it can be renamed later
 == Obtain game graphics ==
@@ Liña 60: / Liña 95: @@
 exclude them from version control. There is also a misc/ folder now but it will hold up to 1 Mb of data files which would be checked in, so rules pdf's may not fit there.
 == Update game infos and box graphics ==

Victoria la: /* Wrap Up */

2018-04-18T01:45:20Z

Wrap Up

← Revisión máis antiga		Revisión como estaba o 18 de abril de 2018 ás 03:45
Liña 270:		Liña 270:

	== Wrap Up ==		== Wrap Up ==


			* Implement game progression (getGameProgression() in php)
			* Implement Zombie turn (zombieTurn() in php)
			* Define and implemented some meaningful statistics for your game (i.e. total points, point from source A, B, C...)
			* The games logs should explain what happened if player was not looking
			* You need to implemented tiebreaking (using aux score field) and updated tiebreaker description in meta-data
			* Make sure all UI strings are marked for translation
			* UI elements which are images (i.e. tokens, cards) should have tooltips


	When you think you game is completely working there is still bunch of stuff you have to do/check before telling admin that game is ready, please go though this [[Pre-release checklist]].		When you think you game is completely working there is still bunch of stuff you have to do/check before telling admin that game is ready, please go though this [[Pre-release checklist]].

	~~'''TO BE CONTINUED...'''~~

Victoria la: /* Create Database Schema */

2018-04-18T01:36:24Z

Create Database Schema

Victoria la: /* Select a First Game */

2018-04-18T01:26:54Z

Select a First Game

← Revisión máis antiga		Revisión como estaba o 18 de abril de 2018 ás 03:26
Liña 26:		Liña 26:

	Even if you see few projects with name of the game they may not be active. There are a lot abandoned game projects. If its not clear by the status, post to Developers forum as ask if anybody actively working on the project, and at the same time ask admins on the same forum post to send you graphics for that game if they have it (yeah on the forum, there is better chance of them seeing your post on the forum then in email).		Even if you see few projects with name of the game they may not be active. There are a lot abandoned game projects. If its not clear by the status, post to Developers forum as ask if anybody actively working on the project, and at the same time ask admins on the same forum post to send you graphics for that game if they have it (yeah on the forum, there is better chance of them seeing your post on the forum then in email).

			If you goal was to fix bugs in existing project, you have to ask on forum to get access to it, projects developed by bga admins are not in the studio.

			If you want to take over existing project first ask on forum to see if project is abandoned, then get read only access (via project list) and see if this worth using it, if it has no code or graphics just start from the scratch, don't worry about project name it can be renamed later

	== Obtain game graphics ==		== Obtain game graphics ==

Victoria la: /* Select a First Game */

2018-04-18T01:12:24Z

Select a First Game

← Revisión máis antiga		Revisión como estaba o 18 de abril de 2018 ás 03:12
Liña 15:		Liña 15:
	== Select a First Game ==		== Select a First Game ==

	For you first game you must either		For you first '''real''' game you must either
	* Select a game from [http://en.studio.boardgamearena.com/#!page/availablelicences Available Licenses]		* Select a game from [http://en.studio.boardgamearena.com/#!page/availablelicences Available Licenses]
	* Or from Public Domain		* Or from Public Domain

Victoria la: /* Create State Machine */

2018-01-06T02:37:44Z

Create State Machine

← Revisión máis antiga		Revisión como estaba o 6 de xaneiro de 2018 ás 04:37
Liña 246:		Liña 246:
	Please fist watch this again [http://www.slideshare.net/boardgamearena/bga-studio-focus-on-bga-game-state-machine BGA game state machine]		Please fist watch this again [http://www.slideshare.net/boardgamearena/bga-studio-focus-on-bga-game-state-machine BGA game state machine]
	and then please read [[Your game state machine: states.inc.php]]		and then please read [[Your game state machine: states.inc.php]]

			Now the state machine should be relatively simple, if you find yourself with machine with more than 10 states its probably not the way to go.
			Not all the player interactions need separate states, a lot of things can be implemented directly on client, i.e. if your player need to select
			a reward token, which offers choice of resource, instead of two states on server just have one state on server and possible few states on client (client side states)
			to collect this info.

	== Implement Notification handling ==		== Implement Notification handling ==

Victoria la: /* Create Database Schema */

2018-01-06T02:30:20Z

Create Database Schema

@@ Liña 185: / Liña 185: @@
 * For dynamic stuff we should try to reduce amount of fields we need, i.e. we need a field for card, so its one, we need to know what zone cards belong to, its 2, and we have possible few other fields, if you look closely at you game you may find out that most of the zone only need one attribute at a time, i..e draw pile always have cards face  down, hand always face up, also for hand and discard order does not matter at all (but for draw it does matter). So in majority of cases we can get away with one single extra integer field representing state or order
 * In real database both card and zone will be integers as primary keys referring to additional tables, but in our case its total overkill, so they can be strings as easily
 Another Example: '''The euro game'''
@@ Liña 204: / Liña 216: @@
 </pre>
-You can also use cards database schema and [[Deck]] implementation for most purposes (even you not dealing with cards).
 See [[Game database model: dbmodel.sql]] for details about editing the file.

← Revisión máis antiga		Revisión como estaba o 18 de abril de 2018 ás 03:36
Liña 173:		Liña 173:

	Usually design process will contain the following steps:		Usually design process will contain the following steps:
	* Design game model - model that represent your game in progress, such as at any ~~give~~ step you can restore the game from that model		* Design game model - model that represent your game in progress, such as at any given step you can restore the game from that model
	* Mapping - now map real game to that model		* Mapping - now map real game to that model
	* Encoding - now represent this model in database and material file with reasonable amount of fields		* Encoding - now represent this model in database and material file with reasonable amount of fields
Liña 182:		Liña 182:
	* Framework handles state machine transition, so you don't have to worry about database design for that (i.e. who's turn it is, what phase of the game we are at, you still have to design it but as part of state machine step)		* Framework handles state machine transition, so you don't have to worry about database design for that (i.e. who's turn it is, what phase of the game we are at, you still have to design it but as part of state machine step)
	* Also framework supports basic player information, color, order around the table, basic scoring, etc, so you don't have to worry about it either		* Also framework supports basic player information, color, order around the table, basic scoring, etc, so you don't have to worry about it either
	* The only thing you need in ~~our~~ database is state of the "board", which is "where each pieces is, and in what state", or (position,rotation) pair.		* The only thing you need in your database is state of the "board", which is "where each pieces is, and in what state", or (position,rotation) pair.
	* The card state is very simple, its usually "face up/face down", "tapped/untapped", "right side up/up side down"		* The card state is very simple, its usually "face up/face down", "tapped/untapped", "right side up/up side down"
	* As position go we never need real x,y,z. We need to know what "zone" card was, and depending on the zone it may sometimes need an extra "z" or "x" as card order. The zone position itself usually static or irrelevant.		* As position go we never need real x,y,z. We need to know what "zone" card was, and depending on the zone it may sometimes need an extra "z" or "x" as card order. The zone position itself usually static or irrelevant.
	* So our model is: we have cards, which have some attributes, at any given point in time they belong to a "zone", and can also have order and state		* So our model is: we have cards, which have some attributes, at any given point in time they belong to a "zone", and can also have order and state
	* Now for mapping we should consider what info changes and what info is static, static info is always candidate for material file or html		* Now for mapping we should consider what info changes and what info is static, static info is always candidate for material file or html
	* For dynamic stuff we should try to reduce amount of fields we need, i.e. we need a field for card, so its one, we need to know what zone cards belong to, its 2, and we have possible few other fields, if you look closely at you game you may find out that most of the zone only need one attribute at a time, i..e draw pile always have cards face down, hand always face up, also for hand and discard order does not matter at all (but for draw it does matter). So in majority of cases we can get away with one single extra integer field representing state or order		* For dynamic stuff we should try to reduce amount of fields we need, i.e. we need a field for card, so its one, we need to know what zone cards belong to, its 2, and we have possible few other fields, but if you look closely at you game you may find out that most of the zone only need one attribute at a time, i.e. draw pile always have cards face down, hand always face up, also for hand and discard order does not matter at all (but for draw it does matter). So in majority of cases we can get away with one single extra integer field representing state or order
	* In real database both card and zone will be integers as primary keys referring to additional tables, but in our case its total overkill, so they can be strings as easily		* In real database both card and zone will be integers as primary keys referring to additional tables, but in our case its total overkill, so they can be strings as easily