RedgeZat

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

Monty Python postulated it was after you read what they called 'the funniest joke on earth' So here is the question, if you survive that joke, do you have an uber weapon?

Books in game, what a Novel Idea. And something to do at night. A simple thing to add in, with some relevance to society, and no reason to be upset if you don't read. Since it is something to do.

If the game has crafting, it would make sense to gather resources during day, shelter and craft at night. Although in reality they should have a realistic day night cycle. 2 hours day, 30 minutes night, since most people sleep at night, and that is not modeled if it is 2 hours day, 2 hours hours night, and I don't know, I haven't played the game. And having players online while having to sleep would be comically unworkable, although it could be presumed that everyone would sleep for 1:30 min of the 2 hour night, and emulated with faster night, slower day.

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.

Thats the way I see a zombie game should be also, When did 'other survivors' become the biggest threat in any zombie movie. (other then the bikers, the governor, and the soldier in 28 days) Honestly people would be using bows and arrows till somebody figured out how to make shells primers, and quality gunpowder, and even the machined M16 jammed in Vietnam, so home made shells? Automatic pistols and rifles would be jamming all the time.

Well that is why you don't point weapons at people. As far as involuntary trigger pulls to balance encounters. I haven't played the game, and think it being mostly guns is unrealistic. But that is a really good idea. It basically lessens 'who shoots first wins', and that makes KOS not as often.

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.

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.

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?

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.

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.

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.

Can't you clip out details and swap out textures, that would make gamma change useless. At night, surface illumination < some value, flip to texture dark no details. Put a check in the rendering cycle for ambient light and total light. add a global 'dark texture' if at anytime light is to low, texture is swapped with dark texture. You would not have to check every polygon being texture every render cycle, since if you checked 1% every render, in 3 seconds it would adjust all the textures to dark, or back to normal. And the checking would only have to be done at night, when there is less rendering occurring anyways. If a mobile light source, such as a player light is in the area, bump it up to 100% for close polygons since then it would have to flip based on a point source light moves Note the 'light reflective properties would have to be copped over to dark texture in the case of reflective surfaces, so that it would stil accurately illuminate things around it with what little light it does get, however it would solve gamma hack. Or something like that.

I can postulate a reason. In society groups of people that communicate cause information exchange and organization. Organization among the peasants leads to learning and exchange of ideas, sometimes against some feudal system. So making games with less and less chat, or circumstances where you don't chat with others, can create a limit on the abilty for society to learn or interact with each other. The safest society for a ruling security state is everyone in a cell, not able to speak or be heard by anyone else. It is a common method in prisons, and a trend in some gaming. And training hostile actioins to others could keep the peasants fighting amongst themselves in work and other enviroments in life also, if the mentality transfers over to real life. If a game wanted to solve that, where it was not where everyone was out to steal from everyone else, The easiest way would be to lessen the one shot kill, or first strike as the way to win a battle, and make 'using ammo' a decision, make it expensive, so there is a cost reward to such attempts. Such a game could create a lessing of the KOS pvp, but if that was the intent, I would be at the taverns right now.(long story) RedgeZat Although with the voice chat, that probably is not the intent, but if there is reward for asshat behavior, and punishment for civilized behavior, society can move that direction, including in a game.

Well technically making shells with primer caps would be rare in post apocolyptical enviroment. As would making granulated high quality gunpowder However people would be making muzzle loaders with home made black powder, easier to make. So a smoke, to lite the fuse on a muzzle loader while in combat, would make sense. Although I understand people like guns in games, even if it is not realistic, so meh, whatever. Modern Guns with working reliable ammo would be top tier weapons.

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)

I posted a thread on a really easy way to scale zombies up by hundreds. http://forums.dayzgame.com/index.php?/topic/188014-why-the-limits-on-zombies-and-loot-system-to-increase-limits/ By having server only handle 'active fighting zombies' and 'zombie nodes' and computed algorythms done on client side, zombies could be increased by 100 times with less server impact then currently used if they are all currently server zombies. There is precidence for that system also, it is no different then parent/child node animation, although in a different context