From 79d224ac7f7ee0f504b9b9e73385bbf3582f4d62 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Mu=C3=B1oz?= Date: Sun, 9 Dec 2018 20:35:51 -0500 Subject: [PATCH] Fix segment for link to api. --- docs/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/overview.md b/docs/overview.md index 518c778..6553921 100644 --- a/docs/overview.md +++ b/docs/overview.md @@ -12,7 +12,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: @@ -92,4 +92,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! \ No newline at end of file +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!