The AF Lobby Plan

[tomjn]

The broad stroaks:

• Build a heavily streamlined lobby
• React, Redux, React Router for the UI
• SCSS for CSS
  • Less.js is a bit old now
  • PostCSS seems new and muddles JS and CSS, it might be cool to be able to use Tailwind, but it's a higher bar to entry, I want the project to be maintainable and SCSS is straight forward to learn
  • I like Bulma, it has a nice grid system, some basic components for things like buttons and typography, doesn't overextend itself
• Use Neutralino JS to host the application
  • electron bundles chromium giving it a large footprint in memory and file size. I have misgivings about chromiums performance
  • NW.js seems better than electron but not as lightweight as Neutralino
  • Neutralino has a simple API and smaller footprint
  • There was another option that was very lightweight but provided just a webview, it would need to have been forked to provide an API to launch spring or read files
• Completely abandon the existing server infrastructure
  • Battles will be retrieved from a REST API endpoint, no login necessary
  • Debuggable using standard REST API tooling, such as POSTMAN
  • Players will make changes to the battle using the same endpoint and POST requests
  • OAuth 2 based authentication
  • No channels DMs or chat, players can use Discord servers, Slack, Skype, etc
  • Player identity to be managed via the REST API and a federated login, preferably Discord
    • I'm in favour of using WP to manage login and REST API, with no WP frontend or WP interface for users. Headless, purely internal
    • any $1 webhost can be setup to act as a game server in minutes, multisites can be used to partition games/battles, object caching with Redis should make things stupid fast with the right data structure
      • a lot of it can be partitioned into separate projects, Discord login is a highly desirable plugin that others would want who have nothing to do with BAR or Spring, free testers and maintainers ftw
  • Autohosts would just be instances of dedicated spring that are told "go to /wp-json/lobby/v1/bar/1234 and start an instance, then POST to that endpoint to say you've started, let us know at the end who won/lost.
    • A heroku dynamo could be spun up for each battle using the Heroku API and a github repo to auto-scale.
    • Alternatively a docker container that takes an environment variable containing the battle ID and a shared secret for API auth
    • The command should be runnable via npx, e.g. npx spring-start --engine=".." --map=".." --game="..." etc should download the relevant engine if it's not already, then start up a headless spring. Anybody with node could spin it up with ease
    • Autohosts won't manage the battle itself, they're dumb launchers for the spring executable
    • No voting controls
    • The first player in a battle is nominated the host. They can hand the host to another player. If they leave, the first person in the list gets passed the host. They don't necessarily have to literally host the game on their computer. Look at the way Zoom has a person who controls the meeting called the Host, but that person is just the admin of the zoom meeting, the hosting is done by servers elsewhere
  • PRDownloader etc, I'd really like it if that part of spring-launcher was hived off into its own package so that mutual maintenance could happen. I don't fancy rebuilding basic stuff like this from scratch, better to share and improve alike. There should be a lot of small utility packages at the end of this, nice building blocks everybody can use, be they javascript or typescript
  • Ranks are going in the bin. The current system of arbitrary medal tiers for time ingame is silly. Supernoob got a stupid high rank without playing a single game by spectating. Just bin ranks, and have none.
  • When the time is right to do it properly, introduce a ranked ladder for competitive play, define how long a season lasts, etc
  • Nuke flags. When the community is large enough, just ask players if they want the american server or the european server, otherwise they're super unreliable, expose personal information, and add unnecessary information to the UI
• Singleplayer is more important than multiplayer, multiplayer users are just deafeningly loud in comparison
• For maintenance and Documentation
  • markdown document in each folder for documentation
  • I want to use jest for testing, in particular snapshots
  • A fetch polyfill for API requests
  • I like the idea of using https://sentry.io/ for automated bug reporting

I've identified these projects will be needed:

• Discord WP plugin
• Battle API WP plugin
• Lobby repo
• autohost repo ( also on https://www.npmjs.com/ )
• PRDownloader library repo ( also on https://www.npmjs.com/ )
• unitsync equivalent library repo ( also on https://www.npmjs.com/ )
  • for this it shouldn't assume unitsync and just provide an interface for maps and games with options, then a default implementation that does spring. I expect other game engines would find this helpful, and that would help enormously with maintenance

[tomjn]

Brief mockup of the basic lobby UI frame:

AFL2	[ ] tomjn
Singleplayer	Current screen gets displayed here
+ New Game
DSD FFA
Red Comet 2v2
Settings

• all nav always goes on the left,
• The main AFL2 can be swapped for a game logo
  • it always leads to the main page which gives a bigger welcome logo and a login option
  • It does not have options for singleplayer, as mentioned earlier, all nav is on the left
• The settings option always shows at the bottom regardless of scrolling, as does the AFL2/top bar
• The user link in the top bar might lead to a profile page, but it isn't a dropdown menu to hide things in
  • That profile page would have the logout button
  • usernames can't be changed
  • clans are clans, they don't belong in the username, add a separate system for it at a later date, like a prefix field or actual clan groups. Not minimum viable lobby
• No hamburger/3 dot menus

[tomjn]

The unitsync problem has been a major thorn in my side, it was a huge time sink with AFLobby, and it's gotten worse since then.

For now to get things moving it'll be necessary to hardcode the game/map list.

However, I'd really like to:

• have the JPEG minimap generator function restored to unitsync.dll
• until unitsync is handled, define the available resources via the REST API:
  • an endpoint that lists resources
    • think of it as a manifest of recommended games
  • resources can be tagged as maps, games, engines
  • resources have:
    • an image
    • a version
    • download URLs

If interfacing directly with unitsync in Node isn't possible, then I have some alternatives:

• A go app that does the interfacing, and spits out the data as JSON, and minimaps in a folder
  • very low footprint, fast, compiles to machine binaries
  • cross compiles on every platform
  • could run without compiling for debugging
  • not as many people are familiar with the go language
• A spring game that uses the lua API to read the VFS
  • runs everywhere spring does
  • requires the engine to be ran in headless
  • most portable, least performant

As for native Node, N-API may provide the solution https://nodejs.org/api/n-api.html but I know little of how it works

[tomjn]

For login, OAuth2 is the paradigm of choice, this means we can login users via other services such as Discord, or provide multiple options.

E.g.

• Twitter https://developer.twitter.com/en/docs/basics/authentication/oauth-2-0
• itch.io https://itch.io/docs/api/oauth
• Discord https://discordjs.guide/oauth2/
• Steam: https://partner.steamgames.com/doc/webapi_overview/oauth
• Sign in with Apple: https://github.com/patrickbussmann/oauth2-apple
• A completely custom user database on any WP site: https://github.com/WP-API/OAuth2
• All of the above at the same time or any combination a games maintainers might choose

By using OAuth2, we also eliminate the need to implement authentication from scratch at the client end, they can just use a generic library for their programming language. As a result, existing bots such as hubot or slackbots would be able to authenticate with minimal changes if any. Automation would be significantly easier

[tomjn]

Basic UI frame up and running:

Using the codename necrontyr, colours need adjusting, not a fan of the teals. Next step will be to integrate react router

[tomjn]

[tomjn]

Finally excised the blue header, added disabled menu items for campaign and replays

[icexuick]

I like this!

[tomjn]

A fortuitous consequence of using a custom post type in WP to represent battles, is that they can have comments if so desired. This might actually provide a crude means of battle chat complete with a historical record/backhistory

[MasterBel2]

I fear you're adding extra baggage that turns this into SpringLobby 2.0 in many ways – just cut off the hands and the feet. I'd be really interested to see the rest of your plan to understand it so I can discuss with you more fully about things, but for now I'd pitch what I envision.

Let's start with a bit of background first, though.

What does a user currently have to do to play a game?

-1. Discover BAR Website

The SpringLobby Way: (worst case scenario. Most players won't spam the start button for example)

0. Redirect to SpringLobby's website
1. Download lobby
2. Open lobby
3. Register an account + email verification
4. Find a populated battle, join
5. Wait for everything to download
6. Learn that you have to press "ready" to start
7. Deal with people constantly changing to maps you haven't downloaded yet
8. Spam the "start" button until you get kicked by flood protection
9. Get back into the battleroom, press ready, wait for everyone who's AFK, and finally start the game

The Chobby Way: (not quite worst case scenario)

0. ???
1. Download lobby
2. Open lobby
3. Register an account + email verification
4. Decide singleplayer v.s. Multiplayer
5. Find a battle & join
6. Wait for everything to download
7. (I don't know past this point)

What should it take to get a new player ingame?

0. Navigate to page showing current game queues (FFA/ Team / Scavs/ 1v1)
1. Click a link saying you want to play
2. Download lobby (Can this be automated if we detect it's not installed)
3. Open lobby, and have everything already done, just have to wait and the game will start.
4. (Maybe have a "ready" button)

Click a link on an application deep link on the website which launches the lobby, puts them in the queue they selected, and as soon as practical the game starts. If a user wants to leave the queue they press a "Leave Queue" command.

If the user hasn't downloaded the lobby yet, it automatically downloads the lobby instead of just launching it. Or less ideally, on clicking the link a "Download lobby" button appears beside the link also, just in case they haven't downloaded it yet. On launching the lobby, if it's launched within 5 minutes (or so) of downloading it automatically adds them to the queue they selected (according to a config included in the app bundle when downloaded.) Else it presents them with a similar list to what they see on the website.

Lobby should download with the latest game + engine version, plus all maps in the standard queue, so a user never sees downloading, except when they first get the game, or when an update is pushed. Ideally.

Although. If they're downloading from the main page, should just download the map in the queue that the player selected to speed up download times? Then the lobby will download the missing content in the background.

Login details are saved in keychain, or similar programs, for users who have already logged in. An option to log out/switch account would be important. For new players, logging in should be as simple as typing in their wanted username, and it's assigned to them as soon as they claim it. If it's already taken, ask them to choose a new one (or show a password field so they can log in?) Passwords could be automatically generated and stored securely in a password manager. An option to retrieve the password so they can log in on another machine is important.

If a player isn't being redirected from the website, they should have access to a

Features players will probably want

1. Choosing maps in a queue. Only give players 3 maps to choose from, resetting every hour. Players permanently vote for "Don't care", one of the three maps, or "New selection".
2. Chat. Could provide chat for the queue they're currently in. (As the number of players online increases this will become infeasible and it will make more sense to let groups of players familiar with each other organise their own chat.) 3.1. Organising a game with a specific group: private hosting should be a thing, as should be inviting players to your battle. For the host, this should probably give full control. To prevent the issue of hole punching/whatever, a relayhost-type system should be used where the game itself is hosted on a remote server that all players connect to. The "Host" simply has full control of game options, deciding who is in the game, etc. 3.2. But what about LAN Parties, when all this falls apart? Is it safe to assume that since this is an open source community, people will indefinitely be able to rely on our servers? I don't think we should assume this. 3.3 What about spectating private games? Uhhh… this is where it seems like we're just rebuilding the current system?

My Concerns With My Own Proposal

1. Email verification? This slows down troublemakers, sure, but is it realy
2. Recovery emails? How should this be prompted such that people don't lose their accounts, but in a non-intrusive way?

This post will be revised to add things as I remember what I wanted to put here, or as suggestions & criticisms are made.

[tomjn]

I don't intend to add a lot of what you've mentioned:

• I'd prefer it if the lobby came with an engine and the game, and at least 2 or 3 maps. Alternative engines is more for testing and replays. Unless these differ from the current status quo I see no need to mention them in the UI. There is the current BAR and then there are other versions of BAR

Channels and DMs

There isn't any.

There won't be channels in this lobby, at least not in v1, I question if they're needed at all. If they're ever added, they'll be de-emphasised. They certainly aren't going to be built first like most lobbys. Tbh if I were to organise a game with friends, I'd probably fire up a zoom room so we can talk and ignore the lobby channels completely.

The only chat I see happening in the next few months is battle chat, but that doesn't mean someone couldn't build a chat component and add it to the sidebar. Eitherway chat is not the primary purpose of a game lobby, gaming is, and most games don't have it.

Logins

Login details are saved in keychain, or similar programs, for users who have already logged in. An option to log out/switch account would be important.

User switching isn't in minimum viable lobby, perhaps several months down the line. But with no clans, and no rankings, I see minimal utility in the feature. In the future it would have more relevance.

As for email, the lobby itself doesn't need email verification, or emails at all. That's up to whatever OAuth2 provider gets used. It would seem that most of the OAuth2 part is already built on the server side by other people already. I don't consider this a part of the lobby project, but instead its own parallel thing. A login/register button takes you to the browser.

However:

• In this design, you can see battles without logging in
• I would suggest that if your goal is just to spectate, that no login is necessary either
  • a spectator would have no presence in the battle other than a counter for the number of spectators, they would need to logged in to join the battle as a player
  • they'd be given random names Google Docs style, afterall these people are anonymous, they have no identity ( unless they logged in )
  • this means there is no login/registration barrier to new players spectating and observing, you don't need to be a ranked player in a clan to be a bystander or a member of an audience. Let the masses lurk so they can get ingame as quickly as possible, perhaps they'll get the itch to join and give themselves a name

Downloads UI

Lobby should download with the latest game + engine version, plus all maps in the standard queue, so a user never sees downloading, except when they first get the game, or when an update is pushed. Ideally.

The most I expect is an indicator next to a player to say they're downloading things, and a progress bar in the top to show your progress. It should be contextual, I don't like the idea of having a dedicated download page, and if I did add one it would be for acquiring new content, more like a map store.

But I don't consider this within the scope of minimum viable lobby

Downloading The Lobby

If the user hasn't downloaded the lobby yet, it automatically downloads the lobby instead of just launching it.

I really don't like downloading a downloader. The initial download should be able to get you ingame with singleplayer. I also don't intend to have this UI shown inside the browser on the website. If it's running in a browser, it's because you have the browser and react dev tools and webpack watch running to debug something. This is a desktop app.

Private Battles and LAN

But what about LAN Parties, when all this falls apart? Is it safe to assume that since this is an open source community, people will indefinitely be able to rely on our servers? I don't think we should assume this.

Technically a server is just any WP site with a specific plugin installed. A multisite would thus be able to host hundreds of servers from a single installation. You can install WP with a 1 click installer on most cheap hosts. As for the plugin itself, it just needs to define some data types, which is stupidly easy. I went to WP Generator and filled out some questions and it populated an array of options I copy pasted into a local dev environment.

Given this would use Node, and the REST API is rather simple, a future experiment might be to use one of the Node CMS' and spin up a mini web server in the background that just uses these API points then advertises it locally or gives instructions to other people.

As for authenticating private battles, and private LANs, I'd like to rip off Pokemon Go. Don't show the battles at all, just add an option to enter a private battle, and give it a code, e.g. pidgey squirtle alakazam. It could be customized instead to BAR units or memes like nyan cat. This way private battles are truly private, and don't clog up the battle list.

But while I have these in mind, these are not minimum viable lobby, so are not currently in scope.

What should it take to get a new player ingame?

Singleplayer:

1. User downloads BAR
2. User opens BAR and is presented with lobby UI
3. User clicks single player and selects some options and clicks start

Multiplayer:

1. User downloads BAR
2. User opens BAR and is presented with lobby UI
3. User selects a battle in the sidebar
4. User gets a banner across the top saying they're spectating, and a big button to Join if they're logged in, or a prompt to register/login
5. Once logged in they can click Join
6. Usual battle banter occurs of picking a map, team, colour
7. When enough players are ready they can press start, countdown from 5, game starts

If a user already has BAR and an identity then:

1. User opens BAR and is presented with lobby UI
2. User selects a battle in the sidebar and clicks JOIN in the banner that appears
3. Usual battle banter occurs of picking a map, team, colour
4. When enough players are ready they can press start, countdown from 5, game starts

Right now I've several competing thoughts about the exact layout of the battle screen, but I've plenty to do before I reach that point. However, I don't want a great big panel of options and settings. I'd like to eliminate as many as possible or move them to a new host screen.

Part of me wanted to make it so that battle rooms have a map, and you'd need to open a new room with a new map, but that just sounds really annoying so I killed that.

[tomjn]

Some brief progress updates

• basic react router integrated with some basic scaffolded screens
  • added some placeholder form UI to demonstrate
• redux store added, but not used, also added in fetch polyfill
• the currently joined battle will show just above the multiplayer bit
• added subtext for battle sidebar listing for current status
• started on the WP data plugin

[tomjn]

Repo: https://github.com/tomjn/aflobby2

[tomjn]

Neutralino on MacOS doesn't work, it may work fine for Windows/Linux but this oversight is not a good sign for the project. On first glance, someone popped up and added MacOS support then left. I don't believe the maintainer has the ability to test Mac support, or even understands how apps on MacOS work ( they suggested doubleclicking to launch a raw compiled binary that wasn't in a .app bundle )

[tomjn]

Just for personal reference, some battle room research I had in tabs

I quite like the PA layout, though I would reorder and redesign a lot of that sidebar. I thought I'd taken screenshots of Stellaris and some others but misplaced them, Stellaris has a 3 column layout, players/chat/options with a start button at the bottom

[icexuick]

Notalobby SP

[MasterBel2]

• I'd prefer it if the lobby came with an engine and the game, and at least 2 or 3 maps. Alternative engines is more for testing and replays. Unless these differ from the current status quo I see no need to mention them in the UI. There is the current BAR and then there are other versions of BAR

I fear that by relying on Uberserver, you greatly increase the difficultly of maintaining this paradigm, and not being sucked back into the current lobby paradigm of Chobby, or worse, even SpringLobby.

But to each their own; I shall cease to bother you now.

[MasterBel2]

Although I'll take a moment to clarify something:

My idea was to not download a downloader: The website isn't a lobby on the player's computer; instead, a new player finds the website "oh that's cool", sees a button to play and presses it, and he instantly receives a download of everything he needs. (Afaik a purely in-website lobby is not possible, but if possible that would likely be ideal.) All he has to do then is open the lobby and he's put in a queue, ready to play.

In the background, invisible to the user, the lobby then collects all assets that weren't needed for that first game, as soon as possible (?). Everything needed to join the queue and get ingame in the first place was already downloaded within the lobby package itself, again invisible to the user.

[tomjn]

I fear that by relying on Uberserver, you greatly increase the difficultly of maintaining this paradigm, and not being sucked back into the current lobby paradigm of Chobby, or worse, even SpringLobby.

I have no intention of supporting uberserver in any way shape or form. Uberserver and the TASServer protocol will burn with the fire of a thousand suns. For my official stance at length on the subject, please refer to this helpful video

My idea was to not download a downloader: The website isn't a lobby on the player's computer; instead, a new player finds the website "oh that's cool", sees a button to play and presses it, and he instantly receives a download of everything he needs. (Afaik a purely in-website lobby is not possible, but if possible that would likely be ideal.) All he has to do then is open the lobby and he's put in a queue, ready to play.

Women play RTS games too, but what you're describing just sounds like a download link.

In the background, invisible to the user, the lobby then collects all assets that weren't needed for that first game, as soon as possible (?). Everything needed to join the queue and get ingame in the first place was already downloaded within the lobby package itself, again invisible to the user.

My preference is an installer that installs the game, old school style. None of this collecting assets and downloading assets nonsense. If you want extra maps or updates that's a different thing. Installing the base game should install the base game, that the lobby is built with JS and HTML should have no effect on the website at all, it's just an implementation detail, like which type of screws and nails were used in building your house

[icexuick]

I'm all for oldschool / basic style. Lean and mean.

When joining a server, things should auto-download however. That is a huge benefit. Preferably also as fast as possible AND ideally showing progress to other players how much % is downloaded/installed.

For hosting your own game or play single/offline, there should be an easy way to get new maps, or widgets or other 'mods'. This need to be some sort of a 'subscribed' list (could be a bit like steam workshop). Ideally, this would be linked to your account, so if you re-install and re-login the lobby knows what maps/stuff to download.

[icexuick]

Most important thing is that the lobby is fast, intuitive and also very(!) easy to setup games. Choose a game-type-mode, choose starting locations, setup the teams, do balancing stuff, add scavengers or random-drops or whatever modoption. This is currently costing way too much time and also fun.

[tomjn]

quick update on battleroom scaffolding:

Also some Starcraft screenshots:

[tomjn]

Just putting this here:

Also, I like that Starcraft 2 has a separate singleplayer UI that streamlines things, I got a friend to send newer screenshots: