Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ The first argument given to all event consumer methods is the `world`. The `worl
// ...
}
```
As you can see, the `world` is made up of `agent`, a reference to your agent, `data`, which is a store of data related to internal functionality of the bot, and `resources`, which are the main points of entry to all other game state. The world and its contents are spoken of in more detail in the API Reference documentation [here](docs/api.md). We will go further into how to use the `world` context shortly, but for now it's enough to understand how to access it.
As you can see, the `world` is made up of `agent`, a reference to your agent, `data`, which is a store of data related to internal functionality of the bot, and `resources`, which are the main points of entry to all other game state. The world and its contents are spoken of in more detail in the API Reference documentation [here](./api.md). We will go further into how to use the `world` context shortly, but for now it's enough to understand how to access it.

## Systems
A system is an encapsulated part of your agent. Think of them like middleware in `express`. Systems are optional, but are very helpful for breaking bots down into easier to handle, reusable pieces, creating modularity. For instance, you could create a `WorkerRushDefense` system, and each time you make a new bot, simply include this system without having to copy and paste code or update it across many agents. Systems can even be published and installed as dependencies. There are also some special types of systems (such as a Build System) which implement additional features like following a build order. Systems implement the `EventConsumer` trait, and so they can accept consumer methods just like an agent can. Here is an example of the same worker rush bot given in the readme, but this time implemented as a system:
Expand Down Expand Up @@ -109,4 +109,4 @@ The `map` resource represents everything related to positioning of the game worl
The `actions` resource is the main way to interact with the sc2 client itself, via commands (actions or queries). While the other resources are mainly used as a way to *read* data from the game state, think of `actions` as a way to *write* to, or mutate, the game state. Generally, consumer methods will end with calling and returning something from this resource. In the above example, `attackMove()` is used to send the workers to attack the enemy base. Other helper methods exposed include `attack()` (a unit target), `build()`, `train()`, `move()`, `gather()`, and `upgrade()`. On top of these and others, `sendAction` is available to send a more raw query that otherwise doesn't have a method exposing. Beyond these commands, the query for placements is provided via `canPlace()`, and lower level `sendQuery()` for sending other query types. Further details of the `actions` resource API are available [here](./api.md).

## Now what?
Now that you have a basic overview of `node-sc2`, it's time to make a bot that can consistently beat the built-in Elite AI. Head on over to the [tutorial](./tutorial.md) now!
Now that you have a basic overview of `node-sc2`, it's time to make a bot that can consistently beat the built-in Elite AI. Head on over to the [tutorial](./tutorial.md) now!