microsoftdx / nether Goto Github PK

Should be enough information for cloning, building and running.
Includes any machine dependencies that need to be installed

The build scripts currently don't track the build results for all builds, so the status of the last build is what currently determines whether the build script returns a success or failure error code.

From comments on #52:
The build task is set to build Nether.Leaderboard.Web. It should probably execute build.ps1/build.sh (depending on platform - see https://code.visualstudio.com/Docs/editor/tasks#_operating-system-specific-properties)

Setup the basic infrastructure to support incoming game events in order to support #3

Important to accomplish:

• Setup should be fully automatic and incorporated in the overall strategy for deployment of resources in Nether according to #7
• Investigate and understand how authentication and discovery of this service endpoint should work from the client side

In the discussion with @krist00fer yesterday about project structure, my initial reaction was that we'd decided on the requirements and structure and should just "suck it up". I spent some time thinking about it afterwards, and now I think I've changed my mind!

A large part of the current project structure is driven by the desire to be able to run and scale each service independently. However, the split in the projects is also slowing the implementation and iteration of design, has added some extra challenges for the "clone, build, run" developer experience, adds complications for deployment (which also impacts integration testing), and potentially complicates authentication.

All of these are challenges that we will need to face, but after thinking about it last night I'm not sure whether they're challenges that we want to face now. My feeling is that we would be better of accelerating the initial implementation of the API, build & run, integration tests etc, as this will allow us to have something to share (both with other people interested in contributing and with people who we're targeting as users of nether). With a bit of thought, we should be able to set up a structure that helps to minimise the amount of code refactoring when we are ready to pick up the work of splitting the services out again.

Thoughts? :-)

#4 #5

Start with the example where Leaderboard need to interact with Analytics

#4 #5

Enable extensions to be specified in configuration and registered with DI. (According to #134 )
E.g.

• when loading data store implementations it is expected that there will be an interface for this, and implementations can be specified in configuration
• if a service needs to talk to another service it is expected that this will be implemented as an extension (e.g. if leaderboard needs player info). Again, this is expected to be defined in an interface with the ability to specify the implementation in configuration

What to other contributors need to know to contribute successfully?

Includes:

• coding style
• definition of done

This would be the first implementation of the REST API for Player Management

Document the authentication process for gamedevs that do not want to use Nether client library/plugin for Unity.

Update the DI helpers to allow other dependencies to be resolved/injected

In order to support #6

Nether need to be super easy to deploy, hence deployment should be fully automated and documented. We need to figure out if using ARM Template(s) will be enough or if we even need to create some kind of configuration/deployment tool (that in the end might use ARM Templates) in order to fully automate deployment and configuration of the project.

Important things to accomplish:

• Gamedev should be able to deploy fully setup solution with no or minimal knowledge of Azure
• Gamedev should be able to select what building blocks to use in their solution and therefor only deploy necessary parts correctly configured to work with each other.

Important things to accomplish:

• Should work flawless on both Windows and Mac
• Should be easy and intuitive to start using and should follow normal guidelines for Unity Developers

• set up automated build (in #18)
• run tests in automated build (in #69)

The game publisher should be able to retrieve a list of all players using a simple web interface.

#4 #5

Leaderboard - get a list of highest scores per gamertag

If possible we should follow the API Guidelines defined here https://github.com/Microsoft/api-guidelines

In order to support #4

Setup and implement first API to support authenticated incoming requests from game clients to publish game scores. This is the first feature in a series of more features that will all support the full high score services in Nether.

Important things to accomplish:

• Configurable authentication that should easily (and by default) integrate with Nether's built in user management, but should not force the use of such.
• Setup and implement this one testable API with full support for automatic testing. This should serve as a foundation for all further testing that will be done.

GET
POST
#4 #5

example of json body:
{
"gamerTag": "krist00fer",
"score": 4711,
"game-id": "space-shooter",
"ip-address": "213.88.131.129",
"country": "Sweden",
"city": "Stockholm",
"longitude": "xxx",
"latitude": "xxx"
}

Add authentication - should cover:

• local, offline development (#35)
• enabling identity in module projects (e.g. Leaderboard) (#37)
• work out how authn/z works for gamer vs publisher (#38)
• Support first sign-in flow, i.e. no gamer tag yet
• Support subsequent sign-in, and set gamer tag in claims
• Enable non-temp certs (#257)
• Enable persistent user store (#169)
• Enable persistent user grant store (#230)
• Enable interactive flow (#259)
• Self sign-up with username and password? (#258)
• Azure AD B2C (#36)
• understand how authn works from Xamarin (#40)
• understand how authn works from Unity (#41)

Create a high level planning until December 20, 2016:

• Which functionality will be delivered?
• When?
• Who?

Initial thoughts

• Should we partitition?
• What consistency level do we require? (how to balance with performance?)
• Are we efficiently storing/querying?
• What paths can we disable indexing for?

Review guidance here: https://azure.microsoft.com/en-us/documentation/articles/documentdb-performance-tips/#sdk-usage

Any other thoughts/ideas ;-)

We've talked a few times about what we need to get in place before opening this up to broader involvement, so I've created this issue to discuss/track what those pieces of work are :-)

This is just a starting point for discussion ;-)

• Instructions on how to clone, build and run the solution #99
• Guidelines on contributing #100
• Define the MVP #98
• More complete API design to enable people to pick up a piece of a service and get started implementing (focus on the MVP)
• Authentication - start with facebook auth #41
• deployment?
• Integration tests for the existing code

Agree/disagree?...

Current thoughts are to use IdentityServer for this with a fixed, in-memory set of users

In order to support User Story #6

We need a flexible and configurable project solution that should:

• Support working on from Windows and Mac
• Have solid support for configuring different building blocks of Nether
• Have a good foundation to build and maintain automatic testing
• Have a fully automated build solution

The gamedev should be able to instrument the client side code by sending pre-defined and custom game events to the server side. Those events will then be used for further analysis.

Create an ARM template for Leaderboard:

1. Web API deployment
2. Document DB

High score lists should be queryable by:

• Global list
• People close to "my score"
• Geographic location
• Tag/tags (could be used to separate games or game modes)

#4 #5

We should set up the web projects so that we have a simplt, consistent way to specify the port(s) that the server listens on.

Players should be able to sing up to the game with their existing social accounts (Facebook, Google, Amazon, LinkedIn) or by creating new credentials (email address and password, or username and password); we call the latter "local accounts."

As per #85, we need to figure out what the MVP is. This might be a scenario to demo, or the scenario for an interested partner. Having this will focus efforts on API design etc