Optimizations roadmap
-
I personally am not concerned about the differing tick rates, as as artem and others have pointed out, they will start converging at some point on their own. At this point I think sharding is a good solution, maybe in the future a way to recombine them may be developed.
Is sharding itself going to be available on private servers? I can completely see people creating a cluster of small low-cost servers and running a larger PS on them.
Any idea what the max world size of the shards are going to be? I personally would like to see them smaller than the existing world, maybe 50x50 or 100x100 at most.
-
I'm not worried about the different tick rates either; I feel every problem that has been identified can plausibly be solved satisfactorily without kneecapping the tick rates of new shards.
Even the comparative increase in spawn rates could solved by rate limiting the portals somehow.
-
I don't find myself agreeing often with Tedivm, but I do now.
I believe the synchronized tick times would be necessary in order to maintain game balanced and the one world feel.
I've also had my worries alleviated to an extent. The idea of shards does feel quite interesting now and provides some very intriguing possibilities. If you couple the shards with a nice 3rd structure representation of some sort on how shards are connected, that would make it even cooler.
The sharding does provide a nice encapsulation of game state allowing for a solid scalability plan.
It's perhaps important to realize that having the tick times as low as possible shouldn't really be the target of the game. Instead, the game world should aim for a specific tick rate. A tick rate that we all feel makes the most "sense" considering game balance and the relationship between the game and real life. For super low tick rates there's always simulator or private servers.
My suggestion, of course, would be 3.6s per tick. That allows a very easy conceptualization of the game world in terms of real time: 1k ticks are 1hour. Alternatively, 2.4s would be another decent number to aim for since that would make 1 creep last 1 hour.
In fact, I would suggest that even if we eventually have the ability to lower tick rates below those numbers, that the tick times be artificially held to those values. The extra hardware capacity would come in handy to ensure tick time consistency.
One last important point. I would strongly advise that coupled with sharing you shatter the main world. The current world is too big to be a single shard considering the current performance issues. Make it a fancy event of some sort. Draw some lines which will become the shards. This gives players/alliances incentive to preemptively position themselves so they end up in a single (or multiple) shards.
Or go crazy and just reset the world, but I do feel if you do shards, the current main world needs to be adjusted somehow or it will never be "playable".
-
A shattering event could be really fun. Would anyone really be upset to have their empire distributed among multiple shards?
Some world position logic might be disrupted, but otherwise there's no reason to change room names.
-
I personally don't have any opposition to a "shattering" (which, as a bonus, already has a really cool name) but I also am entirely in a single quadrant.
If there was a special testing setup for people to have time testing across multiple shards and coordinate the "shattering" event then I think active players who are in multiple quadrants would actually have an advantage over the fact that they would already be spread out. That being said I can also many reasons why people would not be a fan of this, so I would definitely recommend getting more community feedback before really considering it.
-
Another option, rather than a shattering, do a gradual depreciation of the world, disable respawning into it and /or encourage users to spawn in the newer shard(s) instead, then in the future it may be empty enough you could shrink the current world or disable it entirely
On the other hand, if a shattering occurred, (say, on the double highways to make 4 shards), it would be interesting having the one room on one shard while all the other rooms are on a different one, would be a nice opporunity to work on multi-shard code and cross-shard travelling.
-
A 'shattering' event would be awesome.
But if it isn't 'opt in' somehow (even if it is just everyone in a sector/sector group agreeing to shatter that section) I can see players getting frustrated. This is since it has the potential to completely destroy any hard-coded configuration (but if you have an empire of a decent size you probably have relatively little of it (or at the very least it is easily managed etc.))
Now that isn't to say that the players in the sector(s) who want to shatter can't just boot out the nonconformists via force (or vice versa).
Plus I want to get out the popcorn and watch entire areas of the map go dark.
-
A shattering event sounds cool, but I think just creating a new shard and "blacklisting" some sectors so people can't move into them would probably work.
-
I'm no game designer, so these ideas may be terrible, or interesting.
One thing I think Screeps is missing is some variety on the map. There is little in the way of strategic areas. As long as you have space, you are happy. There isn't much of, oh hey look so and so's space is better than mine, I should take that. Or, I need that space for some strategic reason.
Someone had mentioned a while back about Z index on the shards. What if the shards were vertical from each other, and the portals between them went vertically? Meaning my room at W1N1 would in some way be able to portal to shard above and below me at the same room. This would add some strategic reasoning to position between shards, and connect them in a physical meaningful way.
Additionally I'd love to see special areas of some kind appear on the map such that we could fight over them.
-
@Timendainum you mean have them be less of a portal and more of a ladder?
-
> What if the shards were vertical from each other, and the portals between them went vertically?
This is a truly great idea! It would make shards (probably called "levels" then) feel more like an intrinsic concept of the game world and less like a workaround for database performance bottleneck. (I still would prefer solving that problem by switching databases, however.)
-
I agree with @tynstar
-
The concept of "vertical" persistent portals is a core idea of this world sharding system. I've probably not expressed it clear enough in the blog post, but this is really what we've meant originally. Sharded worlds will have different sizes, so one-to-one position match can't be done, but their portals will link them in the same vertical positions like elevators.
-
Being forced to defend from attack across multiple shards is more apparent when it's described as a ladder / elevator / floor / Z axis
-
Shard portals will be placed only in neutral highway rooms. And you cannot build portals yourself. There is nothing special in defending from such attacks, it is like any other attack from the highways.
-
It’s still an open question whether the number of established players willing to respawn on the new shard is enough to reduce the load of the old one. In order to significantly improve performance they need to not only create colonies, but to respawn completely. Your reasons are fine, but they may not convince many established players to do so.
I would happily move to a new shard. When you got a lot of GCL it’s a lot of fun to play around in a new area and expand rapidly! I think this might also be a motivation for other players as well. Instead of fighting over territory you just move to a new shard.
-
So excited that WebGL is coming. I stopped myself opening the game many times because of the horrible battery performance.
-
We're now testing Apache Cassandra on the PTR, see this post:
http://screeps.com/forum/topic/75/PTR-Changelog-2017-06-23
-
Jo I know I may gain some hatred for that but screw node.js.
Switch to Open Resty (nginx + lua application server) and rebuild the server in Lua.
Lua is very similar but way faster and offers native sandboxing*.
If you then add multitasking(requires external lib) in organised coroutines it should give you a enormous performance boost.
Once that is done spreading it to multiple server clusters should be easy.
If you want to evaluate Lua read "Programming in Lua, fourth edition" or the first edition online <- aimed at Lua 5.0 and is still largely relevant.
*There is a bit of work to do, to do it proper.
-
> Switch to Open Resty
You do realize that everyone in the screeps world will have to rewrite their entire script library? And it still won't solve the performance issues as they're database & disk I/O related.
