Code Monkey home page Code Monkey logo

space_traders's Introduction

codecov

Space Traders in Dart

A Dart client for spacetraders.io.

Packages

  • cli - The main CLI for "playing" the game.
  • db - Postgres bindings for storing client state.
  • openapi - A generated Dart client for the Space Traders API.
  • server - A very basic server for supporting the UI.
  • types - Shared types between the packages.
  • ui - A Flutter UI for the Space Traders API.

cli, db and types are the most complete and useful packages. openapi is generated (and pretty terrible code). server and ui are mostly stubs.

Setup

This requires Dart 3.0.0 or later.

The easiest way to get Dart is typically via Flutter. See https://flutter.dev/docs/get-started/install for instructions.

On ubuntu:

sudo snap install flutter --classic

If you're running this in a docker container, or otherwise as root Dart and Flutter will print a warning about running as root. You can ignore it or disable it with:

export BOT=true

Usage

The client originally ran as a single program using JSON files for state. At this time it's been partially refactored to use a Postgres database for state. Thus you need to run the database server first.

Database

See instructions in packages/db/README.md.

Note: currently our notify/listen code seems to cause a leak on the server side of the connection. Thus you may need to restart both the cli and network executor every 12 hours or so, depending on how much RAM you have.

I run the cli, db and network executor all in the same instance which has 4GB of RAM. I typically restart the cli and network executor every 12 hours.

Network Executor

The network executor is the rate limited client for the Space Traders API. It's a separate process to allow us to eventually have multiple clients running at once.

The CLI does not require the network executor (it knows how to do) in process rate limiting, but it's recommended if you plan to be running things for long periods of time.

I typically run the network executor in a separate terminal window or tmux or screen session. e.g.

screen -S net
cd packages/cli
dart run bin/network_executor.dart

CLI

The CLI is the main way to play the game. It's a single process that handles all the game logic and logging. It does require user input to register, but after that it can run unattended.

Similar to the network executor, I typically run the CLI in a separate terminal window or tmux or screen session. e.g.

screen -S cli
cd packages/cli
dart run

Example CLI output

 dart run
Building package executable... (1.6s)
Built space_traders_cli:space_traders_cli.
Welcome to Space Traders! πŸš€
πŸ›Έ#1 ⛏️   6 COPPER_ORE         πŸ“¦ 57/60
πŸ›Έ#2 ⛏️   3 AMMONIA_ICE        πŸ“¦ 17/30
πŸ›Έ#1 Docking at X1-VS75-67965Z
πŸ›Έ#1 🀝  6 COPPER_ORE         -14%  -8c per,  6 x  48c = +288c -> 🏦 30,624c
πŸ›Έ#1 🀝  6 ICE_WATER          -13%  -2c per,  6 x  13c =  +78c -> 🏦 30,702c
πŸ›Έ#1 🀝 12 QUARTZ_SAND        πŸ‘Œ per, 12 x  21c = +252c -> 🏦 30,954c
πŸ›Έ#1 🀝  7 IRON_ORE           +52%  13c per,  7 x  38c = +266c -> 🏦 31,220c
πŸ›Έ#1 🀝 11 ALUMINUM_ORE        -6%  -3c per, 11 x  48c = +528c -> 🏦 31,748c
⏱️ 62s until 2023-05-20 10:25:38.984
πŸ›Έ#1 Moving to orbit at X1-VS75-67965Z
πŸ›Έ#1 ⛏️   6 QUARTZ_SAND        πŸ“¦ 21/60
πŸ›Έ#2 ⛏️   5 ICE_WATER          πŸ“¦ 22/30
⏱️ 66s until 2023-05-20 10:26:52.461
πŸ›Έ#1 ⛏️   8 AMMONIA_ICE        πŸ“¦ 29/60
πŸ›Έ#2 ⛏️   8 AMMONIA_ICE        πŸ“¦ 30/30
πŸ›Έ#2 Docking at X1-VS75-67965Z
πŸ›Έ#2 🀝 11 ICE_WATER          -13%  -2c per, 11 x  13c = +143c -> 🏦 31,891c
πŸ›Έ#2 🀝 11 AMMONIA_ICE         -5%  -2c per, 11 x  40c = +440c -> 🏦 32,331c
πŸ›Έ#2 🀝  8 SILICON_CRYSTALS   -14%  -5c per,  8 x  31c = +248c -> 🏦 32,579c
⏱️ 63s until 2023-05-20 10:28:05.339
πŸ›Έ#1 ⛏️   4 ICE_WATER          πŸ“¦ 33/60
πŸ›Έ#2 Moving to orbit at X1-VS75-67965Z
πŸ›Έ#2 ⛏️   5 AMMONIA_ICE        πŸ“¦  5/30
⏱️ 65s until 2023-05-20 10:29:18.158
πŸ›Έ#1 ⛏️   8 SILICON_CRYSTALS   πŸ“¦ 41/60
πŸ›Έ#2 ⛏️   6 COPPER_ORE         πŸ“¦ 11/30
⏱️ 66s until 2023-05-20 10:30:31.109
πŸ›Έ#1 ⛏️   4 ICE_WATER          πŸ“¦ 45/60
πŸ›Έ#2 ⛏️   7 COPPER_ORE         πŸ“¦ 18/30
⏱️ 66s until 2023-05-20 10:31:43.985

cli bin/ directory

There are a variety of scripts I've written in packages/cli/bin which can be used to query the database, or do other things. They're not documented yet, but you can see what they do by reading the source. I've tried to sort them by area of interest.

Most scripts run completely on cached data, but the ones which do talk to the API are smart enough to use the db and network executor if available otherwise they will use the API directly via an in-process rate limiter.

Development

Testing

You can run individual packages tests locally by cd'ing into the package directory and running dart test.

There are also tools like very_good which can run tests across multiple packages, e.g. dart pub global activate very_good_cli then very_good test -r.

Coverage

I've slowly been adding tests and increasing coverage. See codecov for the current coverage.

You can run all the tests locally and collect coverage by running ./coverage.sh. This will run all the tests and generate a coverage report in coverage/lcov.info. You can then view the coverage report by running genhtml coverage/lcov.info (on linux) and opening the generated index.html file in your browser. There are also a variety of other tools for viewing lcov.info files, including extensions for VSCode. Mostly I just use codecov for viewing coverage.

Reset day checklist

cd packages/cli
dart run bin/reset.dart
cd ../db
docker exec spacetraders_postgres /scripts/init_db.sh spacetraders
  • Update open_api_config.yaml to have the latest git hash.
  • regenerate space_traders_api

Generating openapi package

export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
dart pub global activate openapi_generator_cli
rm -rf packages/openapi/
openapi-generator generate -c open_api_config.yaml
rm -rf packages/openapi/test
dart pub -C packages/openapi get
dart format packages/openapi
git add packages/openapi

Then modified:

Bugs to report to OpenAPI

  • Required arguments in request body should make body required/non-nullable. Example: RegisterRequest for POST /users/register
  • The generated "enums" do not have equals or hashCode. e.g. ShipRole. It doesn't end up mattering because they're singletons though.
  • Generated toJson methods are not recursive (e.g. Survey.toJson doesn't call SurveyDeposit.toJson).
  • Seems to lack anyOf support (GetSystemWaypointsTraitsParameter).

TODO

See TODO.md for a list of of issues I'm working on.

space_traders's People

Contributors

eseidel avatar dependabot[bot] avatar

Stargazers

 avatar  avatar Parth Mangukiya avatar C'tri Goudie avatar Gabor Dolla avatar Arthur R Longbottom avatar Minh Tran avatar SpaceAdmiral avatar Francisco Pitriqueo avatar Murilo Sandiego avatar Aleksey Lysov avatar Paul Zarudnev avatar Ilyas LEFEBVRE avatar Mehdi Amiri avatar Amir Panahandeh avatar  avatar ε΄δΈŠι˜Ώε‰ avatar xuty avatar Felix Angelov avatar Erick avatar Sandalots avatar Dillon Nys avatar

Watchers

 avatar  avatar

Forkers

agdolla

space_traders's Issues

feat: Better understand and use market data

Right now I've done some basic integration of market data from:
https://st.feba66.de/prices
Via:
https://github.com/eseidel/space_traders/blob/main/packages/space_traders_cli/lib/prices.dart

But there are a bunch of things wrong with this approach.

  1. This is global market data. Across the whole "universe". Likely that data is split across functionally separate markets. Although trades are possible across the whole thing, it may be prohibitively "long" distances. Also the data is relatively small (only 4k trades last I checked), which likely means it's only for a small subset of the universe, which may or may not correspond with where I'm trading.
  2. I'm currently using "median" value across all the data for a given trade good (probably at least want to use only "local" data for the last N minutes). I'm not sure "median" is the right way to get a sense of "what is a normal price for this", maybe? Should I put putting it into some sort of distribution? (to avoid that "median" might be dominated by lots of trades at the same overused market?)
  3. Currently I'm displaying the percentile information from this data on trades (to try and get a sense of how good/bad the trade was). But I probably want to display either percentage discount (e.g. 50% of median price) or percentage discount * median price (e.g. this trade was -5c worse than median per unit).

image

Things I've considered doing with price data is planning trade routes.

The game does not let you see price information at a waypoint unless you have a ship there. You can obviously record recent transactions in your own database when you visit a waypoint.

The game will let you see what imports / exports / allowed-tradegoods (not necessarily wanted by the waypoint, just allowed for trading between agents) a given market handles.

A basic trading algorithm might be to buy goods locally that seem at the greatest credits discount below median trade value and then head towards either a nearby market with recently known above-median trade prices, or head blindly to a market marked as "import" for those goods, on the assumption that should give you median-or-better trade prices?

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.