I wish we'd have some grandiose reason as to why we did it, and why now, but really, it was just the point where some of the paperwork overhead didn't seem worth it after a while, and after we've recouped some of the costs of the initial server shutdown, it no longer seemed fair to ask money for a multiplayer game that's essentially entirely operated by the community itself - while we could justify it by still occasionally patching the game when really major bugs appeared, this has become so uncommon that the justification has become thinner and thinner.

Going free has been something that you've been asking for a while - understandably - and one of the main arguments was that it's the only thing that's standing in the way of a large player population. If this is really the case, then challenge accepted - impress me.

If you have any questions, you can find us in the OpenPerpetuum / Perpetuum Discord.

It's been a few weeks now that the "main" Perpetuum server is no longer running, which I suppose is the symbolic conclusion of the development of Perpetuum, something that was our first venture in game development and took 10+ years of our lives. In some ways, it was an emotional moment to pull the plug, and in other ways it really wasn't. Let me try to explain why.

We started working on the game (then just called "GenXY") in around 2004 - we genuinely had no idea what we were doing, we had no idea of the scope of it, we had no idea what it'd become or what we'd WANT it to become; we just had a faint idea that it was possible, and we started on it because we didn't know better. Turns out, that was kinda really we needed to get it done - because if we would've known what's coming, we probably never would've started.

I don't mean that as necessarily a negative, it's just that we mostly just made shit up along the way as we went: there's no "How To Make An MMO" handbook, and there sure as hell wasn't one in 2004. Most of us were still in our early 20s, and we never realized the amount of technology we would need to conjure up along the way, but we were ambitious (and stupid) and the fact that we can't (or not supposed to) do it just never occurred to us. So we went to it head first. We really were indie before "indie" was a thing.

Of course, the mission objective changed a few times along the way - initially we didn't want character models, just these little soul-like particle bursts, because we wanted to cut down on having to write an animation engine. Then when we realized that'd be boring, we went for robots because we didn't want to code skinned animation. The longer we went on, the more it snowballed, and next thing we knew we had this elaborate multi-platform architecture to have a game, a client, a website, a webstore, a backend, all these things in all different programming languages, platforms, database engines, that we just cooked up out of nowhere because we just thought "we have to figure this out", and we did, even though many many people not only warned us against, but actively predicted we couldn't do it.

That's not to say it wasn't bumpy. Even after alpha, even after closed beta, even after beta, it was bumpy. There were some joyful fuckups (like accidentally shutting down servers with a piece of pastry and setting our kitchen equipment on fire), some a bit more stressful (like screwing up the game launch because we weren't drunk, as opposed to the early access launch when we were) and some of them pretty miserable (like the cease-and-desist letter - guess who!). But through all of this, we had one goal and one goal only - to finish and release a game and do the best we can. And in that, say what you want, we succeeded. Not opinion, fact.

We didn't always see eye-to-eye with you - and that's putting it nicely; as developers, it was necessary to be cagey and secretive sometimes, to be stern at other times - even though we desperately wanted to keep in contact with out playerbase, we learned quickly that any reaction we released to the public had immediate ripples in-game, sometimes considerably bigger ones that we imagined, so we often secluded until we had something that was ready to show. This of course sometimes meant that what we produced wasn't in line with the general expectations, or that it split the playerbase even more - it often felt like a no-win-scenario, but we soldiered on, because we were desperate to make this work. There's a delicate balance between listening enough and not listening too much, and we often missed that balance - but we always tried.

The way I imagine studio closures happen in gamedev, they're probably come more as a sudden shock - for us, that wasn't the case. There were several moments where we knew that this isn't gonna go for long - we all hoped it would, but I think reality set in when we weren't able to reach the numbers we needed; we reached a number that was enough to sustain development, but we had no funds to market the game, or to produce massive amounts of content, and our creativity and work-ethic was only able to get us out the door, not all the way to the next town. So yeah, we've seen the end coming for a long time - and who are we kidding, you did too. But we didn't want to go away without leaving a mark, pretending this never happened, so we did what we could to make sure the legacy at least in part lives on.

I personally am still 100% proud of the effort we've put in over the years and the spirit we've invested in this game. Would I do things differently, knowing what I know now? Sure. But hindsight is always 20/20, and with the naive mindset we had, and the resources we had available, I think we made the best game we could.

A few people have asked what projects we moved on to, so here's a brief summary: (I'll continue to expand this if I can find others)

• Zoom spent a bit of time in motion graphics, and now works at Primal Games on a yet-unannounced title
• Alf is developing cloud technology at Nokia, which he says is a lot less stressful
• BoyC is working on car UX software at NNG
• Quodys, in his own words, "is on his journey to wreck a yet bigger enterprise, this time a global telco company"
• Gargaj (me) moved on to Slightly Mad Studios and has worked on Project CARS 2, and is now working on a yet-unannounced title.

Aside from that, as many of you know Zoom, BoyC and myself have been and will continue releasing work under the name Conspiracy; we've recently released our first venture in VR on the Oculus store - it's not really game-related, but it's something we'll keep on doing if you wanna follow us there.

Anyway.

Thanks for sticking with us over the years - you helped us achieve something that very few people could.

See you around, somewhere, sometime.

Yes, it is our favorite vaporous vacation vendition, the Steam Summer Sale and this time we offer you a whopping 50% off on Perpetuum and all in-game items starting from June 11 to 22, both on Steam and on our website; a great opportunity to buy several copies of the game and thousands of credits to various members of your family, your pets, your dentist, your high school crush, your lawyer, your probation officer and Dave the Guy from Grocery Store on The Corner.

Perpetuum 3.6 release

It's been a long and bumpy road, but we're finally there. Our truly random assignment system aka. Assignment system revamp Stage 2 will hit the live server on Monday the 15th of June, along with a healthy number of general updates and fixes.

Public testing of the patch has been going on for almost 2 weeks already, and those of you who have been following development saw almost daily updates and fixes. I'd like to take the opportunity here to thank everyone who participated in the testing - your feedback and bug reports helped us a lot in speeding up development, and certainly made this a better patch.

Testing will not stop though, since in this first patch we're only releasing the new assignment system for the three Alpha 1 islands: New Virginia, Attalica, and Daoden. As soon as we finish reworking the other islands, you'll be able to see and test them first on the test server.

The order of release will be Alpha 1 islands (in Monday's patch), then Alpha 2s, Beta 1s, and finally Beta 2s, the latter ones receiving assignments for the first time ever.

The testing forum topic can be found here, the first post of which also serves as preliminary patch notes.

We hope to welcome a bunch of new players during the weekend, and some of us devs will probably pop in to general chat too, so see you there!

On June 16th (Monday), starting at 10:00 we'll start the migration from our old servers in Budapest to a large datacenter in Amsterdam operated by Internap.

Internap certainly has a track record in gaming hosting, so this will hopefully lower the on-terrain latency - Amsterdam is one of the major hubs of Transatlantic networking, so players from Europe and America should notice a much more stable connection. Internap also cooked up various solutions to continually adapt networks, so in short we're having high hopes for this.

Now, a few words about the migration itself: During the period of moving, which we estimate to be around 3-4 hours (but you know how it is), all services will be down - game, web, email, IRC, everything. Some of this delay is inevitable (DNS propagation) and services will come back asynchronously: we'll try to get the game back up as fast as we can - most services are already running and working fine, we just need to synchronize some files and databases.

It's probably your best bet to follow us on Twitter or Facebook to follow our migration progress.

Wish us luck.

Anyway.

I don't think I have to introduce Steam Greenlight to anyone, but I'm happy to say that we took the chance as soon as we literally could and put the game up, so now you can express your desire to get the game up on Steam! Click here!

Exploits and reimbursements

There have been some occurrences of faulty functioning on server-side which were widely discussed on the forums. As a general statement, I'd like to remind everyone that as it says in the EULA, the abuse of such faulty mechanics is forbidden, and you may be risking your account status by doing so.

The most prominent such issue, as most might have heard of, was an anomaly which resulted in bots respawning in your hangar after they've been shot, essentially allowing you to fight with the same robot multiple times, turning Perpetuum into something of a George Romero movie. This was prominently used during a major fight on Monday; to address this, we will reimburse those players who suffered losses to these zombie bots, and will also temporarily suspend the accounts of those players who have repeatedly utilized this flaw.

Another, less problematic issue arose from the change of the production fees on Gamma islands: now that the mechanic has changed, and fees are returned to the owner corporation instead of the Syndicate, we will retroactively reimburse the corporations with these fees for their previous productions as well, since they should've been receiving these funds in the first place.

The Big One

And now for the most uncomfortable part: Our announcement about the adjustment of the gamma teleport ranges kicked up a massive stink, and it'd be feeble not to address that. To this end, we'd like to offer a chance to the major corporations / alliances involved in this game to express their opinions on the upcoming change, and invite them to a public roundtable on July the 5th (this forum and the opening post will continue to update with more information), where we'd like to provide an opportunity for the delegates of these groups to debate the change, provide us developers with enough insight so that we can handle this right, or even to make further adjustments. This also means that said change will be postponed until we have reached an agreement with the playerbase.

This all, of course, is far from being a final denouement of the situation, and we're well aware of that, but admittedly we painted ourselves in a corner a bit, so at this point what we feel is best, is to give you players a chance to right our wrongs.

Finally the day has come, when we unleash what we essentially consider as almost a rewrite of the game (considering there's barely anything left untouched in it), and open the Gamma Frontier. This has been a frankly unreasonable amount of work, but having seen some of the things already built on the test servers, I feel it was already well worth it.

A big big BIG thank you and massive respect goes to anyone who gave the test server a shot and systematically uncovered our occasional mishaps through numbers and lines of code; we hope the final product lives up to your expectations. (And if you didn't join the test server, now you know who to blame.)

The massive list of changes and upgrades are available here, the help pages are available here, and a fairly accurate representation of the dev-team can be found here.

And now, it's your turn: Last one on Gamma is a rotten Arkhe!

The server will open on Friday, 12:00 CEST, and you can already start preloading the test-client here. An important technical note I'd like to make: There's been a number of considerable changes in architecture, so it's important that you make this a separate installation! It is not recommended to install this over an existing Perpetuum installation or to try and skip ahead in preloading by using an existing datafile - this test client will only work with the test server! Other than that, it's the same old download-run-watch-progress-bar-login routine we all know so dreadfully well.

Now, this isn't the only thing to keep in mind. The test server, being somewhat different from the usual environment, needs a few things to be explained or taken note of:

• If you have a valid, paid account when the test server opens up, your account will be valid for the test-server as well. On the other hand, we will not perform continuous syncing; if you're late for the party, you won't get in. (That doesn't mean we won't do syncing later, but you have to have your best puppy-eyes in store.)
• The test server is subject to the same EULA/COC as the live one - be civil, even if something's broken (and oh yes, there will be blood).
• PVP on the test server should be strictly consensual; we won't limit your options via technical restrictions, but assuming that you're on the server to test, breaking someone else's gameplay won't help any of us, and we might revoke your access if you keep continually disturbing other players.
• For obvious reasons, some things will run in "cheat mode": The market will seed everything for low prices, you will get large amounts of EP and NIC, time-dependent processes will be sped up to minutes instead of hours, and robots will get automatically reimbursed after they've been shot. Of course this makes economic balancing difficult, but at the same time we don't want to wait two months for the first base to be built either.
• The test server will cease operation as soon as we consider testing complete and deploy the patch to the final live server. No data will be migrated back.

There will be a separate forum for the testing server topics here, so please open topics or post opinions there instead of other forums so we don't have to fish all the ideas and death threats together from other forums.

That's all I suppose, happy preloading, testing, and Lord Have Mercy.

I'm not exactly adept at expressing gratitude on a poetic level, but a gesture like this is not only appreciated for what it is, it also inspires on a more personal level to work harder/more on the upcoming patches. (Although that might be just the sugar rush.) Thank you very much on behalf of the remainder of the DEV team!

It also reminded me that we (somehow) forgot to mention our previous goodie-bag-by-mail, received last summer from Shea:

Again, thank you so much! <3

It has been an extraordinary weekend for us, seeing both the Agents in the audience and in the arena completely tuned to the same frequency and enjoying it as much as we enjoyed donning the visibility vests while rounding up the teams, conducting the matches as the officials, and pushing out the Zamboni afterwards to clear the arena of leftover robot parts. The great atmosphere certainly underlined our trust in the community Perpetuum has built around itself, it has been a great inspiration for us, and we're certainly gonna do this once again.

The execution of the tournament by was no means flawless, and I'd like to observe some things that we need to think about later: First off, the upper rim of the arena was way too popular, because it consisted of one single ring without any interruptions. We duly noted this and while we don't want to discourage long-range fighting, the amount of constant merry-go-rounding eventually just became silly after a while, and we'll certainly take steps against this next time. Another thing that gave us a bit of a headache was the obviously hasty decision of allowing matches to be decided with a coin-flip. This turned out to be a bad idea and we'll make sure to granulate the rules more specifically next time, perhaps including things like damage dealt or shots fired. (Again, these are just conclusions, not plans. We'll see.)

That all said, let's start the ceremony with a few people who we need to thank.

The "Jackie Stewart"-award for the commentary booth

The tournament certainly wouldn't have been as enjoyable as it was for people outside the arena if it wasn't for the amazing (and I mean that to the fullest extent) insights to the people who did the commentary with Mancs and Calvin on the stream: a big thank you go out to Lemon, Gremrod and GLiMPSE who attended our little livestream as guests, performed interviews and generally made the video stream entertaining even for people who weren't as savvy about the game as most of us. Their reward for their time and unwavering enthusiasm shall be a custom label on the forums reminding everyone that these people mean business.

The "Baby's First PVP" award for the best newcomer group

We'd like to take time to provide some kudos to the only corporation in the tournament who, despite being a fairly new PVE formation, decided to not only give the whole thing a shot but also managed to advance to the second round of the tournament, so a big hand goes to Rue Tang Clan for proving that even low EP players with enough dedication, creativity, a good understanding of game mechanics can match up any other group. They will receive what they probably need the most after the tourney: a round of reimbursements for their robots lost during those two matches.

The combined "Dale Earnhardt Jr."-award for most left turn laps around the arena and the "Garden Rake"-award for least rules observed

To commemorate the special moment of seeing four completely masked Troiars running full speed around the top rim of the arena for 30 minutes in hopes to avoid any sort of firefight and getting through the round via the coin flip, but ultimately realizing that they forgot to fill out the point cap and will be eliminated regardless, we'd like to present Infinity with a special Perpetuum 500 lightweight frame to aid them in their future efforts of legging it from firefights. This is also in honor of what we perceived to be the biggest surprise in tournament, eliminating M2S in the first round.

The "COME AT ME BRO"-award for most spectacular tanking

This one goes to a moment in a match we all found incredibly entertaining: We'd like to hand out our only individual award to Tux from 62nd, who successfully held his ground as a single robot for about 20 minutes after his team was destroyed early by Remedy, eating ridiculous amount of damage and EW like a boss. His reward will be, appropriately, a unique The Wall-brand shield hardener, to help him become comfortably numb.

...and now without further ado, let's hear it for the winners:

• On runner-up place: Remedy Inc.
• On third place: Crimson Imperium Reborn
• On second place: Immortal Legacy

And finally, the winner of the first anniversary Perpetuum Tournament is:

With a nail-biting finale, CHAOS has shown us amazing proficiency, tactics and discipline as they marched through the rounds with their impenetrable Tyrannos squad, and they're well deserving to the champion title, and by proxy the free entry to the next tournament as reigning champion. The top three teams are already in the process of receiving their rewards (see details here), and all other participating teams will also receive a complimentary goodie package, so hopefully we can wrap all this up within a few days.

Once again, a big big honest Thank You to all the groups who have stepped up to participate, the players spectating in the audience, all the players who in the meantime roamed the fields in search for treasure, and all those who watched the weekend unfold on the video stream. (If you missed it, check the video archive here.)

We had a great time - hope to see even more of you in the next event!

The principle of our system

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

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

So here's how it works.

A simple example

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

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

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

Implementation

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

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

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.

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.

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.

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

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

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

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

Exercise for the reader

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

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

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

As you may expect from indie game developers, our daily nutrition-intake is largely homogeneous at best, and can be usually expressed with what our friends in Britain would characterize as "beans on toast". To this end, when the game launched, I decided to traverse to the local kitchen appliance store and surprise ourselves with a wonderful sandwich grill, to spice up our otherwise dull circulation of carbohydrates.

The grill has served us wonderfully for a few months, until it's untimely demise when encountering a larger piece of pastry, at which point the structural composition of the object underwent a major realignment:

It was a tragic casualty, but after much grieving, we carried on. Then today, tragedy struck again, as the trusty office toaster, which has served us for the entire duration of the Perpetuum development, has inexplicably caught fire and nearly proceeded to burn through the bottom of the cupboard, only to be carefully unplugged and shoved in the kitchen sink by yours truly in a haphazard but effective manner.

Forensics have later revealed that the culprit was quite possibly the ejection lever lodging in halfway, either due to hardware failure or the toast itself wedging between the rim and the metal framing, which has caused the heater mechanism to switch from "medium well" to "meteor shower", and eventually "thermal ammo AOE attack", cheerfully melting the plastic framing itself in the meantime and looking wistfully towards the wooden cupboard bottom.

So yeah, we're one toaster down, and I'm still hungry. However, on the plus side, rest assured this will not serve as a hindrance on our development schedule.

Yes, we know, it's about time.

But yeah, sorry about that. The hotfix is out, restarting the client will apply the fix and as an added compensation we also added secondary sorting to datagrids.

Anyhow, I thought it's about time to provide some updates about what we've been doing in the past week or two, because we've certainly been busy enough not to say anything so far. As you may remember we posted earlier about what we're planning to add into the game in the coming weeks, with which we've been progressing steadily, but there were also other developments on other fronts, which might be of interest.

Reaching out to another world

The most apparent update we have is that we've been in cooperation with the wonderful people at CodeWeavers to bring Perpetuum to OSX and Linux, and finally we can present you with official Crossover Games support, which will allow you to enjoy the game on those two platforms just as good as under Windows, and you even get a discount if you purchase through that link! We ourselves have been using the game through this method on a MacBook Pro, and it seemed to work flawless as far as we could see. The gist of this essentially means that we'll keep an eye on possible bugs caused by the emulation, while the Crossover developers will continue to pay attention to your reports for the bugs you find seem to be platform specific. Before you ask, we're not excluding the possibility of a future native client for those platforms, but right now the game itself (as a game, not as a piece of software) needs way too much care internally for us to be able to shed any assets or resources on porting, and especially maintaining it afterwards. Right now, we feel really strong about Crossover as a means to deliver our game to a wider audience, so spread the word if you know someone who remained stranded on the OS-fringes until now!

Arrr, treasure!

Moving over to actual game-features, most of the artifact scanning is implemented (save for the usual minor GUI-related swashbuckling) and has proved itself eyebrow-raisingly fun for such a cynic as myself, probably due to the notable simplicity of the mechanic itself. The whole concept boils down to this: You get a normal geo-scanner, you get some artifact scanning ammo, load it, go out to terrain, scan. If there's something cool within range, you get a distance reading. You move around, scan again, you get another reading, with a delta calculation to show you whether you got closer or not. From this point on, it's an entertaining little game of "hotter / colder", which starts out as relatively simple when the distance is still large and any movement toward the general direction is considered as advancing, and gets gradually more and more tricky once you get closer and smack headfirst into either the "It says it must be here SOMEWHERE!"-run-in-circles-scan-like-a-maniac-syndrome, or the unfortunate occurrence that the artifact is likely to be in the middle of a bunch of angry NPCs. Either way, scanning within a given range of the artifact will finally result in the reward to appear - this can be a container with munchies in it, or a trigger to a variety of other things, depending on the type of that artifact. (This is helpfully specified for you along with the distance, just so you don't go cheerfully dowsing for Pandora's box.) There will be additional factors on how efficient you'll be able to geocache yourself to riches, but I'll leave that up to you to discover once the patch is out. The preliminary estimate for this patch is March 9, 2011, but this is still just what we're aiming for and there's still a lot of testing and balancing to do.

Combustion

We've also initiated the process of adding more zones to the game, a considerable task that's gonna take us quite some time to finish, hence it will probably not appear in the next patch yet. We're finished with the basic layout of the maps themselves, we've already placed the terminals and teleports, what remains is the actual level design: flattening the grounds to walkable paths, painting mineral fields, placing NPCs, placing decoration, stuff like that, as well as coming up with absolutely ludicrous new names for everything, the part of the process we admittedly enjoy the most. The plan is to provide six new zones, literally doubling the area available inside the game: three new safe zones (the ones with only a single terminal on them) for general activity, and three unsecured zones (with two outposts each) for unrestrained territory-knuckling. The teleport network has already been laid out, and though I won't go into detail here, we're hoping to provide easy access to each map from most of the current ones.

Some minor additional bits that have been done: We've changed the datafile handling so the local settings (keyboard, sound, window positions) will be saved separately from the large datablob, so deleting that will never cause your settings to be lost again. (Whoo-hoo!), we also added a free-look button so you can rotate the camera around the robot even when it is moving, we've made tabstrips squishy so now you won't have the problem of channels not fitting on the chat window, and last but not least we're in the final stages of adding direct credit card payment to our store. (About time, really.)

So that's about it for now, and we'll update you with details as soon as we have time to take a larger breath.

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.