Start a real project / complete walkthrough
Select your first game
For your first real game (after you've completed at least one tutorial), you must choose a game from the Available Licenses list.
What if the game you want isn't on the list? Don't start a project until you are sure BGA has a licence for it, or it will never be published on BGA! If you are in contact with the publisher, ask them to submit the game licence here: https://boardgamearena.com/gamepublishers.
After choosing a game, take a few seconds to check the list of current projects before creating your own. If someone is already developing the game, consider asking to join their project. Check whether existing projects are still active, as they might have been abandoned!
Create a project
If you haven't already, create a new GAME project in BGA Studio for your game.
If the original game name is taken:
- Contact the project administrator to see if you can work together.
- If the project administrator doesn't answer, or the project is not visible because it was soft-deleted due to inactivity, use Contact Us / Support so the BGA team can give you access to it.
Then set up your project the same way you did for the tutorial project.
Don't forget to create a Git repository (or similar) to keep a history of your work. Make sure you don't commit the publisher's original graphics files and you don't include a file containing your SFTP password.
Obtain game graphics
If you are developing a game from the Available Licenses section, ask the admins for the graphics using the Request Art Files button on the Studio licence page. This can take time, as the admins may need to contact the publisher. You can continue with the next steps while you wait, but the game cannot be published on BGA without the graphics! If you are in direct contact with the publisher, you can ask them for the art files yourself. It's usually faster than going through BGA.
Obtain game documentation
Make sure you have the latest English version of the rules (usually a PDF). It's usually available on the publisher's website.
Read the rules in full to get a clear idea of the states, table options and other features you will need.
Update game info and box graphics
Even if your game isn't playable yet, make sure it looks good in the game selector, with nice box graphics and correct information.
To do this, edit gameinfos.jsonc. You can find the game on http://boardgamegeek.com and use the information there to fill in the file.
Next, add the game metadata images, such as the box image, using the Game Metadata Manager. For details about images, see Game art: img directory.
Simplify the rules
Programming a game may take much longer than you expect. Start with simplified rules and get that version working first.
- If the game has expansions, deal with them later.
- If it has advanced rules, start with the basic or beginner rules.
- If it has different rules for 2 and 4 players, start with the simpler version. For example, restrict the game to 4 players at first.
- If it has 50 unique cards with 2 copies each, start with 2 unique cards with 25 copies each, just to get things working.
- Set aside any other rules that are not needed for the basic version.
Once the most basic version is working, you can add more rules step by step.
Time to code!
But first...
Keep the BGA Studio Guidelines in mind!
It's also a good idea to read through the Framework documentation before working on your project.
Now we can get started, following the same steps as the tutorial but applying them to your game!
Edit the game information
This time, fill in all the information, including the player count, game name, BGG ID and tie-breaker rule.
Create the states in the front and back ends, with basic navigation
With the rules in mind, you should have an idea of the states you need, both visible (active player or multiple active player) and invisible (game).
Create a basic version in both the front and back ends, with temporary buttons and simple actions to move between states. Test it to see if the flow matches how you expect the game to play.
Start the visuals
Display the game elements in the front end, such as the board and player zones.
You will probably need tools like GIMP to crop and resize the artwork and save it as WebP. ImageMagick can help if you need to process many files. There are also free online tools to convert PDF files to PNG if needed.
Store the game state
Create the game items (cards, dice and so on) and their managers. Set up the initial items described in the Game setup section of the rules. BGA handles player setup automatically.
Compute the possible actions
For each state, compute the possible actions in the relevant managers. Send them to the front end so they can be displayed to the player.
Create the actions
For each state, implement the actual actions and update the relevant managers.
You may also need variables, for example to remember a selected card before moving to a state where it will be placed. In that case, you can use $this->bga->globals to store the card ID.
You can now remove the temporary buttons you used to test the navigation.
Remember that actions should send notifications to the front end! Make them clear enough for a turn-based player to understand what happened, even if they didn't see their opponents' moves.
Handle zombie players
For each state, implement the zombie method by choosing a random move, calling the action function and returning its result.
Handle the notifications
For each notification sent by the back end, create a matching notif_ function to read the data and update the front end. After the animation, the display should match what you would see after refreshing the page.
Update the score
If you have live scoring, update the bga->playerScore counter each time the score changes. If scoring only happens at the end of the game, update it in the EndScore state.
Don't forget to set the tie-breaker values in bga->playerScoreAux, usually in the EndScore state.
Implement game progression
Implement the getGameProgression function and add updateGameProgression: true to every state where game progression should be updated.
Continue the implementation
You now have the basic game working! Time to add the rules you left out at the beginning!
Note: You can request a private alpha now if you want to show your progress to the publisher before continuing. See the Private alpha section below for details. Or wait until everything is ready. It's your call!
Add expansions and variants
If you want to add them, create a new entry in gameoptions.jsonc.
Make sure you have a licence for any expansions you add. Only variants from the official rules are allowed, so no house rules.
If the game has a specific set of rules for an official solo mode, you can also implement them.
Add user preferences
Add user preferences for customization using gamepreferences.jsonc.
These options do not affect the rules, but can make the game more comfortable to play. Examples include color-blind support and automatic confirmation with a timer.
Tooltips
Don't forget to add tooltips to your game elements to make the game easier to learn. Use the _() function to make tooltips translatable.
Check the translations
If you haven't already, read the documentation about Translations.
On a Studio table, add "&dummyTranslations" to the URL to test the translations. All front-end translations (using _('...')) should appear surrounded by «» to mark translatable text. If text should be translated but has no «», you probably missed a translation function!
Theme your game
You can add a background, sounds and fonts to match the theme of your game. Limit these changes to the game area. Do not customize BGA framework elements.
Private alpha
When you want to show your game to the publisher or friends, you can request a private alpha. Create a build and click the "Request PRIVATE ALPHA status" button. The admins will check that your game starts and has something to show, then move it to private alpha.
Once it's in private alpha, visit your game's page (https://boardgamearena.com/gamepanel?game=…) and add the following information if you can:
- Links to the rules (in multiple languages if available).
- Links to teaching videos.
- A link to the official game website in the "On the web" section, if there is one.
- Consider writing a summary of the rules.
Note: Community members can also add this information. You only need to make sure the English rules are available before the next step.
You can continue working on Studio while private alpha testers play the latest version you have built and deployed.
When you have new features or bug fixes to share, create a new build and deploy it to make it available to testers. You'll use the same process in the later stages.
You may now receive emails about bug reports for your game. Once you have fixed a bug, build and deploy the fix, reply to the report and mark it as fixed!
Public alpha
When you think your game is fully working, go through the Pre-release checklist before telling the admins it is ready.
When everything is ready and there are no blocking bug reports, click the "Request PUBLIC ALPHA status" button. The admins will check your game and move it to public alpha.
Beta
When your game has enough reviewer approvals (10 or more), you can click "Request BETA status". BGA needs the publisher's approval before moving your game to beta. If you are in contact with the publisher, reply to the automated beta email and CC them. They can then reply with their approval so BGA can see it.
Once the game is in beta, it can be translated and a tutorial can be created.
Final release
The release date is decided by BGA, but the publisher can contact BGA to request a release date.
The game can also have a silent release, which means it won't appear in the release news. This allows it to be released at any time.
Conclusion
You can now bring a game to BGA and maintain it. A big thanks for all your hard work!
You can follow the same steps to start another project, or help improve existing projects!