Time to talk about the next update to Perpetuum, as per usual we have a few interesting changes and new features coming to the game.

First of all as I've written previously, we're updating the roaming NPC system. Roaming NPCs will travel in caravans around the islands, and we're adding new flocks of NPCs for more varied random encounters on the terrain. This is only a very first step in our plan to bring a whole bunch of new content to the game for more stuff to do "between PvP sessions". We'll be adding a whole lot of new features to this end in later updates, which will be revealed a bit later. Various areas of the terrain will go through some small rearranging in this patch. Changes include new decorations around teleport stations, terrain updates here and there, and even a teleport station moved a bit farther away from a terminal.

We're bringing in a feature that was originally suggested in a very early brainstorm by a player during the beta. We liked the idea very much and had everything ready for it for quite a while now, but other priorities meant that this had to wait. The paintjob on your robots will now get worn down gradually as you engage in combat. This change is only aesthetic and will be undone as soon as you pack your robot together, however it's a small thing you can brag about and show off.

So now for the more interesting updates :)

A new type of plant will make its debut with the coming update. The special thing about this plant is that on its own it won't be growing anywhere, it can only appear in the game world if players plant it. This plant will contain a new harvestable material for use in the manufacturing of high end items. Beware of people trying to harvest or even destroy your crops!

One of the most fixed things in Perpetuum up to now was the constant, fixed distance of 1000 meters players could see each other. The upcoming update changes this. First of all: how far you can see and how far you can be seen from will both vary based on the robot you use, and the two will not necessarily be the same anymore. This alone would be an interesting change, but we're also adding modules to help modify these values during gameplay: The detection type module will allow you to see farther away. The flare type module will make the target show up for people farther away. And of course, the stealth type module will allow you to be seen from a shorter distance. These changes will bring the PvP on the beta islands to a whole new level, and we're excited to see how players will be using the new features to give them a tactical edge over their enemy.

Let us know what you think about the upcoming update in the comments!

Some of you already know about this, we've been waiting with the official announcement until we knew the system was working glitch free.

We in the Perpetuum team realize that the strength of our current player-base comes from groups of friends forming communities inside the game. Perpetuum was built around the concept of people playing together, not simply next to each other in the same world. Because of this we wish all new players to experience team play as early on in the game as possible.

To this end we're very glad to announce the recruit program: players with active accounts who have subscribed for at least 30 days will be receiving recruit codes, which can be used to kickstart a new account. These codes can only be used on accounts on which no codes have been redeemed yet and give 15 days of play time.

Most importantly if the player decides to subscribe to the game for at least 30 days, the validity of the original account which received the recruit code will also be extended by 15 days. We're sending out recruit codes daily, and after a while we'll be giving you a code like this for each purchase. If you haven't received one yet, don't worry - it'll come in time.

Again, keep in mind that these codes can only be used on a new account. Invite your friends to try Perpetuum!

I took the liberty to hijack the blog from BoyC to start a little skunk-work series of tech-articles about the stuff that goes on behind the curtains in Perpetuum. There's some fairly unusual ideas and solutions we came up with over the years and I hope they're as interesting to you as they were for us to invent / implement. (Or well, potentially more interesting, and without the malnutrition / hangover / sleep deprivation.)

So, maps.

The main principle

What is the task at hand, what are the conditions we can work under?

  • We need to have a map in the game where players can see the main navigation points. The goal is the map to look as good as possible within the given circumstances, since players will be staring at it for prolonged periods, and we don't want them to stuff their own eyes into the recycling facility 5 minutes into the first transport mission.
  • We do not have expendable artists who can spend time on painting maps manually, but more importantly, unlike other games, the map here needs to be as accurate as possible, for strategic reasons.
  • The terrain is a height-map - we can safely assume the client has access to this data, but this data has the possibility to change fairly often. (Think terraforming, either by players or by level design.)
  • Not really a mission-statement as such, but resolution-independence is a plus.

Summed up, we need a fairly non-linear data flow coming from a 2D dataset, and ending up in a good looking texture. In other words, procedural textures. Luckily, we're fairly comfortable with that. (*wink* *wink* 64k *cough*)

The steps

Let's look at our starting dataset first:

This is the actual terrain height-map, a 2048x2048 2D dataset of 16-bit height values. The reason it looks so dark is because this is a linear mapping of the 0..65535 range to the 32 bit colors available on your screen. Given that we don't really have to care about the peaks so much, since robots can rarely pass those, we can re-map the range of interest between two completely arbitrary values following "This Looks Good Enough"-principle, ideally somewhere around the water level for the low value, and the highest walkable point on the map for the high value.

This already looks a lot more usable. Sure, the mountain peaks become a big white spot, but we don't have to concern ourselves with those because they're rare, usually uninteresting for the player, not to mention the strange yodeling sound they emit.

It's time to add color. Cartographers generally follow a principle where they assign certain colors to certain heights, which works perfect for us, because we can use a look-up table internally to do so. This look-up table, in our case (and ideally), is a simple 256 pixel wide bitmap, painted by a graphics artist:

So if we use this to color up our altitude levels, we get this:

This almost looks good enough and no-one would blame us if we'd stop here (no, you wouldn't, shut up), but we knew we could do something more interesting given the data at hand a little maths. The image already has a nice faux-natural quality to it, but it needs contrast, the same way maps often have a little lighting / shading on them.

Adding contrast

At this point, the idea was to take the altitudes, more specifically the altitude-differences (or slopes), and turn them into shading. For this, what we've done is an implementation of what generally bitmap-manipulation software call as "Emboss", and basically means taking surrounding pixels, and calculating a normal vector out of them. Many of you might wonder if it means we're calculating a normal map, and in one sense yes, but the trick here is that the direction of the light can be fixed, because why not, it's Good Enough, and that allows us to speed up the calculations simply by assuming that the light always comes straight from the left.

For less technical minded: This practically could mean that we start walking (figuratively speaking) from left to right on every row of pixels, and if the next pixel is a point higher, we get a bright point, if it's lower, we get a dark point. (If you're indeed a code-savvy person, please refrain from gnawing out your own cerebrum at this stage because of this rather sloppy explanation, I was trying to make a point here.)

If we take this normal value and map it (with a bit of magic number wizardry) to the grayscale color range of 0..255 (0 meaning the next pixel was lower, 255 meaning higher, 128 meaning it was the same level), we get this:

Not the prettiest of pictures, but it's a vital component towards what we want: contrast.

So we have a colorful picture with no contrast, and we have essentially a bump map with no colors - how do we blend the two without calculating lighting on every pixel?

Simple: Prepared lookup-tables. We know we have 256 levels of color, and we know we have 256 levels of contrast, so we can pre-calculate a 256x256 pixel lookup table with all the possible combinations and utilize that to render the final image:

This lookup-table is ostensibly the above gradient, with the top half fading to black and the bottom half fading to white. Between that, in the very center, is our original gradient.

All it remains now is to run the following little lookup, matching our color and contrast:

for every pixel {
  tx = get_remapped_altitude() // 0..255
  ty = get_contrast() // also 0..255
  final_color = shaded_gradient_lut(tx,ty)
}

And here's our final image:

The difference is subtle, but definitely visible when the maps are zoomed up close - which is what will happen in most cases.

The advantages of this method are manifold: it's fairly fast (it's entirely fixed point arithmetics), it's resolution-independent, it looks Good Enough, and most importantly, it's responsive to the level of immediacy, i.e. every change done on the map can be rapidly re-rendered on the map as well. (This also goes for the passable terrain calculations, but that's a whole new story.)

That concludes our first visit to the forsaken wretched nadirs of the Perpetuum codebase. I'm not sure what to write about next time, but I suppose a quick look at the "number of changes per line of code" graph will quickly indicate where the "interesting" bits in our code are.

The roaming NPCs we introduced in the last patch became an instant hit with most of the player base. They are quite rare to find, can be in a lot of varied places, and have a very low respawn rate, making the sighting of an Observer on any island a rare moment. They also pack quite a punch, taking down a single one of them often needing the cooperation of several players, but the loot they drop is well worth the effort for everyone involved. Due to the very positive feedback on these high end enemies, we're currently working on some upgrades to the roaming NPC system that will allow them to move in a much more coordinated fashion. Observers will in many cases be accompanied by other enemies, and they will move as a group, which was impossible in the previous system.

How do you like the Observers so far, and what do you think of this update? Share your thoughts in the comments!

Here is what player movements on the alpha islands looked like in the last few days. Can you find your trail?

New Virginia
Attalica
Daoden

Also, the new dev server is finally up, so development pace can pick up again. The next patch is going to be exciting!