[T:V] Floating Bases

Status
Not open for further replies.
V

Void|deadjawa

Veteran X
I think it would cool if floating bases were able to move very slowly towards each other as a map progressed. Like for example, at 20:00 they were 800m apart, at 10:00 they would be 700 m apart and near the end of a map theyd be like 600 m apart. I think that'd make for more interesting cap routes, and more interesting timed strategy. For example, as a base moves around you'd have to change your cap routes to compensate for the different terrain. I think it'd also make for really intense end-maps.

EDIT: The base's path would be pre-mapped into the game so its the same every time. This way you know the way its going to go and can plan your routes accordingly.
 
Last edited:
Zoolooman said:
And massive, massive network traffic.
Click to expand...


I see why you'd think that. Train brushes are pretty common in online games. Only problem I might see are dynamic shaodws or a static commander map.


On a side note, remember that duke nukem 3d level that was basically one big rotating doughnut? That map rocked.
 
I just can't wait to see the newbies try to fly up to that base in the first screenshot, only to tumble to the depths below! muahahahaha it will be much entertainment.
 
Actually, I was more thinking:

Ok! Base A has how many game objects in it?

The base... the inventories, the people, anything that is thrown or dropped on the base, any weapons landing on the base, and hand grenades thrown against the base surface. The spawns (pack spawns, weapon spawns, and player spawns). The sound objects (like in T2 maps). The generator(s).

Now, you have no problem normally. You just send this information every once in a while. (This inventory now dead, replace with dead inventory).

But if an entire base moves, ALL THE OBJECTS that normally don't generate network traffic to the client must begin doing so.

The sounds, the invs, stations deployables and gens attatched to the base. All the spawns and spawned weapons. Anything fallen against the base surface.

The network traffic would be tremendous. This is why games don't contain fully featured moving bases, and why any game trains tend to be very minimal (just the object).

And even then, most of those game objects cause nasty network traffic with too many things on them. Load up 4 people on a HL elevator or train, and you get network traffic glutting out the wazoo. Hooray packet loss. Certain movers are fine because the number of things they touch and the amount of network information it'll generate is low. These are elevators, doors, forcefields, spring elevators and boost pads.

But imagine if an entire base, filled with activity and containing doors, forcefields elevators and booster pads and everything else. That's a LOT of network traffic. I fear that it is in fact too much traffic to handle.
 
You'd have th moving effect mapped out on the client side too. Whenever an object moves as normal it'd be just as normal with the base. The only time you'd have to send an update to the client is when any of those base objects are interacted with, which you do anyways. I don't see it generating any extra traffic with the correct protocal.
 
Zoolooman said:
But if an entire base moves, ALL THE OBJECTS that normally don't generate network traffic to the client must begin doing so.

The sounds, the invs, stations deployables and gens attatched to the base. All the spawns and spawned weapons. Anything fallen against the base surface.
Click to expand...

Not necessarily. If the game was designed to support this, it wouldn't be an issue. However, if it were even possible with Unreal, in its current state it would probably cause a big problem.
 
Sir Lucius said:
You'd have th moving effect mapped out on the client side too. Whenever an object moves as normal it'd be just as normal with the base. The only time you'd have to send an update to the client is when any of those base objects are interacted with, which you do anyways. I don't see it generating any extra traffic with the correct protocal.
Click to expand...

I was just about to say exactly that.
 
The real problem is that the client and the server are never in sync unless the calculations are simple or pre-recorded. It is likely that you'd have to basically record the entire path of the base spot by spot for the entire period of it's motion, or suffer from the server and the client getting out of sync. That is, unless of course, they update the client with what is happening to the base (syncing up). And that Mr. Lucius, is why it would either: generate more network traffic =or= generate a large file.

I'm not making this up. This is what the programmers said for both T1 and T2. Entire bases moving is an obvious strain on the networking side of the game.

I love the idea, I'm just telling you why it isn't *likely* to ever happen in a Tribes game.

Technical impossibility? No. Unlikely? I'd say so.
 
I'm not so sure. Why would it require mounds upon mounds of data to keep it in sync?

Server Player1,2,3,4,5,6,7,8,9,10 -> base1 has move 10 feet north, base 2 has moved 10 feet south

It really wouldn't be that big of an issue as long as the game was built to support it. The only time sync'ing would be a problem is if someone was already lagging.
 
I think the reason they didn't do it in the past had more to do with the fact that'd they'd have to redraw the shadow map or ignore. T:V is *supposed* to have some form of dynamic shadows, so I don't see that being a problem anymore.
 
Because is isn't just a base.

Think of it like this. A base, if moving, is like a vehicle following a predetermined path.

You either:

Calculate it's physics based on inputs or map out it's entire motion (requiring more data).

Everything in the base that wasn't generating but a smidge of network traffic now moves along with the base. The inventories, the stations, everything. If a player has a ping delay, the information from the server would need to be synced up every once in a while. This means network traffic for everything that was once still, as it now moves.

Now make this two or even more bases.

I'm not saying this is impossible, I'm just telling you that with the goals and the limits of the technology (the internet and the theoretical connections of the clients) that having a few hundred objects trapseying about the map either requires you to have all motions mapped out before hand, or you'll send at least some traffic syncing them up. Especially if the bases do something more complex that can involve rounding of numbers (different between client and server) such as rotating or turning.

If they add it to the game, I'd be VERY happy. So would map makers.

I'm going from what I know and what I've been told when the EXACT SAME THREAD was made for both T1 and T2, and I'm reminding everyone of what Mark 'Got Milk?' Netcode God Frohenmeyer had to say both times (and later DaveG had the same thing to say).
 
Alright then, I give up. I won't post in this thread again. I have no reason to become invested in this discussion if everyone believes it is possible and viable. I'm not going to convince anyone otherwise.

Let's hope they implement it if it is easily possible and network friendly.
 
Except that if every object inside the base is not referenced by the map as whole, but as an object inside the base, then they do not have to be tracked separately from the base. In fact, it would be absolutely necessary for it to be coded this way, otherwise players would start jumping around and going through walls because of lag (sort of similar to T1's elevator effects).
 
Interesting idea. How would lag be handled, though? For example, say Average 56k Joe, who just happens to be losing packets left and right, decides to use an inv station. At this point the packet loss reaches an ungodly level causing him to temporarily freeze. During this time the server sends "let's move base A to x,y,z". Unfortunately, Joe's computer misses this packet. Five seconds later Joe's ping returns to normal and his game is now out of sync. Two things can happen: 1) if the server resends base/object locations every X frame (to keep everyone synchronized) then Joe finds himself warped inside one of the base walls; or 2). the server does not resend position info and Joe's base/base objects are in an entirely different position than anyone elses.

One alternative could be to have the bases moved only on the client's side depending on the map time. The problem with this, however, is that should the mission timer for any client ever become out of sync than the above situation would still occur at some point.
 
Zoolooman is probably right. The only way I can think of to get rid of the excess updates is to put a whole bunch of special code in so clients will auto-update "child" object positions based on the position of the "parent". That way the game could just move the base around and send a single position, and have all the child object positions assumed to be moved as well.

Of course that brings about the problem of keeping track which child belongs to which parent. This wouldn't be an issue for "static" objects such as inventories, generators, and the like, but stuff such as dropped items, players, projectiles, deployables could face some nice lag/rounding errors in their positions. The added network traffic to constantly adopt/orphan child objects might get a little high as well.

Then again, it might work out perfectly, but it's always best to make sure you have your bases covered before jumping in :-/
 
Zoolooman said:
Because is isn't just a base.

Think of it like this. A base, if moving, is like a vehicle following a predetermined path.

You either:

Calculate it's physics based on inputs or map out it's entire motion (requiring more data).
Click to expand...


Uh... if it's going to move consistently.... this would work just fine.

It's not going to zig-zag across the map trying to move out of the way of incoming cappers.

:rolleyes:
 
Status
Not open for further replies.
Back
Top