Spaces:
Running
Running
| # Simulate | |
| `index.js` allows for running multiple random simulations of Pokemon battles | |
| for testing or benchmarking purposes. Without any arguments, `index.js` will | |
| run 100 random battles and report any errors that occur. | |
| Using any flag will trigger [minimist](https://github.com/substack/minimist) to | |
| be installed if it has not been already. | |
| ## multi | |
| The `multi` subcommand (alias: `random`) allows for configuring the amount of | |
| battles played, which formats are used, how they are run, and what to output. | |
| ### General | |
| - **`--num`**: play a specific number of games for a format instead of the | |
| default 100. | |
| - **`--seed`**: PRNG seed to use (eg. `'1234,5678,9012,3456'`). | |
| - **`--output`**: makes the harness display the _output_ logs of each battle | |
| it runs. | |
| - **`--input`**: dump the battle _input_ logs of each battle it runs. | |
| - **`--error`**: dump the battle _input_ logs of each battle which errors. | |
| ### Format | |
| By default, the harness will select the format of the next game it runs randomly | |
| based on its initial `--seed`. Alternatively, it can run games all in the same | |
| format, cycle through the formats or run all formats. | |
| - **`--format`**: play the specified format for each of the games it runs. | |
| Note that the harness only supports formats where the team can be randomly | |
| generated. | |
| - **`--cycle`**: cycles through the possible formats, playing one battle in | |
| each `--num` battles in total. | |
| - **`--all`**: plays every supported format `--num` times before moving on to | |
| the next format. | |
| ### Concurrency | |
| The harness runs games sequentially by default, but can be configured to run | |
| games asynchronously. | |
| - **`--async`**: runs each game concurrently instead of waiting for the | |
| previous game to complete before starting the next. Note that since battles | |
| run through the harness should not be blocking to begin with (battles | |
| naturally wait for players to make their decisions, but the AI's should be | |
| making decisions pretty much immediately), this mode is not expected to have | |
| large performance benefits over the default sequential mode and may require | |
| additional memory. | |
| **TODO**: Add support for running battles in `--parallel` on muliple cores with | |
| [`worker_threads`](https://nodejs.org/api/worker_threads.html). | |
| ## exhaustive | |
| The `exhaustive` subcommand cycles through all generations and game types, | |
| attempting to use as many different effects as possible in the battles it | |
| randomly simulates. This can be useful as a form of | |
| ['smoke testing'](https://en.wikipedia.org/wiki/Smoke_testing_\(software\)), a | |
| form of sanity testing/build verification which can be used to expose obvious | |
| critical issues with the application. Making it through a successful cycle of | |
| smoke tests does *not* mean the application is without bugs, or even that it is | |
| crash free - it simply provides some confidence that the application is less | |
| likely to catch fire. | |
| ### Flags | |
| - **`--format`** / **`--formats`**: play the specified format(s) instead of | |
| iterating through all possible formats. If multiple formats are specified, | |
| separate each format with a comma (eg. `format1,format2`). | |
| - **`--cycles`**: exhaust the pools of effects `--cycles` times instead of | |
| just once. If `--cycles` is negative, `--forever` is implied. | |
| - **`--forever`**: continue iterating through formats infinitely, exhausting | |
| each `--cycles` times. | |
| - **`--seed`**: PRNG seed to use (eg. `'1234,5678,9012,3456'`). | |
| - **`--maxFailures`**: exit early if this many failures have occured. | |