3. Optimizations roadmap

Optimizations roadmap

  • Culture

    I think the portals will have to work a bit differently. The room bouncing problem is already bad enough when your script is running on one server, but having to send a creep and have another script grab it at the right tick sounds like an amazingly frustrating experience. Having "entrance" and "exit" portals for each side, so a creep can get on a square in one world and end up on a non-portal square in another, with no concern about bouncing between the two.

    I also think Memory should be completely independent so one server doesn't overwrite the other. Being able to request segments from different shards would give a useful communication channel.

  • Culture

    > But the lower tick rate on the new shard is one of the only things I can think of why you would want to spawn on a new shard.

    If the worlds are connected in a stable way then I would happily put an outpost on the other server, and build up on both sides. Having bases that players can't get to without either respawning or investing in extra-dimensional portal traversal seems like a huge strategic advantage.

  • Culture

    > They will be fully isolated. But you can start doing some import/export shenanigans between them, might be quite interesting way to raise some credits 😉

    Credits too? Will subscription tokens be the same across shards?

  • Dev Team

    I think the portals will have to work a bit differently. The room bouncing problem is already bad enough when your script is running on one server, but having to send a creep and have another script grab it at the right tick sounds like an amazingly frustrating experience. Having “entrance” and “exit” portals for each side, so a creep can get on a square in one world and end up on a non-portal square in another, with no concern about bouncing between the two.

    Activating a portal would most likely require some explicit action like Creep.moveToShard(portal, shardName) since the same portals may be used for more than two shards in the future.

    I also think Memory should be completely independent so one server doesn’t overwrite the other. Being able to request segments from different shards would give a useful communication channel.

    Memory and segments will be independent to prevent race conditions, and due to loosely coupled architecture (runtime workers will be connected only to their shard’s database, not to others’). We still need to figure out some way to pass messages between shards in an asynchronous manner though.

    Credits too? Will subscription tokens be the same across shards?

    Can’t tell anything for sure now. We need to prevent race conditions on operations with credits and other account-wise resources like tokens. It can be achieved by either introducing locks and mutexes on such operations (reducing the performance), or separating their balances on each shard with an ability to transfer between them.

  • Culture

    > Can’t tell anything for sure now. We need to prevent race conditions on operations with credits and other account-wise resources like tokens. It can be achieved by either introducing locks and mutexes on such operations (reducing the performance), or separating their balances on each shard with an ability to transfer between them.

    Either way if you do this (split balances) it would be really useful if you also added in the market functions to transfer credits between players. If two players are in completely different shards they can't use the "expensive energy order" trick to transfer credits so there will need to be some mechanism there. It would also be nice if there was a client side or api level way of transferring credits, since even with the above mentioned transfer function it still requires an active room for console commands and with the multiple shard system that may end up being complicated.

  • YP

    while credit transfer would be a nice thing, I think even better would be private market entries... so you would add a receipient to the market order and no other player could see or accept the order.

    to better arrange those transfers/deals some kind of in in-script messaging would be great of course 🙂


  • you can "in game message" now with public memory segments.

  • YP

    > you can "in game message" now with public memory segments.

    really? how do you send someone a message with a public segment? do you put your message in there and hope that they read your segment in the near future?

    do you scan every players public memory segments for messages ?


  • Well, I'd suppose you'd have to write one, but two people that know (or a large group that knows) to look at a certain segment could use that as a place to store "messages" that other people that know where to look, could read and process.

    One thing is for sure, I don't need yet another source for spam. So no Game.notify("coteyr", "my message here") or anything like that.

  • YP

    How would you spam someone? The messages would get delivered to an array that has to get read - or ignored - by your script.. you would not even notice the messages if you don‘t look for it. I don‘t think many people will be interested in wasting cpu by sending messages to people who would not even notice that they got a message.

    I still don‘t get how you would do the group messaging using public segments. How do you store your messages in someone else public segment? It‘s easy to publish data but it‘s impossible to tell someone to fetch your data without using a terminal hack or something like that. Checking every other players public segment one by one every tick will take a while if you want to communicate with a group of people like your alliance and neighbors.

  • Culture

    (Answering with own ideas, not as a Screeps official)

    Activating a portal would most likely require some explicit action like Creep.moveToShard(portal, shardName) since the same portals may be used for more than two shards in the future.

    That’s a nice solution. The bouncing between shards could cause big issues due to different tick times.
    Will the creep memory be passed along? I’d love to at least give it some purpose once it’s on the other side.

    We still need to figure out some way to pass messages between shards in an asynchronous manner though.

    You could probably make a memory segment public per shard, which you can load in other segments. It could be loosely coupled

    RawMemory.publishActiveShardSegment(id)
    publishes data exactly once in a synchronous matter. This way there is no need to keep it up to date every tick.
    RawMemory.setActiveShardSegment("shardname")
    set active shard data on the shard it’s run on
    RawMemory.shardSegment["shardname"]
    get data from the raw memory

    That could fit nicely in the architecture without too much work. I’d grade cross-shard operations as an “advanced game mechanic” anyway, so doing it with segments seems like a good idea.

    @W4rl0ck

    I still don‘t get how you would do the group messaging using public segments
    You could do the following in your code:

    RawMemory.segments[0] = "hi bob";
RawMemory.setPublicSegments([0]);

    Another player could do:

    RawMemory.setActiveForeignSegment("dissi", 0);
// Next tick:
var messageFromOtherPlayer = RawMemory.foreignSegmentobject.data;

    This should at least get the messaging going

  • YP

    @dissi: it was not a technical question about code.. I know how to get public segments of other players.

    The problem is the other player would not know when I put some data into my public segment... so the plan is to put something into a public segment and then tell somebody in slack to fetch it?

  • Culture

    W4rl0ck- you have to work out the protocol you build on top of the segments with the players who are also using them. There are a number of different options for this- The Culture is using terminals to transfer private keys as well as segment id's to watch, for instance- but at the moment there is no "universal" messaging system (although one could easily be built by the community).

  • YP

    Yeah. But the devs said in an other thread that they don‘t like using terminals for communication...

  • Culture

    That was just one example, it was not intended to be the only one. You could easily share private keys in slack, or not use private keys at all. You can agree on communication segment ids and code them in yourself. The point is that the protocol itself is something that the group of people communicating need to come up with themselves.

    This is a bit of a tangent though. If you are interested in creating a standard protocol for this you can join #diplomacy in slack where we're discussing these things.

  • Dev Team

    Will the creep memory be passed along? I’d love to at least give it some purpose once it’s on the other side.

    No it won’t, since the player may have custom Memory structure. But the creep’s name will be transferred, and you will be able to pass custom text messages to other shard as well (somehow).

    You could probably make a memory segment public per shard, which you can load in other segments. It could be loosely coupled

    This would require to connect runtime workers to all shards’ memory storages which creates to much coupling between all backend components. The idea is that inter-shard connectivity is being done only by one single isolated component running in background, passing creeps and text messages along between shards.


  • I think that the concerns here regarding the competitive advantage of young vs old shards are well expressed. I think that it should be possible to address these concerns by scaling the core progression statistics based on each shard's time dilation.

    Base resources scaling could be something like y = 2 - 2/x so that at a 2s tick there is no benefit but the bonus is not linear (encouraging DoS).

    For example, if with 3 shards exist: A (the origin, 5s tick), B (first new shard, 3s tick), and C (brand new shard, 2s tick) then the benefit to several resources should exist:

    * GCL gained on an account might be scaled up per y = 2 - 2/x. Shard A would contribute 60% additional GC per RC, B would contribute 33% additional GC per RC.

    * Power processed could have limited scaling perhaps on the function y = 1.5 - 1/x. Shard A would contribute 25% additional Power per Power processed. B would contribute a 16.7% bonus.

    * The 5% market surcharge may be reduced to y = 0.05 * (0.5/x +0.75). Shard A would charge 4.38% on market orders. Shard B would charge 4.58%.

    CPU expenditure would not be affected.

     

    There's probably some edge cases I haven't considered, but scaling of this kind would slightly blunt the advantage players get from aggressively populating new shards, and provide some incentive to spanning new and old shards. 


  • Dear Screeps devs,

    I'm very happy to see the team's dedication to handling the performance issues in the game. This is certainly a core issue for the game to continue thriving and should take precedence over the development of new features.

    On the subject of performance, I believe the first and most important aspect is CPU stability. From the various individuals I've spoken with, tick times are usually a secondary concern compared to tick variability. The VM proposition for this topic sounds fantastic. Looking very much forward to that.

    Regarding the proposal of world sharding. I am honestly quite worried.

    1. It fundamentally changes the game without specifically improving gameplay. It adds another layer of complexity which players have to take into account.
    3. It adds a significant layer of game engine complexity which will likely require major dev investment and maintenance.
    4. Its effects on the community are hard to quantify. It's incredibly risky to play around with such a small, fragile community. 
    5. It's hard to accept that all technical options have been explored with regards to optimizing performance.

    To me (not a specialist in the industry/field), it feels like it should be possible to parallelize and scale the processing of the game world. Is the DB the only bottleneck?

    Afaik the concept of DB scalability is quite a studied field of computer science. What is fundamentally different about the Screeps world compared to other large-scale services/applications?

    Afaik Screeps uses Mongodb. Why is sharding not a valid option?

    Perhaps if additional information would be provided to the community about this problem, we might be able to assist. There's quite a number of individuals in the community with experience in the programming field :).

    Kind regards,
    Atavus

  • AYCE

    Aterm,

    Have you guys considered talking to CCP? They have a large single sharded game, and while they are using a different database platform they may have some helpful advice on how to scale a large single instance database.

  • YP

    eve online is completely different. While everything is one cluster, every star system is a seperated server that runs for itself. It doesn’t matter if jita lags, your star system is fine. The same in wow. It doesn’t matter if ironforge lags, stormwind will be fine. In screeps the next tick can’t begin before the last one is finished with everyone and everything.

    In screeps there is stuff that can’t run in parallel. The market system for example... if you sell something in eve online, it is directly taken out of your possession. So all transactions can run in a seperated database. In screeps all teurminal transfers and market transactions have to run after all rooms are processed... and they can’t really be run in parallel. It has to check if the resource is still available in the sellers terminal and if the destination terminal still has space free. That’s why they introduced the terminal cool down and why they don’t like using terminals for messaging.Â