Coder Social home page Coder Social logo

buddygg / buddy_matching Goto Github PK

View Code? Open in Web Editor NEW
64.0 5.0 7.0 486 KB

Somewhat generic player matching service built with Elixir and Phoenix

Home Page: https://www.buddy.gg

License: GNU Affero General Public License v3.0

Elixir 100.00%
elixir league-of-legends genserver phoenix matching fortnite umbrella fortnite-api riot-api

buddy_matching's Introduction

Backend service for buddy.gg

Build Status Coverage Status License: AGPL v3

Somewhat Generic player matching service built with Phoenix, utilizing GenServers and sockets to avoid having an underlying database.

The application is structered as an umbrella consisting of 4 apps.

Currently built only to support matching players from League of Legends, but can ideally be easily extended to support multiple games.

Run local

To start the server:

  • Install dependencies with mix deps.get
  • Start Phoenix endpoint with mix phx.server Now you can visit localhost:4000 from your browser.

To test interactively in IEx:

  • Install depedencies with mix.deps.get
  • Start IEx with iex -S mix phx.server

To test interactively with Riot's API in IEx, create a local dev.secret.exs from the template, and fill in your 24h API key generated at https://developer.riotgames.com/.

Run tests

mix test

Development

Features should be implemented on feature branches based on [development] and rebased thereinto with Pull Requests. New features should not add any issues to mix credo and should be formatted using mix format.

Releases should be merged from [development] into [master], whereafter [master] is rebased into [development].

Deployment

Development:
Branch 'development' is automatically deployed to Heroku at: https://lolbuddy.herokuapp.com/api/

Examples:

Master:
Branch Master is manually deployed to DO at https://api.buddy.gg/api/

Examples:

Deployment is handled with edeliver, distillery and conform. See the respective repos for more information.

buddy_matching's People

Contributors

ecly avatar hanspagh avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

buddy_matching's Issues

fetch_last_solo_match/2 not guaranteed to return match from current season

Queries for last solo queue match seem to be able to return games from last season, causing us to show potentially wrong results for border. This occurs in fetch_last_solo_match/2 in riot.api.ex, and is a somewhat special case bug.

This is currently only a problem for us early in a season, as we require players to have a match history from which we can deduce their last played champions and/or their border. If they have a match history, and their last solo queue game was from the last season, we will get a rank indication from 2 seasons ago.

Potential fixes:

  • Query API for season specific match
    • Requires some consistent way of getting current season id
    • (Riot currently has bug with bad season id's for matches making this inconsistent)

...

Remove player from socket.assigns

Instead - add an additional function to RegionMapper and PlayerServer, that simply looks up a player from the name+region. Instead of the id+name that we store in Presence right now, store name+region instead, such that we only save this once, and can merely look it up from there when we need to get the player.

Handle matching of PUBG players

Be able to handle matching of PUBG players

  • New gen servers to store players in
  • Some sort of PUBG api lookup to get player stats
  • PUBG player struct and matching

Update README following umbrella conversion

Once the umbrella_conversion hits the development branch, we'll want to to update the README.md to reflect the new structure. Additionally we may want to add appliciation specific READMEs.

Handle matching in PlayerServer

To try and reduce memory footprint, at the cost of CPU-usage, try to implement the PlayerServer such that getting players from PlayerServer only returns matches - eg. that the read from PlayerServer now takes a Player as a parameter, and then filters its state, only returning matches.

Add more json validation

We need to do more json validation, since it's really hard to debug why parse player json fails, when we are just throwing errors.
Ex. sending voicechat as a non array

Fix remaining 2 credo refactoring opportunities

Both of these are from doing lazy logging. We can either remove these function calls or refactor the code to reduce function depth by one. This is needed if we want to properly utilize our git pre-commit hook, as we will otherwise end up commiting everything with --no-verify otherwise.

Allow player's league to have no rank

If we adjust matching to try to match players even if they do not have a rank, they we can somewhat more cleanly represent players for whom we only know their tier based on last season's border.

This will also make it perhaps easier to represent such players in the frontend, instead of arbitrarily showing Gold5, for someone who all we know is that they have a gold border.

We can either use 0, or nil in place instead of the current 1-5 for these cases, but it will taint the code slightly.

Map.fetch in OK's for comprehension should be Map.get

Since OK doesn't perform nicely in the case where Map.fetch/2 returns :error, we should replace <- with = and use Map.get. It should instead just fail in the following calls if these are dependent on Map.get/2 not returning nil.

I believe this is used in Fornite API and potentially in Riot API, and will remove some otherwise potential unexpected errors.

Update documentation following abstract_matching and new_player_struct

We'll have made tons of changes, and we have certainly not updated the documentation everywhere we did. We should do a proper sweep-through and ensure that we don't have outdated documentation lying around.

The README's may additionally require updates following these changes.

Validate players on channel join

To avoid JSON tampering of bad players, validate the players on channel join. This mean eg. ensuring that they have at least one language, an age group and that all strings are of reasonable length. Currently comments have 100 character length restriction in frontend - we could enforce this as well.

Ignore language option

Consider adding an extra entry to the criteria struct, allowing language filtering to be disregarded. Matching wise this would be implemented as language matching handled with:

intersects(p1.languages, p2.languages) || (p1.criteria.ignoreLanguages && p2.criteria.ignoreLanguages)

Player voice key to list of booleans

Since we want players to be able to choose a "don't care"-option for whether they'll use voice chat or not , we'll now represent the voice selection with a list of booleans. Selections will result in the following lists:

  • Yes => [true]
  • No => [false]
  • Don't care => [true, false]

This means we'll have to change a fair chunk of tests/comments to work with this new expected datatype, and we will perhaps similarly have to add a couple of tests covering the "don't care"-case. In matching, we'll adjusting the check for voice to using list intersection.

Handle unranked players

For unranked players, try to get last season's rank based on their border. If none available use Silver 5.

Channel memory deallocation after matching

Currently channels are allocated the the memory needed to store all the matches for the brief moment that they get these from the GenServer. This amount of memory remains allocated for the channel, even after it is done with the matches. Somehow reduce reduce the allocated memory for the channel after this or send all messages from PlayerServer (ugly); or perhaps something else entirely.

Use Riot API for champion names

Although it may slightly decrease speed, we would like to use Riot's API for getting champion names from IDs to avoid having to maintain the list of champions. At the very least we could make it a fallback.

Remove ranks from challenger/master players

These tiers have no 'ranks' in the sense that diamond 1/2/3/4/5 has, so we shouldn't display these despite riot giving them the rank 1. This will make it look as expected in the frontend.

Deployment notes

  • heart for handling errors
  • configure logging
  • Prometheus for metrics and stats tracking (Really cool)
  • remote_console to connect to the running node
  • Setup systemd with edeliver
  • Encrypt secret configs

Fix tsung config

After the api changed the tsung config is not working anymore, this due to the socket api payload was changed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.