Orchestrating Carnival Project Development

[hyperupcall]

To better orchestrate the development of this project, I propose we discuss our long-term implementation strategy within this issue. Everything is still being worked out - so nothing is final!

Where will the carnival games be stored

The name of this repository implies that there will be a variety of different games people can play. We need to organize this repository so that people can access code from different carnival games.

We can organize the file structure like the following, separated by game, if someone wants to version control a game directly this repository (using submodules). If a user has their game on repl.it, we will be able to just link to the game without putting it on version control.

carnivalGame1
    carnivalGame1Server
        app.js
         ...
    carnivalGame1Client
        ...
carnivalGame2
    ...
carnivalOrchestration
    ...

Central server

CarnivalOrchestration holds the code (for the central server) where a user can select which game they want to play. Most likely it's going to be some website to visit. Sign in (optional), choose a game, get redirected. It's that simple. If we're able to implement some authorization layer then this website can contain / facilitate the following:

• Global Leaderboards
• Continuity of usernames across carnival games (such as JohnDoe99 [Carnival])
• Easy sign in for existing users (for compatible games)

Communicating with game servers

We can allow each person making their own game to choose a programming language for their own game / game server. The game server should still have the ability to communicate to the central server. Most communications are probably going to be over HTTP or HTTPS.

Some strategies for communication include this chart. @A5rocks also proposed a strategy here from this comment.

See @aStableNaka's comment about the type of data we want to be sending. This concerns player information or whatever. This data must be be requested as a separate API request after the OpenID Connect authorization protocol chain has been completed. See more about auth flow below.

Central client

The central client will be served by the Central server and will be a web page showing a list of game options. There are a few ways we can do this. One option is creating a Single Page Application (SPA) with ReactJS or VueJS. A second option is still using ReactJS or VueJS, but with Server Side Rendering (SSR). This will include using NextJS and NuxtJS for ReactJS and VueJS respectively. Lastly, we can go with a more traditional method of serving more "static-like" content.

Authentication / Authorization

I've been looking at authentication / authorization techniques and the OpenId Connect protocol seems the way to go. The master (central) server in this repo can act as the authorization server while the clients for this authentication server (relaying parties) include each game that we want to add. The client stuff should be pretty simple, as it's importing libraries to do the authentication. We should provide code snippets and instructions for people to implement this auth; the official certified libraries can be located at here.

Database

Database solution still in discussion. Since we're using OpenId Connect for authorization, we don't be storing any passwords whatsoever. Some things we would want to store in the database include, but are not limited to the following

• Player
  • name
  • username
  • id
  • email
  • scores
• Leaderboard
  • placings

Does anyone want to use anything in particular? Some members have been in favor of NoSQL database solutions like MongoDB, but others prefer the safer and more traditional approaches of SQL database such as SQLite, since there is a strict structure, among other reasons. There's also the topic of having our database as a local file (SQLite) or on some server, like PostgresSQL or MongoDB.

Games

Some games people are looking to include. Please post a comment!
Blackjack - EanKeen
Reversi - L0RDposeidon
Uno - Mat1
Nim - JackFly26

Want to add a game?

You can contribute any game, terminal, 2D, 3D - it doesn't have to be a game with a "carnival" or "casino" theme. Ideally it should be able to authenticate users sent from the carnival server. We will provide code snippets for this specific auth use case.

Standards / Guidelines

Thinking about contributing a game! Here are the requirements - they're not set in stone and if you have any questions, please post a comment!

• Usernames cannot include '(', ')', '[', ']', '{', '}' with the exception below
• Respond with the users in each room and the max amount of users available to each room in JSON format after a GET request to /api/foo?
• Layout of instructions for each game should be similar to other games (regarding control schemas or general directions). Not necessarily a similar theme, of course.
• [Optional] Users that are redirected from the master (central) server and have some sort of Carnival account or whatever must have their usernames exactly match the one on carnival, with a Carnival account identifier (Ex. JohnDoe8 [Carnival])
• [Optional] Communicate with the central server concerning leaderboard stats (or other information that you might want to display on the Carnival client)

[hyperupcall]

If you plan or want to participate, I ask that you write a comment. Tell us which game you want to make. If you want to share any concerns, please reply to this issue. I suggest we use this thread to talk about changing the direction of the carnival project, at least in the near future.

[aStableNaka]

I'm on board with option A. It separates each game into it's own server-ecosystem, allowing the creator to design everything in their game from the ground up (as long as it complies with the necessary feature requirements).

For distinguishing games/displaying an individual game's info on some hypothetical "Main client", there should be a meta file in the game's directory which has information about the game for the main client to work with (Thumbnail, title, description, etc). The main client will then use this info to display the game. I recommend the package.json standard (without all the nodejs related stuff if you're doing python)

Communication wise, I think websockets is the best way to go since it's cross platform. It's a good compromise between speed and functionality (if the game in question depends on real-time mechanics). Http requests are stateless which could be an issue if you're doing multiplayer games, whereas websocket session data can easily be destroyed as soon as the socket closes. And pipes are unix only, so if a windows user wants to download a copy of the "Main Client" for use on their desktop, they will run into issues.

Do we have any consensus on how we might go about implementing the "Main Client"? If not, here are some things I think it should do at the very least:

• Display all standard-compliant* games
• Retrieve and execute game clients
• Allow a user to identify themselves

*The standard of compliance for games is tbd

[hyperupcall]

@aStableNaka Concerning the main client, those are excellent base requirements. I would add that we'll need a way to communicate the data of the user to each game client. Proper handling of this data should be expected in all games. I will add such compliance standards should be loose so there's less of a barrier to entry.

For example, concerning data, it may include:

{
  name: "First",
  username: "firstLastUsername",
  overallExperience: 0,
  overallLevel: 0,
  gamesPlayed: ["game1", "game2"],
  gameSpecific: {
    game1Data: {
      experience: 0,
      level: 0,
      custom: {
        customProperty: "7"
      }
    },
    game1Data: {
      experience: 2
      level: 4
    }
  }
}

In this example, all clients will get the names of each player, the username, overallExperience, overallLevel, gamesPlayed, and gameSpecific data. Concerning compliance standards, it can include not mutating the data of any other game, and adding only itself to the gamesPlayed array. Better yet, we can just return the data of the person, and the data of that game to that game client. The customProperty property of the gameNData object is totally optional.

Within the master / main client, we can probably have data that says where each game client is located. Concerning this, I was thinking we can have some nodejs app that serves a web page, displaying data for all games. Clicking on a launch game button or icon will cause a request to the master server which just executes the game client chosen.

[aStableNaka]

@eankeen We should let each game handle it's game-data in its own way. In my opinion, the user data should only include data about the user and nothing else. Everything before the "gameSpecific" field is great, but everything beyond that is unnecessary and we should let each individual game determine how it wants to store it's data. However, that being said, the userdata should contain a permanent unique ID field (Similar to discord's snowflakes) which serves as a unique identifier for the user which can be used for accessing game-specific user data.

{ name: "First", id:"21873912879421731894", username: "firstLastUsername", overallExperience: 0, overallLevel: 0, gamesPlayed: ["game1", "game2"], }

This is an example of what the user data ideally should be. It serves only to identify and store user-specific data.

This data can be stored in a global server, or clientside if the user wants to be anonymous.

But storing this data client-side might cause some issues. We want the id to be somehow immutable. This is another issue we'll face. Should we design some kind of authentication protocol for IDs? We don't want to deal with impersonators or potentially catastrophic database problems caused by spam bots which can easily change their user ID.

But then again, this is just a hypothetical. However, I can see the need for an ID field in the userdata if we chose to let each game handle data their own way.

We might also need a universal database library that games can use to store data if need be, or we can have a single global database where each game is allowed a partition for storing their own userdata.

[ghost]

I definitely am interested in making a game but I need to know the standards. What qualifies as a valid game? How much variety will be introduced in terms of game types? How will the user navigate to different games?

Qualifications

Will this just be for stereotypical carnival games (throw a basketball into a hoop, throw a ring onto bottles, etc.) or will it allow a greater variety?

Variety

The types of games I can think of are console, 2D, and 3D. Will this be held to a specific standard?

Navigation

How will users navigate to a game? This is really about how the game will be organized. Will it all be in one game program?

In regards to conformity, I prefer Option B. Maybe this project could be split into a Node.js and a Python version. Specific libraries and basic conformity standards (i.e. "this is how the directions should look") could be instituted for each one so that it doesn't become a complete mess with a bunch of extremely different games.

[ghost]

Right now it's just Python. My specialty is Node.js. Maybe make another repo?

[A5rocks]

We're thinking about this architecture : https://docs.google.com/drawings/d/1HMPVkyTLoUkfnML1PNRxXSLLuMazcVI5_49gNFZ2FXk/edit?usp=sharing (AFAIK)

"Pipes" are supposedly internal sockets, but you can join the discord server to get more information (https://discord.gg/5gcPC6B), in the #carnival channel.

This means that any language is supported, so long as they have access to pipes.

As for your earlier questions:

Qualifications: So long as the game manages to work, it will be okay (confirm with the people more involved on this project on the discord server)

Variety: What I said above.

Navigation: A client that connects to the server... You know what, the drawing explains this better.

[leon332157]

Ok so it is the architecture atm, the plan is keep developing this and then put it into a production use, and see the feedback. For example do ppl perfer games to be in different repls or a github repo. Or is this pipe system stable enought to handle this.

[aStableNaka]

@Reader8765 For navigation, we're still exploring options of designing the main client.

[ode]

I suggest the game reversi.
https://en.wikipedia.org/wiki/Reversi
will do when I have time.

[hyperupcall]

So I simplified the issue and it should be actually readable. I do apologize as I was writing it late at night and made less sense than what I wanted. It should address all your concerns @L0RDposeidon @aStableNaka @leon332157 @A5rocks

[Zwork101]

To help you guys organize better, the project board should be public now: https://github.com/orgs/repl-it-discord/projects/1

[ghost]

@aStableNaka What are some of the options?

[hyperupcall]

@Reader8765 I'm not @aStableNaka, but I can try to help answer your question.
Concerning what kind of client stuff we're thinking about, there's three options so far.

• We can render a Single Page Application (SPA) with ReactJS or VueJS. Meaning most of our routes and logic and stuff will all be in the front-end part of the app.
• We can use server side rendering for ReactJS and VueJS with NextJS and NuxtJS respectively to have more of our logic in the backend
• We can go with a more traditional approach and use some traditional backend frameworks (expressJS, Flask, etc) to allow our users to navigate

Whatever we choose we need to allow for secure login and low load times. If you have any questions let me know - I'm personally leaning towards the options of 1 and 2 because I like what they have to offer and I have experience doing 1.

[ghost]

I know Vue and could help with that. Just tell me what I need to do.

[hyperupcall]

@Reader8765 Awesome! Using Vue is a possibility - I would very much enjoy it but as contributors we can't really decide on some backend structure yet. I'll let you know when a decision has been made - you can join the Discord server (which I believe you're already in) if you want to add anything else :)

[polyrtm]

I want to make Nim.

[hyperupcall]

@JackFly26 Sweet! I'll add that in!

[hyperupcall]

Updated main issue to add current discussion of database solution.

[hyperupcall]

So just an update, @TheDrone7 and I are ramping up development of the project. We're creating a Vue app with Nuxt for the frontend. Also, the repository is based solely for this carnival website, rather than the games for it. We listened to your feedback and chose to interface with our Postgres database with a Node backend. I'm closing this issue up for now since we're developing past the preliminary stages. Feel free to create another issue if you have any other comments or questions 😄