Almost a year ago we began planning a redesigned version of R&D. The tech-tree plan was scrapped some time before then, as well. I wanted to share the core concepts with you now, because R&D will soon be an active project, focusing first on items/ground weapons, as ground combat between players, NPCs, and facilities has concrete rules. The goal of R&D is to provide a self-balancing, open-ended system for creating stuff in game. Part of this comes from the system for R&D itself and part comes from other changes, like the firepower mechanic introduced earlier this year, which self-balances against armor to avoid the problem of infinite damage scaling. Depending on the success of the model it will extend in a natural way to ships, vehicles, and other things.

Creating new entities will be broken into two distinct activities (research and design) based on a simplified view of real world technology development. In the design activity, a new entity design is created from modules. Each module covers one aspect or system of the entity being designed. In a hypothetical ship design example, the hull, shields, power generators, etc. would all be distinct modules. Each module has free (design) variables chosen arbitrarily by the player and process parameters determined by the technology available to the designer. The process parameters generally serve to create constraints on the acceptable values to use for design variables by translating them into costs or requirements, such as RMs, available power, required power, and others, but there are no hard caps on design variables. A meta-process for “ship” design or “item” design will also control the number and types of modules that can be installed together within a single design. The research activity would exist separately from design and work to improve the values for process parameters in a particular technology. Technology management will be extensive, with the ability to trade and share technology as well as derive new processes from existing ones. Research time will scale with the total number of improvements that a technology has over the baseline, so a derived technology may not be “cutting edge” in order to facilitate easier research in a previously neglected direction.

Once a player is satisfied with a design, it would be converted into a datacard and an entity definition with stats as we have now. There will probably be no limit to the number that can be created, although there may be a small cost associated with finalizing a datacard design. There may be minor changes to stats (nothing is planned), but the stats, not the modules, will determine how the entity behaves once it has been produced, just as they do now. However, the underlying module structure (including any margin in the design, such as extra power or space) is preserved, which forms the basis for aftermarket modifications to be performed individually per entity. The concept for entity modification hasn’t been fleshed out much beyond whether it is possible, but the “process -> module -> entity” structure is able to support it natively and keep it balanced.

In R&D the design phase will probably not involve any skill checks and be determined entirely by players’ creativity. The research phase will probably function more similarly to force training wherein there is a timer and a dice roll that determines success, with some attention paid to skill point assignment, although the objective will be selectable (e.g. look for a better hull parameter or better shield generator parameter).

Feel free to discuss the upcoming R&D design, but we’re still not taking suggestions on the details at this time. Also, the infamous tech level statistic will be returning as a descriptive quantity.

Other changes will probably be made to “how things work,” eventually, as well. There’s been a thread discussing the Rock Ivory rarity; this will probably be adjusted as a temporary solution within a few weeks, because it is easier than adjusting RM requirements intelligently. When RM requirements actually follow from entity design, coherently, it will change again (possibly for all materials). Another thing that we’re exploring is a worthwhile entity upkeep system, one that does not penalize players for being inactive or having a lot of stuff, but rather focuses on upkeep associated with frequent use of entities without being tedious or requiring extensive micromanagement. Even with combat adding destruction, the general flow of goods is that they are created and then remain (especially for non-combat entities); a complete lifecycle needs to be in place that has “being discarded/refurbished/recycled” as an important step, to create equilibria for demand.

There will be an unrelated sync within a few days as we push some bug fixes and updates from the past few months, including redesigned rules pages and upgrades to the scripting system capabilities. We are also improving compliance with EU cookie laws, so you will see some additional banners related to cookie usage after the sync to inform you that they exist and are unfortunately inedible.