Board Game Arena

VanHlebar wrote: ↑ I will have to look at your solution. The problem that I have is that a player needs to have 3 different options when they click on a region of the map:

1. Move the King to that location
2. Move their Grande to that location
3. Place a Caballero into that region.

Yes each of these options are only available from a single State, it would be silly to display an error message for the first and second option when the user is trying to place a Caballero into a region. Once I have connected the onclick event to the div for the region for during the phase place King phase, if I don't disconnect it then it will still be there when the player moves to the next phase of the turn which is placing Caballeros.

Hi,
In such cases, I connect this div (edit: as soon as it is placed, and I never disconnect it) to a onClickThisDiv() method, in which I check in which gamestate the click occurred (and other things if needed), to trigger the relevant action (moveKing(), moveGrande() or placeCaballero() methods in your case) or to display an error message relevant to the current situation.

sourisdudesert wrote: ↑09 December 2019, 11:41 Sorry I don't know how to make this more clear.

Perhaps by... documenting what you said above? In the studio documentation? In a place where aspiring developers can find it, read about why they might want to use other, "proper" framework functionality for their use case, and where you offer those alternatives in an accessible way.

I'm absolutely with RicardoRix here, in case it wasn't clear enough. The studio docs are already lacking, and that's not something I can say about the Android SDK docs for example. There are many more instances where a BGA-Studio developer will be unable to find official answers to (their formulation of) a common-enough development challenge than there are for Android (an example you were using, so I'm comparing these two)

You still have full control over which games can and cannot get released on BGA, so I am absolutely confused by how you're handling the topic here. Afraid that some developers use functionality in a way that's dangerous? When reviewing the game, simply check for what you think those dangerous situations are (example from Android: detectNonSdkApiUsage) or even let the developers do that checking and have them provide explanations. There might be good use cases that right now you are actively working against with the apparent stance of "using undocumented API can cause problems, so we won't tell people what the API does and how things could go wrong there". Are you sure that is the best approach in terms of helping developers here?

And yeah, please, talk to and with those (your!) developers instead of antagonizing them by deliberately hiding information. What did Android do in one such case? They provide tooling to verify you're only using SDK-approved parts of their API, they have clear annotations that explain what you can and cannot do when you're not (e.g. UnsupportedAppUsage), and -- honestly -- their entire ecosystem is actually complex enough that all of this can, at the same time, work and make sense. BGA, on the other hand...

https://developer.android.com/distribute/best-practices/develop/restrictions-non-sdk-interfaces#feature-request wrote:If you cannot find an alternative to using a non-SDK interface for a feature in your app, you can request a new public API

How about starting with that? When somebody finds a hidden gem that they feel is helping them achieve something, BGA works towards either finding a proper alternative or making the API public?

Well, there is a difference in saying that even in the Android framework, backed up by the ressources of Google and staffed with quite a lot of engineers, there are some undocumented functions not meant to be used, and comparing BGA Studio to the Android SDK on everything

Of course we are not Google (one of only two admins speaking here). And yes, we are not perfect. We are not aiming to build up the perfect development tool with BGA studio: our aim is to provide an appropriate tool to build board games adaptations. The tool is not the goal, the games are.

We'll continue to improve BGA studio along the way, but it will probably never be perfect. That doesn't mean that it cannot be used: a lot of great games have been developed using it.

We also made the documentation a wiki so that it can be improved by developers, because we know that we cannot do everything ourselves (and senator, we don't run ads).

I would like to use this occasion to thank again everyone in the community contributing to BGA, developers, translators, publishers, premium members, moderators and players contributing bug reports, suggestions, and well-meaning constructive criticism. You are helping us move forward, and we are glad that you use and enjoy this website!