lobby server, game content servers and player authentication

[raaar]

Context is more games having player profiles with configurable options that have a direct impact on gameplay, like commander and unit upgrades, unlockable units, etc. AND continuing to use the official spring server.

This could evolve to several games supported by micro-transactions and possibly redirecting part of that income to the shared infrastructure.

Before the game starts, there would be lua network interaction with an external server to fetch each player's configuration.

An idea is having multiple secondary authentication tokens (passwords) associated to each account and game on the official server. When retrieving configuration from a game server, the corresponding secondary authentication token would be sent and the game server would decide if the <player_name>,<player_token> pair really matches a registered user on that server and reply with the configuration.

Individual games could authenticate users without knowing their main lobby server passwords or the passwords that same user uses on other games.

This way, a ZK game room could exist on the official server but still retrieve player configurations from the zk server.

[code_man]

Nemo made a gadget that reads data from a database in json form which is generated on a web page and then spawns units based on that, so doable as third party thing already.

[raaar]

That's interesting, link?

But the question here is player-specific content and authentication: how can the external server authenticate the players? Player name is unsafe.

[abma]

But the question here is player-specific content and authentication: how can the external server authenticate the players? Player name is unsafe.

the same way as replays.springrts.com does?

[8611z]

Generally the get-data-from-a-server thing is possible, but I think this would not work:

This way, a ZK game room could exist on the official server but still retrieve player configurations from the zk server.

The servers have seperated user databases. If you register an account on spring-server it does not exist on zK-server and other way around.

Before the game starts, there would be lua network interaction with an external server to fetch each player's configuration.

zero-K's commander units get created in unitdefs_post.lua file, lua-socket stuff would have to run at this stage. No idea if they work there? At least it would require modifying zK mod.

[raaar]

I know different servers usually mean different databases and users. That was precisely why I'm asking this.

Is the way replays.springrts.com knows its users compatible with users playing through different lobby servers?

The relevance of this is also related to the desired purpose of the official server, do we want game devs to move to a separate infrastructure? Should a mixed approach be allowed/encouraged? It can be good to keep the consistency, but it can also be more trouble than it's worth.

Should we have a standard of user consistency between multiple servers that game devs and server owners can adhere to, to prevent account spoofing (which may not even be malicious)?

Games usually have player registration. We could have cross-server account creation and authentication, where the official server would act as a "master" and compliant game-specific servers would check with it for duplicates, or simply defer user authentication to it. I'm not sure, this is an exploratory thread.

[AF]

This is all silly, people set up their own servers for a reason and if we end up with shared users and shared ranks then it all becomes meaningless

We end up with these problems:

- Rank becomes even more meaningless as any user can set up their own server and spoof an extra million minutes of play
- Moderation and banning becomes difficult as a user can avoid a ban by moving to another server
- It introduces new centralised dependencies
- The protocols and code become more complicated as server to server protocols are put in place, verification systems thought up, a new race between those implementing them and those exploiting them, technical debt, etc all at a time when there are fewer developer resources to go round

People set up new servers to have their own separate lobby system, be it for personal reasons, local communities, or for their own game. It gives them capabilities that they just don't have if they're on the main shared server, and the flexibility to do things. Setting up shared stats battles and users kind of nullifies all of these things. For example, does it make sense that you have no control over the running of your games online presence? What if Battlefield developers turned around and said "sorry we can't ban XYZ for ABC, someone else runs all that and they disagree" or "We'd like to do it but it's not our code base and the other developers have different ideas"

To which we are lead to the following potential solutions:

- The goal of all of this is to bolster the springrts.com lobby community and player presence, so instead of linking servers and doing a lot of work, why not just join the one server?
- These things don't belong on a server, and should be 3rd party external services. Link your user with the 3rd party service probably by being given a code then PM'ing it to that services bot on the server as verification. Let other developers do this and simplify the lobby server accordingly
- This is not something worth bothering with, independent servers should be independent, otherwise we're just creating some sort of distributed load balancing

Regarding replays usernames, just set the username as username@servername on the site, the user shouldn't need to know which server the game was played on once they're inside the replay, and the idea that usernames are somehow bound identities that are precious is charming in a system that lets you rename yourself with little or no cost involved

[8611z]

This reads as if new servers are set up every few days. Oo
One server exists only because a dev wants to run his illegal banned spring-mt-variante. Existence of second server is justified by its supporters so that zero-K does NOT share anything with other mods.
Two unusual situations and not the norm.

The relevance of this is also related to the desired purpose of the official server, do we want game devs to move to a separate infrastructure? Should a mixed approach be allowed/encouraged? It can be good to keep the consistency, but it can also be more trouble than it's worth.

Some peoplepersons want seperate infrastructures for games. Others think that is detrimental to the mod itself and spring as whole. My opinion on that is pretty clear but I can at least understand the motivations of other side to have seperate lobby-client or installer, even if I think it is mindboggling stupid and all attempts have clearly failed.
With seperate lobby-server I am lost why anyone would want that.
What is there to gain? Does anyone plan to do that in future?

I thought this was the original problem/idea:

Context is more games having player profiles with configurable options that have a direct impact on gameplay, like commander and unit upgrades, unlockable units, etc. AND continuing to use the official spring server.

That seems possible because the following is possible:
1) websites log-in with lobby-account (exampe: replays.springrts.com, zero-k forum)
2) sending data from ingame to website (example: awards, elo)
3) sending data from website to ingame (example: custom commanders, planetwars)
4) autohosts that block or allow players depending on custom criteria (example: rank-limit, ingame time)
5) autohosts that store options per user (example: favorite-color plugin)
It does not work by lua-network but by autohosts, parsing messages contained in replayfile etc. I do not see where different lobby-servers come into play?
Do you want something like custom-per-player-commanders in your mod, and the mod should be playable on both servers?

[raaar]

I'm not asking devs to do anything yet, just exploring these issues.

Do you want something like custom-per-player-commanders in your mod, and the mod should be playable on both servers?

yes, I want to add custom-per-player stuff eventually, configured through an external web service, and I want to use the official spring server.

Using other servers would be a contingency.

About people sending chat messages to the autohosts, which would in turn to send information to the game-specific web service. That looks doable. Not sure if it is safe, though... do they need to be connected to the official server to do that?

[AF]

I'm still not sure what problem you're trying to solve, I don't believe you've articulated it well enough to get the message across.

My current interpretation based on your last post is:


1. John Smith joins Server A and plays for a while, earning commander upgrades
2. John Smith has a friend on Server B and joins Server B, his command upgrades are not present
3. ??? < - solution goes here
4. Hurrah! John Smith has the same upgrades on Server A and Server B, they're tied to a shared identity

Am I correct in this interpretation?

Or is this as I originally envisaged, a mechanism to share identities/Rank/upgrades/benefits/Battles/Replays across servers?

The problem being solved here is wishy washy and vaguely defined, please state it unambiguously, clearly, in outright solid concrete terms. Do not assume we are aware intimately familiar with the problem, or that we understand it the same way you do