Fuel 's new websites (X-post) 2004-03-04 - By Brian Robbins
Back
> Ok, am curious, because I am working on something extremely
> similar myself :) Firstly, it looks very nice indeedy, and
> collision is pretty good generally (modelsunderray with
> proxies I assume?).
Actually there's very few proxies. In most cases I'm doing
modelsUnderRay() against the actual geometry that you see. There's a
few places where we have proxies, most notably the rails on the
treehouse, and all the cacti.
I'm also casting 3 rays per movement, more or less corresponding to the
body position, and the two shoulders. This provides a reasonably decent
collision detection, but it's definitely not perfect. If you really
want to, you can squeeze through some of the walls :(
> The models are very sweet :)
Thanks, I'll pass that on to our modelers.
> Basically I'm mostly interested in the MU stuff.
> At a rough guess you are interpolating over a time interval
> then extrapolating after using last direction. Can you
> confirm / deny this? :)
More or less yes, that's correct. All the communication is going
through FlashCom using remote shared objects. There's one object per
character in the world, and each object has a position (x,y,z) rotation
(x,y,z) and their last movement vector(x,y,z), and their current action
(such as walk, run, etc).
All remote avatars have a target transform which they interpolateTo
every frame. When I receive updated information for a player, I move
their targetTransform to the new location/rotation. Additionally on
exitFrame, I move the target transform by their stated movement vector.
In general I've found this to provide the best overall movement, but as
you noted it's definitely not perfect. The biggest problem we had was
actually with the bucket elevator going down to the caves. Our current
method provides the best display of that case . . .
> Also, how many updates a second are
> you doing,
Until a couple days ago I had it set to 4, but I recently changed it to
8. This is definitely something that I'm playing around with.
Fortunately because we're using FlashCom, updating this is as simple as
changing 1 line: setFPS(X)
> what's the max number of users per world and any
> idea on overall bandwidth?
This is something that we're still tweaking. The systems are in place
for us to arbitrarily limit the number of people who can be in each
junkyard "room" at one time. Right now we're not using that so we could
potentially have hundreds logged in at once. One of the things we're
doing over the next several days is examining the lag issues for players
to see what the ideal number will be. Internally we've had 12 people
logged in at once with a good experience for everyone. I'm hoping that
we can keep it around that limit or more for the public at large.
> The MU 'experience' as it were is pretty bad for me - not
> sure on other people, but then again I'm still in Colombia -
> where's the server located?
I'm not sure exactly where the server is located. North America, and I
believe East Coast, but I'm not 100% sure. It's too bad the experience
wasn't very good for you. How many people were on at the same time?
Also, did you try out Blackjack? It's obviously a turn-based game, but
there are some instances where you'll notice the effects of lag
(visually, but it shouldn't affect the gameplay) I'm curious how that
experience was for you.
> Interaction between people is minimal - I like the effort to
> collide with other people but naturally it has it's
> limitations, particularly with not very smooth movement (2
> people walking towards each other will pass through).
Yeah, again this is something we keep going back and forth on. There's
just something strange about being able to walk through and/or stand on
someone though :)
> Basically gimme the lowdown, and in return, here's what I'm doing:
>
> Each room - max of 8 people. It's FPS so you don't see the
> others. Position / angle / state updates sent 4 times a
> second - I only send data that has changed from last update.
> I only ever interpolate, never extrapolate. This means even
> on an ideal connection you are generally looking at an image
> 1/4 second > old (since if I receive an update, even
> instantly, I use that as the end point for interpolating from
> the previous snapshot). But of course, you have to add your
> ping to this, and then each person is behind that by a
> minimum by an amount equal to their ping (so in my case
> people might be up to a second behind :( ) up to half a
> second (if their sending of data update to the server is just
> past the server sending it's latest positions).
Yes, if the environment is setup right for it, this method I think will
give you the least amount of visual errors for users. Unfortunately we
have several elevator objects and the visual inaccuracies are VERY
noticable. In our opinion even worse than the errors we have now.
However, it looks like I may need to go back to a system more like
yours, and just put in special case instances for elevators that will
"lock" remote avatars to the ground they are on. I was hoping to avoid
that . . .
> The plus side is you never get the walking through objects
> effect I see almost all the time on yours, and movement is
> generally always at the 'proper' speed. It'd probably help
> yours if the ground was flat, that'd cut out the majority of
> it :)
Yes, I think that's the biggest source of visual errors is when you see
players walking through the ground.
> The bad side is that of course ping fluctuates so
> motion can be a bit stop-start, although I'm hoping to sort
> this a bit more obviously.
I'd suggest setting up a system like ours where each remote user has a
target transform, and is constantly moving towards it. This way all
remote movements are smoothed out, and it should greatly reduce any
jerkiness.
> No collision with people! Just didn't think it was worth it
> really - might change my mind on this though since it's not
> that hard to ignore objects if they end up intersecting -
> although this is highly likely to happen should 2 people be
> moving - if 1 is stationary then proper collision isn't hard
> to work out :)
Yeah.
> I've yet to work out proper server load, but I'm hoping (probably too
> much) that using MUS TCP 8 people should run fine on a 56k modem.
I would hope so. As I mentioned we're using FlashCom and I'm not sure
how well MUS TCP would work for those speeds.
> I'll post up a demo as soon as I think it's stable enough -
> it's not far off now, although it's looking ugly as hell.
Looking forward to seeing it!
-Brian
Brian Robbins
Senior Creative Technologist, Fuel Industries
<http://www.FuelIndustries.com>
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
