Massive Refactor

[StoneT2000]

It makes little sense for this repository to have it's own "Design" class. A environment should be definable in any format, and be allowed to plug right into this. This framework really should just be about linking agents to a central environment and processing the communications.

At the moment a few problems A lot of overcoding A lot of code in wrong places Bad terminology Also all the plugins should not be in this repository. Weirdly does the compilation for you... bots should honestly be precompiled. A compilation server should be separate from any match running server. (and we can provide some starter scripts for that perhaps) Runs a server to host a API to serve any data, but weirdly can also handle user management, authorization. That was a bad idea because everyone handles users differently. Instead, should treat dimensions as a microservice. It can run a single match for you, or run a bunch. It's up to user to track things.

The only features this should have

• Run a match given a design that can accept agent inputs and returns reward and observations. Design/Environment should foremost be easily a simple drop and run for python gyms (pass a python file, do some parsing), and some extra linkage for non python envs.
• Run a tournament/leaderboard evaluation system that is highly customizable
• By default store replays and logs into local file storage. This can easily then be drop in replaced by a file storage plugin (e.g. GCS)
• By default write results locally into memory. This can easily then be drop in replaced by a database plugin (e.g. mongodb) Should be distributed
• Allow handling of dockerization of bots for security, benchmarking etc.
• Allow all lifecycle functions of a match and data accessible via an API.

Why keep this typescript? Event based is nice which python is bad with in my experience. In general should be quite fast when running matches given that JS is "generally" faster than python (and there are native modules in JS that are super fast). Even then, bulk of the time is spent on the environment doing processing and agents making decisions. Overhead from I/O is minimal. And if I/O becomes an issue, this is likely only happening when someone wants to do data driven RL and generate a ton of frames, of which you would not use dimensions for. Dimensions is just for high performance cross platform, cross language, competitions with nice features.

Also, can import dimensions into a local "battlestation" where you can run local tournaments from app, evaluate, watch replays etc. as opposed to making a bunch of API calls.