DevUrandom wrote:
The aproach is good in general, but it would need to be figured out whether the serverpower given is enough. Otherwise we need to rely on the clients to do certain stuff themselves.
The "check what you see and what you don't" principle is good.
the reason "pure client/server" gaming was never ever used before is because servers didn't have enough processing power: you could waste bandwidth to lighten processor load -- in the mid/late 90's it was too much strain on a processor to figure
anything out in regards to sending out the right data to the right players, so often enough games would send
everything, which made cheating easy, so they did runtime checks of various kinds to try to prevent that, but those can't work 100% of the time, since all data is mutable.
currently, though, processing power is usually much less valuable than bandwidth, especially in a lot of countries, where if you
can get any kind of broadband connection, you pay per the byte and/or have a maximum monthly bandwidth cap, and client/server models, if doable, would oddly flip the bandwidth requirements: servers wouldn't be sending anywhere near as much data upstream, and would be receiving slightly more bandwidth downstream (as the server would handle more of the stuff traditionally left to the client), while clients, normally getting a whole lot downstream and barely sending anything upstream, would equalize out somewhat.
the biggest problem is making lots of things more efficient: you can't just brute force something server side any more if there's a faster alternative, and ideally, the server would spend no time seeing if something happened -- it would have to use an event-queue, if not done already, which would release a lot of cpu cycles for other things.
an example of how one aspect would typically work in a traditional vague client/server relationship (i don't know if that's how the below example works, but i'll go for it anyways):
player wants to produce a vtol at a vtol factory -> player clicks on the vtol factory and clicks on the design to put into production.
the client starts producing the vtol, and checks every tick to see if it's done, and updates the display.
when the vtol is finally complete, the client sends a message to the server along the lines of "i just built a vtol, and it is now at coordinates 234,720".
abuses:
client can use memory hacks, or even just send an artificial message along those lines via another program, and the server has no idea any cheating occured. in the case of a foss game like this, instead of memory hacks, they could just mess with the source code -- we could send some "validate yourself with a checksum" message, but that could always be replied to with a hardcoded "valid" response -- since all algorithms are open, there's not much we can do in that area... all data is mutable.
pure client/server equivalent:
player wants to produce a vtol at a vtol factory -> player clicks on the vtol factory and clicks on the design to put into production.
the client sends a message to the server: "i want to build a design x vtol at factory y. (request #578)".
if the request is valid, the server would send back "request #578 valid", which is a really short message saying that the vtol is being produced and that the client should detract the cost of the vtol from their power
display, and set and update the corresponding progress bar in the production display area, based on data from the client's copy of the mod, which was presumably checksum validated against the server copy. (the messages would be in binary of course, and wouldn't decode as strings)
abuses: player could use an external program or source code modifications to send artificial messages, but since the client is not trusted with
anything, any messages that attempt to do what the player isn't allowed to will come back "invalid" -- most they could do is provide themselves with "quick build templates", and stuff like that which don't actually break rules, and are pretty much equivalent to clicking really really fast. also, something like a "clickbot" -- the rts cousin to an fps aimbot would be possible, but the only real use of this is to allow a player to "auto click" something onscreen, such as targeting an enemy unit - since this only saves 2/10th of a second, it's more of a feature than a cheat. any use of memory hacks or poorly designed message generators would inevitably result in an inconsistent client -- one that might, for example, might display 3 units building in various factories while in reality there is nothing being built, but this only serves to harm the cheater (since their receiving disinformation because of their own actions), so it seems favorable.
there are actually a lot of other things you want to do, like have the server keep track of player camera positions so that you can send them only the information that can "see", thus eliminating a whole lot of bandwidth and any chance for a "clickbot" to see anything that the player can't already see. of course, keeping track of up to 8 camera positions and calculating "player objects within field of view" is generally a bit of work, the problem has been figured out and optimized in 1000 different ways since the same problem needs to be solved for any 3d game, but in this case we'd have the benefit of not having to
render anything, and we have a lot of super-optimized algorithms to choose from -- we don't even have to match the player's camera exactly in terms of field of view: if we can make our camera cover a slightly larger area and save 45% of the processor power that otherwise would've been required, it won't really have great likelyhood of sending data on many "offscreen" units.
when the player pans or rotates, we can even play on the "scan" effect (as seen on the minimap effect) to greatly lessen the processing load by saying that the short 100-200 ms (max) delays in receiving new data is because the "satellite needs to pan and zoom" on the new area. of course that doesn't explain how the camera can view from the scene from an arbitrary angle and height unless we play that off as some kind of "vr tactical simulator that renders 3d objects based on 2d pattern recognition (satellite recognizes a tank with half-tracks and a medium cannon and the simulator renders that combination in 3d) on top of a 3d-rendered terrain map using topography map data". and technically, a game engine is something of a vr simulator, so we probably could get away with it (unless we go with the "anti-gravity hyper-active camera" idea) -- hell, we could even have the client render some "sweeping vr grid" effect for areas that are awaiting an update.
as the player camera moves, the server can use a "best guess based on current movement/rotation direction" method to figure out what data to send as opposed to recalculating it every tick. also, as the camera moves away from a unit, or a unit moves offscreen, the client is responsible for removing that unit from the list of units that can actively be targeted: if the client sends a "have units [x-y] explicitly attack enemy unit z", and the enemy unit "z" is not on the player's screen, the server will send back an "invalid order" response to the client. any new areas revealed by camera movement/rotation would be sent more as a diff than sending every unit on the screen again, and it could be optimized to where units on the 3d game screen do not get sent during a minimap update, since that data is already available to the client.