Anacreon is down for a bit

[george moromisato]

I think someone wrote a bot to deploy fleets; the server was getting hit with dozens of requests per second.

I need to add some countermeasures to drop requests if they happen too often--otherwise it will overload the server.

I'll bring it back up as soon as I have the countermeasures written. Hopefully in the next day or so.

[Watch TV, Do Nothing]

While it's bad that unrestrained use of the API overtaxed the server, I think it's good that players are finding new ways to engage with the game.

As the player base expands, most likely the use of scripts to call the API will expand and start to tie into concerns that I think Finnian expressed last year about whether players can remain alive in competitive games without being "always on call", either by actually being present and able to play literally all the time, or by having some sort of bot operating to shuffle forces around in response to other player's actions.

I think player use of scripts is exciting and cool (I haven't tried it myself except to access planet tables for a mapping project that I did last year). But if it ends up going beyond convenience and data exploration to convey an insurmountable competitive advantage against players who do not use scripts, that's a problem. If there are elements of the game where player power growth is limited by tedium (e.g., expanding against independent worlds) or reflexes (managing tactical combat), we will see attempts to partially or fully automate those processes, and from there we will see automated and semi-automated attacks against other players.

Some of the dangers can be circumvented by designing the game in a way that scripting does not offer a concrete strategic advantages- don't give players enough rope to hang themselves. Anti-blitz measures like the siege system are an exaple of this, because a bot could manage a large-scale blitz much more efficiently than a player. There could also be limited automation within the game client itself (e.g. fleet orders to perform on arrivsl) so that less savvy players are on more even ground.

Some player creative energy might be productively redirected by having games that are specifically for script-supported play and bots.

At a minimum, at some point it may make sense to start thinking about a player code of conduct for using the API, browser automation, etc.

[george moromisato]

While it's bad that unrestrained use of the API overtaxed the server, I think it's good that players are finding new ways to engage with the game.

As the player base expands, most likely the use of scripts to call the API will expand and start to tie into concerns that I think Finnian expressed last year about whether players can remain alive in competitive games without being "always on call", either by actually being present and able to play literally all the time, or by having some sort of bot operating to shuffle forces around in response to other player's actions.

I think player use of scripts is exciting and cool (I haven't tried it myself except to access planet tables for a mapping project that I did last year). But if it ends up going beyond convenience and data exploration to convey an insurmountable competitive advantage against players who do not use scripts, that's a problem. If there are elements of the game where player power growth is limited by tedium (e.g., expanding against independent worlds) or reflexes (managing tactical combat), we will see attempts to partially or fully automate those processes, and from there we will see automated and semi-automated attacks against other players.

Some of the dangers can be circumvented by designing the game in a way that scripting does not offer a concrete strategic advantages- don't give players enough rope to hang themselves. Anti-blitz measures like the siege system are an exaple of this, because a bot could manage a large-scale blitz much more efficiently than a player. There could also be limited automation within the game client itself (e.g. fleet orders to perform on arrivsl) so that less savvy players are on more even ground.

Some player creative energy might be productively redirected by having games that are specifically for script-supported play and bots.

At a minimum, at some point it may make sense to start thinking about a player code of conduct for using the API, browser automation, etc.

I agree 100% with this!

Anacreon is all about diversity, in the sense that different play-styles should be viable. We don't want to end up with one and only one way to play.

Moreover, I'm a big supporter of modding and I am happy that people are writing scripts. This is absolutely a server-problem and not a problem-player.

EDIT: A few more things:

1. I probably need to write a quick document describing our policy on this.
2. In the far future, we might even add native support for scripting on the server itself (that is, player would write scripts on the server).
3. Here's a Ministry record to discuss the short-term fixes: https://ministry.kronosaur.com/record.hexm?id=79981
4. At some point, I should write documentation on the API.

[george moromisato]

Anacreon is back up again.

I've added some basic limits that should, I hope keep the server going. In practice, you should never hit a limit, even if running a bot (unless the bot misbehaves). But if you do run into a limit, please report it (either here or in Ministry).

[whaleduck]

I think someone wrote a bot to deploy fleets; the server was getting hit with dozens of requests per second.

Sorry about that. I tried to limit the rate of requests being made after the server went down at ~7:30 CDT. I didn't mean to intentionally tax the server with a malicious intent.

I was deploying fleets to every planet because I wanted to make a heat map of space forces throughout the galaxy (and also to see how big the api/getObject response could get)

4. At some point, I should write documentation on the API.

I have a fair bit of free time now that school is out for the summer. I can try to write some documentation,

Additionally, I have created an (incomplete) Python package for interacting with the Anacreon API. Perhaps someone can find it useful.

[george moromisato]

Sorry about that. I tried to limit the rate of requests being made after the server went down at ~7:30 CDT. I didn't mean to intentionally tax the server with a malicious intent.

No problem. I never thought it was malicious. And I'm glad I had a chance to harden the server.

Additionally, I have created an (incomplete) Python package for interacting with the Anacreon API. Perhaps someone can find it useful.

This is pretty awesome! I definitely support this.