ed-flanagan / riot_lor Goto Github PK

View Code? Open in Web Editor NEW

2.0 2.0 1.0 98 KB

Elixir library to encode/decode Legend of Runterra deck codes

License: MIT License

Elixir 100.00%

elixir runeterra riot-games lor legends-of-runeterra riot

riot_lor's Introduction

🃏 Riot LoR deck code library ⚗️

Yet another Elixir implementation of Riot's Legends of Runterra deck code library.

Installation

If using Hex, the package can be installed by adding :riot_lor to your list of dependencies in mix.exs:

def deps do
  [
    {:riot_lor, "~> 1.1.1"}
  ]
end

Usage

Documentation

Docs can be found at https://hexdocs.pm/riot_lor.

You can also read supplemental docs under the docs/ directory.

Examples

You can run the project locally with iex -S mix. You may want to configure IEx to

display lists of ints as lists, rather than charlists
limit inspect enum length to 4, in case your want to limit large outputs of decks

Inspect options

iex \
	--eval 'IEx.configure(inspect: [limit: 4, charlists: :as_lists])' \
	-S mix

iex(1)> IEx.configure(inspect: [limit: 4, charlists: :as_lists])
:ok

Decoding

iex(2)> deck_code = "CEAAECABAQJRWHBIFU2DOOYIAEBAMCIMCINCILJZAICACBANE4VCYBABAILR2HRL"
"CEAAECABAQJRWHBIFU2DOOYIAEBAMCIMCINCILJZAICACBANE4VCYBABAILR2HRL"
iex(3)> deck = Riot.LoR.DeckCode.decode!(deck_code)
%{
  %Riot.LoR.Card{fac: 2, num: 6, set: 1} => 2,
  %Riot.LoR.Card{fac: 2, num: 9, ...} => 2,
  %Riot.LoR.Card{fac: 2, ...} => 2,
  %Riot.LoR.Card{...} => 2,
  ...
}
iex(4)> Riot.LoR.Deck.code_count(deck)
[{"01IO006", 2}, {"01IO009", 2}, {"01IO012", ...}, {...}, ...]

Encoding

iex(5)> card_counts = [{"01DE001", 1}, {"05BC198", 1}]
[{"01DE001", 1}, {"05BC198", 1}]
iex(6)> deck = Riot.LoR.Deck.from_card_counts!(card_counts)
%{
  %Riot.LoR.Card{fac: 0, num: 1, set: 1} => 1,
  %Riot.LoR.Card{fac: 10, num: 198, set: 5} => 1
}
iex(7)> Riot.LoR.DeckCode.encode!(deck)
"CQAAAAQBAEAACAIFBLDAC"

Contributing

See the CONTRIBUTING.md file.

Legal

Licensed under the MIT License. See the LICENSE file for more details.

Per Riot's Core Policies:

The riot_lor project isn't endorsed by Riot Games and doesn't reflect the views or opinions of Riot Games or anyone officially involved in producing or managing Riot Games properties. Riot Games, and all associated properties are trademarks or registered trademarks of Riot Games, Inc.

riot_lor's People

Contributors

Stargazers

Watchers

Forkers

hschaeidt

riot_lor's Issues

Rename the app and root module "prefix" as to not namespace trespass

The app name is :riot_lor; however, our "root" module is Riot.
According to https://hexdocs.pm/elixir/main/code-anti-patterns.html#namespace-trespassing this may be considered "namespace trespassing"

This anti-pattern manifests when a package author or a library defines modules outside of its "namespace". A library should use its name as a "prefix" for all of its modules. For example, a package named :my_lib should define all of its modules within the MyLib namespace, such as MyLib.User, MyLib.SubModule, MyLib.Application, and MyLib itself.

This suggests that the "namespace" should be something like RiotLoR. There isn't an official Riot namespace, but I do not wish to claim it. I'd rather keep that namespace open and have my own, distinct, namespace. This is based on this example:

Even if Plug does not currently define a Plug.Auth module, it may add such a module in the future, which would ultimately conflict with plug_auth's definition.

Further, this library is specific to Runeterra, i.e. the LoR. However, if I choose to extend my development to something beyond Runeterra, RiotLoR isn't a great prefix. So, based on this example:

If you are the maintainer for both plug and plug_auth, then you may allow plug_auth to define modules with the Plug namespace, such as Plug.Auth. However, you are responsible for avoiding or managing any conflicts that may arise in the future

It may be prudent to come up with a common, more generic, prefix.
E.g. say I have to libraries: one for Runeterra deckcodes and one for the Riot API. I may desire to have a common prefix, say MyRiotLib. I can then have a common prefix across libraries, i.e. MyRiotLib.Runeterra and MyRiotLib.API.

MyRiotLib is not an app reference itself, but can be a common prefix, like Plug. The respective app names may be something like :myriotlib_runeterra and :myriotlib_api

This is a major change and will require a major version update. Further, there may be implications of changing the app name for Hex

Review need for admonition blocks

Add Livebook demo

I've had a branch on my laptop for months, I need to finish and push

Split varint into own package

I started this project just for fun -- practice some Elixir and explore Riot's deck code implementation. Since it was for fun, I rolled my own varint implementation, not looking for pre-existing libraries. However, the implementation is not project specific and feels out of place within this project (to me). Maybe it makes sense to split out into its own package?

The implementation, as is, is fairly generic, albeit lacking in some possible features/functions. Further, I don't want to litter the ecosystem with Yet Another library. Some other implementations I'm aware of:

https://github.com/ahamez/varint -- dedicated library, seems to be somewhat active. If I feel something is missing, maybe a better idea just to contribute there (e.g., VLQ, signed values, etc.)
https://github.com/elixir-protobuf/protobuf/blob/main/lib/protobuf/wire/varint.ex -- an internal implementation for Protobufs, but a popular one.