Over the course of the last few months, as I was reading forums and talking to people on IRC, I couldn't help but notice the staggering amount of suggestions and fairly simple requests that we've been offered. While this would be by default a fantastic thing, it triggers a returning problem that most players are blissfully unaware of: the complexity of our architecture, and our dedication to keep the architecture as robust as possible. What this essentially means is that sometimes the most trivial minuscule feature has to go through a rather arduous chain of procedures to be finally implemented on the client side. My attempt in this post today is to present you with a case study of how this happens in case of something most people would consider a single line of code and 20 seconds of work. But first, let's talk about concepts.

The principle of our system

The idea of the Perpetuum infrastructure has been engineered to be robust from pretty much Day 1, although admittedly we kept expanding on several things over time. The concept was the following: Since we're a very very small group of developers, we cannot afford turnaround time and taking time away from each other when it comes to fixing things, so the optimal solution is to allow anyone to fix anything they can. Of course, this doesn't mean that people with no interest in coding can happily add mov ax, 1 into random places into our source tree, but it's important to realize that in a project like Perpetuum (which is a rather strongly data-driven game), we have several times more the data than we have actual code. This means that as long as the artists and content folks can change the data, programmers can work independently of them, so essentially what it boils down to is exposing as much data as we can. (If you started giggling, do a few push-ups. It helps.)

The way we do it is manifold: For artists, who mostly work with standard format data (bitmaps, meshes, sound files), we have a file server where they can upload new versions of resources, and they get downloaded the next time someone starts the game. Of course this can result in some problems when we change some internal file formats, but as long as the client is able to do an update, this shouldn't be an issue. (We also have revision control, so reverting to an earlier version is easy.) On the other side, we have the content guys who work on managing the actual game logic data (i.e. item data, balancing, that sort of stuff) - this isn't as trivial because this data needs to run through both the server and the client: the server needs this data for calculating the game logic, the client needs this for displaying data and doing client-side prediction. This also needs to be both persistent and easily alterable, so for this, we need a strictly database-driven environment.

So here's how it works.

A simple example

The most trivial example I already noted when we were working on it was related to sparks: The spark GUI was pretty much finished codewise, when Zoom noted that the order of the sparks doesn't make much sense because the syndicate ones are on the bottom while the ones that are harder to access are on the top. The reason for that, obviously, was that Alf simply added them in the order he felt like at the time, assuming that we can just sort it on the GUI-level later. He was obviously right about that, except we didn't really think of a method.

The idea looks simple on the surface, but there are several solutions to fix it and all of them are either laborious or asinine:

  • We could leave them unsorted. That doesn't fly because it's annoying.
  • We could sort them on a GUI level, by hardcoding weight values. This is just a big no-no considering that any change would need to go through the client coder. (=me)
  • We could create a resource file in the resource repo that describes an order, and thus any non-programmer could edit it. Sounds good on paper, but sparks can be added or removed at any time, which means that if the resources are out of sync, the whole thing becomes a mess, and you're still working with two things at the same time. So no, this is just shooting ourselves in the foot. (Update - I might have forgotten to mention the most important part: non-programmers and markup languages rarely mix well.)
  • We could sort them on the server, by hardcoding etc etc see above yeah no.
  • We could extend the database records for sparks with a sort order value. Shiny clean solution, but with the most work to be done. Why? See below.


So here's the entire process of how a single integer value traverses through our infrastructure. As you may see these aren't particularly complicated steps by themselves, but the amount of steps and their versatility eventually amounts up into a surprising amount of time.

First, we take the database table for sparks, and add a field. This is done on the database server, usually by Crm.

SQL design phase

Second, we extend the administrative web-based back-end (what we lovingly christened "the MCP") with the field so that we can have data to work with. This can get tricky if the field isn't just a standard number (but e.g. a new item type or an extension ID), but in this case this is just a simple text field. This is done by me.

That isn't going to do you any good, Flynn.

Let's remind ourselves of something at this point: Because of our rather rigorous security-principles, no game-related data will be kept on client side, everything comes through the server. Now because sparks are very much a core gameplay element, everything related to them will also come through the server as well. So our next step is to add server code that loads the new value from the database, and hands it to the client. This is done by Crm again, and usually involves a server restart, much to the chagrin of whoever is working on the development server at the time.

Server phase

So now our value is en route to the client, all is left for me is to add fields to the client cache and use it to actually sort the sparks in the correct order, i.e. the aforementioned "single line of code". Of course, the actual sorting algorithm code is already there, I just have to build a new comparison function, test it, deploy it as the newest client update, and ultimately the feature is done easily.

Client phase

Simple enough, but if you look back, the ricochet performed by that one measly integer value is pretty staggering.

What you have to understand here is that this is the best solution, as strenuous as it seems:

  • It's robust (no hardcoding involved, extending doesn't involve breaking anything previous)
  • It's completely "user"-driven, anyone can use the web-interface to change the values without having to worry about breaking something in the code level (mostly); database-constraints and form-validation can take care of values we don't want in there.
  • Most of the code-changes needed are just passing around values without thinking of what it really is.
  • Once the code works, it'll always work as long as the data itself is solid.

But of course, as mentioned, the downside is that it needs four different levels of changes (database, back-end, server code, client code), which is only done by two people because of the involuntary competence we acquired over the years - in a "larger" project, this could possibly take a lot of cross-department management, while here it's usually just strong language and the occasional "Eh, I'll just do it myself". However, once we're done, we can wash our hands and never think of this pipeline again, because the content will go in on one end and the code will take care of it in the other. (On a tangential note, this applies to blogposts too: This post will probably be / was proofread and reviewed by several of us.)

Exercise for the reader

Now, to make sure that you understand the gravity of this stuff, here's a little thought-experiment for you: When you right-click an item and select "Information", there's a lot of parametric data that ends up on the screen, each with their specific measurement unit and number format. Now remind yourself that some of these values may look completely different internally: percentage values that show as 5% are obviously stored as 0.05, bonuses that show up as -25% may be stored as 0.75, some values need two decimal digits while others need five, and so on.

So here's the challenge: knowing the above principle (i.e. be data-driven), what kind of system do you build to make sure that each of those values end up being displayed correctly for the player? (No prize for the correct answer, although we do offer occasional trauma counselling.)

In a later post, I will go into a deeper insight about how an actual feature (case in point the whole spark-doohickey) goes from an idea to design to concept to task to implementation, down to the level of "BUG #4170 - please move that text one pixel to the left".

For the brand new players around and those who are not quite familiar with the inner workings of character advancement in Perpetuum, attributes are what determine the extension point (EP) cost of extensions. The higher an attribute, the less are the costs of a connected extension, hence the less time is spent on achieving the next level.

The problem with attributes has always been that you have to make important choices at the very beginning of the game. However, at that point you usually don’t have the slightest idea what they will mean for the future, and you don’t even have any chance to make adjustments later on. Obviously this can be a very frustrating experience for our new players. The account reset system has been created to alleviate this frustration, but it has many drawbacks and it affects the persistence of the game in a negative way.

Farewell attributes

We’ve been internally debating the issue for a long time now and we have finally come to the conclusion that attributes are not necessary. They are pretty much an unneeded annoyance, and while they seem to make the game more complex and deeper, they do not contribute to it in an entertaining or useful way. We have realized that while we’re advocating that you can be anything within the game, we’re in fact penalizing it if you decide to do so.

So we’re removing attributes from the game. Those who fear that this will reduce the diversity of the characters should take a look at the number of extensions one can install: currently there are more than 160 different extensions in the game and their numbers will grow in the future. We’re confident that they alone are more than enough to create specialized characters, where no single one is like another. (Not to mention that currently the trend is to blindly specialize your attributes towards either of the three career types, mostly combat or industry - not much diversity if you ask me.)

The removal of attributes will mean that we’re simply omitting them from the formula that we use to calculate the EP cost of extensions, and the cost will simply depend on the level and complexity of them.

To compensate the loss of the attribute bonuses, we're reducing the base cost of extensions from the current 100 EP to 60 EP. (This is the cost of a complexity1 / level1 extension, and all extensions are built up from this base amount.) In the name of fair play, this change means that we have to recalculate the available EP of every account, since the cost of every extension will be different. A side effect of this is that everyone will end up with a varying amount of extra EP (woohoo!), and that maxing out all extensions will only require around 16 years instead of 20 (or something like that...). Just to add another interesting bit here, getting all current extensions to level 5 only requires 393 days, so you see the level 5 barrier is really notable!

If this is all too complex for you, it’s enough to know that after this change you’ll end up with the same extensions and a bunch of extra EP, and some of the extensions will be cheaper than before.

Changes to character creation

Since our current character creation process is mostly based on selecting your starting attributes, obviously removing those will make its mark here as well.

In the future, creating your character will simply decide your starting point, your initial extensions, and your first spark (more on this below). You will no longer have to suffer the drastic consequences of your choices, since all of these can be changed or improved during the game.

Due to the removal of attributes and the recent reorganization of Syndicate corporations, we’ll take out the step of selecting your starting corporation. Instead, it will be simply determined by the school of your choice. (Existing characters will be unaffected by this.)

Extension downgrading

The attribute system isn’t the only thing that makes the life of new players hard. The plethora of available extensions can be quite daunting as well, or trick you into spending all your starting EP on Convergent Electrostatics level 10, just because it sounds cool.

Our plan is to give new players an option to downgrade their extensions, and get back the spent EP and NIC. This option will only be available for 30 days after the first character has been created on the account, and with a few limitations, like not being able to downgrade below your initial extensions, heeding prerequisites and a freeze level for extensions which is yet to be determined. (The freeze level means if you upgrade to a certain level you won’t be able to downgrade anymore.) Lastly there will be a rolling limit which will only allow you to downgrade a sum of 5 levels of any extension in the last 10 hours.

We don’t want our veteran players feel they are left out of the party, so after the patch everyone will get a 30 day grace period, during which they also will be able to downgrade considering the limitations mentioned above.

Removal of the account reset

Together with these changes we will remove the account reset feature, as it won’t be necessary anymore for the purpose we originally intended it for. We have decided to return all EP gathered in penalty pools due to the resets, so everyone will start with a clean sheet regarding accumulated EP.

As mentioned earlier, the changes will not affect anyone negatively. However, you can of course still do an account reset until that patch, for whatever reasons you might have. We wouldn’t recommend it though, as you will still lose all the faction relations and knowledge you’ve gathered.

It’s full of sparks!

For those not familiar with the lore, a spark is basically the tiny nanobot that the Agents are using to infiltrate the “minds” of the native Nian robotic lifeforms and remote-control them. When you’re upgrading your extensions, you’re upgrading your spark’s abilities.

So far sparks have not had much of a role in the game, you simply chose one during character creation, it gave you some attribute points, and you’ve been stuck with it ever since.

Now that attributes are being scraped, we see an opportunity to give them a function they deserve: sparks will provide small permanent bonuses (pretty much like extensions), and they will be interchangeable.

The initial 9 sparks that are currently selectable when creating an Agent will become the standard basic types, but later on you will be able to unlock and buy more advanced models, for example by reaching a certain relation with the Syndicate corporations.


  • Attributes will be removed from the game, character diversity will purely depend on extensions
  • Character creation will only determine your starting traits, you will not be forced to chose a specific path
  • New players will be able to downgrade extensions for 30 days
  • Sparks will give small bonuses and will be interchangeable
  • Account reset will cease to exist
  • Surprise EP for everyone \o/


If we could somehow separate the sparks from the rest of the system, we could deploy the rest of it already next week, but unfortunately it’s not possible. So while all this won’t be part of the next patch, we’re still anticipating it to be in the next after, probably within a month from now.

We’re of course quite curious what you think all of this, so you may now express your happiness or dismay here or on the forums as usual!

In case you haven’t heard of it yet, Perpetuum will take a little break tomorrow. The reason is that the datacenter where our servers are located is moving to a bigger location (still in Budapest), so we will have to physically move our servers as well. Since we are operating everything from there, this means that not only the game server, but the website and all connected services will be also unavailable for that time. To avoid confusion: this is not the server move that we plan to make some time in the future to address routing issues, this is simply a necessity.

The servers will go down tomorrow (2011-09-13) morning at 7:00 CEST and will be probably offline for the better part of the day. It’s hard to make any predictions on when we’ll return, but we’ll keep you updated via our facebook page during the downtime.

We will of course compensate the lost game time to all of you by extending account expiry times accordingly.

But something good will come of this all too: while everything is down, we’ll use the opportunity to deploy a shiny new website:

Apart from sporting our first high-detail robot models that our artists have been working on for a while now, you’ll also find some structural changes. If you ever wanted to have all the news at a glance, the main starting page will become your best friend from now on. The latest news, blog posts, patch notes and all that will be part of the new front page. We have also simplified the main menu and rearranged some links into more logical categories.

A brand new section will also see the light, an ever-expanding collection of articles about the world of Perpetuum: gripping short stories, insights on some of the more intriguing parts of the lore, or official Syndicate-memos for those who are into more serious role-playing.

The blog and the forum will also be more tightly integrated into the whole design, so we hope this will make navigating our pages much more comfortable.

So that’s all for now, tell us what you think about the new website when it goes live tomorrow evening!

The week of 25th of July is almost over and you still can’t close your outposts. Hey you devs, what’s up with that?

Well, a change of plans. After the previous devblog about being able to block other corporations from entering your own outposts, there have been discussions about it both on our forums and ingame. The initial reactions were welcoming, but quite a few concerns emerged soon.

We have conducted our own internal discussions about this matter as well, and came to the decision that we’d bring forward an Intrusion revamp planned for later, rather than build upon a broken mechanic and create more issues. So outpost closing will still happen, but in a hopefully much more sensible Intrusion system.

While the other promised feature, the “elite” NPC spawns is pretty much finished, it still needs some testing & tweaking, so this will be delayed to next week. Though there will be a patch tomorrow (07.29.), it will contain fixes for the new storyline assignments and some other minor changes.

So, let’s continue with the important part of this devblog, the Intrusion system.

What’s wrong with the current system?

The random nature of the times neither benefits defender, nor attacker - one’s ability to hold an outpost is largely luck, combined with the number of players one can bring to bear in a specific time zone. This encourages superalliances, and overconcentration of players (a.k.a. blobs) in order to ensure the safety of these locations. While we have no problem with people banding together as they see fit, we don’t want that banding together to be the “one correct option” - and the current system encourages this.

Furthermore, the intrusion system is in no way a reflection of who actually controls a location. It is instead a reflection of who can bring the most power to bear at a random time, once a week. This is problematic because a) it discourages exploration and utilization of betas in general, b) it does not reflect the “truth” of who is in a particular area, and c) by encouraging superalliances, we’re essentially excluding small parties from taking and using remote locations successfully - cutting off part of the playerbase.

So after much consideration, we bring you the new Outpost Capture system, coming “soon.”


The simplest way to understand the new mechanic, when you boil it down to an essence, is this:

“If you reside in an area and control that area, you will eventually come to control the outpost. If you raid-and-retreat from an area, it will become very hard to hold the outpost.”

Here’s the mechanics of the system:

Every outpost, as you know, has 3 SAPs. This will not change. What changes is that instead of an Outpost having all 3 SAPs becoming accessible once a week, two SAPs will become accessible every 24 hours. Exactly when and which SAP becomes available is completely random and unknown - just that you can count on two sometime during every 24 hour period. Every Outpost operates independently - the SAPs at Brightstone are on a completely different timer than the SAPs at South Isietsu, and so on. The effect of capturing a SAP would be changed as well.

When a SAP is captured, this lowers or raises the Outpost’s stability level, depending on whether the SAP was captured by the Outpost’s current owner or some other party.

Stability, in effect, is a measure of the Outpost owner’s ability to maintain control over the areas around the Outpost. Captures by the owner indicate the area is in hand and therefore stable - captures by outside parties indicate the area is troubled, and therefore unstable. If the owner of the Outpost captures the SAP, they have demonstrated control and dominance over the area - the stability value of the outpost grows. If another party captures the SAP, they have demonstrated that the owners of the outpost are NOT in full control of the area: the stability value of the Outpost decreases. After the SAP capture is complete or 2 hours pass, the SAP disappears and reverts to its neutral, passive state. The stability level of an outpost changes by roughly 6.66% per SAP capture.

Capturing an Outpost - When Destabilization Occurs

In order to fully destabilize an Outpost - take it from 100% to 0% - you need to capture 15 SAPs in a row. (Essentially, one full week plus one more SAP.) This shows absolute domination and control of a location.

Because we recognize it is possible for someone to capture an Outpost through blind luck - they had one person wander by at 3am when the two parties battling for the Outpost were asleep, and the critical SAP just appeared - we have also incorporated a “Snowball Effect.”

The first and second time in a row that you capture a SAP, you get credit for one capture. The third time, you get credit for two captures. The fourth, three captures, and so on. Essentially allowing for a 1+1+2+3+4+5 situation - three days with absolutely no response from the defender and 100% domination by the attacker leads to a capture on the start of the fourth day. You would be able to dock again much sooner than that, obviously. Note that a “no capture” SAP (nobody captures it and it expires in 2 hours) resets the Snowball Effect. Among other reasons, this was instituted so that if someone is utterly unable to hold a location - they got very lucky with the initial capture, for example - the dominant party in the area can flex a little muscle and take the outpost down again right away.

When An Outpost is Captured the stability of the Outpost instantly reverts to 50% in the hands of the new owner: they have the ability to lock the Outpost, but only barely. The new owners of the Outpost, though, can demonstrate financial might along with their military acumen by bidding NIC in order to prove their commitment to the area. Doing so will immediately raise the starting value of the Outpost Stability. This can only be done immediately after the Outpost is captured. No one is impressed with you throwing cash around after you’re supposed to be in control!

The probable values for “demonstrating financial might” are as follows:

  • Pay 100m NIC: Outpost starts at 60% stability.
  • 250m NIC: 70% stability.
  • 450m NIC: 80% stability
  • 700m NIC: 90% stability.
  • 1 billion NIC: You start with absolute 100% stability on the outpost. (You go with your bad NIC-holding self.)

The outpost stability level is also a measure of the benefits you receive. Outpost ownership is no longer going to be an absolute: the greater the stability of the outpost, the more benefit the owner receives. The values below are subject to tweaking, but here’s a general idea of what we’re thinking:

  • 0% stability - The Outpost has been destabilized and is open for capture. The next SAP capture could change ownership of the Outpost.
  • 25% stability - No benefits other than getting paid when other groups use the outpost; you’re barely holding on to control.
  • 50% stability - Minimum threshold for outpost locking controls (to block other corporations from entering), moderate relation bonuses for industrial facilities. Minor price reductions.
  • 75% stability - Reduced prices for service in the outpost, high relation bonuses for industrial facilities, Outpost locking controls.
  • 90% Stability - Owners receive high discounts for services and enjoy maximum relation benefits, may also lock the Outpost.
  • 100% Stability - Owners not charged for any service and enjoy maximum relation benefits; may also lock the Outpost docking mechanism.

A few questions that people might have

Q. Won’t my corp just lose SAPs when they come up in the middle of the night and none of us are on?

  • A: Absolutely. If you don’t have a presence on the island 24/7, there exists the possibility that your stability level will - over the long term - tend to hover right around the percentage of the time you’re on the island. If you’ve got a presence the 80% of the time, you’ll probably hold right around 80% stability if someone starts challenging you for it. If no one challenges you, the SAPs you miss will despawn in 2 hours, and eventually you’ll raise the stability to 100%. If you lose one overnight, no big deal: your presence on the island will allow you to push it back to 100% soon enough.

Q. What if more than one party is pounding on my outpost at a time? How does that work?

  • A: You’ll have a hard road. It doesn’t matter which corp takes your SAPs - the Outpost Stability goes down all the same. To use a historical metaphor, it didn’t matter to a Roman citizen which nation was pillaging and sacking them before Rome fell - just that they were being pillaged and sacked.

Q. So when a Outpost reaches 0% stability and becomes open for capture, more than one party could show up and fight for it? What happens if the original owner captures it again?

  • A: Yes, we expect that the areas around an Outpost at 0% stability will become wild melees as multiple parties all move to be the one to capture an outpost. These could turn into pretty impressive endurance matches, since you can never be sure when the critical SAP will appear. (Imagine the King-of-the-Hill match if the next SAP to open was the Passive one!) If the original owner manages to capture the SAP, they also get the 50% value and the chance to pay to increase it, but if they’ve been ground down to 0% once, they’ll be ground down again. (Or not, if they can prove they deserve to keep it now.)

Q. What if my corp gets a string of bad luck with their SAPs, or has to go AFK for a day or two because of (insert reason here?)

  • A. Remember that the system is gradual: you’ll be able to tell if you’re in trouble, and if your entire corp disappears for a day or two, you’re still in control. It’s by the end of the third or fourth day (depending on how quickly and how hard you were under attack) you’ll have a problem. You can interrupt a Snowball Effect with one capture, and if you honestly can’t field enough force at your Outpost to prevent even one enemy capture, you probably shouldn’t hold it right now. When everyone’s back and ready to fight, you can always take it back the same way you took it to begin with.

Q. What happens when this system goes active?

  • A. All current owners will be given 50% stability at all of their Outposts, with no possibility of paying to increase the value. We’ll give you basic docking control - whether you can hang on to it after that is entirely up to you.

Q. Will we be able to tell the Outpost’s stability level?

  • A. Yes. We’re still working on where the information will be known, but it will be publicly available.

Q. Can a corp that has strong relations with mine capture a SAP for me?

  • A. We have no plans to allow this at the present time. If you’re leaning on another corp for safety, they’ll need to either defend the SAP until it disappears... or maybe they should be the ones owning the Outpost?

Q. Could a corporation just watch two other groups battle it out, and then swoop in for the last capture when it really matters?

  • A. Someone might be able to pull that off once, but they’ll just lose control right away themselves if they’re not exerting enough force to hold the place - and if they are, then they’re the rightful owners to begin with. It’s unlikely that a group could repeatedly “snipe” the last SAP for the capture when its time of arrival is unknown. If you’re trying to take an Outpost and you’re being repeatedly “sniped” by different parties, you may not have the force to hold on to it yourself!

In Summary (TL;DR)

  • Outpost Ownership will now naturally reflect who lives on an island.
  • Outpost Ownership is going to become organic, and not absolute, in a tug-of-war fashion.
  • This allows us to implement Outpost locking without creating the nightmare situation of “You wake up and can’t get to your stuff.” It will be very clear in advance when you’re in danger of losing control.
  • We feel this system encourages small groups to “take their shot” since few groups will have the ability to maintain multiple locations at the same time.
  • We feel this system will encourage PvP on the beta islands: it’s a very safe bet that somewhere on some island at some outpost at least one SAP is vulnerable at all times, and people will need to be on their islands in order to keep their outposts safe. More beta traffic offers more opportunities for raiding and for defending. More PvP for everyone!
  • We want the system to reward people who live on the betas, not just those that raid them.

Is This All?

No! We’re anticipating a great deal of improvement to your Beta experience. Possibilities on the horizon include Aura-type bonuses for Outpost ownership which also scale with your ability to demonstrate stability.

We’re very excited to implement this new system and see the dramatic and positive effects this will have on PvP. We’re committed to making living on the outer islands more interesting for everyone, and more rewarding as well. Demonstrate that you can hold an Outpost this way, and when other changes to improve Beta life come in the future, you’ll be glad you did!

We look forward to your feedback and opinions on this proposal. We’re excited to see how this changes your Perpetuum experience, and see how you feel about it!

Scuttle safe!

Well, this has been an exciting three weeks. We had to allocate most of our resources to stabilizing our service, but rest assured we did this with great pleasure. While our efforts had clear results, the development plan for the first two weeks was ruined, and the last week was spent finishing the storyline missions that are to be released with the next patch. This would have been deployed today, but we found an unexpected mission-critical bug and will release it sometime in the beginning of next week. Till then, a few teasers:

While these new missions are only available to Agents with high relations (they are level 3 assignments) and form a small proportion of all missions in game, they serve as a great platform to test our new assignment features that will find their way into the entire assignment system.

The influx of players brought light to a lot of glitches, imbalances and dysfunctional mechanisms in the game, so instead of rushing forward and pushing out new features in the next weeks, we are taking a step back and making everything that is available in the game better. All of these features are subject to change, but their purpose and outlines are quite clear. Behold, in the specific order of release:

Week of 25th of July

All our base are belong to us

Beta outposts are greatly underused at the moment. This is due to their poor risk versus reward ratio. Industrial traffic attracts a lot of hostile attention and the attackers have great advantages at the moment:

  • safe equipment storage
  • instant respawn
  • seeing the defenders’ available backup numbers
  • seeing what the defenders deploy to the island through an Arkhe scout
  • docking when overwhelmed
  • generally nothing to lose

To make these outposts and their facilities more appealing, the owners will be able to manage docking access via the relation system. The ownership will be decided in the period of two Intrusions. Losing the first Intrusion, the defenders will lose docking access management rights and the second will decide the new owner of the outpost. Later on the Intrusion timer system will also be revisited.

Welcome your new robot overlords

The Nians are becoming more clever and flexible - if you partially destroy a spawn group, it will keep coming at you. If you totally destroy a spawn group, the Nians will deploy a different kind of spawn the next time to keep you guessing. There’s also the chance that the spawn group may be an "elite" spawn - special forces carrying higher quality gear, or items that will lead to higher ranked Elite Spawns.

Week of 15th of August

Fledgeling industrialist love

There is a distinct lack of beginner production in the game. Industrialists either have to commit very serious effort, resources and EP to production, or risk failing to be competitive in any market. To mend this we are going to introduce a simple system that allows us to determine an item’s manufacturing ‘difficulty’, making it more or less sensitive to extensions and facility levels.

The idea is quite simple. CTs will not start at a default 50% material and time efficiency level, but will be predefined by their end product's complexity. Complex items will have low efficiency, leaving great room for improvement, whereas simple items - such as ammo and standard equipment - will start at high values, making them less sensitive to improving factors.

Furthermore we also plan to replace all epriton based components in T1 modules. This and the above changes will allow for a much easier and competitive entry to the industrialist career.

Industrialist brothers in arms

Currently all involved in high level production have to grind their relations up towards the relevant factions to achieve competitive results on the market. This is quite unfair, as these characters typically have little extension points invested in combat, so their combat extension spending comes at an expensive rate and they are forced into activities they may not prefer.

Henceforth, the combat mission relations will not be effecting production. Industrial mission relations will still be calculated, as the facilities currently used by the Agents are owned and loaned by the Syndicate.

From the cartographer’s wishlist

  • Agents will be able to set waypoints by a point & click method on the map, rename them, and organize them info folders.
  • Outpost ownership will be displayed on the map.
  • The legend area will be resizeable, making the use of the map much more comfortable.


Probably one of the most anticipated features since launch is the autopilot. Good news everyone, the time has come. You will be able to add waypoints in a certain order to create routes. When the autopilot is engaged, it will follow the route. Although plants that may grow in the path will block the robots, it’s worth noting that there are already many paths connecting the main landmarks that are cleared of these annoying vegetables. Have fun finding them and plot away!

Why is it called Zombiepilot?* Because it is really dumb and will literally do nothing more than try to lurch its way towards the next waypoint. Braaaiiinns!

* It's not, actually.

Perpetual life

Perpetuum’s persistent universe is in strong contrast with the Agents being able to reinvent themselves and appear with different names and faces. Character resetting will be removed at this point. Obviously doing it right the first time is nearly impossible. Fear not - we have a solution.

For the first 30 days you can both add and subtract extension levels in your Agent Profile. The limitation to this is that you won't be able to jump back and forth between full-fledged combat and industry specialization every minute, and that taking any extension to level 6 will freeze it perpetually. There will be an option for a one time attribute reset in this first period as well, most probably via running a trimmed version of the character creator again.

Week of 22nd of August

Farewell ‘Triangle’

All assignments will be overhauled:

  • The newly introduced features will make all assignments more challenging and exciting.
  • Transport missions will be fixed, their targets will not be another terminal, where another mission can be picked up, but rather a special building on the field. This will correct their reward per time ratio.
  • Mining missions will have a special target material, which is required by the Syndicate for the process of collecting energy and transferring it back to Earth, and is not used in the production chain.
  • Geoscanning assignments will be removed, and added as extra objectives to mining missions. These changes will ensure that these assignments do not interfere with the economy on the surface.

As you can see, we have a lot of changes on the horizon that we’re excited about, and we think you will be too. We look forward to reading your feedback on these suggestions, and working with you to create the best possible play experience. Until next time:

“Scuttle safe!”