<?xml version="1.0" encoding="UTF-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Perpetuum DEV Blog</title>
		<link>http://blog.perpetuum-online.com/</link>
		<description>Perpetuum Developer Blog</description>
		<language>en-us</language>
		<docs>http://feedvalidator.org/docs/rss2.html</docs>
		<lastBuildDate>Wed, 15 Jul 2026 09:04:56 +0200</lastBuildDate>
		<copyright>Copyright 2007-2026 Microsystem Gaming Solutions </copyright>
    <atom:link href="http://blog.perpetuum-online.com/tag/insight/?rss" rel="self" type="application/rss+xml" />
		<ttl>60</ttl>

		<item>
			<guid isPermaLink="false">perpetuumdevblog-62</guid>
			<link>http://blog.perpetuum-online.com/posts/2012-12-29-the-future-research-assignments-instances/</link>
			<title>The future: research, assignments, instances</title>
			<description><![CDATA[<p>
The end of the year is near and we’d like to offer you some insight on <b>what’s going on around Perpetuum</b>, 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.
</p>

<a name='Behind_the_scenes'></a>
<h3>Behind the scenes</h3>

<p>
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.
</p>

<p>
For one, we’re of course getting ready to release Perpetuum on <a href='http://steamcommunity.com/sharedfiles/filedetails/?id=92921690' target='_blank' class='external'>Steam</a>. 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.
</p>

<p>
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.
</p>

<p>
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.
</p>

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

<p>
<b>We’ve chosen three large systems</b> 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.
</p>

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

<a name='Research_revamp'></a>
<h3>Research revamp</h3>

<p>
<b>What’s wrong with the current system?</b>
</p>

<ul>
<li> <b>Random research results are not fun.</b> 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.</li>
<li> <b>There are too many types of kernels.</b> 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.</li>
<li> <b>Corporations are not a part of the system at all.</b> 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.</li>
<li> <b>Research has much more potential.</b> Why waste it simply on prototyping, a feature used by not many players?</li>
</ul>


<p>
<b>The new system:</b>
</p>

<ul>
<li> <b>Point-based.</b> 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.</li>
<li> <b>Choose your research goals.</b> 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.</li>
<li> <b>Reduce the number of kernels</b> 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.</li>
<li> 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. <i>(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.)</i></li>
<li> <b>Separate knowledgebase for individual agents and agent-independent knowledgebases for corporations.</b> 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.</li>
<li> 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.</li>
<li> <b>Here’s the twist:</b> having the same item researched in your own knowledgebase AND in the knowledgebase of your corporation as well will provide a <b>factory production bonus</b> for you. We think this provides an incentive to develop both knowledgebases, your own and your corporation’s as well.</li>
</ul>


<p>
<b>So what will happen to your current knowledgebase</b> when this gets into the game? Well it will be wiped of course and you’ll have to start over, <a href='http://www.nelson-haha.com/' target='_blank' class='external'>ha-ha</a>. 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.
</p>

<p>
Some of you have been also wondering what happened to the promised <b>new tier of items</b> 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.
</p>

<a name='A_new_assignment_system'></a>
<h3>A new assignment system</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
So we’ve been planning a <b>complete revamp of the system</b> for a while now, and unlike in the case of research, <b>randomness</b> could be our friend here. This is a huge undertaking, and luckily we can separate it down into <b>two stages</b>: 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.
</p>

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

<p>
Once you click a button in this grid, you’ll be assigned a <b>random assignment</b> 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.
</p>

<p>
So this random assignment provider would be the first stage. The <b>second stage</b> is where we also randomize the objectives within the assignments. This system is still heavily under development, but it would use <b>assignment templates</b>, 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 <b>small assignment terminals</b> around the islands, so you will be able to take them there too and not just in the big bases.
</p>

<a name='Assignments_in_squads'></a>
<h3>Assignments in squads</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
We had a little <a href='http://forums.perpetuum-online.com/topic/5671/poll-squad-assignments/' target='_blank' class='external'>poll on the forum</a> 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.
</p>

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

<a name='Instances'></a>
<h3>Instances</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
What we definitely <b>don’t want is to drain population</b> 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.
</p>

<p>
However there are a number of features and mechanics where we just <b>simply can’t go around instances</b> 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.
</p>

<p>
This is especially <b>critical for a new player</b> - 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 <b>we’ll use instances for our tutorials</b>, 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.
</p>

<p>
Of course it would be a waste of technology to use instances only for a tutorial. <b>It holds many possibilities</b>, 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.
</p>

<a name='Closing'></a>
<h3>Closing</h3>

<p>
That’s pretty much all I have for you right now. These are the features that we’ll be working on in the <b>next 2-3 months</b>, 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.
</p>

<p>
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.
</p>

<p>
Post your opinions and questions below, or feel free to create separate feature discussions on the forums, and last but not least, <b>we wish a Happy New Year to all of you!</b>
</p>
]]></description>
			<pubDate>Sat, 29 Dec 2012 13:17:15 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-51</guid>
			<link>http://blog.perpetuum-online.com/posts/2012-04-26-industry-remixed/</link>
			<title>Industry, remixed</title>
			<description><![CDATA[<p>
Following on the trails of the massive three-part series about structure networks, today we’ll dive into the scary depths of <b>industry</b> and make an attempt at explaining why it was necessary to <b>turn it upside down</b>. Be warned: it’s long and there is some heavy number-crunching ahead, but luckily there is a <i>tl;dr</i> at the end.
</p>

<a name='Mineral_field_and_geoscanning_changes'></a>
<h2>Mineral field and geoscanning changes</h2>

<p>
As mentioned in the <a href='http://blog.perpetuum-online.com/posts/2012-02-15-the-road-to-pbs-terraforming/' target='_blank' class='external'>first PBS blog</a>, we’re changing the current fixed position mineral fields to <b>random spawns</b>, where the fields won’t get “refilled”, but new fields will appear instead, once the current ones are depleted. The change is first and foremost required due to the new terraformable gamma islands, because fixed mineral fields would interfere with the nature of free terraforming.
</p>

<p>
However, we’re doing this not only on gamma islands, but on all alpha and beta islands too. The only difference is that on alphas and betas new mineral fields can only spawn on passable terrain, but on gammas they can spawn anywhere on the island, and you will have to terraform your way to them (this is a change since the terraforming blogpost). Our intention with this is to make the process of <b>scanning for minerals more meaningful</b>, maybe even to the point of turning it into a profession in itself, as opposed to the current system where you just need to find and map out all the fixed mineral fields and return to them like they were some kind of candy dispensers.
</p>

<p>
Now, with the need for constant geoscanning for new fields you may think that it would be a very tedious task with the available tools, and you’re right. That’s why we’re replacing area-based geoscanner charges with brand new <b>directional scanning</b> charges. These will show you the direction to the nearest tile holding the charge-specific mineral, but not the distance. It’s somewhat similar to artifact scanning, but it will require different tactics. Notice I wrote “nearest tile”: it’s equally possible that it will guide you to a tiny residue, or to a tile which is part of a large field. Once you’ve found your spot, you can use the good old tile-based scanner to find out whether you hit the jackpot or not. In the long run, this system will require miners to do a “clean job”, as randomly scattered residual spots will soon make directional scans less and less efficient.
</p>

<p>
This ties into the generation of new mineral fields: the system periodically checks the overall amount of minerals on each island, and if this gets under a certain threshold value, a new mineral field will be generated in a random spot. However, if the mineral map of an island gets too much fragmented by haphazard mining practices, the spawning of new fields will probably slow down, since the overall mineral amounts will be there, but scattered all around the island in lots of low-yield tiles.
</p>

<p>
We’re also changing the mining process itself: the current method of storing “mining cycles” in ground tiles will be converted to a more straightforward system. Tiles will hold the <b>exact amount of minerals</b> you can get out of them, so there won’t be a “loss” of minerals when someone with less advanced equipment or extensions mines them; he/she will just simply extract less over time, without wasting any potentially minable minerals during the process.
</p>

<a name='New_minerals.2C_factional_redistribution'></a>
<h2>New minerals, factional redistribution</h2>

<p>
So far there hasn’t been much difference in the availability and usage of minerals and commodities among the three factions. Of course we’ve tried to make specific minerals more abundant than others, but this was a fragile balance, as the components used for manufacturing didn’t have such separation among the faction technologies. With the coming expansion we’re taking a big step to <b>stir up this uniformity</b>.
</p>

<a name='Factional_differences_for_raw_minerals'></a>
<h3>Factional differences for raw minerals</h3>

<p>
Each of the three factions will have <b>one distinct mineral</b> that is representative in their specific technology. For Pelistal this will be Silgium, a brand new minable raw mineral, for Nuimqol it’s Imentium, and for Thelodica it’s Stermonit.
</p>

<p>
Titan and HDT will have a role as common basic minerals used by all factions, and <b>Titan will be reinstated to Beta</b>, but these two will be still more abundant on Alpha islands.
</p>

<p>
In the high-end mineral department, Epriton and Noralgis will be accompanied by a <b>new mineral available only on gamma islands</b>. At first this will be used for building higher tier PBS structures, but in the future it will be required for new robots and equipment as well.
</p>

<p>
Furthermore, faction-specific minable and harvestable minerals will be distributed in a way that each faction will have certain minerals that are <b>not available</b> on their islands, at all. The aim of this system is to stimulate trade and transport between islands, while avoiding monopolies. This is how it looks:
</p>
<ul>
<li> Silgium and Triandlus: available on Pelistal and Thelodica islands, but not present on Nuimqol islands</li>
<li> Imentium and Helioptris: available on Nuimqol and Pelistal islands, but not present on Thelodica islands</li>
<li> Stermonit and Prismocitae (yes, it’s finally harvestable): available on Thelodica and Nuimqol islands, but not present on Pelistal islands</li>
</ul>


<a name='Commodity_types_and_component_diversity'></a>
<h3>Commodity types and component diversity</h3>

<p>
Of course if we differentiate raw minerals this way, we also need to do the same for the commodities that they are refined to, and consequently it will be also reflected in the equipment they are used in.
</p>
<ul>
<li> Common basic commodities: Titanium, Plasteosine, and 2 new commodities</li>
<li> Nuimqol specific: Statichnol, Chollonin, Polynitrocol</li>
<li> Thelodica specific: Metachropin, Prilumium, Polynucleit</li>
<li> Pelistal specific: Isopropentol, Vitricyl, Phlobotil</li>
<li> High-end components I. (epriton based): Briochit, Alligior, Espitium, Hydrobenol</li>
<li> High-end components II. (gamma mineral based): 4 new commodities</li>
</ul>


<p>
Commodities will also get <b>categorized by their role</b> in manufacturing. This can be either basic component, offensive/weaponry component, defensive/armor component, or electric/energy component. Besides bringing more immersion into the game, this should also make it easier to remember what components you generally need for a type of module, and it should also help industrialists in specializing in a specific type of equipment. Both faction and type will be displayed on the icon of commodities.
</p>

<p>
All this juggling with the components has the consequence that pretty much every robot and module will require <b>completely different commodities</b> compared the current setup on the live server. We did this in a way that the final price of things generally shouldn’t be too much different than what you’re used to, but be aware that <b>there will be some changes</b>. There is an intended “trend” too, namely that robots will require slightly more materials than before, and modules slightly less.
</p>

<p>
Is your head spinning yet? Well we’re not stopping here, it’s time for some <i>Hungarian Maths™</i>!
</p>

<a name='Recalculating_the_industry_-_the_new_facility_point_system'></a>
<h2>Recalculating the industry - the new facility point system</h2>

<p>
One major issue with how the current industry in Perpetuum works is its rather <b>bad scaling</b>: novice manufacturers have a very hard time keeping up with veteran industrialists, and the main reason for this is the <b>tremendous gap</b> between their efficiency. This makes it near impossible for beginners to have at least a small chance at providing goods at competitive prices.
</p>

<p>
Of course, experienced manufacturers with high-tech facilities and tools should always keep their leading edge, but we’d like to <b>lessen that efficiency gap</b> and at the same time make the entry into the industry a <b>less painful</b> experience.
</p>

<p>
This is where our newest obsession comes into picture, convergent functions, or the term you’re probably more familiar with: <b>diminishing returns</b>. (I say obsession because it’s something we plan to apply to various other parts of the game in the future as well.)
</p>

<p>
Simply speaking, we’re turning <b>all the facility-related calculations</b> into the same point based <b>diminishing</b> system like the way armor resistances work for robots. Facility base efficiencies, your related extensions, your faction relation, etc. will all have a point equivalent and the sum of these points will be your final efficiency. Like in the case of armor resistances, this point value can be converted into a percentage value, which will always converge towards 100% efficiency, but it will <b>never reach it</b>. And similarly, the more efficient you are, the more harder it will be to improve on it.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_facilitypoints.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_facilitypoints.png" alt="Production point and facility efficiency graphs" title="Production point and facility efficiency graphs"/></a></div>

<p>
The graph on the right should help you understand it better. When accumulating production points (horizontal axis), it’s relatively <b>easy to reach a good efficiency</b>, but it will gradually get harder to really stand out. Factory efficiency for example starts at 150% time and material needs (compared to “perfect” efficiency), and closes to 100% from upwards. The recycling plant’s efficiency starts at 25%, and the more it closes to 100%, the more commodities you will get from items. The money you have to pay at the repair shop begins at 75% and converges to 0%, but will never reach it.
</p>

<p>
The system makes the current level-classification of facilities obsolete, as their efficiency will be measured in production points from now on. For “fixed” (NPC controlled) alpha and beta terminals this won’t make a real difference, but in the case of gamma islands where you can attach any number of facilities and facility upgrades to the main terminals, it can be any number in between (and over!) the old level equivalents, too. Of course these points will still be displayed in the terminal information windows, so you can easily compare them from anywhere in the world.
</p>

<a name='CTs_and_production_in_the_new_system'></a>
<h3>CTs and production in the new system</h3>

<p>
Calibration templates (CTs) deserve their own paragraph here: their efficiency will be also measured in production points, but the hard limit we had at 100% in the old system is completely gone. The point system makes this possible, because as I explained earlier, the overall production points “thrown” into the pipeline can be quite a lot, but your calculated efficiency still won’t ever reach 100%.
</p>

<p>
Since the limit for improving CTs doesn’t exist anymore, you will be able to combine CTs in the new gamma-only calibration complex (mentioned in the <a href='http://blog.perpetuum-online.com/posts/2012-03-31-the-road-to-pbs-islands-building-types-and-control/' target='_blank' class='external'>3rd part of the PBS blog</a>) infinitely. But remember that it’s only production points what you’ll be combining there - the final efficiency in the factory will always boil down to something less than 100%. This also means that there will be a point where combining two CTs will gain you such a small efficiency increase that it won’t be worth to do it any further.
</p>

<p>
The <b>production point system</b> also has a nice peculiarity: since efficiencies start to get better already at lower point values, it’s enough to have a really good CT to reach satisfactory results even without access to high-level facilities. Similarly, if you have very good industrial extensions, you can get away with mediocre CTs and facilities, and so on. But the important part is that there will always be some <b>room for improvement</b>.
</p>

<p>
The manufacturing process itself will also change a bit. First off, <b>factories</b> will not just provide a boost to production times, but they will again have their <b>own material efficiency bonuses</b>. Second, the currently separated cycle and quantity in the factory will be merged into one, and CTs will be degraded with every item production cycle. To compensate for this, CTs will degrade much less in these cycles, and we have also boosted the extension that controls the maximum number of manufacturable items in one slot at a time to 10 per level (so 100 at level 10).
</p>

<p>
There are still a lot of small details I didn’t cover, but this is already getting too long again, and we’ll also happily answer any specific questions in the comments below, should you have any.
</p>

<a name='But_wait.2C_there_is_more'></a>
<h2>But wait, there is more</h2>

<p>
Still, there are two things that are not directly industry-related, but they are important enough to share with you.
</p>

<p>
One. <b>Scarab Mk2.</b> 900U cargo space. Needs gamma minerals to build.
</p>

<p>
Two. <b>Navigation extension is dead.</b> Since speed is such an important aspect of the game, it has always been a must-have extension for everyone, which is bad game design practice. It will get removed and everyone will have “level 10” by default.
</p>

<a name='TL.3BDR'></a>
<h2>TL;DR</h2>

<ul>
<li> Fixed mineral spawns replaced by random fields</li>
<li> Area scanning replaced by directional scanner</li>
<li> Minerals, commodities, and components redistributed among factions, with the intention of creating diversity and inducing trade and transport</li>
<li> New gamma-only mineral and commodities used for PBS and future stuff</li>
<li> Production point system - completely new industry calculations using diminishing returns, for lessening the gap between beginner and veteran industrials, while still retaining the possibility for the “leading edge”</li>
<li> Scarab Mk2 \o/</li>
<li> Navigation extension gets removed, everyone will have full speed by default</li>
</ul>


<p>
<b>Oh, I almost forgot:</b> all of this will come together with Player-Built Settlements, and as most of it is already done, you'll be able to test it on the <b>public test server soon</b>.
</p>

<p>
<i>I like that word.</i>
</p>
]]></description>
			<pubDate>Wed, 25 Apr 2012 19:10:40 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-50</guid>
			<link>http://blog.perpetuum-online.com/posts/2012-03-31-the-road-to-pbs-islands-building-types-and-control/</link>
			<title>The road to PBS: Islands, building types and control</title>
			<description><![CDATA[<p>
Welcome to the third and final instalment of our blog series showcasing the upcoming <b>Player-Built Settlements (PBS)</b> system. This part will tell you about the new island layout, the various building types and their purpose, and the concept of control and assimilation. If you haven’t read the first two parts, it’s highly recommended to do so, in order to better understand the things I’m about to explain here. The first part about terraforming is <a href='http://blog.perpetuum-online.com/posts/2012-02-15-the-road-to-pbs-terraforming/' target='_blank' class='external'>here</a>, and the second one about building and planning is <a href='http://blog.perpetuum-online.com/posts/2012-03-01-the-road-to-pbs-building-and-planning/' target='_blank' class='external'>here</a>.
</p>

<a name='24_new_islands_to_explore_and_live_on'></a>
<h2>24 new islands to explore and live on</h2>

<p>
There’s been a lot of speculation going on on the forums about how many new islands there will (or should) be. Some said an absolute minimum of 12, some argued we shouldn’t stop under a few hundred :)
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_gammanetwork.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_gammanetwork.jpg" alt="The new teleport network layout" title="The new teleport network layout"/></a></div>

<p>
While we’d love to have the latter number in the future, for now we have settled for <b>24 new terraformable gamma islands</b>. We feel that this should provide ample space for our current and anticipated playerbase without creating a vacuum. Of course we’ll be ready to add even more islands in the near future if the demand arises.
</p>

<p>
We’re not only adding new islands, we’re also <b>revamping the entire connection network</b> of the current alpha and beta ones. Some of you have voiced your concerns, and we also feel that the current teleport network is so dense that it makes the world feel rather small. Being able to jump quickly from one end to the other also renders any kind of long-range transport routes near obsolete. The same is true for living on beta islands, with the main trading hubs (currently the alpha terminals) being just a few minutes away.
</p>

<p>
The basic concept and the reasons for the the new layout:
</p>
<ul>
<li> <b>Less complex teleport network:</b> can’t reach “anything from anywhere”, gives individual islands more importance and makes them more unique.</li>
<li> <b>Breaking up the Alpha 1 triangle:</b> factions get more meaning, and the trading of faction-specific items should be more induced (this will be complemented by further industrial changes, details in the next blog).</li>
<li> <b>Inserting Alpha 2 between Alpha 1 and Beta islands:</b> this is intended to give Alpha 2’s a middleground role between the starting haven Alpha and the total hell that are the Betas. Alpha2’s have higher level NPCs, and those venturing there should already be aware of the dangers that Betas hold.</li>
<li> <b>Strategic variance in Gamma island connections:</b> we have both relatively easily reachable islands with many entry points, and hard to reach “hinterland” islands with more defendable entries. We’re very curious which ones will be more craved for, and how they will be used.</li>
<li> No island with only one entry point by design.</li>
</ul>


<p>
We also intend to create an <b>unlock mechanism</b> for opening the new islands, so they won’t be available from the get-go, and we’d also like to provide certain exploration rewards for the first pioneers. We’re still looking at our options on how exactly this will work, so I’ll get back to you with the details as soon as it’s settled.
</p>

<a name='The_structure_network_planner'></a>
<h2>The structure network planner</h2>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_networkplanner.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_networkplanner.jpg" alt="The structure network management and planning interface" title="The structure network management and planning interface"/></a></div>

<p>
I have already shown you a crude concept of the <b>network planner</b> in the previous post, and before I start with the explaining of various building types, I’d like to show you our progress on it. As you can see, it all happens on a new tab in the world map window, and it’s available when you’re inside a terminal or out on the terrain, too. One grid cell in the planner is equivalent to one tile on the terrain, so buildings are shown accurately as they occupy an area.
</p>

<p>
Types of buildings are mainly identified by their icons and their size, but there is also the optional name-tag, and you can even rename any of them. You can also select an individual building to bring up an information panel with all its parameters and settings. We have a number of connection types between buildings (energy, control, booster, etc.), each of them having a specific shape and color for easy overview.
</p>

<p>
Building plans are displayed just like completed buildings, but in purple color. There are various options to help you in planning your network, the proper connection distances and validating the terrain where you intend to deploy a building. As said, it’s a fairly complex system and I could go on forever but I’d rather continue with the rest of the features. You’ll be able to read all about the details in the game guide and test it yourself :)
</p>

<a name='Building_types'></a>
<h2>Building types</h2>

<p>
As you already know, the basic concept of <b>PBS</b> is a <b>network of interconnected buildings</b>. There are a number of building types, each of them having a special role within a structure network. In this section I will tell you a few details about each of them, and I hope this will help you get the big picture on the whole system. There is one important fact to remember while looking at the list: structure networks are limited by the number of <b>connection slots</b> of each building in the network, and by the balance of generated and consumed <b>energy</b>. Note that names can still change and some of the more specialized buildings may not make it into the first PBS patch.
</p>

<a name='Main_terminal'></a>
<h3>Main terminal</h3>

<p>
The central hub of your network, everything starts and ends with it. You can dock into it, equip your robots and store items, just like in any other NPC terminal. It doesn’t need any upkeep or energy to work - once built, it will stay there until someone destroys or deconstructs it. (Oh yes, it will be possible to deconstruct your buildings.) The main terminal comes in three different sizes, varying in number of connection slots, amount of HP, and physical size.
</p>

<p>
Another important role of the main terminal is that it provides ownership, or in other words, broadcasts <b>control</b> to all its connected buildings, which in turn further broadcast it to their connections and so on. If a building loses the chained control link with your network, it stops providing whatever its role is and you won’t be able to change its parameters until you regain control of it. More importantly, it’ll become open prey for an enemy network to “assimilate” it.
</p>

<a name='Control_tower'></a>
<h3>Control tower</h3>

<p>
Like the name suggests, control towers <b>broadcast control</b>, and they can do this through relatively large distances. They can be used to create watchposts or mining outposts far from the core of your network and your main terminal. Control towers themselves do not need energy to operate, however they don’t transfer it either, so you need to build a reactor at your outposts too, in order to operate the surrounding buildings.
</p>

<p>
Control towers also function as <b>defensive bastions</b>, which I will explain further in the control and defense section.
</p>

<a name='Reactor'></a>
<h3>Reactor</h3>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_powerplant.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_powerplant.jpg" alt="Reactor" title="Reactor"/></a></div>

<p>
Reactors provide the necessary <b>energy</b> for your buildings to operate. They work very similar to a robot’s accumulator, but since they’re much bigger, they are also much slower regarding recharge (think days here). Like robot accumulators, they also have their peak recharge potential at 50%. However, a deployed reactor starts with 0 energy, thus the recharge starts out very slow, and if you connect many consumers to it at this point, it will never “kick in”.
</p>

<p>
There is also a quicker but more costly way of generating energy in your reactor: by <b>fueling</b> it with certain commodities, like vitricyl or prilumium. You can use this method if your reactor or reactors can’t provide the necessary amount of energy for your network, or if you want to kickstart a newly built reactor. Reactors can also be fed from other reactors, so if you already have a working energy network (with the necessary surplus energy), starting a new reactor should be easier too.
</p>

<a name='Energy_transfer_nodes'></a>
<h3>Energy transfer nodes</h3>

<p>
These little nodes are used to <b>transfer energy</b> from the reactors to all of the consumer buildings. They have a certain cycle time for this, so energy propagation through the network takes some time. There is also a little bit of energy loss when it goes through them, so taking energy via a long chain of nodes will “leak” a small but notable amount on its own.
</p>

<p>
Energy transfer nodes come in two sizes: the <b>large</b> one can transfer large amounts of energy per cycle, and they have bigger connection ranges (can be linked together from further away), but have only a few connection slots. These are intended for your main energy lines, the “backbone” so to say. Then there are the <b>small</b> transfer nodes, which are pretty much the opposite: small throughput, small connection ranges, but more connection slots. These will be your endpoint distributors.
</p>

<a name='Standard_facilities'></a>
<h3>Standard facilities</h3>

<p>
Basic main terminals don’t include any industrial facilities, you have to get the DLC for them. What this means is that you need to build the factory, the prototyping facility, the refinery and all the other individual facilities, and connect them to your terminal; only then will they appear in its facility menu. The trick here, of course, is that the main terminal has a limited number of inward connections.
</p>

<a name='Facility_upgrades'></a>
<h3>Facility upgrades</h3>

<p>
Facilities have low efficiency on their own, but luckily we have facility upgrades to boost just that. Naturally, the increased energy consumption will not make it as easy as it sounds.
</p>

<a name='Special_facilities'></a>
<h3>Special facilities</h3>

<p>
We’ll introduce two brand new facilities, which will only be available to be built on gamma islands. One is the <b>Calibration complex</b>, which will let you combine calibration templates of an item to get a higher efficiency CT. The other is the <b>Decoder forge</b>, and as you can probably guess, it will combine lower level decoders to provide you with a higher level one.
</p>

<a name='Defensive_turrets'></a>
<h3>Defensive turrets</h3>

<p>
Your trusty watchdogs when you’re not home. They hit hard, and they hit far. In their current implementation they work with pure energy, but later on we might convert them to ammo-consuming beasts too, so you can chose your damage type.
</p>

<p>
There are three basic types: <b>EM turrets</b> have the highest dps, <b>missile turrets</b> have very long range and have the highest burst damage, and <b>laser turrets</b> are the most accurate at the cost of damage.
</p>

<a name='Mining_tower'></a>
<h3>Mining tower</h3>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_miningtower.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_miningtower.jpg" alt="Mining tower" title="Mining tower"/></a></div>

<p>
The name may be deceiving, as it’s not something that does the work while you’re not there. Instead, it works as an aura to <b>allow you to exploit a new type of mineral</b>, available only on gamma islands. This new mineral will be used to manufacture <b>higher tier buildings</b>.
</p>

<a name='Masker'></a>
<h3>Masker</h3>

<p>
Provides a masking aura for the robots in its range, making them harder to detect for other robots. Has no effect on buildings.
</p>

<a name='Repair_nodes'></a>
<h3>Repair nodes</h3>

<p>
These can be connected to any building and they will automatically start repairing any damage done to them, provided they have enough energy to do so.
</p>

<a name='Booster_nodes'></a>
<h3>Booster nodes</h3>

<p>
Currently, booster nodes can have either of the following functions: reduce the cycle time of turrets, increase the range of turrets, or increase the armor resistance of any building. Once you have a working booster node, you can simply select which one of those functions they should provide, and you can change this any time later on too.
</p>

<p>
As said, not all of these may make it in the first round, and we still have more ideas, for example solar panels which generate energy depending on the time of day.
</p>

<a name='Control.2C_defense_and_capture'></a>
<h2>Control, defense and capture</h2>

<p>
As I mentioned above at the main terminal details, <b>control linking</b> is a very important aspect of holding your network together. If you build parts of your network in a way that they depend on a <b>single junction point</b>, it will easily become a <b>weak spot</b> that you’ll have a hard time defending, even if you surround it with turrets of doom. When you lose such a junction point, you risk losing control of entire parts of your network, together with any connected defensive buildings, so <b>redundancy will be pivotal</b> in planning a solid network.
</p>

<p>
It’s not just a matter of losing control, but you may even find that the neighboring network snatched away your buildings. Such <b>assimilation operations</b> will be entirely possible: if there are any “orphaned” buildings in the connection range of your own network, which noone has control over, you can simply connect them to one of your buildings and they will start working for you.
</p>

<p>
Of course, losing parts of your network is one thing, but losing your main terminal with all your assets in it can be disastrous. Thinking about various <b>defense mechanisms</b> that allow you to get some sleep while not worrying to lose your main terminal made me write <a href='http://forums.perpetuum-online.com/post/62887/#p62887' target='_blank' class='external'>this</a> post on the forums. While the idea of making the main terminal invulnerable as long as any other building is connected to it sounded good at first, it also made us realize that it makes a capture mechanism near impossible. If you have to destroy everything first in order to break control, there won’t be anything left to capture. This is especially true for the expensive high-efficiency facilities, which are connected directly to the main terminal, with no way to break control other than destroying the terminal itself.
</p>

<p>
We also tried to avoid any timer mechanisms, but in the end there is no way we can control the number of players attacking a base, and there needs to be some kind of solid attack window that you can count on as a defender.
</p>

<p>
So the final concept of the main terminal defense mechanism looks like this: as I mentioned above, control towers function as bastions, which means <b>if at least one control tower is connected to it, the main terminal is invulnerable</b>.
</p>

<p>
Once there are no control towers connected to the main terminal, you can start shooting it. When its armor reaches 50%, its <b>emergency shielding</b> activates, and once again it becomes invulnerable. This state lasts for <b>3 days</b>, plus an optional 0-24 hours that the owner can set before it gets into emergency state. This makes sure that the <b>defenders can set their own time</b> of day when the terminal comes out of its emergency state, and becomes vulnerable. Once an emergency phase ends, it cannot be activated for <b>4 hours</b> - that’s the window when the attackers can finish it off. The time when the emergency period ends can be <b>scanned</b> the same way you can scan for outpost intrusion times.
</p>

<p>
The combination of these two mechanisms should make sure that a lone terminal can’t be lost overnight, but it also makes sure that complex networks with many control towers and extensive defense systems will be much harder to take down, and then some more.
</p>

<a name='It.27s_the_little_things'></a>
<h2>It's the little things</h2>

<p>
Besides giving you the possibility of building your own empire, we're also trying to add in some little extras that will make you stand out, and let you feel home. One of these things is that every corporation will be able to set a <b>signature color</b>, and this will be used for all the owned buildings' tint stripes, as well as the terminal inside background color.
</p>

<p>
Furthermore, what is an empire good for if you can't show it off? From the beginnings already, we really wanted to show territories in some way. Now with PBS, the occupied area of buildings finally provides a way to actually <b>make your territory visible on the world map</b>. We're aware that this is not something everyone would like, since it obviously gives away some strategic information, even though no individual buildings will be visible, just a colored "blob" (which also uses the color mentioned above). So this feature will be <b>optional</b>, CEOs can decide whether they want to show off or not.
</p>

<a name='We_need_your_help'></a>
<h2>We need your help</h2>

<p>
By now you should probably have a rough idea of the sheer complexity of this system. Since we are still merely a group of 10 people, it would be pretty much impossible for us to test it on our own. The outcome would most likely be an unbalanced patch, crawling of nasty bugs.
</p>

<p>
We have already set up a separate <b>test server</b> and as soon as we are finished with all the features, you’ll be able to come and fiddle with terraforming, planning and building before we deploy it to the live server. How and when exactly this will happen will be <b>announced soon</b>, stay tuned.
</p>

<p>
Well, I think <b>that’s about it</b> regarding the basics of PBS. Of course I’ll try to answer any questions, and I’m sure you have a few of those.
</p>

<p>
<b>In the next blog</b> I will tell you the tale of how we turned the industry upside down, to the extent that we probably should call it <b>Industry 2.0</b>.
</p>

<p>
<i>I love cliffhangers.</i>
</p>
]]></description>
			<pubDate>Sat, 31 Mar 2012 10:47:54 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-45</guid>
			<link>http://blog.perpetuum-online.com/posts/2012-03-01-the-road-to-pbs-building-and-planning/</link>
			<title>The road to PBS: Building and planning</title>
			<description><![CDATA[<p>
Hello everyone, we’re back with the second part of the <b>Player-Built Settlements</b> show, please take your seats. In the <a href='http://blog.perpetuum-online.com/posts/2012-02-15-the-road-to-pbs-terraforming/' target='_blank' class='external'>first part</a> we have taken a look at how you can terraform a suitable place for your buildings. This time we’ll see how the <b>building process</b> itself looks like and how you will be able to plan a <b>network of interconnected structures</b>. Please note that some of the details discussed here can still change as we are closing to completion and start the testing process.
</p>

<a name='Acquiring_buildings'></a>
<h3>Acquiring buildings</h3>

<p>
The basic line of standard Syndicate-issued buildings will be available directly from the market. However, the Syndicate will also provide the option to relieve itself from the tedious task of manufacturing these buildings, so every corporation will be able to acquire the knowledge to <b>manufacture them</b> on their own as well. This will be achievable via new special kernels, available from Syndicate Supplies for either assignment tokens, or special artifact items. (These artifacts will be available throughout all islands.)
</p>

<p>
Later on we’ll also introduce <b>higher tier buildings</b>, but manufacturing those will need a <b>new type of mineral</b>, available only on gamma islands - more on this in an upcoming industry-themed blog.
</p>

<a name='Starting_a_settlement'></a>
<h3>Starting a settlement</h3>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_large_pbs_base.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_large_pbs_base.jpg" alt="Large player-buildable main terminal" title="Large player-buildable main terminal"/></a></div>

<p>
<b>PBS</b> will work in a <b>network system</b>, and every one of them will have to start with a central control node, the main terminal. All other buildings will have to be connected to the main terminal via an energy link or a control (~ownership) link - more on this a bit later.
</p>

<p>
So let’s say you have the <b>building blueprint</b> item for your first gamma terminal in your cargo. You pick a nice spot on one of the gamma islands, and start to terraform the area to be suitable for building (if necessary). To save you from insanity, buildings won’t require perfectly even areas for building; small slopes below a certain threshold will work too.
</p>

<p>
There will be a few no-build areas, e.g. around teleports, but currently we have no other limits planned for placing main terminals. The only limit regarding them is that <b>one corporation</b> can only have <b>one active main terminal per island</b>. The activation/deactivation and unattended defense mechanisms (the usual timezone issues) are still being worked out, but our aim is to prevent multi-headed dragons, i.e. redundant networks that are very hard to destroy, while still allowing relatively easy upgrading of your central terminal.
</p>

<a name='The_building_process'></a>
<h3>The building process</h3>

<p>
Once you’ve found the right place for your main terminal, you simply deploy the blueprint item from your cargo. This will place a kind of holographic version of the building onto the tile you’re standing on, and at the same time, push you and everyone else out of its construction radius. (Construction radius is an outline area around all buildings, and no two can overlap each other. This prevents building very dense and impenetrable settlements.)
</p>

<p>
After the blueprint is out anyone can start building it, this is not limited to the owner corporation’s members. Construction is done with <b>building modules</b> equipped on their robots, which use <b>building charges</b> available from the market, but they are also manufacturable (this part is still heavily under discussion). Any number of Agents can help in the completion, the goal is to reach a certain number of building cycles until it’s finished.
</p>

<p>
When the building is complete, it’s still <b>offline</b> and it has to be brought <b>online</b> to be operational, and this is something only the owners can do. The main terminal is a special building in this regard, because it can be activated on its own. However all other buildings will need to be <b>connected to the main terminal</b> before they can be brought online.
</p>

<a name='The_main_terminal'></a>
<h3>The main terminal</h3>

<p>
In case it’s not evident for everyone, I must stress that <b>you can enter a player-built main terminal</b> just like any other NPC terminal. So once your terminal is finished and online, you can hop in, store your stuff, or equip your robot. The available base facilities include private and corporation storages with all their features, robot equipment, the market, and robot insurance. All other <b>facilities</b> like the factory or the repairshop need to be built as <b>separate structures</b> and connected to the main terminal.
</p>

<a name='The_reactor'></a>
<h3>The reactor</h3>

<p>
However, nothing works without <b>energy</b> (the only exception being the main terminal), so the next thing you want to build will be a <b>reactor</b>. This is a separate building, but you can’t just place it anywhere. Apart from the terraforming requirements, all your buildings need to be in the <b>control range</b> of another owned building, and for your second building this means the main terminal. (Well, that’s only half true: you can place your buildings anywhere, but you won’t be able to connect and activate them if they are not in range.)
</p>

<p>
The <b>control links</b> will generally also mean an <b>energy link</b> at the same time, but since the reactor is the building which is generating the energy in the first place, it will only need a simple control link.
</p>

<a name='Planning_your_empire'></a>
<h3>Planning your empire</h3>

<p>
So now you have a main terminal, and a connected reactor, generating energy (not for free, mind you). This is when things will start to become complicated and the need emerges for some delicate <b>planning</b>.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_pbsguimockup.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_pbsguimockup.png" alt="Mockup of PBS planner and maintenance window" title="Mockup of PBS planner and maintenance window"/></a></div>

<p>
Granted, planning and maintaining an extensive network of buildings just by walking around it on the terrain would be a tad difficult, so we’ll introduce a new <b>schematic map</b> into the world map window, intended specifically for this task. The picture you see on the right is a crude mock-up of how the layout will look like, the final design will be of course much prettier.
</p>

<p>
The left main area is where the planning will happen. Not only that, but here you will be able to <b>connect your buildings</b> and watch over their health and energy levels as well.
</p>

<p>
The planning process itself will be somewhat like a puzzle (in the better sense of the word). You grab a building plan on the right, and drag it onto the grid. The grid represents ground tiles, so when you place a building plan, it will snap to this grid. When you’re satisfied with its position, you will need to finalize the plan, which will check whether it’s a suitable location regarding terrain, construction radius and all that stuff. At the same time it also places a <b>marker</b> onto the terrain, so you will know where to deploy what building blueprint. This way you will be able to make plans for an extensive network of structures before even laying a brick, and your crew can <b>work towards your goals</b> using the terrain markers.
</p>

<a name='Advanced_networking'></a>
<h3>Advanced networking</h3>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_pbsconnections.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_pbsconnections.png" alt="Example of a PBS network" title="Example of a PBS network"/></a></div>

<p>
The picture on the right is something DEV Alf has thrown together for your amusement. To be able to understand it, you have to know that every type of building will have a fixed number of inward and outgoing <b>connection slots</b>. A connection can be anything: a simple control or energy link, but it can also mean a functional link, like in the case of facilities connected to the main terminal. The important thing here is that all types of connections are using the same limits, and it will be up to you how you play them in order to have a logical and working network.
</p>

<p>
Since every building has limited connection slots, and because the area around the main terminal will soon become crammed, you will eventually need to use <b>energy transmitter nodes</b>. These buildings function like hubs: they <b>broadcast both control and energy</b>, but they too have limited connection slots. You'll even be able to set the energy priority for each node, so in case there is an energy shortage (because, say, someone destroyed one of your reactors), your critical buildings can remain operational. Our aim here is to provide you with basic building blocks and use your imagination and creativity to create extensive and efficient connection networks.
</p>

<p>
The picture also shows various other types of buildings, which I’m sure you’re eager to hear about, but unfortunately you’ll need to stick it out until the next part :) In that one we’ll have a look at all the building types you can create (even some never before heard facilities), and I’ll also try to explain why it will be good for you to own a gamma base in the first place.
</p>

<p>
Until then, let your anger or approving thoughts roam free in the comments or the forums.
</p>
]]></description>
			<pubDate>Thu, 01 Mar 2012 17:53:29 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-44</guid>
			<link>http://blog.perpetuum-online.com/posts/2012-02-15-the-road-to-pbs-terraforming/</link>
			<title>The road to PBS: Terraforming</title>
			<description><![CDATA[<p>
Many of you might have already heard bits and pieces about <b>Player-Built Settlements</b>, or <b>PBS</b> in short. As the name suggests, it’s our system which will allow players to create their own settlements, a place that they build with their own hands, shape to their own needs, and where they can really feel at home - basically <b>a system which takes our sandbox to a whole new level</b>. It’s a fairly complex system and we’ve been working on all the details for quite some time now. Today I’m happy to tell you that we have arrived at a point where we are confident enough to share our ideas with you.
</p>

<p>
Due to its complexity, this will be a series of blogs, likely at least a three-parter. We’ll start with terraforming, an essential feature and a prerequisite to building structures. Later on we’ll also take a closer look at the basic rules to building, and the various types of structures.
</p>

<a name='Gamma_islands'></a>
<h3>Gamma islands</h3>

<p>
Shaping the ground to your liking should be a fun thing to do, but I’m sure you understand we have to set up some limits. The current alpha (and to some extent, beta) islands have too many interconnected systems which could be easily disrupted if we would allow you to create hills and holes wherever you like. Since the world of Perpetuum feels still rather small, the most efficient and future-proof solution is to create <b>new landmasses</b> with their own set of rules. So before I <i>dig</i> into terraforming, let’s have a look at <b>gamma islands</b>.
</p>

<p>
When creating the concept of new islands, one of the main conditions we set for ourselves is that their time to completion needs to be improved considerably. Although even our current islands have been all started by procedural heightmap generation (which can be done in a very short time), in order for them to be ready and usable they needed a lot of manual work.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/devblog_gammaisland.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/600/devblog_gammaisland.jpg" alt="Terraformers, meet your canvas" title="Terraformers, meet your canvas"/></a></div>


<p>
With gamma islands, in many ways we have it a bit easier: we don’t have to worry about passability, since you are supposed to work on roads and paths with terraforming. We don’t really need to place decorational buildings either, that will be your job too. However, there is still the issue of mineral distribution and NPCs.
</p>

<p>
Currently all the mineral fields are hand-painted and fixed by location. This wouldn’t really work on a terraformable island, because they could easily get out of reach or be blocked by buildings. I think we have already hinted that <b>random mineral fields</b> are on our todo, and some of you have also suggested it on the forums. We already have a working version of it and it seems to work pretty well.
</p>

<p>
There was one interesting question regarding random mineral field placement - should it consider unreachable areas, or should we leave it to the players to terraform their way to the new fields? The latter sounds fun at first, but with time as players skim down hills to get to the precious fields, it would likely induce completely flat islands, which is... undesirable. It could also get a little frustrating if you already get the third epriton field in a row on top of Mount Doom. So, the current version of the mineral field generator neatly looks for passable areas and avoids tiles blocked by buildings as well. We think terraforming by strategic, construction or decorational purposes will give you enough work as they are.
</p>

<p>
An important thing to note here is that we will introduce <b>random mineral fields</b> not only to gamma islands, but <b>to every existing island</b> as well. Of course this will have the unfortunate effect that your current geoscan results will become obsolete, but we feel this will make the miners’ life much more interesting, and <b>give geoscanning a real function</b>. I’ll do a separate blog about this and other impending major industrial changes after the PBS series.
</p>

<p>
So, that should cover the mineral question, but what about NPCs?
</p>

<p>
As you can imagine, due to the ever-changing terrain, fixed spawn points would not be feasible. Even our current fixed-path roaming caravans could run into problems. This left us with the solution to have only <b>completely free roaming NPCs</b> on gamma islands, so Agents can experience the real wilderness there. Of course the spawn generator will have to check for passable and large enough areas so they don’t get trapped, but that’s pretty much the only limit for them.
</p>

<p>
In the end, random mineral fields and completely free NPC spawns should take off a lot of tedious configuration work from our shoulders, since we only have to set the type and amount of minerals on the island, the type and number of NPC spawns, and the island is pretty much a go.
</p>

<a name='Diggin.E2.80.99_up_Nia'></a>
<h3>Diggin’ up Nia</h3>

<p>
Now that we have covered <i>where</i> you can terraform, it’s time to see <i>how</i> you can do that.
</p>

<p>
The game has supported terraforming from the very beginnings, but so far it has only been a privilege to us devs. One issue that we had up until now was that terrain texture cover had to be regenerated after every modification of the terrain heightmap, in order to have rocky textures on steep walls, grass on plains and so on. This texture mask was then stored in a special bitmap, which had to be patched out to the live client. Even if we only modified one tile, we had to update the whole island’s map, so whenever you saw 100+ MB patches, it usually meant that we updated these maps.
</p>

<p>
But now that DEV BoyC is working on the complete <a href='http://blog.perpetuum-online.com/posts/2011-12-21-terrain-sneak-peek/' target='_blank' class='external'>revamp of our terrain-engine</a>, he could come up with a solution that allows for real time updating of terrain textures based on slope and elevation. This means that when you start to raise a mountain, the ground texture will gradually change from grassy to rocky, all in real time. Not to mention that we can scrap those old island texture masks too, and that means less memory usage, smaller patches, and a smaller datafile.
</p>

<iframe width="610" height="370" src="http://www.youtube.com/embed/DduYqCo3iYI?rel=0" frameborder="0" allowfullscreen></iframe>

<p>
<b>The terraforming process</b> itself will happen with help of a terraforming module of course, which will use different kinds of charges, depending on what you want to achieve. The basic <b>raise/lower</b> charges are self-explanatory, these will simply pull up or push down the targeted area by a fixed height value. Then there is the <b>leveling</b> charge, which tries to pull the surrounding tiles to the targeted tile’s level, within a small radius. Finally we have the <b>smoothing</b> charge, which can turn sharp edges and spikes into smooth ground, and also works on a small radius.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/devblog_terraformtypes.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/600/devblog_terraformtypes.jpg" alt="Terraforming charge types and their effects" title="Terraforming charge types and their effects"/></a></div>


<p>
The terraforming module will also check for plants in the area, and will first try to kill them before modifying the ground. This however will be a very slow process (and a waste of terraforming charges), so plant bombs or “manual gardening” will still retain their importance.
</p>

<p>
Due to various position updating issues we had to make a rule which will not allow terraforming if anyone is within a 1-tile border of the terraformed tile or area (“safe area”). Unfortunately this rule (and some other factors) does not really make this kind of terraforming suitable for group efforts, and is only intended for smaller fixes or touch-ups here and there.
</p>

<p>
However we have plans for another, <b>team terraforming</b> feature. We’re still working out the details of this one, but the basic idea is that a player could use the same terraforming brushes like we devs can to create a kind of holographic <b>terrain blueprint</b>. Then, terraforming beacons need to be deployed inside that area, and a team of terraformers can start charging the beacons using special modules from outside the area. In effect, the terraforming beacons will start to “pull” the affected area towards the form of the blueprint.
</p>

<p>
There will be a few global limitations to terraforming, even on gamma islands. First and foremost, there will be a few predefined non-terraformable areas, which will generally mean the vicinity of fixed teleports. We don’t want anyone to get trapped on the other side, or allow to shut off complete islands from the rest of the world. Another important rule is that you won’t be able to modify the shoreline of islands. And lastly, there will be limits to how high or low you can dig, and the maximum steepness you can achieve.
</p>

<a name='In_our_next_episode'></a>
<h3>In our next episode</h3>

<p>
Well, that’s pretty much all there is to the basics of terraforming. We’re still working on some of the details, and we’re of course eager to get some feedback from you as well. In the next part we’ll have a look at the basic rules of building structures and how you can connect them to each other.
</p>
]]></description>
			<pubDate>Tue, 14 Feb 2012 18:02:08 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-35</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-10-31-from-idea-to-feature-part-1/</link>
			<title>From Idea To Feature - Part 1</title>
			<description><![CDATA[<p>
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 <b>sometimes the most trivial minuscule feature has to go through a rather arduous chain of procedures</b> 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.
</p>

<a name='The_principle_of_our_system'></a>
<h3>The principle of our system</h3>

<p>
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 <b>allow anyone to fix anything they can</b>. Of course, this doesn't mean that people with no interest in coding can happily add <i>mov ax, 1</i> 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 <b>exposing as much data as we can</b>. (If you started giggling, do a few push-ups. It helps.)
</p>

<p>
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.
</p>

<p>
So here's how it works.
</p>

<a name='A_simple_example'></a>
<h3>A simple example</h3>

<p>
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.
</p>

<p>
The idea looks simple on the surface, but there are several solutions to fix it and all of them are either laborious or asinine:
</p>
<ul>
<li> We could leave them unsorted. That doesn't fly because it's annoying.</li>
<li> 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)</li>
<li> 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. <i>(Update - I might have forgotten to mention the most important part: non-programmers and markup languages rarely mix well.)</i></li>
<li> We could sort them on the server, by hardcoding etc etc see above yeah no.</li>
<li> 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.</li>
</ul>


<a name='Implementation'></a>
<h3>Implementation</h3>

<p>
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.
</p>

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

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_sparkproc1.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/blog_sparkproc1.png" alt="SQL design phase" title="SQL design phase"/></a></div>


<p>
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.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_sparkproc2.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/blog_sparkproc2.png" alt="That isn't going to do you any good, Flynn." title="That isn't going to do you any good, Flynn."/></a></div>


<p>
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.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_sparkproc3.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/blog_sparkproc3.png" alt="Server phase" title="Server phase"/></a></div>


<p>
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.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_sparkproc4.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/blog_sparkproc4.png" alt="Client phase" title="Client phase"/></a></div>


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

<p>
What you have to understand here is that this is the best solution, as strenuous as it seems:
</p>
<ul>
<li> It's robust (no hardcoding involved, extending doesn't involve breaking anything previous)</li>
<li> 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.</li>
<li> Most of the code-changes needed are just passing around values without thinking of what it really is.</li>
<li> Once the code works, it'll always work as long as the data itself is solid.</li>
</ul>


<p>
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.)
</p>

<a name='Exercise_for_the_reader'></a>
<h3>Exercise for the reader</h3>

<p>
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.
</p>

<p>
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.)
</p>

<p>
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".
</p>
]]></description>
			<pubDate>Mon, 31 Oct 2011 07:01:48 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-30</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-09-28-attributes-extensions-and-sparks/</link>
			<title>Attributes, extensions and sparks</title>
			<description><![CDATA[<p>
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.
</p>

<p>
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.
</p>

<a name='Farewell_attributes'></a>
<h3>Farewell attributes</h3>

<p>
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.
</p>

<p>
So <b>we’re removing attributes</b> 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 <b>160</b> 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.)
</p>

<p>
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.
</p>

<p>
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 <b>recalculate the available EP</b> 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 <b>varying amount of extra EP</b> (woohoo!), and that maxing out all extensions will <i>only</i> 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!
</p>

<p>
<b>If this is all too complex for you</b>, 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.
</p>

<a name='Changes_to_character_creation'></a>
<h3>Changes to character creation</h3>

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

<p>
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.
</p>

<p>
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.)
</p>

<a name='Extension_downgrading'></a>
<h3>Extension downgrading</h3>

<p>
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.
</p>

<p>
Our plan is to give new players an <b>option to downgrade their extensions</b>, 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 <b>a few limitations</b>, 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.
</p>

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

<a name='Removal_of_the_account_reset'></a>
<h3>Removal of the account reset</h3>

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

<p>
As mentioned earlier, the changes will <b>not affect anyone negatively</b>. 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.
</p>

<a name='It.E2.80.99s_full_of_sparks.21'></a>
<h3>It’s full of sparks!</h3>

<p>
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.
</p>

<p>
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.
</p>

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

<p>
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.
</p>

<a name='TL.3BDR'></a>
<h3>TL;DR</h3>

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


<a name='When.3F'></a>
<h3>When?</h3>

<p>
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.
</p>

<p>
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!
</p>
]]></description>
			<pubDate>Wed, 28 Sep 2011 08:14:44 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-29</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-09-12-a-new-home/</link>
			<title>A new home</title>
			<description><![CDATA[<p>
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.
</p>

<p>
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 <a href='http://www.facebook.com/pages/Perpetuum/140852567506' target='_blank' class='external'>facebook page</a> during the downtime.
</p>

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

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

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_newsite.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/500/blog_newsite.jpg" alt="" title=""/></a></div>


<p>
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.
</p>

<p>
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.
</p>

<p>
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.
</p>

<p>
So that’s all for now, tell us what you think about the new website when it goes live tomorrow evening!
</p>
]]></description>
			<pubDate>Mon, 12 Sep 2011 14:22:52 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-27</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-07-29-intrusion-2-0/</link>
			<title>Intrusion 2.0</title>
			<description><![CDATA[<p>
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?
</p>

<p>
Well, a <b>change of plans</b>. After the <a href='http://blog.perpetuum-online.com/posts/2011-07-15-the-great-big-revamp/' target='_blank' class='external'>previous devblog</a> 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.
</p>

<p>
We have conducted our own internal discussions about this matter as well, and came to the decision that we’d <b>bring forward an Intrusion revamp</b> 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.
</p>

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

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

<a name='What.E2.80.99s_wrong_with_the_current_system.3F'></a>
<h3>What’s wrong with the current system?</h3>

<p>
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.
</p>

<p>
Furthermore, the intrusion system is in <b>no way a reflection of who actually controls a location</b>. 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.
</p>

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

<a name='Ownership-Through-Occupation'></a>
<h3>Ownership-Through-Occupation</h3>

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

<p>
<i>“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.”</i>
</p>

<a name='Here.E2.80.99s_the_mechanics_of_the_system:'></a>
<h4>Here’s the mechanics of the system:</h4>

<p>
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, <b>two SAPs will become accessible every 24 hours</b>. 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.
</p>

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

<p>
<b>Stability</b>, 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 <i>stable</i> - captures by outside parties indicate the area is troubled, and therefore <i>unstable</i>. 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.
</p>

<a name='Capturing_an_Outpost_-_When_Destabilization_Occurs'></a>
<h3>Capturing an Outpost - When Destabilization Occurs</h3>

<p>
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.
</p>

<p>
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.”
</p>

<p>
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.
</p>

<p>
<b>When An Outpost is Captured</b> 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!
</p>

<p>
The probable values for “demonstrating financial might” are as follows:
</p>

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


<p>
<b>The outpost stability level</b> 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:
</p>

<ul>
<li> <b>0% stability</b> - The Outpost has been destabilized and is open for capture. The next SAP capture could change ownership of the Outpost.</li>
</ul>


<ul>
<li> <b>25% stability</b> - No benefits other than getting paid when other groups use the outpost; you’re barely holding on to control.</li>
</ul>


<ul>
<li> <b>50% stability</b> - Minimum threshold for outpost locking controls (to block other corporations from entering), moderate relation bonuses for industrial facilities. Minor price reductions.</li>
</ul>


<ul>
<li> <b>75% stability</b> - Reduced prices for service in the outpost, high relation bonuses for industrial facilities, Outpost locking controls.</li>
</ul>


<ul>
<li> <b>90% Stability</b> - Owners receive high discounts for services and enjoy maximum relation benefits, may also lock the Outpost.</li>
</ul>


<ul>
<li> <b>100% Stability</b> - Owners not charged for any service and enjoy maximum relation benefits; may also lock the Outpost docking mechanism.</li>
</ul>


<a name='A_few_questions_that_people_might_have'></a>
<h3>A few questions that people might have</h3>

<p>
<b>Q. Won’t my corp just lose SAPs when they come up in the middle of the night and none of us are on?</b>
</p>
<ul>
<li>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.</li>
</ul>


<p>
<b>Q. What if more than one party is pounding on my outpost at a time? How does that work?</b>
</p>
<ul>
<li>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.</li>
</ul>


<p>
<b>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?</b>
</p>
<ul>
<li>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.)</li>
</ul>


<p>
<b>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?)</b>
</p>
<ul>
<li>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.</li>
</ul>


<p>
<b>Q. What happens when this system goes active?</b>
</p>
<ul>
<li>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.</li>
</ul>


<p>
<b>Q. Will we be able to tell the Outpost’s stability level?</b>
</p>
<ul>
<li>A. Yes. We’re still working on where the information will be known, but it will be publicly available.</li>
</ul>


<p>
<b>Q. Can a corp that has strong relations with mine capture a SAP for me?</b>
</p>
<ul>
<li>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?</li>
</ul>


<p>
<b>Q. Could a corporation just watch two other groups battle it out, and then swoop in for the last capture when it really matters?</b>
</p>
<ul>
<li>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!</li>
</ul>


<a name='In_Summary_.28TL.3BDR.29'></a>
<h3>In Summary (TL;DR)</h3>

<ul>
<li> Outpost Ownership will now naturally reflect who lives on an island.</li>
<li> Outpost Ownership is going to become organic, and not absolute, in a tug-of-war fashion.</li>
<li> 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.</li>
<li> 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.</li>
<li> 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!</li>
<li> We want the system to reward people who live on the betas, not just those that raid them.</li>
</ul>


<a name='Is_This_All.3F'></a>
<h3>Is This All?</h3>

<p>
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.
</p>

<p>
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!
</p>

<p>
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!
</p>

<p>
<i>Scuttle safe!</i>
</p>
]]></description>
			<pubDate>Thu, 28 Jul 2011 18:02:48 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-26</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-07-15-the-great-big-revamp/</link>
			<title>The Great Big Revamp</title>
			<description><![CDATA[<p>
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 <b>next patch</b>. This would have been deployed today, but we found an unexpected <i>mission-critical</i> bug and will release it sometime in the <b>beginning of next week</b>. Till then, a few teasers:
</p>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_02.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_02.jpg" alt="" title=""/></a></div>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_08.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_08.jpg" alt="" title=""/></a></div>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_14.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_14.jpg" alt="" title=""/></a></div>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_19.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_19.jpg" alt="" title=""/></a></div>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_09.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_09.jpg" alt="" title=""/></a></div>

<div class='imgleft'><a href='http://content.perpetuum-online.com/images/content/Perpetuum_110712_16.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/185/Perpetuum_110712_16.jpg" alt="" title=""/></a></div>


<p>
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 <b>new assignment features</b> that will find their way into the entire assignment system.
</p>

<p>
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. <b>All of these features are subject to change</b>, but their purpose and outlines are quite clear. Behold, in the specific order of release:
</p>

<a name='Week_of_25th_of_July'></a>
<h2>Week of 25th of July</h2>

<a name='All_our_base_are_belong_to_us'></a>
<h3>All our base are belong to us</h3>

<p>
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:
</p>

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


<p>
To make these outposts and their facilities more appealing, the owners will be able to <b>manage docking access</b> 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.
</p>

<a name='Welcome_your_new_robot_overlords'></a>
<h3>Welcome your new robot overlords</h3>

<p>
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.
</p>

<a name='Week_of_15th_of_August'></a>
<h2>Week of 15th of August</h2>

<a name='Fledgeling_industrialist_love'></a>
<h3>Fledgeling industrialist love</h3>

<p>
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.
</p>

<p>
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.
</p>

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

<a name='Industrialist_brothers_in_arms'></a>
<h3>Industrialist brothers in arms</h3>

<p>
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.
</p>

<p>
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.
</p>

<a name='From_the_cartographer.E2.80.99s_wishlist'></a>
<h3>From the cartographer’s wishlist</h3>

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


<a name='Zombiepilot'></a>
<h3>Zombiepilot</h3>

<p>
Probably one of the most anticipated features since launch is the <b>autopilot</b>. 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!
</p>

<p>
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. <i>Braaaiiinns!</i>
</p>

<p>
<i>* It's not, actually.</i>
</p>

<a name='Perpetual_life'></a>
<h3>Perpetual life</h3>

<p>
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.
</p>

<p>
For the first 30 days you can both add and <b>subtract extension levels</b> 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 <i>perpetually</i>. There will be an option for a one time <b>attribute reset</b> in this first period as well, most probably via running a trimmed version of the character creator again.
</p>

<a name='Week_of_22nd_of_August'></a>
<h2>Week of 22nd of August</h2>

<a name='Farewell_.E2.80.98Triangle.E2.80.99'></a>
<h3>Farewell ‘Triangle’</h3>

<p>
All assignments will be overhauled:
</p>
<ul>
<li> The newly introduced features will make all assignments more challenging and exciting.</li>
<li> 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.</li>
<li> 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.</li>
<li> 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.</li>
</ul>


<p>
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:
</p>

<p>
“Scuttle safe!”
</p>
]]></description>
			<pubDate>Fri, 15 Jul 2011 14:24:15 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-25</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-07-01-movement-of-the-people/</link>
			<title>Movement of the People</title>
			<description><![CDATA[<p>
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.
</p>

<p>
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.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/blog_serverload.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/200/blog_serverload.png" alt="Something you don't want to see." title="Something you don't want to see."/></a></div>

<p>
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!
</p>

<p>
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.
</p>

<p>
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 (<a href='http://en.wikipedia.org/wiki/Distributed_Transaction_Coordinator' target='_blank' class='external'>MSDTC</a>) was NOT the problem, it causes an insignificant load, so we are fine with that.
</p>

<p>
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.
</p>

<p>
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: <a href='http://soci.hu/' target='_blank' class='external'>http://soci.hu/</a>). 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.
</p>

<p>
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!
</p>

<p>
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!!!!! >:)
</p>

<p>
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.
</p>

<p>
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!
</p>
]]></description>
			<pubDate>Thu, 30 Jun 2011 18:19:00 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-24</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-06-24-this-summer-part-2/</link>
			<title>This summer... (Part 2)</title>
			<description><![CDATA[<p>
The reason why I split this post in two parts was because the remaining features I promised to write about were either unfinished concepts, or not that solid on our list, so they could be pushed around in case something more important turns up. (Well that, and the fact that it would have been terribly long.) A lot stuff happened since Part 1 that can influence our priorities in the development of Perpetuum, most importantly: <b>player feedback</b>.
</p>

<p>
Apart from the forum, which probably plays the most important role in this, there was Episode #7 of the <a href='http://incomingtransmission.wordpress.com' target='_blank' class='external'>Incoming Transmission podcast</a> (thanks again Gremrod &amp; Kalsius for doing it!). Gremrod asked me beforehand what topic I would suggest for them to discuss, and since there have been some talks about when Alliances/Conglomerates will be implemented, I told him this would be something we’d like to hear about before we do it. So, among other topics, they talked about a proposed alliance feature and while everyone throws around their ideas and suggestions (noted!), the majority seemed to agree that currently an alliance feature would be premature with the current playerbase, and we should rather focus on improving current corporation features. We also discussed it and agree, so that’s what we’ll do.
</p>

<p>
Unfortunately this will delay artillery and second-generation weaponry, but I think we can agree that it’s better to improve current features first, rather than drop another variable into the complex formula that is PvP combat, creating even more balancing issues to deal with.
</p>

<a name='Corporation_management_improvements'></a>
<h3>Corporation management improvements</h3>

<p>
In the <a href='http://www.perpetuum-online.com/Changelog:2011-06-17' target='_blank' class='external'>last patch</a> we’ve made remote production processes visible on monitoring panels. This was only the first step, and we intend to merge all your production jobs in one common monitoring panel. This in turn will pave the way for the much requested <b>corporation-created production processes</b>, complete with production rights, logs, and source/target storage options.
</p>

<p>
Another relatively complex idea we have in store is a system where corporation leaders have a place to plan jobs, operations and events for their members. We call this <b>corporate projects</b>.
</p>

<p>
It will sortof work like an agenda: you think of a goal for your corporation, and optionally set a deadline. Members can then opt in to help the cause, and their efforts will be of course logged and displayed for everyone in the corporation to see. Goals can be anything from mining a hundred million titan ore, to delivering a few kernels for your research department, reaching a simple income goal, or even a number of PvP kills. Naturally you will also be able to set rewards for these goals.
</p>

<p>
I’m sure with the right tools you guys can be much more creative than what we can think of right now. If it turns out as it should, the system will be loose enough to simply use it for organizing any kind of corporation events, or keeping track of salaries as well.
</p>

<a name='Account_reset_changes'></a>
<h3>Account reset changes</h3>

<p>
Again? Yeah, admittedly we overshot a little bit with the last account reset revamp. Sure, it was a bliss for those with a “misplanned” character, but in the wrong hands it’s a dangerous tool which hurts the persistence of the game.
</p>

<p>
So we’ll try to bring you a solution, where beginner players who realized their mistakes they made at character creation don’t have to delete that character in order to refine their attributes or extensions.
</p>

<a name='Spark_teleport'></a>
<h3>Spark teleport</h3>

<p>
As mentioned <a href='http://blog.perpetuum-online.com/posts/2011-03-28-the-calm-before-the-storm/' target='_blank' class='external'>earlier</a>, the spark teleport system will allow you to teleport yourself without any robots or equipment from one terminal to another.
</p>

<p>
The system will work with the help of <b>spark teleport nodes</b>: at any given time you can have a maximum of 3 of these nodes placed at the terminal or outpost of your liking. This creates <b>unique teleport channels</b> which you (and only you) can use to move your spark from any other terminal to those locations. Of course both using a spark teleport and changing the configuration will have a cooldown limit in order to make it not too overpowered and you can also expect it to be a small NIC sink.
</p>

<a name='Waypoints_and_routes'></a>
<h3>Waypoints and routes</h3>

<p>
Hot on the trail of the geoscan result folders, we’ll introduce the same system for waypoints as well, with a little twist. You will not only be able to organize them, but with the proper sorting they will make up <b>waypoint routes</b>.
</p>

<p>
In its first iteration, these routes will probably be used by a not-that-bright <b>autopilot system</b> which will simply walk a straight line between waypoints, so its uses will be pretty much limited to highways and main roads without any blockings. (Later we might bring in some pathfinding AI as well.) Using the pre-made and stored routes will be as simple as selecting one while on the terrain and activating the autopilot, which will then start to walk towards the first or nearest waypoint of the route.
</p>

<p>
Of course this won’t make you travel faster, but it will help those doing the same transport routes over and over and allow them to do something else meanwhile, like checking the market, or trolling on general chat.
</p>

<a name='We_heard_you_like_pink_robots'></a>
<h3>We heard you like pink robots</h3>

<p>
Some of you may think that this seems to contradict the “more important features” statement I made above, but since the core mechanics which make robot paintjobs possible have been in the game for a while now, it doesn’t really take away much development time. We just missed a sensible game mechanic for it, which I’ll be presenting now.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/helloictus.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/200/helloictus.jpg" alt="Actually this is a very bad example. Please do not do this. Please." title="Actually this is a very bad example. Please do not do this. Please."/></a></div>

<p>
Painting robots will be as simple as fitting a module on them: the equipment window will get a second tab, where you’ll see 8 color slots. There you will drag&drop paint items of different colors and mix them how you like - the result will be instantly visible on the 3D preview of your robot. Drop a red and a green paint, and you’ll get yellow. Drop another red after those and you’ll get orange. Add one black and you’ll get brown. Pretty straightforward I guess.
</p>

<p>
The paint color items itself will be available in the energy credit shops soon to come, and will include the basic red, blue, green, black and white colors that you can mix freely. However, beyond the paint colors you’ll also need a <b>paintjob token</b> if you want that color to stick to your robot.
</p>

<p>
As mentioned in the first part of this blog, this will be a <b>microtransaction feature</b>: for a small fee you’ll be able to purchase packages of multiple paintjob tokens that you can use to finalize colors on your robot. The exact pricing is yet to be announced, but since robots are pretty short-lived and packing one will also make it revert to its default color (just like paint decay), it probably won’t be too heavy on your wallets. (And refreshing an old paintjob with the same color will be probably for free.)
</p>

<p>
This system has also the advantage that those players who don’t care about the color of their robots can still participate in the economy of paint items, even if only to sell them on the market.
</p>

<a name='All_the_small_things'></a>
<h3>All the small things</h3>

<p>
Of course these are not the only plans we have, but at this point it would be too early to write in detail about them, simply because we have to collect all the ingredients before we can present you the full meal. Some of these already reach <b>beyond our summer-list</b>, but in order to make room for some healthy theory-crafting, here is a short menu: geoscan result trading, dynamic mineral nodes, free camera and other camera improvements, persistent (SQL-based) field containers, improved NPC AI with different behaviors, random assignment objectives, titles/achievements and more.
</p>

<p>
<i>Bah, again nothing about player-built structures *grmbl*</i> - I hear from the back rows. Yes, thank you for your question, that concept is alive and in the works, but still has a long way to go. While it’s one of our priorities, we don’t want to leave you with nothing in the meantime. But as mentioned in an earlier post, the target time for that is still the end of this year.
</p>
]]></description>
			<pubDate>Thu, 23 Jun 2011 18:24:43 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-22</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-06-06-this-summer-part-1/</link>
			<title>This summer... (Part 1)</title>
			<description><![CDATA[<p>
This post should have been already published a few days ago, but unfortunately we had to put out some <a href='http://blog.perpetuum-online.com/posts/2011-06-03-new-world-order/' target='_blank' class='external'>fires</a> - and I’m not talking about toasters here. Now that the smoke has settled a bit, it’s high time to take a look at the near future of Perpetuum again.
</p>

<p>
Most of the stuff that we promised in our <a href='http://blog.perpetuum-online.com/posts/2011-03-28-the-calm-before-the-storm/' target='_blank' class='external'>candyshop</a> post at the end of March is already in the game: global storage listing, the kernel change, geoscanning folders, the new market rates graph, the event notification system, CT trading, market order modification, trophy details and explosion damage. Only two things are still waiting to be done from that list: performance-based assignment rewards and the spark teleport. So in this two-part post I will not only talk about these, but I’ll show you much more of what will hit the world of Perpetuum <b>during this summer</b>.
</p>

<p>
A quick note before we begin: while most of these concepts are complete for the most part, there can be still a few changes or refinements until they get into the game in their final form.
</p>

<a name='Assignment_love'></a>
<h3>Assignment love</h3>

<p>
Probably the most frequent criticism we get about the game is the lack of PvE content. The development of this type of content is the most resource and time consuming of all, but we are of course committed to progress in these parts as well. While our sandbox <b>storyline assignments</b> may not turn out as grandiose as those in other dedicated themepark-MMOs, they will still be a nice breeze of fresh air for those interested in the lore and the ones looking for non-standard objectives.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_nrefinery_04.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_nrefinery_04.jpg" alt="A Nuimqol refinery complex, one of the storyline assignment locations." title="A Nuimqol refinery complex, one of the storyline assignment locations."/></a></div>


<p>
Geoscanning assignments will be converted into artifact scanning assignments, which will send you out to pinpoint special artifacts within a relatively large radius. We won’t banish geoscanning from assignments though, they will get their new - and much more logical - place as initial objectives in mining assignments. No more complaining that there is no imentium right under objective point A.
</p>

<p>
For a few days now some of us have been analyzing existing assignments with the goal to bring their difficulty and rewards into the right balance. A lot has changed since these assignments were introduced, and even then they weren’t necessarily balanced regarding walking time or risk versus reward, but better late than never I guess.
This is only the first step, in the future we intend to raise the quality of most assignments by adding more objectives and generally making them more interesting.
</p>

<p>
We’re also planning the introduction of dynamic reward bonuses, based on the average completion time of assignments.
</p>

<a name='Career_tips'></a>
<h3>Career tips</h3>

<p>
Admittedly, this feature is a bit late since we already intended it to be in the Terra Incognita expansion. Since this is such an important feature for newcomers, we didn’t want to release it half-done and possibly confusing, but it will now surely be a part of our next patch. For those who don’t remember, this will be an extension of our help system, an “I want to do this in the game, give me some short tips” sort of thing.
</p>

<a name='Friend_approval'></a>
<h3>Friend approval</h3>

<p>
Don’t worry, we don’t want to turn the game into facebook any more than necessary, but with the addition of event notifications it became just too easy to spy on your enemies. A simple extension of the system by request/approve mechanics should solve this issue. Unfortunately we will have to wipe your friend-lists for this to work, but we hope this will only mean a slight inconvenience for a greater good.
</p>

<a name='NPC_balancing'></a>
<h3>NPC balancing</h3>

<p>
Electronic warfare NPCs are annoying little bastards. We play our game too (srsly), and the feeling that they are a bit too much for the newbies has been growing in us for some time now too. They are usually easy to kill, but when they get together with their damage dealing friends, they can easily overwhelm an inexperienced player. If you get in trouble near one of these spawns, it’s already too late to run.
</p>

<p>
With the introduction of the new islands we’ve got some more playroom for balancing, so we’ll lighten up the old starter alpha islands a bit by either removing EW NPCs from spawns, or reduce them to one. We’ll also remove or replace high ranked NPCs that are too close to the alpha terminals, so new Agents who are not so familiar with NPC names won’t get slaughtered after a few steps on Nia.
</p>

<a name='Changes_in_outpost_ownership'></a>
<h3>Changes in outpost ownership</h3>

<p>
The recent political events have been very eye-opening for us and brought up the necessity of a system which would be able to prevent one corporation to gain total dominance in the ownership of outposts. (While we know now that there have been other factors in play, the possibility still remains.)
</p>

<p>
To this end we’ll introduce <b>outpost maintenance fees</b>. The first outpost will be free for every corporation, with no upkeep necessary, but every additionally owned outpost will have exponentially higher maintenance fees. Corporation leaders will be able to set a priority list for their owned outposts, which will control which outpost ownership will be lost first, in case the corporation is not able to pay the upkeep for all of them. This system will hopefully make corporations appreciate more what they own, and prevent them from expanding lightheadedly.
</p>

<p>
Furthermore, corporations in possession of outposts will be able to designate <b>one</b> of them as <b>headquarters</b>. A HQ-outpost will have multiple advantages, bringing more incentives to both own and to keep them: for one, corporations will be able to control access of others to the outpost, based on their relation settings towards them. And it will be also possible to purchase various <b>upgrades</b> for it, which brings us to...
</p>

<a name='The_energy_credit_system'></a>
<h3>The energy credit system</h3>

<p>
I have already talked about the EC system in <a href='http://blog.perpetuum-online.com/archive/2011/02/' target='_blank' class='external'>The future of Perpetuum</a>, and I’m happy to report that the concept has been steadily growing more and more solid since February, to the point where we’re close to finishing it.
</p>

<p>
Allow me to not repeat the basic premise here again, for the lazy ones it should be enough that you will be able to collect energy for credit points, which you can use to buy shiny stuff.
</p>

<p>
Collecting energy will be possible on both Agent and corporation levels:
</p>

<p>
<b>Agents</b> will be able to collect energy from natural fields found on Nia. These fields will work quite similar to normal mineral fields, but they will be only visible at night, and you can’t use scanners to find them. To collect energy, you will have to deploy rare energy crystals found via artifact scanning, and if necessary, defend them until they are fully charged. The charged crystals can then be brought back to a terminal and sold to the Syndicate for credit points.
</p>

<p>
The current list of things you will be able to purchase with EC includes mission ammo, Niani modules, possibly some prototypes, and *drumroll* ...robot paint. (And sorry to burst your bubble right away, but the sooner you know the better: paintjobs will be tied into microtransactions for a small fee, because we're greedy capitalist pigdogs - details about paintjobs will come in part 2 of this post.)
</p>

<p>
<b>Corporations</b> owning outposts will be able to collect EC on a corporate level. This is the only part of the concept that’s still missing some puzzle pieces, but our intention is to make them actively work for those points and not just sit on their outposts which simply generate it for them.
</p>

<p>
We have decided to separate the Agent and corporation “EC-shops” in order to keep a healthy balance, so corporations won’t be able to purchase things from the Agent EC-shop and vice versa. However, Agents will be able to donate their points into the corporate EC-pool.
</p>

<p>
The things corporations will be able to buy using EC will hopefully give a nice boost to the incentives of owning an outpost:
</p>
<ul>
<li> Outpost upgrades: these can be temporary manufacturing boosts, higher level facilities, or even outpost auras, which will pretty much be the outpost-class version of NEXUS modules, affecting either the corporation’s robots on the island in some way or possibly accelerate plant or mineral growth within a certain range around the outpost.</li>
<li> Special assignments which can be activated for a fixed time, for corporation member use, or even better: for the public, so they can lure more taxpayers to their outpost.</li>
</ul>


<p>
So that’s it for now, in the second part I’ll talk about the spark teleport, changes to waypoints and a new addition called waypoint routes, artillery and second generation weaponry, and we’ll also have a look at paintjobs. Promised.
</p>
]]></description>
			<pubDate>Mon, 06 Jun 2011 11:29:09 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-21</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-06-03-new-world-order/</link>
			<title>New World Order</title>
			<description><![CDATA[<p>
It has come to our attention that some players have gained illegitimate possession of significant amounts of robots, equipment and other commodities, due to an exploitable game mechanic. The method that was used can by no means interpreted as intended gameplay. A lot of technical preparation and effort went into the experimentation and execution.
</p>

<p>
The magnitude of these exploits have helped these players to affect the whole poiltical landscape of Perpetuum.  With the uneven playing field, legitimate corporations had an extremely hard time competing for their goals. Their persistence is admirable and we are committed to achieving and maintaining a game where skill and effort prevail.
</p>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_plasmasell.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_plasmasell.jpg" alt="Calculate it." title="Calculate it."/></a></div>

<p>
We have thoroughly examined the extent of the exploits and removed all robots, equipment and commodities associated with them to the last. All accounts that were involved in the fabrication of aforementioned resources have been permanently banned from the game. The same is true for those accounts that had characters gaining unfair knowledge base improvements.
</p>

<p>
We are certain that from now on, Nia will be a much more interesting, exciting and rewarding place to be, and are looking forward to a new age in both the political and economical events of the game. The extent of our investigation and handling of the situation ensures that everyone has the same chance for fame and fortune in our distant world.
</p>

<p>
The exploitable mechanism has been fixed. We warn all players, that we will deal with similar offenders with utmost severity. If anyone has further information regarding the issue, now is the time to come forward and share it with us privately at <a href='mailto:support@perpetuum-online.com' target='_blank' class='external'>support@perpetuum-online.com</a>. We will keep pursuing this case with full effort. For those that feel they have been cheated out of their hard earned wealth, please contact us and we will examine your cases individually. Our goal is to enrich the immersion and experience within the game, not to harm them.
</p>
]]></description>
			<pubDate>Fri, 03 Jun 2011 17:18:04 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-20</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-05-30-market-graph-theories/</link>
			<title>Market graph theories</title>
			<description><![CDATA[<p>
This morning while we were listening to the 6th episode of the <a href='http://incomingtransmission.wordpress.com/2011/05/29/episode-6/' target='_blank' class='external'>Incoming Transmission Podcast</a>, I realised I must clean up something about the market. In the beginning, the insurance prices were based on the actual trading price of the robots. (Plus a multiplier to be correct.) This was a very nice dynamic system on paper, and a rather pivotal part of the game. By that time we were too busy to check the market rates graph frequently, and on top of that when I checked it I fed myself with freshly crafted theories to explain why does that look odd.
</p>

<p>
Despite many warnings from many players I didn't do anything, because I was so convinced by my own little theories. This was a terrible mistake that resulted in insurance frauds. (... link to a very long story here ... ) I can talk about this for hours but to keep it short, I was so sure it would all be fine, the game is just starting and that's why the graph is so empty/odd and it will boil itself down to a natural balanced level. But it didn't. As a result we changed the whole system to a more predictable one. Currently we are still monitoring the sales, but we are setting the insurance prices manually. This period was the left one on the image.
</p>

<div class='imgcenter'><a href='http://content.perpetuum-online.com/images/content/blog_marketbug.png' target='_blank'><img src="http://content.perpetuum-online.com/images/content/300/blog_marketbug.png" alt="" title=""/></a></div>


<p>
After that things went well, the market collected the prices properly and we were happy campers. Later on before the Terra Incognita patch I managed to put a new bug in, which ruined the graph again. When I realised it there was no way back - we weren't able to deploy a hotfix until the expansion. During this period the repair prices were based on the raw material sales, so the workaround was that I logged in periodically and made some fake sales. FAKE SALES????!!! WHAT?! Yes, I sold and bought randomly one (1) from each raw material so the underlying mechanism had some data to work with. This was enough to keep it going. See the second bugged period on the graph when I had to cheat the price filter mechanism. After that came the expansion and since then it's all good again. You can see these periods in every item's global rates graph.
</p>

<p>
This is how little bugs can ripple through the system causing trouble.
</p>

]]></description>
			<pubDate>Mon, 30 May 2011 11:00:33 +0200</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-10</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-02-15-the-future-of-perpetuum/</link>
			<title>The future of Perpetuum</title>
			<description><![CDATA[<p>
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.
</p>

<p>
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.
</p>

<a name='Artifacts_and_discovery'></a>
<h3>Artifacts and discovery</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
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.
</p>

<a name='The_energy_must_flow'></a>
<h3>The energy must flow</h3>

<p>
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.
</p>

<div class='imgcenter'><img src="http://content.perpetuum-online.com/images/content/devblog_energyuplink.jpg" alt="" title=""/></div>


<p>
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.
</p>

<p>
You’ll be able to achieve this via two ways, one PvE and one PvP option:
</p>
<ul>
<li> 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.</li>
<li> Own an outpost with a corporation which is producing the energy for you.</li>
</ul>


<p>
So what will EC be good for? New modules, rare components used in Mk2 robot production, CTs available only here... you know, <i>stuff™</i>. 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.
</p>

<a name='Assignment_improvements'></a>
<h3>Assignment improvements</h3>

<p>
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.
</p>

<a name='Corporation_recruitment'></a>
<h3>Corporation recruitment</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
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.
</p>

<a name='Artillery_and_area-of-effect_explosions'></a>
<h3>Artillery and area-of-effect explosions</h3>

<div class='imgright'><img src="http://content.perpetuum-online.com/images/content/devblog_artillery.jpg" alt="" title=""/></div>

<p>
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.
</p>

<a name='Even_more_types_of_weapons'></a>
<h3>Even more types of weapons</h3>

<p>
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.
</p>

<a name='Hybrid_robots'></a>
<h3>Hybrid robots</h3>

<div class='imgright'><a href='http://content.perpetuum-online.com/images/content/devblog_hybrids.jpg' target='_blank'><img src="http://content.perpetuum-online.com/images/content/250/devblog_hybrids.jpg" alt="" title=""/></a></div>

<p>
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.
</p>

<a name='New_lands_to_explore'></a>
<h3>New lands to explore</h3>

<p>
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.
</p>

<a name='Terraforming_and_player-built_structures'></a>
<h3>Terraforming and player-built structures</h3>

<p>
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.
</p>

<p>
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”.
</p>

<a name='Closing_words'></a>
<h3>Closing words</h3>

<p>
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.
</p>

<p>
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.
</p>
]]></description>
			<pubDate>Mon, 14 Feb 2011 21:56:08 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-9</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-02-13-the-tale-of-the-nic-that-wasn-t/</link>
			<title>The tale of the NIC that wasn’t</title>
			<description><![CDATA[<a name='Once_upon_a_time.2C_there_was_insurance...'></a>
<h3>Once upon a time, there was insurance...</h3>

<p>
And for a while it was good. Citizens were happy because they could ease their pain after that evil, evil pirate made them go up in flames while they were peacefully digging the ground - a common event on our beloved Nia. But then came along two monsters, Greed and Hax.
And the DEVs of the kingdom saw the gathering of dark clouds.
</p>

<a name='Insurance_frauds.3F_In_my_MMO.3F'></a>
<h3>Insurance frauds? In my MMO?</h3>

<p>
Robot insurance payouts are based on the global moving average market prices of two weeks. This only means completed transactions so it does not take active orders into account.
A system where we take the global average of all markets means that it's much more difficult to manipulate market averages. This, however, is also it's biggest flaw - when certain types of robots are only traded at a few terminals, the local prices go down due to the market wars, up to a point when they can be bought cheaper than the global market average. Due to some additional flaws in the mechanism, with good skills and good facilities it became very profitable to manufacture robots with the sole purpose of insuring them and blowing them up as soon as they roll out of the factory. The insurance fraud is born.
</p>

<a name='Healing_the_wounds_of_economy'></a>
<h3>Healing the wounds of economy</h3>

<p>
We considered many options on how we should go about this, but in the end we opted for counting the robots that were used in these operations, checked the actual insurance payouts they received for blowing them up, and then calculated the <i>real</i> average market prices that the payouts should have been in the first place. The difference of these two values is the falsely gained money, their "profit". This is what we had to take away.
</p>

<div class='imgcenter'><img src="http://content.perpetuum-online.com/images/content/dr_lithus.jpg" alt="" title=""/></div>


<p>
We have systematically inspected the transaction logs of all accounts that we could connect to the frauds. The vast majority of these frauds originate from the corporations Menace to Society, X-23, Mahtisoturit, BattleAxe, Not Amused and E=Mk2 but there are many more (the frauds were not necessarily executed by the corporations but by their members without the corps' general knowledge). During the server downtime today we have removed a sum of close to 1 billion NIC from numerous private and corporate wallets.
</p>

<p>
Now, this isn’t such a large amount considering the whole economy, but it’s certainly large enough to have an unnatural and unwanted impact on it, especially so early after the launch of the game. One of the most important factors in this game, the even playing field has been jeopardized. Counteraction needed to be done.
</p>

<a name='And_they_ganked_forth_happily_ever_after.3F'></a>
<h3>And they ganked forth happily ever after?</h3>

<p>
We certainly hope so. I know this is something that a company doesn’t do too often to its clients (which is sad), but I’ll try to be honest with you: Doing this hurts us just as much as it hurts those who just lost millions of NIC. But you all have to understand we’re in the same boat here. We could have started swinging the banhammer around but we feel it would have done more harm than good, so we didn't take disciplinary actions <i>this time</i>. Both you, the players, and us developers have the same goal - to have an ever-improving and expanding game, which stands the test of time. And if this goal becomes endangered, we have to act, whether we like it or not. I hope everyone agrees and this won’t have an impact on our good relationship with you.
</p>

<p>
Meanwhile, we are of course working hard to be able to activate the modified insurance feature again, and we hope to roll it out in a patch some time in the next few days.
</p>

<p>
ps. The next blogpost will really talk about the incoming updates and new features. Promised.
</p>
]]></description>
			<pubDate>Sun, 13 Feb 2011 07:33:52 +0100</pubDate>
		</item>
		<item>
			<guid isPermaLink="false">perpetuumdevblog-8</guid>
			<link>http://blog.perpetuum-online.com/posts/2011-02-06-keep-off-the-grass/</link>
			<title>Keep off the grass</title>
			<description><![CDATA[<p>
In the last patch, Noralgis appeared in Perpetuum, making the T4 industry a lot more complex and expensive. The pivotal point of this chain is the placement of the incubators. We feel that the community doesn't have sufficient information on the topic, so let me sum up the rules in a few lines:
</p>

<div class='imgright'><img src="http://content.perpetuum-online.com/images/content/noralgis_concept.jpg" alt="" title=""/></div>

<ul>
<li> Noralgis likes the soil where Prismocitae and Oryovia grows, so in general these two plants are the main indicators of the areas where it's worth trying to plant the incubators.</li>
<li> Contrary to other plants Noralgis has no altitude limitation, so there are a lot of places on the map - for example on the shore - where it can grow, though it's very hard/expensive to find such spots.</li>
<li> Within 8 hours Noralgis will turn into its first state, indicating whether the tile where you placed the seed is fertile or not. This applies to all islands.</li>
<li> From the second growing state - when it starts to block movement - the incubator will produce material. This will be half of its full capacity which is more on beta and less on alpha islands.</li>
<li> During consecutive cycles - which can be 8 hours or less - it either grows back some material, steps into the next growing state, or both. These events are random, so it could happen that your plant is not growing or not producing new material at all, when a field next to it is flourishing. Try working with as big numbers as you can!</li>
<li> After a random number of cycles the plant reaches its last phase, and starts to have a chance to die. This will only happen at the last phase.</li>
</ul>


<div class='imgcenter'><img src="http://content.perpetuum-online.com/images/content/noralgisgrowth3.png" alt="" title=""/></div>


<ul>
<li> On Alpha islands, this death-chance is higher, and the plant has a shorter life-cycle than on beta islands.</li>
<li> If Noralgis is able to grow in a place, it means that the tile is fertile and it will stay fertile forever. Planting there will always be successful and this fertility condition never changes.</li>
<li> Noralgis incubators can't be placed next to each other directly. Always leave one tile distance between each of them, otherwise they can kill each other. This also means you can kill a complete field by planting a lot of seeds among them; technically it can "reset" the field. Rather inefficient, but it's possible.</li>
<li> When you empty a plant by harvesting all the material out of it, it will immediately kill the plant. So it's wise to leave some in, at least one.</li>
<li> Each time when a plant steps into the next state, it produces a boost of minerals. Half of its physical capacity will be produced, but at the same time the plant is stepping closer to the state when it will die out.</li>
<li> <strike>The freakiest one: do not leave your robot standing on a tile where you planted Noralgis - it will die. Practically speaking: plant it and do not let anyone close to it until it starts to block. Hiding it is a good practice.</strike> This mechanic has been removed since.</li>
</ul>


<p>
Hopefully this helped to shed some light on the plant system in Perpetuum. The ultimate practice is to kill a Prismocitae or Oryovia and place your incubator there, leaving one tile between each.
</p>

<p>
Have fun!
</p>

<p>
ps.: This text will also be included in the ingame help in some form.
</p>

]]></description>
			<pubDate>Sun, 06 Feb 2011 17:04:29 +0100</pubDate>
		</item>
	</channel>
</rss>
