Changelog 2016-10-13

  • Mineral regeneration mechanics are changed. Mineral regeneration amount is no longer random, but rather depends on a new property called Mineral.density:
    • DENSITY_LOW: 15K amount (10% probability)
    • DENSITY_MODERATE: 35K amount (40% probability)
    • DENSITY_HIGH: 70K amount (40% probability)
    • DENSITY_ULTRA: 100K amount (10% probability).

    It gives the same average value as before this change, but now it is predictable and creates some variety between rooms.
  • In most cases, density is not changed between regenerations. However, there is a 5% chance that it will be changed to a random new density on the next regeneration cycle. For DENSITY_LOW and DENSITY_ULTRA deposits this chance is always 100%.
  • Mineral deposits density is visually observable on the world map using the corresponding display option.
  • Flags count is now limited to 10,000 per player. 
  • When created via the API, flag names are limited to 60 characters (creating via UI is already limited, there was the lack of filtration in the API). Old flags names will be truncated to 60 characters.
  • When remainingAmount property of a market order becomes equal to 0, the order now does not get deleted, but becomes inactive instead. You can call extendOrder and reactivate it keeping the same persistent ID. You must call cancelOrder explicitly in order to remove this order from your list.

Changelog 2016-09-30

  • Game.market.getAllOrders method now supports internal indexing by resourceType. When you provide an object literal filter description, it will work significantly faster:
    Game.market.getAllOrders({resourceType: RESOURCE_UTRIUM}); // fast
    Game.market.getAllOrders({resourceType: RESOURCE_UTRIUM, 
                              type: ORDER_SELL}); // fast
    Game.market.getAllOrders(); // slow
    Game.market.getAllOrders(i => i.resourceType == RESOURCE_UTRIUM); //slow
  • Increased player code length limit from 1 MB to 2 MB.

Steam Market integration

We have enabled Subscription Tokens integration with the Steam Community Market. Now you can not only buy tokens using Steam Wallet, but also sell them there. If you own Screeps in your Steam account, having tokens in your profile will allow you to exchange and trade them on Steam in the same way as with any other items on it.

Changelog 2016-09-26

  • Increased nukers and observers range to 10 rooms.
  • Increased nuke energy cost to 300K.
  • Changed nuke landing damage to structures:
    • 10M damage to the landing position;
    • 5M damage to all structures in 5x5 area.
  • Added new nuke landing effect:
    • If the room is in safe mode, it is cancelled immediately, and the safe mode cooldown is reset to 0.
    • The room controller is hit by triggering upgradeBlocked period, which means it is unavailable to activate safe mode again within the next 200 ticks.
  • When safe mode is active, all hostile creeps become visually transparent and passable - your creeps can move through them freely (but not vice versa).
  • Source Keeper lairs now start a new keeper spawning period immediately as the old one is injured, rather than when it is dead. If the old keeper is still alive in 300 ticks, it disappears and gets removed by the new one.
  • Reduced energy sources capacity in source keepers rooms from 4500 to 4000.
  • Introduced new StructureExtractor.cooldown property. It is triggered on each harvest action, your harvesters have to wait for 5 ticks until the next harvest call is possible (it will return ERR_TIRED result code).
  • Reduced mineral deposit regeneration amounts from 70-140K to 35-70K. Now all minerals (including hydrogen and oxygen) have the same amounts.
  • Reduced labs reaction speed from 10 units per 10 ticks to 5 units per 10 ticks.
  • New NPC market order prices:

 Resource

Sell order priceBuy order price
3.00 Cr 1.00 Cr
6.00 Cr 1.00 Cr
18.00 Cr 1.00 Cr
Energy 1.00 Cr

Screeps World Review, September 2016

Money, money, money
Must be funny
In the Screeps MMO world.

So, our market is opening its floodgates, and all the miners, chemists, speculators, and shopaholics of all sorts have finally found each other to embrace the craze of spontaneous and unconstrained shopping spree! Want those “60 days of CPU subscription”? Sure, grab them for just 3M! Still have no time to harvest some power? But hey, look at that shining one on the shelf for just 20! And, oh boy, there’s a ton of goodness for 20… 

As we all know, money is power, and some players have started saving credits for the future, while others rushed to buy valuable lots. Currently we’re seeing 100–900 deals between players in an hour with the total cash turnover at 100K–600K credits an hour (less the buying of resources on NPC orders). 

Read More

Changelog 2016-09-16

Introduced new room safe mode mechanics. It will replace room novice walls protection, and allow to arbitrarily safeguard your rooms while you are offline.

Safe mode is enabled on the room controller when a new player spawns in the world initially. It also can be triggered by any player manually using either the StructureController.activateSafeMode() method, or the button in the controller UI. When activated, it blocks attackrangedAttack, rangedMassAttackdismantle, heal, rangedHeal, attackController and withdraw methods of all hostile creeps in the room.

Only one room can be in safe mode at the same time. Safe mode period lasts for 20,000 ticks. It cannot be activated again during the 50,000 ticks cooldown period. But in Novice Areas, there is no cooldown at all.

In order to activate safe mode you spend available activations (StructureController.safeModeAvailable property). You obtain one activation on each controller level upgrade, and also can generate it by Creep.generateSafeMode() method using 1000 ghodium resource.

If the controller is downgraded, it loses all its available safe mode activations, and triggers the cooldown period.

Changelog

Changelog 2016-09-05

The Market system has been deployed.

Standalone server development update

September has begun, and we start getting natural questions like: “When will the open-source server go live that was promised in August?” So in this post we’d like to explain the situation that’s going on now.

Currently we have actually three parallel development pipelines for Screeps:

  • Features of the game itself and its gameplay
  • Optimizing the official server
  • Development of the standalone hosted server

When our second Indiegogo campaign was launched, the plan was roughly this: make a market system as a major feature, and then delve completely into the development of the standalone server and a Steam client for it. That’s why we set August as an approximate milestone date. However, after the campaign’s end and some consideration we realized that the Steam launch proper and the standalone server release are two vastly different things that should be better done one at a time rather than simultaneously. A higher traffic from Steam may require some adjustments in the scalability of the game servers, so we’d be having hard time watching this process and at the same time taking care of the open-source project that would appear along with it. We decided to first launch the Steam client to attract users to the main official world, debug it, and then move to the standalone server without any hassles.

Our experience has shown it was a right decision. When Steam gave us hundreds and hundreds of new players, it revealed a number of issues in our server architecture that prevented capacity scaling for running your scripts, and we put a lot of time and efforts to debug and optimize those bottlenecks. You might remember how the tick duration soared from 2.5 to 5 seconds, then fell back, then grew again, and then stabilized at 2.7-3 seconds. We are content with the current rate, but achieving it required a lot of work within the past two months.

Due to this reason, unfortunately, the standalone server won’t be launched within the coming weeks. We are sorry to realize that we missed some deadline, but please be assured this was not due to our laziness, but we decided to rearrange the work, and the history proved it was a right decision.

And there is another reason for delaying too. After the Indiegogo campaign was over, we spent some time on designing the concept of a standalone server, and we realized we couldn’t just take the current server code, open-source it, and rest on our laurels. For the project to gain traction as standalone as we see it, the following design concepts need to be implemented:

  • Zero dependencies. The official world works on a traditional server stack of many applications: nginx + nodejs + mongodb + redis. And it won’t work for the standalone server. The user should be able to just download an executable file via Steam, launch it, and get a working server at his IP address without any extra programs to install. We use Electron packaging to achieve this, but it also requires a separate database layer based on the in-memory database inside the application itself.
  • NPM-based application. Though many users will opt for the easy downloading and running the server as a simple desktop application, we have to support a more advanced installation as an NPM module as well. Being a JavaScript application, the Screeps server organically fits into the npm packets ecosystem, but the current game server architecture (which was initially developed as a set of layers with loose coupling) should be divided into multiple modules to publish them in the npm separately. This will allow, for example, replacing the database layer module with your own one to use the desired server-side stack.
  • Fully moddable architecture. To change the majority of server behavior aspects should require simple redefining of needed fragments through a system of external hooks and extensions rather than modifying the server code. We also need a possibility to add custom game entities even with their own visuals.
  • Single-player bot players. The single-player mode (which makes some people long for the standalone server) will be pretty boring unless there is somebody else but the player in the game world. But the development of a full-fledged AI that can start from scratch in the game world and seriously challenge the human player is a very interesting and complicated task. We want the players themselves to find the solution to it, since that’s exactly the main fun of Screeps. Any player could write a script for his or her standalone AI and submit it into the common repository where other players of the single-player mode can install it. When provided with its own room in the worls, such a standalone AI has to be able to analyze the situation, develop its colony, and bring some life to the game world where it exists. The repository will introduce a ranking system for AI performance, user comments to them, new version updates, etc.
  • Steam Workshop support. The two aforementioned options are perfect in terms of excellent mechanics of Steam Workshop. The system of downloading and installing any custom files provided by the Workshop can be utilized to automatically install and update custom mods, game object types, bot players, and entire complete worlds. This is a huge task, but it’s vital for the Screeps ecosystem.

Implementing some of these things requires the overhauling of the current server code of Screeps since they were not accounted for 2 years ago when the game was first designed. But we are convinced that short of these, the standalone server won’t be the type of product we really want to share with you.

In terms of deadlines, we don't want to be overly optimistic at this point making promises we won’t be able to meet. Let’s keep October in mind. If we get a working version earlier, we’ll definitely show it. As was promised, our Indiegogo campaign backers will be the first to get their hands on it, while the public availability will begin a month later.