TC-137 Update platform SDK scenario wording

[anne-edwards]

Couple of questions/suggestions:

• Is there any reason why sometimes the summary list is at the top, and sometimes it's lower down, below all the "PLEASE REPLACE"s? Being at the top makes sense to me, but I wanted to check.

• What do you think about potentially changing the wording in the GitHub steps so that it matches the wording in the docs? In some cases, the GitHub steps and the docs steps don't actually match each other, whereas in other cases they match up but use inconsistent wording.
  E.g. at the moment the "Player authentication" scenario is like this in the docs:

1. Instantiate clients
2. Create a player identity token (PIT) for a project
3. Choose a deployment that the player is allowed to join
4. Create a login token (LT) to grant access to a player to a given SpatialOS deployment
5. Connect to the deployment using both PIT and LT

but like this in the code:

1. Start a cloud deployment.
2. Create a PlayerIdentityToken.
3. Choose a deployment that is ready for login.
4. Create a LoginToken for a selected deployment.
5. Connect to the deployment using the PlayerIdentityToken and the LoginToken.

[lx223]

@anne-edwards

The default C# formatter orders those fields differently, depending on their modifiers.

For example, in private const string ProjectName, ProjectName is modified to be private const string whereas in private static string RefreshToken, RefreshToken, private static string. The default formatter would group them together and re-order them. But, I agree with you that it would be nicer to have all the REPLACE at the top.

The scenario doc and code don't always align. The code has to be fully working so it tends to have a few more set up like Starting a cloud deployment which we wouldn't have to put in the doc so as not to clutter a walk-through scenario. But, wherever they do align, I think it would make sense for them to share the same wording.

[lx223]

Change LGTM.

[lx223]

Do you currently have it documented somewhere the name of the process? If not, mentioning spatiald probably just adds confusion without providing much value.

[anne-edwards]

We don't define it anywhere; I added it here so that users would at least be familiar with the term when they see it in the code.

However, having just searched in the code, it only appears a few times (as SpatialdEndpoint and SpatialDPort) so maybe it's not worth drawing attention to?

Or, I could define both "spatiald" and "local API service" in the main SpatialOS glossary and explain that they're the same thing, but that "SpatialD" and "Spatiald" are used in the code?

[anne-edwards]

@lx223 thanks for the explanations.

Regarding the ordering, is there any (potentially hacky) way we could make it so that all the summaries are at the top? No worries if not.

Where the scenario and doc align, I'll update one of them for consistency.