Friend System / Groups #74

Closed
opened 2017-01-17 17:46:43 +01:00 by debdolph · 14 comments
debdolph commented 2017-01-17 17:46:43 +01:00 (Migrated from edugit.org)

Created by: DummerDelfin

There should be a friends system. Friends should be able to add their usernames.

*Created by: DummerDelfin* There should be a friends system. Friends should be able to add their usernames.
nik commented 2017-01-18 14:23:01 +01:00 (Migrated from edugit.org)

@DummerDelfin What would these firendships be used for? Can you offer an example where this would be helpful in a game, or some other ideas what you would want to do with it?

@DummerDelfin What would these firendships be used for? Can you offer an example where this would be helpful in a game, or some other ideas what you would want to do with it?
debdolph commented 2017-01-18 15:58:56 +01:00 (Migrated from edugit.org)

Created by: DummerDelfin

Also just for fun. As I said. It would be cool ;)

*Created by: DummerDelfin* Also just for fun. As I said. It would be cool ;)
nik commented 2017-01-18 16:00:29 +01:00 (Migrated from edugit.org)

Well, having a feature that can't be used for anything is not cool.

We definitely need some ideas on what to use it for.

Well, having a feature that can't be used for anything is not cool. We definitely need some ideas on what to use it for.
mirabilos commented 2017-01-22 14:01:20 +01:00 (Migrated from edugit.org)

Created by: mirabilos

Please keep in mind that, the more people you know, the more distinct “groups of friends” you have. For example, I’d wish to keep most coworkers separate from real-life friends, friends from that weird Nerdverein I am in, friends from the choir I sing in, … for some purposes.

There’s also a really hard problem about this:

When starting a game for one group of friends, who’s allowed to decide whether to grow the set of people allowed to play?

In a traditional game, either nobody once the game has started, the game master (usually the person inviting to play), or everyone can individually add or remove (“kick”) people.

In a real-life geoposition-based game, there are possible privacy implications from this. Maybe several policies (the above, plus “all players must agree for others to join” – and even then I’m not yet convinced that’s enough) need to be implemented.

This probably needs some deep thought.

AIUI, for now, the system works like this: the person running the server allows people to register for an account there (or creates accounts beforehand, and nobody can register), and then, everyone with an account can join every game. I think this is workable for a start, especially as running several servers is cheap and can be made easy (vhosts, subdirectories… different ports probably not due to firewalling “fun”); that’s not to say a more complex friends/groups system shan’t be implemented, just that you already have a way to determine access to current games (nobody’s supposed to play on Veripeditus infrastructure; after all, it’s a testing environment for the framework, not an official game hosting platform).

*Created by: mirabilos* Please keep in mind that, the more people you know, the more distinct “groups of friends” you have. For example, I’d wish to keep most coworkers separate from real-life friends, friends from that weird Nerdverein I am in, friends from the choir I sing in, … for some purposes. There’s also a really hard problem about this: When starting a game for one group of friends, who’s allowed to decide whether to grow the set of people allowed to play? In a traditional game, either nobody once the game has started, the game master (usually the person inviting to play), or everyone can individually add or remove (“kick”) people. In a real-life geoposition-based game, there are possible privacy implications from this. Maybe several policies (the above, plus “all players must agree for others to join” – and even then I’m not yet convinced that’s enough) need to be implemented. This probably needs some deep thought. [AIUI](https://www.mirbsd.org/wtf.cgi?q=AIUI), for now, the system works like this: the person running the server allows people to register for an account there (or creates accounts beforehand, and nobody can register), and then, everyone with an account can join every game. I think this is workable for a start, especially as running several servers is cheap and can be made easy (vhosts, subdirectories… different ports probably not due to firewalling “fun”); that’s not to say a more complex friends/groups system shan’t be implemented, just that you already have a way to determine access to current games (nobody’s supposed to play on Veripeditus infrastructure; after all, it’s a testing environment for the framework, not an official game hosting platform).
nik commented 2017-01-22 14:07:06 +01:00 (Migrated from edugit.org)

@mirabilos: It's even simpler because the server already has a kind of
“VHost” feature, using worlds. It can run multiple instances of the
same game or different games in different worlds that are completely
separated from each other, and users have distinct player objects bound
to different worlds. Adding something to allow or restrict joining
worlds is fairly simeple.

@mirabilos: It's even simpler because the server already has a kind of “VHost” feature, using worlds. It can run multiple instances of the same game or different games in different worlds that are completely separated from each other, and users have distinct player objects bound to different worlds. Adding something to allow or restrict joining worlds is fairly simeple.
mirabilos commented 2017-01-22 14:29:59 +01:00 (Migrated from edugit.org)

Created by: mirabilos

agreed, but this still needs some thought, especially as this is a separate game class from traditional games, with more privacy implications.

*Created by: mirabilos* agreed, but this still needs some thought, especially as this is a separate game class from traditional games, with more privacy implications.
nik commented 2017-01-22 14:41:33 +01:00 (Migrated from edugit.org)

@mirabilos as far as it was drafted in #21, games created by players
undergo a git-based review process before being installed in the game.

@mirabilos as far as it was drafted in #21, games created by players undergo a git-based review process before being installed in the game.
mirabilos commented 2017-01-22 19:57:36 +01:00 (Migrated from edugit.org)

Created by: mirabilos

Possibly, but that’s not the only way to install games… or servers.

*Created by: mirabilos* Possibly, but that’s not the only way to install games… or servers.
nik commented 2017-01-22 23:23:56 +01:00 (Migrated from edugit.org)

Created by: Separated

Hello!

I believe there may be a mistake on adding me to this email and conversation.

-Eric Pickard

On Jan 22, 2017, at 1:57 PM, mirabilos notifications@github.com wrote:

Possibly, but that’s not the only way to install games… or servers.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

*Created by: Separated* Hello! I believe there may be a mistake on adding me to this email and conversation. -Eric Pickard > On Jan 22, 2017, at 1:57 PM, mirabilos <notifications@github.com> wrote: > > Possibly, but that’s not the only way to install games… or servers. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. >
nik commented 2017-05-09 17:06:15 +02:00 (Migrated from edugit.org)

Mentioned in issue #73

Mentioned in issue #73
nik commented 2017-05-09 17:29:54 +02:00 (Migrated from edugit.org)

Mentioned in commit 9461db6b7c

Mentioned in commit 9461db6b7cada97113788cb65708a422be769da9
nik commented 2017-05-09 18:52:33 +02:00 (Migrated from edugit.org)

Mentioned in commit 6307a26c35

Mentioned in commit 6307a26c35a641d51f6b5ab3f1e03c0ef794315c
nik commented 2017-05-09 18:52:33 +02:00 (Migrated from edugit.org)

Mentioned in commit 32b1f1bf9c

Mentioned in commit 32b1f1bf9ce013d973beea4c81845ec805d53d81
nik commented 2017-05-09 18:52:47 +02:00 (Migrated from edugit.org)

Status changed to closed by commit 32b1f1bf9c

Status changed to closed by commit 32b1f1bf9ce013d973beea4c81845ec805d53d81
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nik/veripeditus-server#74
No description provided.