rustyscreeps/screeps-arena-game-api

Typed bindings to the Screeps Arena in-game API for WASM Rust AIs

screeps-game-api

Typed bindings to the Screeps in-game API for WASM Rust AIs.

Also the homepage for tools relating to writing Screeps AIs in Rust.

screeps-game-api is a Rust binding to the JavaScript APIs for programs compiled to WASM using stdweb.

Also in this organization is cargo screeps, a binary program which wraps cargo web and lets one directly upload Rust WASM code to Screeps servers.

These two tools go together well, but do not depend on eachother. cargo-screeps can compile and upload any screeps WASM project buildable with stdweb's cargo-web, and screeps-game-api is usable in any project built with cargo-web.

Writing Screeps code in Rust can be nice, but it can also be annoying. If you have tips, tricks, or other things you'd like to share, make an issue! We need to write more documentation, and if we have enough ideas, we can start an mdbook for this repository.

• cargo screeps usage docs
• screeps-game-api api docs
• screeps-starter-rust example project

If you need help or want to share feedback, feel free to open an issue or come say "Hi!" on the official Screeps Slack in the #rust-wasm channel!

---

Here's a quickstart for what you need to get going. More documentation will be made in the future.

# clone:

git clone https://github.com/rustyscreeps/screeps-starter-rust.git
cd screeps-starter-rust

# cli dependencies:

cargo install cargo-screeps

# configure for uploading:

cp example-screeps.toml screeps.toml
nano screeps.toml

# build tool:

cargo screeps --help

screeps-arena-game-api's Issues

Creep ID panic

When I try to call creep.id() and print it's results, it panics with
Error:unwrap_throwfailed at imports.wbg.__wbindgen_throw (file:///user/screeps-arena-starter-rust:424:15) at <anonymous>:wasm-function[414]:0x28dce at <anonymous>:wasm-function[293]:0x258fe at <anonymous>:wasm-function[382]:0x284d1 at <anonymous>:wasm-function[92]:0x14f04 at <anonymous>:wasm-function[250]:0x247a2 at <anonymous>:wasm-function[132]:0x1a1cf at <anonymous>:wasm-function[378]:0x2847b at <anonymous>:wasm-function[311]:0x2604e at <anonymous>:wasm-function[92]:0x14f04
I only get this issue with creeps, not structures.

From debugging, it seems to work if I instead call js_sys::Reflect::get(creep, JsValue::from("id") )
But it actually returns a JsValue number instead of string. I think the cause is that the JS API is inconsistient with storing the ID attribute as strings or numbers.

Also another issue is that it panics when you call creep.id() before it spawns. In which case js_sys::Reflect returns undefined attribute instead.

Two versions of BodyPart

objects/impls/creep.rs has BodyPart (representing a section of a creep, which has some hit points)

objects/impls/arena/body_part.rs also has BodyPart (representing an object that can be picked up in ctf mode)

The structures are not the same; maybe their names could be different.

Return value of spawnCreep not per API documentation -> crash

The API doesn't behave strictly as documented.
According to the docs, when spawnCreep is successful, it returns a javascript structure containing a Creep object ( {object: the_creep}).
However the creep object is not as described in the documentation - every field is undefined while the documentation states for example that is is of type string. This means that the API crashes if you try and access any member of this blank object.

The solution I think is to treat the return value of spawnCreep not as a Creep object, but as another type (e.g. CreepPlaceholder or SpawningCreep). Then that object can have id() -> Option<JsString> and the existing Creep object can can continue with id() -> JsString.
The less good alternative is to change the spec of Creep so that all of its attribute functions return Option - but this would make the code harder to work with and less readable, in the 99% of the code base that doesn't deal with spaning, as you'll constantly be having to destructure the enum. Not very ergonomic.
Both of these choices would be breaking changes to existing codebases, however changing the return type of spawnCreep would cause smaller breakage to a smaller area of the code which makes it the better approach not just in the long term but also during the migration.
There are 2 ways we could "fix" this without making a breaking change:

1. return JsString ("") when the underlying javascript attribute is undefined. But this is totally unrusty.
2. Document that the object returned from spawnCreep should not be accessed until several ticks after the object is obtained and the creep is spawned. This is rather unsatisfactory also!

So I think an api breaking change is unavoidable, but will be for the greater good.