Increasement of the rotation limit of the X-Axis

Discuss the future of Warzone 2100 with us.
Blaubaer
Greenhorn
Posts: 9
Joined: 16 Nov 2006, 23:44

Increasement of the rotation limit of the X-Axis

Post by Blaubaer » 24 Nov 2006, 21:20

Hi all,

after the maximum distance from viewer to world obviously has been increased and also the minimum distance,
I wanted to suggest to think about an increasement of the maximum possible X-Axis rotation. Currently the player
hardly can see the horizon, especially in case you are zoomed in close to a vehicle. As it is quite easy to
modify this (see the end) I think it would be an good addition for the next release. It's quite funny to "fly" with
your vtols an attack and see the horizon rather than the ground... It's something like flying in a plane.

The only reason to skip this change is the higher computer power you require to render structures and vehicles in
the far distance. But this should not be a real problem for modern machines. Another (however minor) issue is
fact that the clipping mechanism sometimes erases some of the closer landscape faces.

To test my suggestion simply modify the following:
file: src/display.h

// #define MAX_PLAYER_X_ANGLE  (-14)
// #define MIN_PLAYER_X_ANGLE  (-50)

#define MAX_PLAYER_X_ANGLE      (-4)
#define MIN_PLAYER_X_ANGLE      (-85)

You can play with those values as you wish. But those above work quite well.

Greetings.

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Increasement of the rotation limit of the X-Axis

Post by Watermelon » 24 Nov 2006, 22:08

sounds interesting,maybe we can re-implement 'drive' mode and possibly add the ability to drive VTOL with that change?
tasks postponed until the trunk is relatively stable again.

Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: Increasement of the rotation limit of the X-Axis

Post by Troman » 25 Nov 2006, 00:22

Now that would be interesting. The only thing missing then is the ability to control a cyborg and then we'll have an RTS + Flight Simulator + FPS in one.
Cyborg/Scavenger headshots would boost your ranks immediately. ;)

Back to the topic, apart from the possible problems already mentioned by Blaubaer I don't see a reason that would prevent us from doing this.
Sign Up for Beta-Testing:
?topic=1617.0

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Increasement of the rotation limit of the X-Axis

Post by DevUrandom » 25 Nov 2006, 02:15

Here neither. Just one problem I think we have: The tiles are clipped very tightly, aren't they? I remember that I could see the background on the sides of the terrain...

User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: Increasement of the rotation limit of the X-Axis

Post by Watermelon » 25 Nov 2006, 13:46

Other problem is the drive mode in multiplayer,not sure how to send/recv a player controlled droid info in mp games.
tasks postponed until the trunk is relatively stable again.

Solitaire
Trained
Trained
Posts: 32
Joined: 05 Dec 2006, 22:47

Re: Increasement of the rotation limit of the X-Axis

Post by Solitaire » 05 Dec 2006, 23:38

The tiles are clipped very tightly, aren't they? I remember that I could see the background on the sides of the terrain...
IMHO adding a proper mapborder and skybox would be steps toward major graphical improvements but it would require some tinkering. I always liked being able to stare up into the pretty clouds in Ground Control...
Other problem is the drive mode in multiplayer,not sure how to send/recv a player controlled droid info in mp games.
Ugh. That gives me a headache even thinking about it... AFAIK the only server issues are to keep track of what in God's name the players are actually doing in their commandeered drone-suits ... bearing in mind they are a lot less predictable and "rational" than mere AI drones you'd have to track them very carefully. Thus having eight players running around in cyborgs reenacting scenes from Battlefield 2142 in WZ could be quite a bandwidth hog I'd imagine ;)

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Increasement of the rotation limit of the X-Axis

Post by kage » 08 Dec 2006, 08:02

Solitaire wrote: Ugh. That gives me a headache even thinking about it... AFAIK the only server issues are to keep track of what in God's name the players are actually doing in their commandeered drone-suits ... bearing in mind they are a lot less predictable and "rational" than mere AI drones you'd have to track them very carefully. Thus having eight players running around in cyborgs reenacting scenes from Battlefield 2142 in WZ could be quite a bandwidth hog I'd imagine ;)
dice was never good at resource, network, or general code efficiency (like making battlefield 2 synchronus when every other fps game designers, starting with the original, realized just how bad an idea that was).

if the players reenacted scenes from a source engine, or perhaps unreal engine game, they'd not eat up so much bandwidth.

it's really not that bad... just don't give them a mini-map during direct vehicle control: that way, if they're directly controlling a vehicle, the server should only send them data on what they can actually see, and not everything else that's happening around the map.

on the other hand, i don't know how the netcode is or will work, but you'd might as well take advantage of the "scan" style mini-map -- that way you only have to send them info every scan, not every time something changes, and the server could auto-negotiate mini-map update times for each player (assuming the time between "scans" are long enough), so that the server only has to send minimap data to one player ever, at any given time, theoretically cutting down the outgoing server bandwidth required for minimap updates by as much as 8-fold at the most, and in half at the least.

with little optimizations like the above (if it's not already implemented), we might be able to eventually hack our way into a situation where the servers, while requiring about 20-40% more processing power (to figure out exactly who needs what, and not send them anything more), could actually run via a pure client/server seperated protocol, which entirely eliminates any possibility of cheating in an rts (only way they could cheat is by hacking directly into the server, or by hacking into an enemy player's machine and altering their data as they receive and send it to make them see or do bad things), and this, if done correctly, might well be achievable on a typical dsl connection for an 8 player game.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Increasement of the rotation limit of the X-Axis

Post by DevUrandom » 08 Dec 2006, 11:00

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.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Increasement of the rotation limit of the X-Axis

Post by kage » 08 Dec 2006, 16:43

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.

karmazilla
Trained
Trained
Posts: 84
Joined: 26 Aug 2006, 21:05

Re: Increasement of the rotation limit of the X-Axis

Post by karmazilla » 09 Dec 2006, 13:01

I think tracking the camera like that would give way too muc network overhead. Besides, it's the radars and sensors that allow you to see land and units - these are, on the other hand, feasible to use to determine what to send over a network; they are static structures, so our need to communicate "rule changes" (such as a new sensor being build) would be reduced.
You might even be lead to think that doing this could reduce the overall network I/O, but I'm not so sure. The individual units also have sensors, and they move around - constantly changing the visible area.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Increasement of the rotation limit of the X-Axis

Post by DevUrandom » 09 Dec 2006, 13:28

What might be usefull is sending only those areas of the game/map which the player has units in. Eg roughly calculate the viewing range of the units and send those parts of the quadtree (or however this is handled) which contain those areas. That shouldn't be so costy.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Increasement of the rotation limit of the X-Axis

Post by kage » 10 Dec 2006, 00:53

karmazilla wrote: I think tracking the camera like that would give way too muc network overhead. Besides, it's the radars and sensors that allow you to see land and units - these are, on the other hand, feasible to use to determine what to send over a network; they are static structures, so our need to communicate "rule changes" (such as a new sensor being build) would be reduced.
You might even be lead to think that doing this could reduce the overall network I/O, but I'm not so sure. The individual units also have sensors, and they move around - constantly changing the visible area.
DevUrandom wrote: What might be usefull is sending only those areas of the game/map which the player has units in. Eg roughly calculate the viewing range of the units and send those parts of the quadtree (or however this is handled) which contain those areas. That shouldn't be so costy.
both my method and dev's use about the same amount of total net bandwidth -- his has more server upload required, mine has more server download required.

in either case, it's not really an issue of how it's implemented so much as what it achieves - any way of achieving the same effect (sending the player only what they can see on their screen) while using as little bandwidth as possible eliminates a good chunk of the possible ways any given person can cheat, while also reducing bandwidth usage to a whole lot less than is used now.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Increasement of the rotation limit of the X-Axis

Post by DevUrandom » 10 Dec 2006, 13:03

Oh, apparently I didn't read your text throughly enough, kage.
I thought you wanted to give the player only what his camera currently sees, what will create problems as karma pointed out.

But if you think my approach requires more server upload, but less client upload, then I think that's the way to go, because most clients are limited by the upload they can handle (eg. my upload is cut to 15Kb/s) and we also got modem players, which are lucky if they get my 15Kb/s for download.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Increasement of the rotation limit of the X-Axis

Post by kage » 10 Dec 2006, 13:57

DevUrandom wrote: Oh, apparently I didn't read your text throughly enough, kage.
I thought you wanted to give the player only what his camera currently sees, what will create problems as karma pointed out.
you did read it thoroughly enough, and that is exactly what i wanted to do, because if anything near a pure client/server enviornment existed, there would literally be no reason for a client to need to receive any data that does not pertain to what is seen on screen, and almost everything can be based on prediction and assumptions -- you don't send constant updates of the position and orientation of every unit: instead just send current location and vector, or better yet, current location and destination (but trim the destination so that the destination appears to end just after it leaves the screen, so that stream filters can't determine the true destination of enemy units) -- if the client and server both use the same pathing code, this would literally would look the same on the client as it occurs on the server, but would only require one packet to communicate. this of course, creates the appearant problem that if the camera moves, you'd have to send a new "destination", but you shouldn't have the server do that: only when the unit in question reaches its "destination" (as  known to the client) does the server send a "destination update", and only if any the unit is still on screen when this occurs -- using this, you only need to send updates for each unit every time the order changes or the player's screen is moved so that the appearant "destination" for any unit is on screen at the exact moment when that destination is reached. a lot of caching with reasonable expiries can be done to save bandwidth, such as "you see this enemy unit #x: this is what it is, and you should remember that for 2 minutes -- i won't tell you if it dies, and if you see it again after 2 minutes, i'll refresh your memory"
DevUrandom wrote: But if you think my approach requires more server upload, but less client upload, then I think that's the way to go, because most clients are limited by the upload they can handle (eg. my upload is cut to 15Kb/s) and we also got modem players, which are lucky if they get my 15Kb/s for download.
clarification: i think your idea has more server upload and less client upload than my idea, but based on what i've seen of the source as they handed it to us, i think both of our ideas use less bandwidth in both directions than the current implementation, so, unless warzone already uses some sort of super-efficient network logic, either idea would probably be more lean than the current implementation in all ways.

in terms of specifics, i can get a good estimate of how much server upload would be used in any given situation with my idea (i'd need some more specifics on yours to do the same), but there are too many equally good alternatives for doing camera tracking (and i'm not necessarily suggesting synchronus camera tracking since most camera movements are in one of the 8 cardinal directions, via mouse-at-edge or keyboard scrolling, or via clicking on the minimap, which using those assumptions, lets us cut down on bandwidth usage, per player, for the implementation by about 80%), so i couldn't really give a good estimation other than it would be the same type of stuff as an fps server would handle, but using the above assumptions, we could cut that down by 60-80% for scrolling, and maybe cut it down by 20% for minimap clicking (which, thankfully, is far less used by most players than is scrolling).

rts is a nice genre to work with in terms of bandwidth usage: since everything has a logic to it, and, unless we implement player driving (which would be fun - let's do it), there would be absolutely no occurances of sudden random movement, so think of what we have now as a text file... while not gzip it? (that's a metaphor of course - this would be prediction of the "move camera in direction x until told otherwise" variety, not compression).
DevUrandom wrote: and we also got modem players, which are lucky if they get my 15Kb/s for download.
most modem players are hacking the isp if they can manage 15kb/s, at least in the united states, as 56k service has a theoretical maximum of 7k in both directions. minus packet headers and other overhead, most users get 5k in both directions.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Increasement of the rotation limit of the X-Axis

Post by DevUrandom » 10 Dec 2006, 16:34

Then it seems to be different here in germany.
I got 15kB/s down and 5kB/s up (not at the same time of course), without any hacking, cheating, cracking...

Post Reply