Server and Client Design

[Vidiot_X]

Hi,

 

Aside from all the engines in the game server/client design will impact Phoenix SS in ways that can only be thought of as making-or-breaking it's future. As I see it there are basically two ways to approach this. I could construct a dedicated server with all the bells-and-whistles or go with a simple "Quake" style listener server / client. There are of course advantages and disadvantages to both the most obvious being ease of use and bandwidth.

 

To me a dedicated server implies large multiplayer numbers and large amounts of upstream bandwidth which for the average user will be a limiting factor firmly placing these kinds of servers in the realm of those who have access and a static IP address. The advantage of this kind of server is it's ability to have dedicated point of access and to easily communicate between dedicated servers allowing easy compilation of stats and other data.

 

An alternative to the dedicated server is a listener style server / client that is part of the game and is used in many games out there today. This approach has the advantage of lower numbers of players per server and thus lower upstream data. The ability to report it's IP address to a central location which all clients can access. Instead of a handful of dedicated servers there could be possibly hundreds of listener servers. Because the server and client are part of the game it's very simple for the end user to create a server and also play in the game. The downside to this approach is statistical data exchange. Linking that many servers would a bit daunting and would require a centeral server for them to report data too. Another disadvantage is a limit on the number of players to somewhere between 25-50 players/clients at a time.

 

So, I'm open to suggestions. I have to admit networking is not my strong point but I'm up to the challenge. If you have any ideas on the subject please let me know.

 

L8r,

=Rich=

[JoWie]

Nowadays servers are cheap, so I think that is not a very big issue. A bigger annoyance would be something like SSC.

 

Personally I am in favor of:

• A thin as possible client (client only renders graphics).
  The downside is more down stream bandwidth for clients in small games and input lag.
  The upside is a massive reduction in relative player lag, downstream bandwidth for clients becomes O(1) instead of O(n-1), upstream bandwidth for the server would become O(n) instead of O(n^2), cheating is mostly eliminated, clients are easy to develop for multiple platforms (windows, linux, console, web browser, et cetera)
  
• Player-run servers that can out-scale easily (instead of only up-scaling)
  
• Secure, isolated sub arenas for players that can not operate a server. (a sub arena owner can do anything he wants without affecting other arena's). This involves stuff like isolating files, scripting (like a web browser) and settings.
  
• A single point of trust for things like passwords. Someone runs an authentication service, only this service sees your password, email, et cetera. When you connect to a server, it only knows your username and if your authentication was valid. The service does not care what servers use it.
  

 

I do not really like the idea of a quake style server for a subspace like game.

[Vidiot_X]

JoWie,

 

Thanks for the input. As I understand it the current SubSpace client/server arrangement works along the lines you described. I'm really guessing here but my observations lead me to believe this, perhaps you could outline it for me. I'm not locked into any scheme as of yet so I am flexible as to the server/client design. I do agree that designing a server as you described has the best chance at foiling cheaters and providing security. My main concern is server performance. Having 'thin' clients put the onus for collision and other calculations on the server. I'm a little worried about handling possibly hundreds of clients and all the calculations involved coupled with the network load. The server would of course not display anything graphically, but it is still an unknown for me.

 

I also have to consider the platform targets I'm aiming at Windows, Mac and Linux. The network library I use has to be able to handle all three platforms. So this is going to have it's own set of limitations. On balance I believe your on the right track with your suggestions and I will give this some more thought.

 

Thanks very much,

=Rich=

[JoWie]

In subspace the server could be seen as a specialized relay.

You fire a weapon, you send to the server "I fired a lvl 2 bomb at 12302,852", the server relays this to all players that should know about it. After this no further data about the weapon is sent. (the server can not remove it for example).

 

Stuff like energy is all client side. With some effort you could crack continuum so that you have no weapon delay, can not die, infinite specials, et cetera. Continuum makes it hard to do this by using obscurity techniques (like making sure important variables never have the same memory address, or by sending a hash of the map file to the server periodically, et cetera)

 

Currently there are 3 types of servers: zone, billing and directory

directory provides the zone list and is completely open

billing keeps your passwords, scores and provides cross zone chatting. A billing server may connect to another billing server.

zone is the zone itself and connects to one billing server and multiple directory servers.

billing servers are private and a billing operator has to allow your zone before you can connect to it.

 

If you connect to a non ssc zone, your password is sent in cleartext to the server (and you get a big warning message). If you connect to a SSC zone continuum encrypts your password and only the ssc billing server knows how to decrypt it. Of course any SSC zone could simply send "?password bla" on your behalf, which would result in your account being compromised.

If a player connects to a zone he has to trust both the zone and the billing server.

 

 

I do not know what that networking library looks like. Does it let you define what the raw communication looks like or does it also serialize things for you? If you want to later support a different platform and the network library does not let you standardize the communication, you would have to add multiple libraries to the server (which is not that big of a deal).

 

Most subspace arena's only have about 40 players max. This makes it very easy to out-scale things. If you have a popular zone with 500 players you could just run 5 server, and the players just transparently move between them depending on their arena (subspace supports this, but it is rarely used nowadays).

Perhaps it would be a good idea to build a simulator for those calculations to see what the resource usage is like.

Edited July 23, 2011 by JoWie

[Vidiot_X]

Hi JoWie,

 

Thank you for the thorough outline:)

 

Originally I had planed to implement a 'specialized relay' style of server where the serve simply passes on the client data. In my case (much as you described) ship movement would be sent to the server and relayed to clients as a location (999,999) and bullets/bombs would be sent as a location plus the velocity (DX,DY) only once. I had planned to use each client to monitor collision of bullets/bombs and report any collisions pertaining to that client to the server which would in turn pass that on to other clients. This immediately brought into mind security issues with the client. As you point out SubSpaces's current client (Continuum) addressed these issues in artful ways but still, it's not ideal. It does however offload much of the computational workload onto the clients which I believe is a plus.

 

So, this brings me back to your original suggestion of a 'thin' client and a server controlled environment whereby the server handles collision and other environmental game interactions. As we've discussed this removes most of the security issues from the client onto the server. I guess at this point I will (as suggested) workup some simulations of this kind of server scheme which is what I had planed to do. One plus is that the clients would be able to run almost any system as their doing very little calculations. This arrangement does have an appeal that I like, but may in the end not be practical. Simulations will be helpful in determining this.

 

The idea of a billing server (account server) is interesting and along with a 'list' server would offload some of the workload from the game server. Linking several game servers to allow sever arena areas to 'out scale' also seems appealing.

 

The networking library I'm considering using does indeed have serialization and allows me to send packets (UDP) which include Byte's, Integers, Floats or Strings. So there should be no problem in communication even across platforms. The library does not include encryption but I think this kind of library is available and can easily be included.

 

So at this point I will have to invest some time in simulating different server and client designs to assess there viability. I really would like to design this to meet the communities needs and wants, so your input has been most valuable.

 

Thanks,

=Rich=

[Cheese]

i dislike thin clients

lag will kill things more than you care to think, as well as there being a huge cost to the server

if youre planning to have your server software be widely accessible, having thin clients will cause the server software to be too resource intensive for anyone to run on a nonspecialized machine

[Cheese]

there may be security risk involved in clients doing calculations, but this can be mitigated with error checking (such as periodic map checksums, multiple values sharing the same number & checking for discrepancies, and other obfuscations) and I would suggest you avoid using a thin client if possible

 

plus you can do fun things like set traps for these idiots and send the server a nice 'lol this player is trying to cheat'

[JoWie]

i dislike thin clients

lag will kill things more than you care to think, as well as there being a huge cost to the server

if youre planning to have your server software be widely accessible, having thin clients will cause the server software to be too resource intensive for anyone to run on a nonspecialized machine

 

I would have not expected that from you, with all those server side damage tracking AI bots you are using. ( ).

Anyways, I do not think cpu or memory usage will be the issue. Serving this forum is probably more resource intensive than that (yay php). A common cheap vps could run it.

 

Networking is the only big issue.

Just to avoid confusion: I am not suggesting video streaming. Just something along the lines of the server telling the client "download this map file and these images", "draw a ship at x,y", "draw a weapon at x,y", "draw an explosion at x,y". There are a lot of optimizations you can do, mainly by only sending what is changed and by letting the client guess what happens next (just like what continuum does with position packets which are only sent 5 times per second by default).

 

In such a scheme the lag has interesting characteristics like I quickly wrote down in the first post:

• A weapon will almost never hit on one screen and miss on another ("eating" / relative player lag)
  
• Input lag. It will take like 50-200ms for your ship to respond after you press a key. But, if this latency is stable, you will quickly get used to it. Instable lag is what you must be careful with (which is caused by crappy routers and crappy ISPs, google bufferbloat)
  
• While the bandwith usage is higher, it scales differently. You do not have to send what you don't see. If you are in an arena (as a client) with 100 players you could have the same bandwith as in an arena with only 10 players (continuum already has this characteristic somewhat, but to a lesser extent).
  

 

I think you need to do a lot of tests to see if thin clients are viable.

If I do a quick rudementary calculation with 20 players, 200 weapons, 11 bytes per packet, on screen, 10 frames from the network per second (unoptimized), you would be looking at like 24 KiB/s per client. Which means the server would be at 473 KiB/s upstream, about 1100 GiB of data per month if these players would play like that 24/7/30. 5000 GiB of monthly data costs you 15 euro on leaseweb.

 

It is true people on low end connections will have issues running a zone publically. But I have never actually played in one on continuum.

 

there may be security risk involved in clients doing calculations, but this can be mitigated with error checking (such as periodic map checksums, multiple values sharing the same number & checking for discrepancies, and other obfuscations) and I would suggest you avoid using a thin client if possible

 

plus you can do fun things like set traps for these idiots and send the server a nice 'lol this player is trying to cheat'

 

If the game would become sufficiently popular you would get constant cheating. I remember playing americas army years ago where you would have a patch almost every 3 days just to combat cheaters.

Most of those solutions would be security through obscurity.

 

Especially players that cheat carefully will be hard to track down. There are pre packaged cheats which affect common random number generators. For example you could cause random bullet damage to do 50% less damage on average.

 

I like what bak- is doing by using peer to peer cheat detection, but I am not confident it will be enough.

 

It would also affect decisions to go open source.

Edited July 24, 2011 by JoWie

[»Xog]

Richard, I suggest checking out the way the game "Altitude" handles there servers. People can make their own maps and just click a button to host them, and the list of servers appears. Sort of like Quakes / Unreal Tournament etc. I would highly suggest this, as it can welcome both creative AND competitive players. Edited July 24, 2011 by Xog

[TurboSlug22]

Hi guys,

 

I was talking to Jowie about this earlier today... I just wanted to share my perspective on the topic...

 

I have a lot of prior experience with a very successful MMO which used thin clients. The game was EvE online which has just one server with 30,000 - 50,000 people online (currently 47,000 people online, record max 63,000 people online)

 

Its a space game in the same 'ballpark' as continuum - everything is commands based using buttons or commands mouse menus on screen.

 

Combat works something like this:

 

The 3rd person camera lets you rotate around your ship in 3d space, you double click on screen to set direction in space in xyz space and can click a throttle gauge to set your throttle % - You may then ctrl-click on an opponent in a list of radar objects and select "Target" - pressing F1,F2,F3,F4,F5,F6,F7,F8 activates gun batteries. You then can double click around in space to set your direction or select your opponent and set your preferred distance to keep at range or orbit radius to attempt to orbit your target at a certain range.

 

Your ship responds with a very significant input lag to each instruction. Depending on the congestion, it can take anywhere from 1 second to 30 seconds+ for commands to register. In normal circumstances its on average about 1 second for commands to register. Your ship will not respond until the server does. In fleet battles (common) with 100 people per side, you can get 30 second input lag. At least, this was the case when I played, several years after eve's launch. Things may be better now... I dont know, I dont play anymore

 

The reason for this is obviously due to there being 50,000 people online, however also consider that eve online handles their universe in chunks, there are/were several blade servers, each of which would handle a certain number of star systems. It was quite frequent that individual nodes (groups of star systems) would crash due to over-usage

 

TLDR BOLDING: The biggest advantage an MMO using a continuum style client/server paradigm has vs a thin-client MMO is no-input lag/true real-time PVP.

 

We'd really need to be sure that if ~450 people on a continuum server which was essentially handling the events of the game server-side would experience any slowdown due to a congestion scenario due to position/property/event updates in addition to database queries and updates from all those users concurrently

 

In addition, for the zone we are working on, I would like to use a platform which does not impose any additional limitations on population size even if we all decide we don't need the large population ceiling that we might currently experience in player population levels.

 

Oddly enough, I have to say I like the idea of having a council. I don't know much about how our council operates but in principal, I like the idea of having a group of people that works to maintain some generally agreed upon values in the community... a group of people that might help address major issues globally and work to resolve important issues of all kinds. I think that sort of group would promote the cohesiveness of the community and help integrate and promote aspects of the community. Id like to even see them doing PR stuff for the whole community, maybe not exclusively though..

 

Anyway thin clients have some great perks and I'd be willing to try it if we were sure there'd be no additional input lag - If I was playing an FPS like counterstrike, and I had even a small amount of input lag, it would really throw off my game. In a commands based game like EvE, its ok, because it takes time to use the cumbersome menu-based interface even for flying around so the input lag is less noticable but if you were playing counterstrike or subspace even, and you were trying to aim but there was 200 MS of input lag, you would line up your shot, let go of the movement and open fire, but your character would over aim due to the delay in registering that you'd let go of the key and you would be inclined to miss the target. Input delay of any amount that is perceivable by the brain (~30-50ms) will significantly affect the usability of a non-commands based interface. In my opinion, an interface suffering from even barely noticeable levels of input lag would aggravate the average user so we would need to be very careful here.

 

What makes continuum cool is that your client tells the server where you're facing, which means the ship responds directly to your keyboard input. This is very rewarding and allows you LEVELS more control than EvE online offers, which is why dog fighting in continuum is so much more dramatic and lively

Edited July 24, 2011 by TurboSlug22

[JoWie]

If I look at the thin client approach I see bunch of annoyances for players:

1. In normal operation, you press a button, the effect takes a short while (< 200ms). (note that most computers already have an input lag of around 100ms for 3D games)
   
2. 
    
    
   Player has a lot of lag (he is downloading, has crappy wifi, etc): input lag is worsened, the state you see of other players is greatly delayed.
   I think in this point is important for the player to realize it is his own fault (like making ships blink or by speccing him)
   
3. 
    
    
   The server is struggling with computational / database stuff. The input lag becomes very high (this is what you usually observe in eve).
   I think this would not be an issue in stock servers, but could become apparent in very complex rpg like zones. Smart coding like asynchronous handling of triggers based on weapons, movements, etc would go a long way to prevent this.
   
4. Server is struggling with the upstream bandwith: Everyone starts to experience high lag.
    
    
   I hope this would only be an issue for large zones, which hopefully know how to mitigate this (which would not be very hard)
   

 

 

While the effects of 1 are minor, I think it is the most important point to focus on. The other points are easy to deal with.

 

Perhaps a hybrid approach is key. Let the client deal with its own ship movement within limits imposed by the server (perhaps based upon how far a player could get within 250ms). Firing a weapon takes effect, but the server may reject it or move it slightly (the client could use pretty interpolation to fix it, like continuum does for enemy ships).

In normal operation the player would not notice any input lag on the most important facets.

 

 

 

About SSC, I think servers forming community groups is not an issue. I just think everyone should have the same opportunity to run a zone without people fearing things like password stealing. This is also why I think such a password service should not include banning (unless it would involve something like bots massively registering names)

Edited July 24, 2011 by JoWie

[Vidiot_X]

WOW,

 

It awesome to see all the discussion here. I'm going to respond to all of this soon, there's a lot to digest.

 

For now some of you might want to check out this link:

http://udn.epicgames.com/Three/NetworkingOverview.html

 

I've only read through a part of it but it's a very Interesting read on the game Unreal and it's server/client design. This was suggested to me by the guy who owns the company that makes my programming language. He's a smart guy and indicated this might be a way to go.

 

Back soon,

=Rich=

[»Xog]

As I mentioned in my last reply, that system would probably be the best.

 

The only downfall I can see from this system is everyone just wanting to make their own servers to get the most players, rather than having a lot of people only play a select few.

 

It really is a great system to have for games like this though, as the game itself will look as a great platform for several unique game modes. Having 50 people work on their own little project is a lot more effective than say, you and a few partners working on 50 game styles.

 

I would like to see an interconnected billing system so I can still talk to people who are on other servers though.

[JoWie]

For now some of you might want to check out this link:

http://udn.epicgames...ngOverview.html

 

I have only read the first part, but that is pretty much how I envisioned it

[»Xog]

NetPriority for the win.

[Vidiot_X]

Hi,

 

OK, reading over that Unreal doc, if I'm understanding all this the servers in charge. Basically it breaks down like this

 

*The server sends relevant data (velocity, rotation, spawn points, etc) to the client which takes that data and uses the same functions as the server to fill in the gaps in data (for example position) due to delta timing and other conditions.

 

*The server sends data about other player/clients as needed, based on their position in the game and there priority to said client. For example if player is viewable to the receiving client.

 

*The Client uses said data to approximate a players movement/position using the same logic/functions as the server perhaps slightly modified for better approximation and performance.

 

*The client then updates its game state which is generally considered an approximation but accurate enough.

 

*The client sends it's relevant data to the server which in turn updates it's game state and passes on relevant data as indicated above.

 

This is a basic outline of how I'm understanding this. The server holds the only valid game state and the clients approximate everything based on what the server has sent them. The whole system relies on the server selectively sending out game state data based on priority and delta timing restrictions.

 

As I'm beginning to grasp this I can really see the advantages in security and low latency. I have to say SubSpace is closer to this kind of server client scheme then I would have thought. There are some issues I can anticipate for example zooming the client view out. This would reveal possibly too many players and effect latency. Perhaps limiting zoom would be a fix.

 

I've read over everyone's comments and some of you are very close to this type of server client scheme. So, I'm cool with this design and believe its the way to go.

 

=Rich=

[»Xog]

 

 

This is a basic outline of how I'm understanding this. The server holds the only valid game state and the clients approximate everything based on what the server has sent them. The whole system relies on the server selectively sending out game state data based on priority and delta timing restrictions.

 

 

Yes. In fact I'm not sure if the server could grasp this game style in any better way. I think it is the best, by process of elimination.

Edited September 25, 2011 by Xog

[Avast]

I don't know anything about networking.

 

But I would like to see

 

1. Player made customizable zones (ie Phalanx might want to remain just as, if not more customizable than Continuum)

 

2. Less or as much lag issues that the current Continuum client has (if its more lag problems, then its obviously detrimental)

 

3. Infinite security options, and options to deal with players (besides banning them) which would pretty much nullify any need for netbans, zone police, and subspace council. Get rid of these dinosaurs they only hinder the game. Polix is the only one of them who has evolved to actually just focus on development. But still if you leave him no reason to police, he would be even better off. Since the client would have no limitations, and therefore no need for people to monitor other people. If you need ideas on what type of features, I could go into more detail. But all I have are ideas, I have no idea how practical, or able these ideas are to make into reality. You enter any other game online, and you never see someone who is in charge, or hear from them, or even know they exist. That's how it should be here. At the most phalanx should just have a help channel.

 

4. 200+ zone populations

 

5. Great improvements in most important, game mechanics, ie "one sided walls", maybe even rotating walls, maybe even meteors that have orbits around other objects, ship death explosions that cause you damage if your near or in them. Possibility to place bricks, which last forever, and your ship can move them with a tractor beam etc. How far can you go Richard? At best one idea I had was that ships can place bricks, and build their own mini bases, and defend their flags in them, and so on. More flexibility on the energy bar. This way people who design zones, can use the energy bar in different ways. When your bar is orange, (they can add an effect) when your bar is red (they can add an effect) and so on. Manipulating the energy bar for ships is very important, for customization of zones. Sadly I can't quite remember my epic idea for energy bars, which continuum in no way could possibly achieve. But when I remember I will let you know. More options for tiles on a map. Not just 200 tiles. But 400 different tiles, would actually fit in to what most people ACTUALLY need for map making. However I know most people use LVZ in place of tiles and walls. So I am not sure which one is better for speed or the server/client etc. But if you can allow 400 tiles without losing speed, or creating lag, then I think it's a good idea to just do it. Even if we do have LVZ which we can use as walls. Animated backgrounds is another idea. I notice your background in your video had a planet, space, and some stars. But Imagine a spinning planet, twinkling stars, and so on, aka a Gif background, or whatever animated backgrounds. Is it possible? Will it lag? Heat seeking bombs, which will actually deter from chasing you if you fly near another ship, object, and so on. None of these ideas are meant for mainstream, that would be details that I don't care about. But I think all of this should be possible for zones, and people who want them. Heat damage, ie fly near a hot source, it will damage you slowly over time. And contrary cold damage. Instead of 8 tiles which act as doors. Allow for more than 8. I am thinking at least 16 door tiles. This will GREATLY improve map making.. because so often there are limitations to what you can do with doors, because you are already using doors somewhere else etc, and the client cant differentiate between doors, it either opens all doors, or not. IE make that better. (of course I could be wrong) Many more fly over, and fly under tile options would be nice too. Though LVZ solves this. Objects with their own momentum and flight path, different from orbits, which are circular. Aka take the idea of a decoy, make it solid, add graphic effects to it, and turn it into a meteor, have it move at a slower speed, and just travel anywhere that its original momentum set forth. Possibility of destroying walls, IE destructible tiles. Which could be a new set in the tileset. Currently lets assume we have 8 door tiles, 20 fly over and fly under, 150 solid, then we would have 30 destructible tiles. Perhaps a mini tractor beam (acts like grappling hook) more or less can bring you towards any object, or if you hook onto someone, you can follow them as they fly, (ie making actual convoys) as opposed to turrets, if the object is smaller than you, like a green, it will bring the object to you, rather than your ship to the object. Can be used to swing your ship, or escape black holes. etc. I am probably getting to advanced, or describing a game that sounds nothing like continuum. But I figure it would be continuum, if all the zone settings remain the same. New zones would use these ideas, old zones might adopt some, or use none.

Edited September 25, 2011 by Avast

[JoWie]

Sometimes you have to make a trade off between security and lag.

 

It would not be that hard to support a huge number of tile/object/part types efficiently (billions).

I think richard already completed this http://www.subspace.co/topic/26030-map-editor/

[Vidiot_X]

@Avast,

 

Most of what your requesting should be doable. The basic outline on the way the map engine works is it loads a list of parts which include a tile image, collision data, angle, blending, color data and more for each part. When you place a part in the map editor the part data is 'transferred' to the map and once placed the part is definable and it's attributes can be altered. This link (http://www.subspace....tors-and-parts/) covers the map sector model which should be large enough for very large maps with ten's of thousands of tiles derived from a list of parts. It's important to note that each part in a map is linked to a list of pats that are used to make the map, so even though you may have thousands of parts in a map things like image data are referenced to this part list which means memory is used efficiently. So a map of ten thousand parts (or tiles if you prefer) uses roughly the same memory as a map with 1 part given the size of the sector layout.

 

As far as how many parts you can have, there is really no limit other then video memory.

 

I'll be outlining this all when I have the time but be assured the Phoenix SS frame work will be flexible, scalable and efficient.

 

- EDIT -

I should add that I do not foresee a problem with lag and map parts. The server will have a copy of the map and only look trough the part collision data (and other data) that is very near a player or bullet which limits the range and thus the sum or parts to check. The way I planed to layout the server framework is to translate the 'player-object' position from the server to the client. The client will interpolate the gaps in data because of lag. I'm still working this all out.

[Avast]

That helps people like me, who don't know much about networking or programming, understand what your capable of, and where you plan to go with development.

 

I wouldn't personally be upset if the elements on game mechanics that I suggested where never implemented into the Pheonix Client. It's not even so much that I am giving you a list of things to do. Not at all. Just so there is no misunderstandings. I just wanted to give examples. To me the whole idea or purpose of making a new client is to achieve the things that players might have always wanted to do or see in continuum, but could not do because of limitations and lack of support from the original creators.

 

So everything sounds great, I am glad you plan to improve the game mechanics and make more possible.

 

Out of curiosity whats your background Richard? what zones do you play? did you use other names? Whats your experience in programming, and networking? and why personally did you undertake this project?

[Cheese]

As far as how many parts you can have, there is really no limit other then video memory.

 

so unlimited if you unload them when you get far enough away

[Vidiot_X]

@Avast

Right on. As far as the "who-what-where" on me I have been involved with computers for 25+ years starting with coding my first app on a Timex Sinclair circa 1980's. I love to hang out in DSB and you can find me there as Vidiot_X. My experience in programming covers C,C++, BlitzMax, Monkey, HTMl5 and Java, plus more. I'm writing Phoenix SS really because I love to play Continum/SubSpace and it has been a notion of mine to right my own epic multiplayer space shooter game.

 

@Cheese

Well, not really. All of the part data is loaded into memory. Parts are the basic building blocks of a map. When the parts are loaded the image data they contain is stored into video ram. So you may have placed a thousand copies of a 'wall' part (for example) in a map, all of those copies use the one part image stored in video ram.

 

I will document a fuller explanation how this all works later. It can be a little difficult to explain/understand.

 

- Rich -

[Cheese]

that was a hint for you to unload chunks

lol

 

but maybe youre talking about lvz type things, in which case you can disregard previous statements

[Vidiot_X]

I posted the wrong link here: http://www.subspace....post__p__278609

 

So I hope that helps to clarify what I was talking about. Silly me.

 

@Cheese and of course your right "Chunks" are loaded and unloaded as necessary.

 

- Rich -