The important bits can be divided into three main (heh) phases: To get a more detailed idea of why this was a problem, let’s look at Overmind’s main loop structure (which I talk about in more detail in a previous post). Classes are expensive to instantiate, and having many classes with shared references to each other and to game objects makes garbage collection in the V8 engine more expensive than for a flatter, prototype-based architecture. A major reason for this is its very hierarchical, object-oriented architecture, which heavily employs classes. Prior to some recent changes, Overmind had never been a terribly CPU-efficient bot. This allows players to manually place their own directives which only their creeps will respond to (for fighting their own personal skirmishes), as well as for the Overmind to automatically place directives which all assimilants will see. Only flags matching the correct naming pattern will be uploaded to the master ledger of directives shared among the hivemind. The assimilator looks at the master ledger of clearance codes to determine which players are trusted. In the future, clearance keys will be used to generate flag names based on the tick they were created. If I receive a checksum which matches that of a recent valid version, I reply on the following tick with a unique clearance key valid for the next 1000 ticks transmitted through public memory: If a player is assimilated, then every 1000 ticks, Overmind will send 100 energy to one of my terminals, with a hash of the current codebase as the description.
#Screeps free download code#
Whenever I deploy code to the main server, a checksum for my version of the code is generated and stored in my memory along with all unique hashes from the last 1 million ticks. The Assimilator uses this behavior to generate a checksum of the portions of the script using a sha256 cryptographic hash. To do this, it exploits a wonderful (horrible?) behavior of Javascript, which is that if Foo is a class, then ''+Foo evaluates to a string containing the source code for Foo (!) : This decorator registers that part of the code with the Assimilator, which ensures that it has not been tampered with. If you’ve looked around my codebase recently, you’ve probably noticed some parts of the script which are marked with an decorator.
#Screeps free download verification#
There are a variety of ways it does this, some of which I won’t mention, but I’ll talk about the main verification method here. The Assimilator is a global, persistent object which provides a way of deciding which Overmind players can be mutually trusted. Since I didn’t want to completely obfuscate the entire codebase, I needed a way to verify the integrity of certain parts of the codebase. Since the codebase is open source, one could modify it to receive resources or combat assistance but never to give them when needed. When completed, (my) Overmind will truly be the overriding will of the Zerg swarm.īefore you get too excited, assimilation is still under construction and far from complete, but I decided to use a portion of this post to talk about an important aspect of it which has already been finished: verifying the codebase.īecause of how tightly integrated assimilated players will be, it is possible to modify the codebase to take advantage of the system. It allows all players running Overmind to act as a single, collective entity, sharing creeps and resources between each other and responding jointly to a master ledger of all directives shared by all players. Having so many players running my script near me is a cool experience, and it gave me a thematically-fitting direction for Overmind’s final evolution: to become a true universal hivemind by assimilating other players.Īssimilation is a feature I’ve been teasing for a long time now. It is now the dominant open-source bot running on the public servers, especially on shard2: Over the last year, Overmind has gotten quite popular.
0 kommentar(er)
