1 (edited by Annihilator 2011-12-09 23:14:07)

Topic: Perpetuum world mechanic

ahh. yeah, i forgot the zero!

raw size of one island must be pretty big -> each layer is a 2048x2048 map:
- one 8-bit layer per ore/harvestable plant = +9 layer
- one 8-bit layer for elevation (hightmap) = +1
- one 1-bit layer for blocked terrain = +1
- one x-bit layer for special effects like highway boost or syndicate protection
- perhaps one for texture mapping and plants/buildings

this is also one of the reasons why we still dont have bigger islands then the existing ones...
island of double size would create 4 times the data your client has to load at once into memory.

when you enter an island, most layers, except ore layers, are packed into your RAM. many things must be streamed to your client as you walk around, since plants can be shot, terrain can be terraformed (by DEVs)
and and and...

The DEVs have to find a way how they can increase the island size without increasing the live-stream-data, nor increasing the preloaded data...

*Disclaimer: This post can contain strong sarcasm or cynical remarks. keep that in mind!
Whining - It's amazing how fast your trivial concerns will disappear

2 (edited by Celebro 2011-12-09 21:38:21)

Re: Perpetuum world mechanic

Annihilator wrote:

this is also one of the reasons why we still dont have bigger islands then the existing ones...
island of double size would create 4 times the data your client has to load at once into memory.

when you enter an island, most layers, except ore layers, are packed into your RAM. many things must be streamed to your client as you walk around, since plants can be shot, terrain can be terraformed (by DEVs)
and and and...

The DEVs have to find a way how they can increase the island size without increasing the live-stream-data, nor increasing the preloaded data...


I going on a limb here, could you connect 4 1 tile islands together with the need to reload terrain once you cross the 'line' between them? Or you would just not see anything beyond that line from the other side?

RIP PERPETUUM

Re: Perpetuum world mechanic

yes they can. and they have been trying that when i was on my holiday in budapest. (CRM told me im allowed to say that).

But you have to load the other three "tiles" too due to viewing range. ontop of that - the intersection in the middle (crossroads) could cause you to path all 4 "tiles" in a few seconds.

*Disclaimer: This post can contain strong sarcasm or cynical remarks. keep that in mind!
Whining - It's amazing how fast your trivial concerns will disappear

4 (edited by Celebro 2011-12-09 21:48:14)

Re: Perpetuum world mechanic

Could find a solution by creating high mountain ranges between intersections and many access tunnel paths (to avoid choke points) below ground, once you enter tunnel it reloads and end up on the other side.

That way you block view of the other 3 areas.

RIP PERPETUUM

Re: Perpetuum world mechanic

Well, I created a monster. Thanks for the help guys.

Re: Perpetuum world mechanic

When I hit this issue, my solution was to create a fifth virtual tile, that incorporated the interior corners of all 4 tiles.

1   2
  5
3  4

That is (5) is actually 25% of each of the other (4) tiles. This limits transitions to (3) tiles, 2 real and 1 virtual. Where the virtual tile supercedes the real tiles for graphics layer only.

The problem was with scrolling image data, but it may be applicable here.

Or, you know, just use TP's between tiles and natural barriers to prevent excessive streaming.

Re: Perpetuum world mechanic

hmm, requesting DEV or Moderator to split this topic off to "Perpetuum World mechanic" or so...

now to that: Tunnel between instances? would like Tabula Rasa, only simulating a big island but instead of water you get mountains. It also wouldnt change the fact that there are "chokepoints" where everyone has to come through that wants to enter your instance.

Fact is, perpetuum gameworld consists of 12 seperated instances. Those instances just dont "mirror" themself if one is overpopulated for whatever reason like you see it happen in so called "instance based games".

IMHO the DEVs have to make the TILES smaller to connect more of them into something bigger, and also create LoD maps for each tile.

Example: lets say the current maps would be split into 16 smaller tiles, each 512x512 pixels (while 1pixel = 10mx10m)
, and your client only loads the one on which your bot is placed, + all sourrounding ones. the ones further away would only be lod meshes. The Client would the load the next 3 high-res tiles whenever you cross the border to another one from your HDD and Hash it with the server for updates.

512x512 pixes ~ 5.12km x 5.12km -> with current system about maximum you can cover with a single bot regarding radar range.

another issue with the whole idea is player location - coordinates. they are currently only per "island".
propagating squadmates coordinates on radar far outside visual range only works if they are on the same instance.

last but not least - the worldmap... you can imagine the issues with that one, as it is created from live data, 100% correct, with dynamic resolution, while the radar is "only" the current instance. all these features probably have to be rewritten...

*Disclaimer: This post can contain strong sarcasm or cynical remarks. keep that in mind!
Whining - It's amazing how fast your trivial concerns will disappear

Re: Perpetuum world mechanic

(split from this topic)

Re: Perpetuum world mechanic

Are the tiles hard coded to 2048? In not I'm sure they already went with simply making tiles 4096, and since we don't have continents yet, we can also assume that didn't work.

If it takes a complete rewrite, at least we'll get a bunch of free norgalis again when they forget to add that layer in. )

Re: Perpetuum world mechanic

4096 x 4096 takes the minimum file size per layer from 4 megabytes to 16 megabytes.

I think that was probably their main reason.

Re: Perpetuum world mechanic

Yes, natural barriers will solve the continent issue. Btw, good topic for the blog.

Re: Perpetuum world mechanic

CRM, What about write server how it should be: write a cluster system instead of server-per-island?

Re: Perpetuum world mechanic

Alexadar: It's kind of like that. We can run any number of islands per server, but eventually you'll have to break up the cluster when you REALLY want one island to run on a different machine.

14 (edited by Alexadar 2011-12-10 15:06:09)

Re: Perpetuum world mechanic

You got me wrong.

I meant to write cluster what will work in distributive mode. It means all calculations will be distributed in a cluster. If you want to increase NIA performance, you will just add a server in a cluster.
This cluster will be able to run any number of islands with any size.

Re: Perpetuum world mechanic

Virtualize the underlying servers and optimize the code to seperate out all of the workloads to run by themselves so you can scale as much as possible per vm or rewrite to run on top of Hadoop.

Re: Perpetuum world mechanic

Database virtualization is good on paper but not always good performance-wise.

<GargajCNS> we maim to please

Re: Perpetuum world mechanic

GLiMPSE wrote:

Virtualize the underlying servers and optimize the code to seperate out all of the workloads to run by themselves so you can scale as much as possible per vm or rewrite to run on top of Hadoop.

Game server on top of Hadoop, that's unconventional thinking lol.

Re: Perpetuum world mechanic

Well, so far we haven't found better/more flexible solution than the current one. But I'm always open for new ideas.
The most bestest scenario would be to have a virtual OS that unifies the resources of a cluster of machines = seamlessly distributes the load among them... The server scales automatically, uses all available processors.
Ohyes, let's not mix the database into this, that's a separate thing.

Re: Perpetuum world mechanic

CRM just put it http://software.intel.com/en-us/article … studio-xe/ under managed code Layer, and this will be a victory for MMO industry.

20 (edited by Mark Zima 2011-12-10 15:59:34)

Re: Perpetuum world mechanic

The myth of transparent clustering (it talks about java middleware but the message still applies)
Nevertheless, in theory, nothing prevents you from creating erlang-like or terracotta-like middleware. It all depends on how island instances are structured.


Alexadar, HPC dev studio from Intel is unrelated. It's all about offline scientific number-crunchers.

PS. Requesting the "Perpetuum Server Architecture" blog.

Re: Perpetuum world mechanic

Anyway, i hope you got my idea

Re: Perpetuum world mechanic

Any number of instances in game is fine by me, always allowing all players a way to access them, so it does not loose its sandbox appeal.

RIP PERPETUUM

Re: Perpetuum world mechanic

DEV Crm wrote:

... Btw, good topic for the blog.

does that mean a blog about this topic is in the work?

*Disclaimer: This post can contain strong sarcasm or cynical remarks. keep that in mind!
Whining - It's amazing how fast your trivial concerns will disappear