Why the limits on zombies and loot? System to increase limits

[RedgeZat 2]

Hi everyone, I would introduce myself, but that would be a long boring story.

So I will discuss motivation for posting.


I went to Rust game, they had no admins and people openly chatting about cheating, total lack of credibility of a game having any form of 'rules'.

If the game is about fighting cheaters, you are no longer playing the game, you are seeing who can code or detect or avoid the 'cheaters'.   A game needs a rule set to test the skill within the rule set of the game.  Also why pay to win does not work.  Then the winning rule set is how much money you make at some real life job.


So I go to the H1z1 forums, and they mention limits to something as simple as gardens due to server load, and max loot items.


And I look at the forum here and they say the same thing about zombie limits or loot limits.

So I am posting this to try and figure out why there is some load on the server for 'loot' and 'player placed items' gardens or buildings.



Here is how I think of it.  anything that is algorithmically computable, can be done client side, and 'repeated by server' to double check to see if there was a cheat.

Every zombie, every growing plant, every building, or deteriorating structure, that is all client side.  Why is there a server load?

The only load to the server would be 'validating' that a cheat was not done by running the 'position' 'state' through the formula to see if it matches where the item should be and its state.


Some examples.   

Gardens, you could have 100 plants growing on an area with almost no server overhead.  Mesh inventory spot(displayed by client as an individual normal item on terrain).   The mesh inventory spot holds a 'center node for an offset location' then for each planted item it holds an id, and an offset from that location in xyz  Each garden item has a 'time' it will reach 'next state'  like pickable or rotten state.   That is all client side.  And would be displayed as changing (based on that time stamp it is finished, like how animations are done, at the location it was planted)

The only server interaction is when someone plants a product in there garden (The server gets an item update, a time stamp, an ID as to what type of item it is, and its offset from some 'player set garden node')

Or when someone picks an item, then it is merely sending an action, to server, (gain_from_planted_item_Picked code, Item_ID, Amount Gained, Player_location)  the server would only have to verify that (and could do that in a garbage collection list, so would be an idle thread, to validate the player is not using a hack.)

(fertilizing, watering could also change completion time stamp in the same way. but only from a player action.  Can discuss things like rain and sun later, but also low overhead)


The only other time the 'plants' would come into server awareness would be when another player gets within a certain distance of 'the mesh garden node' then it would 'download' a list of item types and times.  And that is it.  A few bytes per item, and that could be cached, since the drawing of the item, its state of growing, is all a computable state based on the simple number ->  Time when a move to next 'state' occurs

And the client would know all the details of how to render each item at any time!

Where is the server overhead?    A few bytes of storage, and only dowloaded, and cached (or re-cached when garden gets a 'change effect' new pick or new plant list.

if you get within a distance of a garden mesh, you send the server your time of cache, it sends any changes to the 'area' that occurred after the time stamp of your last cache of area time.

As long as the client does all the work, and the server only has to relay existence, and time at next state to someone in range, and only when an interaction changes the 'pattern' the item will follow (seedling, sprout, pickable, heavy pickable, deteriorating, rotting)   the client does everything, and it is not hackable, since a list of gains  'interactions' gets sent to the server to match the results with the recorded, planting information when a player does something with a client side plant.

Player built Structures
The same thing with any placed user wall, it is all client side till a user gets in range, then the interaction is only an update of changes, or server would be involved in a client side interaction, with a check on interaction, any 'firing in area' could load a check on idle time 'find cheaters list' that would compute if there should have been a wall between raytracing, and then flag cheat actions.

Where is the server load?  A few bytes per item, a few bytes downloaded only when items change by a player interaction.



Loot items, same thing,  all the server has to have is a list of items in 'an area' and only send out item 'state' that had a change to it.   If a drop of some piece of wood, was loot, it would have a deterioration time.  That time stamp the client would use to animate its state.  and a location.   It would only be loaded across the server to a player, when that player came in range of some item node it is attached to, and only if the 'state change by user interaction' of the item changed since the last time a player was there.

If someone dropped 100,000 pieces of wood, over the coarse of a month, and you wanted them all as loot that was persistent, that would take only the server time when they were interacted with the first time.

Guy drops some wood.  anyone in 'some range' gets an update as a time stamp till decompose(nest state) and the ID and location, his client then figures what the wood should look like.   If he leaves the area and comes back, his client still knows what the wood looks like, and the server would not update him, it would know his client already knows, because there is no 'new interaction time' on the piece of wood.

If someone puts a nail in the wood, or builds on it, or picks it up, then 'the wood' has an update so that when the person is in range again, the client database is updated.

And anytime anyone 'gains anything' a check is put on server idle processing, to make sure the item was actually there, and not a 'client world database hack'


I don't see where there is a server load, in either memory, bandwidth, or any security holes if everything is based on a time stamp, and the client processing an algorithm that determines what that means.



Zombies same thing, all you would need would be a zombie node, all the 20 other zombies within 100 meters are an algorithm off that node.  A complex pattern based on a time stamp, that would emulate the same on the sever, as a client.   You know a node, and a time stamp, every client can compute where the zombies would be based on there orbiting patterns, and those pasterns can be complex, and include 'attraction' to center point, and collision detection, (and special case where they 'become server zombie find a path to where they should be, if they get stuck' until they get back to there pathing location that fits algorithm 'closeness to zombie node'.  And that also makes wandering hords really easy, give a pattern to the node movement.

Someone walks with a distance of a zombie node, the 'zombie time stamp' and 'Nest ID number' is downloaded by the server.  Then the Client runs the same formula that every other client runs to determine location of zombies in that nest based on zombie spawning timestamp and ID, and figures there current position at the current moment in time, and then adds them to the client.

When a person gets in combat or zombie sees someone, then the zombie is bumped up to a 'server zombie' (with checks to make sure peoples location, and zombie location detection, was not a hack, again in idle processing list, and again, precomputed by the same 'complex movement pattern and time stamp, and state.  And as a sever zombie they use combat and chase AI.  And are not using the precomputed pattern.)

When a combat ends, the server zombie AI, will path the zombie back to where it should be based on the algorithm, when it gets there, it becomes a client only zombie, accept the one type and ids of the node that indicates a zombie nest.

where is the overhead?

Its all client side.


Anyways, I keep hearing people talk about limitations to loot, and zombies, and things like not being able to make things because of server overload, and I just don't see where the overload is, when it is all IDs and clients algorithms and timestamps indicating changes.


With a 1000 players, 100,000 objects, the only server communication would occur during initial placement, something bounded by how much a player can do at any one time or some spawn rate, and 'interaction' and that is also really low overhead, since it is also 'player action bounded'.   And entering a new area where only changes by a player to some state of an object needs an update.

Am I missing something there?


(Note for security, the 'formulas for movement could be changed with periodical (realtime) in game downloads and new time stamps, so people don't figure the algorithms to hud zombies.  And that could be as simple as changing the movement vector and spin rate of nodes and a few variables in movement/pathing algorythm that define the starting point of algo computation and any location at any moment in time, done on the client.)  


If a zombie is spawned, a loot item dropped, or a structure placed, there is no need for client or server interaction other then caching it once based on time stamp of 'last aware of area' of a player in that area, and the timestamp of 'last action on loot or object'

You could have the entire map full of loot/garbage/whatever, and it would be all client side database. until it effects some player needing a 'server check' and that is all bounded by how much a player can do at one time.


And by making the zombies spawn off a node that algorithmically moves and rotates, and with a complex movement algorithm, they would not be seen as moving in a pattern.  Yet they would be at the same location on every client with only a few bytes sent to a client when he gets in range of the area.

I simply don't see why people are talking about limits to zombies or loots based on some server.


Although I am repeating myself, trying to make the concept visible.

If someone kills a zombie in a nest, the node gets a record that zombie number #28 was killed, it then gets a 'update timestamp' for that event and anyone coming range would get a server message from that node.  Zombie_Number_28_dead Node_74 don't render.  And that would update to anyone the first time they get in that range, or if there cache is older then that event.

If a zombie spawns, zombie_57_added would be sent to players in range from node node_74_area_49, the first time they get in range since that new condition occurred and the player cache date would be older and request all new condition updates by there cache time of that area being older.  And there client would know where to put that zombie based on there 'movement algorithm' of zombies and the node location.  And hordes could move by simply moving the node.


Does that make sense?

Where is the server overhead?

Maybe if a bunch of zombies were having to be Server AI at the same time, that would be the only limit, the amount of zombies actively 'agroed' and attacking players.  And having to have server controlled computations.   And some of that could be client side also, but that is much more complex.

 

 

Anyways, figured I would post.

 

Redge

Zathurus

Edited April 24, 2014 by RedgeZat

[RedgeZat 2]

note, a 'server zombie' is a zombie that has his updated location sent every change of path to every player in its range.

 

A client zombie, is one where the server only needs to know a time stamp, and an ID, and does not need to update anything about the zombie, till it attacks, or is shot.(becomes a server zombie)

[Chaingunfighter 917]

The only problem with your suggestion is that trying to switch it between clientside and serverside could potentially cause some problems when you have multiple people in an area.

[RedgeZat 2]

The only problem with your suggestion is that trying to switch it between clientside and serverside could potentially cause some problems when you have multiple people in an area.

Thanks for the reply,

Although actually it wouldn't, it would be either client side for everyone, where its location is known from a computed pattern on every client based on timestamp algo, and owning node.

 

Or anytime the server AI took over, it would be Server side for everyone in its range, where the server starts broadcasting its 'AI governed actions'

 

Think of it this way, every zombie not 'attacking someone' would always be at a algorythmic location on every client.  All the client would need to know is zombie node location, and a timestamp, and zombie number.   It could compute where it should be at any 'moment in time'  and it would look random since it would be algorythmic.  (zombies that get stuck could get bumped to server status by a client in the area, or by themselves from any client if to far from 'there node' when the node moves on a vector.)

 

Then when it attacks, or sees someone, the client it 'sees' (detection is also a client algorithm) sends a message to the server, Zombie (some number, AI Active) then every player in the area starts getting that zombies 'server directed actions' even if it is only attacking one player.  Every client stops rendering it as a Client Zombie, and starts rendering it as a Server Zombie, with AI movement commands.

 

And the zombie would be at the same place on every client, when all there clients started getting the 'server zombie' AI commands with way points or attack commands.  (including the person that initiated the start of the sequence.)

 

 

Summary

The zombie would be at the same location on every client, until a 'client' reported that a player was sighted, or it was shot or interacted with, Client of player reporting the doing of the interaction.

Client sends message, activate zombie

Server then broadcasts change to server zombie to everyone in that 'area' Client stops rendering based on algorythm

Server also sends with that its new waypoint or vector of movement to everyone in that area.  <- *that solves the problem you mentioned

Server moves zombie, broadcasting changes to everyone in that 'area' as new paths are decided.  <- *that solves the problem you mentioned

When combat 'detection' is over, zombie is pathed to where it would be in the client algorithm,

when it gets there, a message is sent back to everyone to make it client zombie again based on client side algos.

 

If someone left the area, the 'return to client status' message would have a fresher time stamp, then there older cached message of zombie node at that location, (that had it as a server zombie), and so they would get the server message to refesh its location when returning in range of area.

 

 

I think it would work, but I want to hear possible problems with the approach. 

 

 

For security all interactions get que'd on a server idle thread, to then be double checked at sometime to locate anomalies (cheats on a client since server would know where they should be also)   And also some checks during idle time to make sure 'detection' on client is not hacked.

Edited April 24, 2014 by RedgeZat

[ChristmasLunch 52]

I didn't read through your entire post but I did skim it, and from what I gather, you're talking about a majoritively client side game with server synchronization, yeah?

 

Well the reason that most things are server side is so that scripters do not have direct access to the files them-self.

 

Say if zombies were client side; easy. A script could me made for zombies not to spawn on you, or agro to you, because all the mechanics were able to be modified by you.

Say if loot spawning was on the client; A script could be made to modify loot cycles and only spawn in high end gear.

Sade if base building was entirely client side; scripters could have pre-made structures loaded in there game, and with a click of a button (or a scroll of a wheel, in this case) they may have built the most OP base with literally no confirmation from the server or any materials.

 

See where Im getting at here? The only files we have access to are sounds and textures (I think), and that's because you can't do an awful amount of harm with those in the hands of scripters. Or at least that's how I understand the system...

[RedgeZat 2]

I didn't read through your entire post but I did skim it, and from what I gather, you're talking about a majoritively client side game with server synchronization, yeah?

 

Well the reason that most things are server side is so that scripters do not have direct access to the files them-self.

 

Say if zombies were client side; easy. A script could me made for zombies not to spawn on you, or agro to you, because all the mechanics were able to be modified by you.

Say if loot spawning was on the client; A script could be made to modify loot cycles and only spawn in high end gear.

Sade if base building was entirely client side; scripters could have pre-made structures loaded in there game, and with a click of a button (or a scroll of a wheel, in this case) they may have built the most OP base with literally no confirmation from the server or any materials.

 

See where Im getting at here? The only files we have access to are sounds and textures (I think), and that's because you can't do an awful amount of harm with those in the hands of scripters. Or at least that's how I understand the system..

 

I am saying moving anything other then player interaction that could form a gain or lose, client side.  

(And the player detection by a zombie.)  Any actual interactions would be moved to server before a loot drop or combat occurred.

 

The Game devs still have access, however the scrips are stored on the client(that is the algo), and at time of interaction, location is validated on server. 

And could be changed and downloaded at anytime, and would be a good idea actually.   And if a player hacked the script, as soon as he attacked the zombie, or got within view, it would be in the wrong place, or wrong type, when elevated to server zombie, and it would be detected.

 

the idea is the movement scrips don't need to be processed on server, then new waypoint sent to client,

 

as long as when an interaction occurs, there is a check to see if that is the right place for something to be.

 

 

I understand, when it moves to client side, it is hack visible.  Although could easily be encrypted and changed regularly.

 

However the only time a hack matters is when a player gains, or avoids a loss, so the 'position' at that moment could be checked, and only then, to validate that a cheat is not being used, and server would not have to manage every movement every time for every zombie movement. 

 

When a zombie gets elevated to a server zombie, (only time it interacts with a player), the server would check to make sure it was where it was suppose to be, if it wasn't the player can be checked for hacks.

 

Loot drop would not be on the client, since anything killed would have been elevated to a server zombie, before it was attacked.

 

 

 

As far as macro scripts If that is what you meant by scripters, as long as the center node moved, and spun, and algo was changed occassionally, it would not be possible to figure out a 'script' to match a location.  If you mean a script to hack the hex code, it would show up as a cheat.

Edited April 24, 2014 by RedgeZat

[wirher 8]

Stop even trying. They have game designers and they know how to make games. 
Basically it should be like that:
1)Client sends event request and displays that event.
2)Server verifies event and If it breaks game logic (read: cheat) it corrects Client's game state.
3)Updated game state is sent to all players (where map should be divided in square chunks to avoid informing for e.g. newspawn on the coast about somebody's inventory on NWAF).
 

[RedgeZat 2]

See where Im getting at here? The only files we have access to are sounds and textures (I think), and that's because you can't do an awful amount of harm with those in the hands of scripters. Or at least that's how I understand the system...

I understand that, It creates more security, in exchange for server load.  I am pretty sure I could still secure a system while still using client processing.

 

The server always knows where the character is,

The server always knows where the zombie should be.

 

The server does not process the movement, until an interaction occurs though, and only then as a check to make sure it is in the right place.

 

It doesn't matter if the player, 'moves a zombie' because the server would know it when it reported the 'detection' or 'kill' or whatever.

and it would flag as a cheat.

[RedgeZat 2]

Stop even trying. They have game designers and they know how to make games. 

 

Obviously not, when they can't make zombie hordes.

 

And I am not trying, I typed that up in a few minutes, it is obvious, hence the original question.

 

Where is the logic flaw, and why the limit on loot and zombies?

[RedgeZat 2]

The real problem is the Hud Hack, since the client would know where the zombies would be.

 

Although there are ways to do that. Dynamically updated code injections in real time.

 

If someone was reading the mem location of 'output' of 'zombie location' they could create a hud.

 

However that location would be algo based on a time based changing algorythm, that would have to be rehacked, everytime the mem location and algo is changed.   Plus a few red hearings.

They could figure out where zombies were, at some previous cache time, but they might not be in the same place next time.

Edited April 24, 2014 by RedgeZat

[RedgeZat 2]

Although the only reason the Hud hack and such things exist, is the OS was built to be insecure.  That and chip architecture should have been where security started, but insecure systems can be profitable to those that make them.

[blackberrygoo 1416]

Ok man well you seem to have all the ideas , despite every game designer making games this current way . Make an mmo and set it up as such and lets see if it works ...

[BeefBacon 1185]

Might I recommend a tl;dr? Because tl;dr.

 

Client-side zombies is an interesting idea, but I'm not sure it would work in practice. As little client control as possible should be granted to make hacking harder.

[RedgeZat 2]

Might I recommend a tl;dr? Because tl;dr.

 

Client-side zombies is an interesting idea, but I'm not sure it would work in practice. As little client control as possible should be granted to make hacking harder.

 

Might I recommend a tl;dr? Because tl;dr.

 

Client-side zombies is an interesting idea, but I'm not sure it would work in practice. As little client control as possible should be granted to make hacking harder.

 

I understand that,

 

However there are many situations where there is no real hack that can occur.  For instance.

 

100 zombies in a town, you spot when on outskirts of town.  What good would a hack be, they are all out of range, and non aggro.

 

Then when they aggro, they become server zombies (interaction), and are validated as not moved or hacked, on your client.

 

You could also have Client Side Zombie followers that act off of 'Server Zombie' until aggressive, or attacked, adding an exponential growth to number of zombies.

 

But I do understand the concern, it makes it, because the OS does not have In Process Protected Memory Access, Locked Memory, possible for some to hack.

 

If the OS added a way for a program (with user permission) to lock a few megs of memory supported by chip architecture, that whole problem would be solved.  It used to be that one process had to open a named pipe to access memory of another program, that is how it should have stayed, and should be chip defended.  So that programs can set what is secure to the program, and what is able to be moved around accessed by other processes.

 

although then some 'agencies' could not read all the work products, papers, and items on every computer, so they don't want computers secure.  And of coarse much of those hacks done by those same contractors would then not be able to be used to try and defend some feudal system where some want to control some sector of some market, and only have those that submit to there controls allowed to have hack free interactions, although that is a long story.

Edited April 25, 2014 by RedgeZat

[wirher 8]

Yeah, srsly it is just TL;DR.
You will not change anything and they will not read your posts. They have experience in game production and even if it is still buggy and looks lame they are more experienced than you.

@up GG with idea of locked memory. Let viruses stay in RAM and be untouchable.