It’s been a little more than a month since we’ve launched on Steam, and we’re closing in on 2 months past our payment model change, so it’s high time to do a quick assessment on where we stand, and where we’re going.

Fresh blood

The best news I can tell you is of course that our playerbase received a much needed boost, thanks to our parting with the subscription model, and the huge visibility that Steam provides.

We’ve hit the 600 mark with the online player count on a recent weekend and our average player count is roughly 5 times as before. Of course this is a tiny amount if you compare Perpetuum to other online games, but I have to remind you that we’re still in Early Access so people are wary to join. Also, as we have stated before, we’ve chosen the path of a slow growth instead of spiking it, so it’s all pretty much going according to our plans. We didn’t have any server issues that can be attributed to online player numbers so far either, which is another good sign.

I don’t have the freedom to tell you actual financial data, but it should be enough to say that after months (years?) of worrying about what to put on your plate tomorrow, it’s a liberating feeling to have that off of the list of things to worry about, and being able to just focus on making the game better.

A new home

We have already started to put those financials to good use, so beyond the company-issued Ferraris (by which we mean a second portion of ramen), we have found a brand new hosting location for our game servers.

As you probably know, the Perpetuum server cluster (if you can call 3 machines a cluster) is currently located in Budapest, Hungary. This is of course quite optimal for us, but very sub-optimal for most you, as we are hardly what you could call the center of the interwebs. My support ticket inbox is always full of reimbursement requests related to lag and disconnections, and most of those can be probably attributed to various network and routing issues.

So after doing the necessary research and inquiries, we have decided to move the servers to a prominent datacenter in Amsterdam. Though technically we’re not moving the machines themselves, but rather renting new ones on location, since we’re very fond of the idea of not having to send in Gargaj to switch a faulty HDD in our self-maintained hardware. To Amsterdam.

Without going into too much technical detail for now, compared to the current mixed-role 3-server configuration, the new setup will consist of 5 core machines: 1 server for handling player traffic (logins and zone jumps), 1 dedicated machine for the SQL database, and 3 dedicated machines for hosting the islands, split down between the 3 main factions.

Paperwork and technicalities are still in progress, but if things go as planned, you’ll be able to test the new servers within a month.

The near future

Let’s have a look at the things that we’ll be focusing on in the coming months. Some of these will be done in parallel, but the general order is something like this.

Gamma revamp

With the closing down of gamma islands a huge chunk of the game content has been temporarily removed, so this is our top priority right now of course - we know that you guys are preparing for the mother of all wars when gammas open up again. We are using our public test server to try out all the new mechanics and limitations that we need to implement to make it all work again.

We’re taking our time with this because obviously nobody wants another gamma wipe a year from now, and we are grateful to everyone who aids us with valuable feedback and actual testing. More info on the progress of this is coming soon to the relevant testing forum topic.

Quality-of-life improvements

Gargaj is on fire, and we have received an overwhelmingly positive feedback on the small QoL improvements like the autopilot, the storage search, and the many small UI-related changes. We’ll continue on this road, so you can definitely expect more of these.

Assignment system revamp - Stage 2

After Gamma is back up, we’ll jump right into doing some long-awaited PvE love: the revamp of the assignments. It’s been a while since we announced this, but better late than never.

As you might remember, the second stage is about making the assignments themselves random. We’ll be using an assignment template system where we only set what type of objectives you need to do, but the exact enemy you need to kill, or the item you need to acquire, or the mineral you need to mine will be all randomly selected from a pool of nearby locations, so your chances of seeing the exact same assignment twice will be quite low.

Not only that, but we’ll also seed the islands with many small assignment terminals that you’ll be able to use while on the terrain, so you can spare the long walks back and forth to the main terminals just to request or deliver an assignment.

Robot paint system

We have already deployed the foundations of the paint system in a recent patch (you probably noticed because most of the robots received a white color due to a bug).

The coloring system will be definitely not just some “pick a color and be done with it”-thing: we’ll have paint items that you can either gather or manufacture and then mix them together to get the final color for your robot; so basically fully integrate the painting frenzy into the industry and market economy.

Teleport and highway network revamp

The topic of long walks is still one of our most discussed issues, and one of the many reasons behind it is the current haphazard teleport and highway system layout. Although we don’t plan to make groundbreaking changes to the teleport network itself, our basic concept for the change is that you should be able to travel between every teleport and terminal/outpost without stepping off of a highway, ever. If you’ve seen the Virtual Training Island, that should be a good indicator of our general direction with this, but we’ll try to even top that.

Balancing changes

DEV Alf is back from the dead too, so you can expect some balancing changes too. He has already jumped into a hot topic right now: the balance of signal detectors and electronic warfare in general.

Steam trading and market integration

This is something that we still need to do some research on, but I’m putting it here because we plan to do it sooner rather than later. As you probably know, several games have items that can be traded via the Steam economy already. The general idea is that first you would be able to trade ingame items via Steam, for example your Gropho Mk2 for some trading card or another Perpetuum originated item.

The ultimate goal however is that we’ll also hook up Perpetuum to the Steam community market, where you’ll be able to sell and buy ingame items for Steam wallet funds. We’re approaching this very carefully of course - it could be a large boost to the ingame economy, but things could also go wrong with it.

The not-so-near future

We’re quite aware that the graphics of the game are starting to look dated. Unfortunately the current engine architecture has also become dated, so this is not simply a question of putting in higher resolution textures and models. The engine requires a major rewrite for any significant upgrades.

Not to mention the GUI - one of the most frequent complaints we hear is about the small size of the ingame fonts. This is also something that’s very hard to fix currently, since the interface is pretty much hardcoded and not “stretchy”. Text with larger fonts would simply overflow outside of the UI elements, and we’d need to have a completely separate, differently sized interface for that to work - and we’d rather put that effort into a new and advanced interface engine that will work for all display sizes without compromise.

For these reasons we’ve been working on the foundations of a completely new client but as you might guess this is not a simple task. At this time we’re still pretty far from replacing our current client, but work towards this goal has been going on behind the scenes for the last year and a half now.

Our first goal here is to get basic functionality going (glorified chat client woo!), which would work as a proof of concept for the new interface engine. Once that’s satisfying enough, we’ll move on to the 3D engine itself. With the new interface tech we developed, the implementation of a new client should go a lot faster than before. Regarding a timeframe, we hope to have something to show later this year, at the very least a partially functional test of the new interface engine.

Conclusion

This year marks the 10th year of Perpetuum development, and after an admittedly quite awful last year - which no doubt you noticed as well - the Steam launch has been one of the most important things that happened to the game. We’re adamant on riding this wave and focusing on making a better gaming experience for everyone, which is an easy thing to say, and it’s equally easy to be sceptic about it, but here’s the thing: This project is important to us - and we’ll act accordingly.

The end of the year is near and we’d like to offer you some insight on what’s going on around Perpetuum, tell you about what’s currently in development, and get you a glimpse of what the near future will bring. Be warned, it’s a long read, but I didn’t want to miss anything - and I’m sure you’ll have many questions even so.

Behind the scenes

We know we’ve been a bit quiet lately, and this has its reasons. In the past months much of our development power has been put into things that are not directly related to the game itself.

For one, we’re of course getting ready to release Perpetuum on Steam. This involves a lot of paperwork, preparing marketing materials, and not to forget about getting the game itself fit for releasing it to such a broad audience.

Steam Greenlight - a highly public event - happened during the autumn, however we've been spending most of our time since the Gamma Expansion working on getting Perpetuum the extra funding it needs so we can take a quality leap forward in terms of world content. We realize that to create the type of content that would allow Perpetuum to grow to the next level requires a team much larger than ours, and all of us are working very hard on making that possible. This process involves all of the devs to some extent, and is mostly why we've been so quiet during these last months. These things however take time, and the new year will see us continuing the effort.

Meanwhile we’re working on the game itself as well of course, so in the rest of this blog I’m going to talk about what’s coming up. The time for small changes is over, we’re getting the big guns now.

As we stated after the gamma expansion, we’d like to focus on the PvE part of the game for a while, since that part is in desperate need of some fresh blood.

We’ve chosen three large systems currently in the game, the ones where we feel that reworking them would substantially make the game more fun to play: the kernel research system and the knowledgebase, the assignment system, and the new player experience with emphasis on the tutorials.

So let’s see them one by one in detail. The ideas presented here are still work in progress and may change as we work out the smaller details, and of course we will consider your feedback as well.

Research revamp

What’s wrong with the current system?

  • Random research results are not fun. This is especially true when a technology line in your knowledgebase is close to complete, at which point kernel research becomes vastly irritating. Due to the randomness the system doesn’t allow for any serious planning or strategy.
  • There are too many types of kernels. Kernels have been partly intended as a second income besides plasma, but their sheer number fragments the kernel market and has a negative effect on their trading potential.
  • Corporations are not a part of the system at all. They are forced to feed one or two of their agents with kernels to stay competitive. This is very risky, as losing those agents leaves the corporation with close to no prototyping capability.
  • Research has much more potential. Why waste it simply on prototyping, a feature used by not many players?

The new system:

  • Point-based. Instead of getting technology directly from kernels, you consume kernels to gather research points (RP). You then spend these points in the knowledgebase for specific item technologies.
  • Choose your research goals. No more random results - you choose what you want to spend your RP on, using a fixed technology tree. It’s completely plannable, research only what you really need. I’m sure you’ve seen such a tree in many games already - just imagine a branch with many expanding nodes, starting out at the base from the lowest tier technology, and unlocking your way up to the most coveted items.
  • Reduce the number of kernels to 6 main types. They all hold a different type of RP, which accumulate into separate pools. To help keeping the system calculable, kernels will always contain a fixed amount of RPs. To keep scalability, NPCs will drop not just one of these, but many, depending on their ranks.
  • The RP technology types are: nuimqol, pelistal, thelodica, common (used for industrial too), hi-tech and “new-tech”. Unlocking item technologies in the knowledgebase will use a varying mix of these RP types, depending on the item’s faction, tier, or even novelty. (Nasty details: the latter is what “new-tech” will be used for, and we’ll always use it when we introduce new robots or modules into the game. When the time comes where “new” items become “old”, and we’re ready to introduce a new batch of technology, accumulated “new-tech” points and kernels will always be converted down to hi-tech points and kernels - this is to prevent unlocking new technology on the first day by prior RP accumulation.)
  • Separate knowledgebase for individual agents and agent-independent knowledgebases for corporations. Agents always accumulate RP to their own knowledgebase, but they will have the option to donate any amount of unspent RP to their corporation at any time. The corporation-level knowledgebase can then be researched using the donated points by anyone with the necessary access.
  • Having an item researched in an agent’s own knowledgebase will unlock prototyping option for it (like it is currently), and having an item researched in a corporation’s knowledgebase will allow every member with proper access to prototype that item.
  • Here’s the twist: having the same item researched in your own knowledgebase AND in the knowledgebase of your corporation as well will provide a factory production bonus for you. We think this provides an incentive to develop both knowledgebases, your own and your corporation’s as well.

So what will happen to your current knowledgebase when this gets into the game? Well it will be wiped of course and you’ll have to start over, ha-ha. Nah, I’m just kidding, once we figure the exact RP value of every item in the new technology tree, we can give you the matching amount of RP for your actual knowledge, so you can basically rebuild your knowledgebase from scratch. Now, we can’t guarantee that you’ll have the same amount of “raw research value” after that, but I’m sure that being able to select specific technologies to research will mostly provide you with a better result overall. We still have to figure out what happens to unresearched kernels, so we’ll get back to that.

Some of you have been also wondering what happened to the promised new tier of items using colixum. Well, this happened :) We didn’t want to build upon a broken system and create an even bigger chaos. This new system will allow us to introduce new item technology in a much cleaner and nicer way, and that’s what we’ll do once it’s ready.

A new assignment system

I’ll be honest with you: the current assignment system is something we put into the game almost 3 years ago just to have an assignment system. There wasn’t much concept behind it, and it shows - it’s bland, grindy, and not really fun.

At first the main problem is that the player is presented with a huge list of available assignments. This can be quite overwhelming and you just don’t know what to do. Later on you figure out which assignments are the easiest to do or give you the most rewards, and then you’ll grind those over and over, effectively destroying your own game experience. And then we introduce the 6/10 rule - insult to injury.

So we’ve been planning a complete revamp of the system for a while now, and unlike in the case of research, randomness could be our friend here. This is a huge undertaking, and luckily we can separate it down into two stages: the first stage will use the current assignments, but will change the way they are provided and accepted, and the second stage will change the assignments themselves.

When you open the assignments window in the new system, you won’t see a list of specific assignments, only some buttons for types of assignments - combat, industrial, transport, and so on. These will be arranged into a grid, where rows mean assignment levels and columns mean assignment types.

Once you click a button in this grid, you’ll be assigned a random assignment of the selected type and level. Then you can either complete that given assignment, or you can choose to abort it, in which case you’ll be given a penalty. However, that penalty is not a deduction of relation points like now, rather a penalty multiplier for your next assignment’s reward. This means that the more assignments you abort in a row, the less rewards you will get for the assignment which you finally complete. The penalty will be cleared after a certain time or when you complete an assignment.

So this random assignment provider would be the first stage. The second stage is where we also randomize the objectives within the assignments. This system is still heavily under development, but it would use assignment templates, where we only set the number and types of objectives that you have to do. The exact NPCs you have to destroy, or the minerals you have to mine, or the items you have to transport would be randomly selected from a pool of objectives around a certain radius of the location where you take the assignment. This would maximize objective variety and minimize boring walking time. In the new system we also plan to scatter small assignment terminals around the islands, so you will be able to take them there too and not just in the big bases.

Assignments in squads

I'm sure most of you are familiar with the current mechanic for doing assignments cooperatively in squads, which is far from being optimal or useful.

As it stands today, the members of the squad and the assignment they are doing have a very loose connection. Everyone is doing their own assignment, it's not shared among members. One member's objectives are not completed if another member does them. The only actual mechanic is that you can share the money and relation reward among your squad members if you chose to do so when accepting the assignment.

We had a little poll on the forum where I asked you which of the two new squad mechanics you would prefer. While the result turned out not really decisive, it turns out that in a system where assignments are given randomly, only the first option makes sense, because there is very little chance that the squad members can get the same assignment.

So we’ll stick with option number 1, where every member of the squad is working on a common goal and contributes to one shared assignment, the squad leader’s one.

Instances

I left this for last because frankly this is the topic where I can share the least details - it’s very much work in progress. However I wanted to tell you as early as possible that instances are coming.

Before you pick up those torches and pitchforks and yell that instances have no place in an open sandbox world, I’d like to explain why they are needed, and what for.

What we definitely don’t want is to drain population from the open world into an infinite number of hidden pockets - the islands feel empty even so, we don’t want to make it even worse.

However there are a number of features and mechanics where we just simply can’t go around instances without having a negative impact on gameplay experience. In an open world you can’t set up a preset game event without pitfalls, however carefully you plan and script it. There are so many unknown variables that a single speck of dust can break the machine.

This is especially critical for a new player - when he can’t finish a tutorial objective because someone mined out all the titan ore before him, he will rarely ask for help, and probably leaves for something else. That’s why first and foremost we’ll use instances for our tutorials, where we can be (almost) sure what happens to the player, and where we'll have much more options than in the open world. Think for example temporarily giving a heavy mech to a new player just to give him a taste what the future holds for him, or to let him try various factions before he makes his actual choice.

Of course it would be a waste of technology to use instances only for a tutorial. It holds many possibilities, like small dungeons that you can scan down and enter from the open world to clear out, or controlled PvP arenas with proper limits, teams, timers and everything.

Closing

That’s pretty much all I have for you right now. These are the features that we’ll be working on in the next 2-3 months, to give you a rough timeframe. Of course once we’re ready with one system we’ll patch it out, you won’t have to wait for all that time.

And don’t worry if all of this is a bit hard to grasp now, I’ll post a follow-up to this blog a bit later when we already have some GUI-mockups and stuff.

Post your opinions and questions below, or feel free to create separate feature discussions on the forums, and last but not least, we wish a Happy New Year to all of you!

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.

Implementation

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".

This blog post is intended to give all of you my take on the last few days. Since it's been such an exciting time for us here, I'd like to give my own perspective on it. This is a pretty tech-heavy post, so be warned.

Last Thursday I travelled to Paris to give a couple of interviews to the mainstream French gaming media about Perpetuum. All went well, and I'd like to seize this opportunity to send a big shout to all the participants for their kindness and professionalism.

Something you don't want to see.

Saturday morning, while roaming the streets of Paris, I started receiving messages and phone calls from the dev team at home about a nice amount of new registrations. As time went on the number just went up and up. Having no idea what's going on, we were simply happy about it and tried to craft theories around it. Later that day I met Guillaume - who is one of our players - and he explained everything about the current situation on the MMO landscape. (Thanks Guillaume for the hospitality, I owe you one!) In the meantime, I was being spammed with messages that something weird was going on with the relay server, causing insane lags. You can imagine the number of calls, as even the battery ran out in my mobile!

Sunday night I got back to Budapest, went home, took a shower and immediately headed to the office to check on the situation and fix the server problem. In the office I found out Calvin came to pick me up at the airport, but since my phone died on me earlier, we managed to miss each other. From this point on, I completely lost track of days and hours with almost no sleep only focusing on the server issue.

We checked everything: optimized the SQL, implemented new caches on the server, tried many other things, but they were minor problems compared to the evil seed that caused the problem. The main difficulty is that it's very hard to generate load on the dev server similar to the live one. For the tech guys out there, the transaction coordinator (MSDTC) was NOT the problem, it causes an insignificant load, so we are fine with that.

We had to put in two nights in a row. We simply had to rest, but it was made hard by the stress and the guilt of leaving the gimped server alone, not knowing what would await us when we wake up. Things were looking grim.

When we realized the seriousness of the problem, I contacted one of the most knowledgeable people I know in this field and asked him to help out as a fresh mind always has a better chance finding hard bugs. Our deepest respect Soci! (Shameless promotion: http://soci.hu/). Luckily, he had time to check out our architecture and together we were able to start an investigation session on Wednesday night. He gave us several suggestions, pointed out and helped optimize several things in the database layer. Then we moved on to inspect the relay server's code. Since the source is huge, the quickest and most realistic method was to attach an analyzer to the live server application. I must admit this was the last thing I wanted to do on my own, but at this point I was willing to sacrifice anything to find the root of the problem.

He instantly figured out that one innocent-looking little function, namely the one which returns who is online (in chat channels, for example) has an emergent behavior, resulting in an exponential load and suffocating the server. (Insert random sarcasm about glaring oversight and tech madness here.) We then ran Visual Studio performance monitor on the live server to dig down to the heart of it. Soci said it might cause some load, so we messaged the server with a warning about what we were doing. And then we accidentally the whole server. :) 0245 server time, bye-bye field containers!

Thursday we closed the session with Soci and went back to implement what we'd learned. Quick tests on the dev server showed pretty amazing results so it made us rather confident. With shaky hands we patched and let the first 50 players in. This was the moment of success! So we immediately let 100 more players in. During this period we constantly checked the load which became insignificant (2-3%) so we raised finally the cap to JUST OVER 9000!!!!! >:)

The time to chill out has finally come, so we popped open one of Gargaj’s precious Norwegian treasures that had been sitting on our shelves for some years, a bottle of blackcurrant wine. I don’t know if it was the quality of the booze or the grace of that moment, but it was one of the sweetest sips we ever had.

Well, that’s the end of that, hopefully I managed to shed some light on the problem and our day-to-day march until we reached victory. The code belongs to us, but the world of Nia is yours. Enjoy!

So what are we up to when we are not out deleting NIC from your accounts and playing Insurance Fraud Online? Well, for one, we make plans. And since we got a lot of complaints from you that we don’t publish too much information about the upcoming features in the game (not unjustly, I might add), it’s high time to sit down and share.

The features below are listed more or less in the order we currently plan to introduce them, with the first ones being only a few weeks away and the last ones planned more towards the second half of the year.

Artifacts and discovery

When we recently hinted that we are working on new PvE content, most of you probably thought “Ohnoez, more Buttkicker Observers and boring missions...”. But nah, we are perfectly aware that it would be just more of the same. Instances probably crossed your mind too, but we don’t want to separate PvE and PvP and we definitely want to keep the game world open and persistent.

So we came up with something that is easy to get into, is available to everyone, from solo carebears on Alpha islands to the proud cowboys of Beta islands, and is something that can reward you with shiny new stuffz.

Artifact scanning (as we call it) is basically an extension to your current geoscanner modules. Every island will have an ever-changing collection of hidden spots that players will be able to search for with their scanners and reap their rewards when they find them. There will be several types of artifacts ranging from simple salvage containers, through hidden stashes guarded by angry NPCs, science vessel wreckages holding calibration templates of new Mk2 robots or even alien data storages with precious intel that will get you on special missions. Since this is a very easily expandable system, you can expect more artifact types every now and then.

The energy must flow

Those who are familiar with the backstory of Perpetuum are probably well aware that we are here to exploit the energy of the planet and send it back to hungry Earth via that same wormhole, which we used to get our tiny “sparks” to Nia. You were probably also wondering “where in the game do we do that?”. Well, currently nowhere since we are still at the early stage of “setting foot”, but this is soon going to change.

We’ll be intruducing a new energy-credit system which will work a bit like a second currency. These energy-credits (let’s call it EC for the time being) will be awarded to those who contribute to the energy-packages that will be periodically sent back to Earth by the Syndicate.

You’ll be able to achieve this via two ways, one PvE and one PvP option:

  • Using fragments of a rare kind of crystalline material, which can be charged with energy and can be found through artifact scanning mentioned above, you have to go out to shiny energy fields, deploy the crystal and wait until it’s fully charged, then return it to a terminal. Of course indigenous Nians also like to be around these energy-rich areas, so you won’t have an easy time doing this.
  • Own an outpost with a corporation which is producing the energy for you.

So what will EC be good for? New modules, rare components used in Mk2 robot production, CTs available only here... you know, stuff™. The details are still being worked on but we’re confident that this system coupled with artifact scanning will give a nice boost to what you can do in the game.

Assignment improvements

Yes, were aware that the current assignment system rather follows the bad concept of “quantity over quality”. We have plans to make current assignments more interesting, include new types of objectives or combine current ones, revisit their rewards and introduce payout bonuses for those who complete them within a certain time.

Corporation recruitment

There are basically two games in the world of Perpetuum. One is the initial “run around, complete missions, collect stuff” side of it, and we’ll be the first to admit that it lacks content to be truly enjoyable. And then there is the second layer of the game, the player corporations.

We fear that some players do not get to the point where they actually join a player-run corporation, and leave the game without ever realizing what is going on behind the scenes in this little world of ours.

Therefore we would like to implement some features that will guide players towards finding and joining a corporation that is suitable for them. The tutorial will also have a chapter on this and we’ll introduce a “yellow pages” type of directory, where players will be able to filter corporations based on their of size, language, timezone and profile, which CEOs and officers will be able to set in the extended corporation information panels.

Artillery and area-of-effect explosions

Continuing our efforts to “fight the blob”, we’ll be introducing area-of-effect explosions, which will hurt everyone within a certain radius. On one hand this damage will be done by the explosions of robots when they are destroyed, but we’ll also bring in new weapons of mass destruction: artillery modules. You’ll see both standard Earth-technology built by the Syndicate and also different types of modules for all 4 factions (yes, even industrial ones) and they will certainly stir up the crowd.

Even more types of weapons

We’re not stopping there, new factional weapon types have been already in the works for a while. These new modules will be of course rather high-end, with high extension requirements and energy usage and while they probably won’t have the highest DPS around, all of them will have secondary effects: Ion cannons will jam enemy sensors much like ECM modules, energy torpedoes neutralize a hefty amount of energy on hit and plasma guns will reduce the armor-resistances of the target.

Hybrid robots

I suppose some of you have already encountered the funny misfits certain DEVs like to run around in. The system where we can freely build robots by combining any head, chassis and leg components has been in the game from the very beginnings. The only problem: it’s nearly impossible to balance it properly. We haven’t given up yet though, so you’ll most likely see a system like this in one form or another.

New lands to explore

This doesn’t need much explanation - having such a limited area available makes territory control too easy for large corps, makes it impossible for smaller ventures to hide and build, and generally limits exploration and exploitation of game mechanics. Even with our procedural terrain generation system, creating whole new islands which actually have some content as well is one of the most time-consuming tasks, but it is also a part of the game that can be expanded indefinitely (in theory). So this will be an ever-ongoing venture, but the plan is to have six new fully featured zones in our first package.

Terraforming and player-built structures

New lands hold new possibilities, and terraforming is an old promise that we intend to keep. While it’s not feasible to allow players to dig up the soil under dumbfounded newbies sitting on the alpha islands, certain newly introduced zones will provide this strategically very engaging option.

Terraforming can be interesting in itself as well, but in the end it’ll be mostly a tool to make room for structures built by the players. This will be our biggest expansion of the game (of what we have solid plans for anyway) and as you might guess this is the feature that I can provide the least details about currently. I think it’s suffice to say that we want to make it very modular, expandable and complex, so you can create something that you call “home”.

Closing words

Well, I think that’s about it for now. These are only the bigger incoming features, but we’re of course continuously working on fixing those bugs and re-thinking current features like the waypoint and the geoscan result system or the event messaging system.

As you can see we are determined to make the game better and more interesting and hopefully this post provides new hope for those who fear for the future of the game. Fear is the path to the dark side and we don’t have pathfinding yet.