I'm going to add 'interraction' with objects tommorow for a start , creating objects by request from the client...
I'm giving up on the idea for Dead reckoning , because I do not know of another way to move objects without c_move or ent_move (except for non-collision my.x += ) but maby I'll remove gliding,so that it can send & update the same pos as predicted. I'm not shure yet.
fastlane , how many people are on your team? sounds like a very big project

Quote:

---

fastlane , how many people are on your team? sounds like a very big project

---

For 4 years, it used to be just me. After 3 years, alone and in about 3 months of doing nothing else, I managed to create a viable MMO prototype that laid the groundwork for what we have today.

Then last year I got outside funding and an office and hired two programmers part time from local universities. For about two months this year I had 3, then dropped to 2, and right now I'm technically at 2 though 1 is in grad school and hasn't done much. These programmers revamped what we had and created the version we use today. So on average, I've had two programmers at any one time.

Since art and music is a low priority compared to actually creating the tecnical side of the MMO, I have always outsourced both. Here, I usually freelance people to handle these tasks. On average, I have about 5 people to help me with art and music.

I'm no storyteller, so I have used some of my funding to hire story consultants. This is a two woman team (The Writers Cabal) whom I've known for a while and they are currently helping me create a viable story for my educational game.

Finally, I have a game consultant (Dr. Richard Bartle) and a business consultant. The former is the grand-daddy of all virtual worlds and helps me with gameplay and virtual world design issues. The latter is helping me make a business case for my game so I can get more investment.

So in the last year, my team has been, on average:

CEO: 1
Prog: 2
Art and Music: 5
Story: 2
Consultants: 2

or about 12 people as part of my team though only the programmers work on this constantly.

A "lagging behind" method, as mentioned is suited the best for most
projects, as the displayed paths of the entites are correct.
Just the time-offset is the negative point.

Using a DR System can handle the time-offset, so beeing in "sync" with the actual
serverworld, but will always create nasty jumps on the client, when the entity
is moving on a non-predictable path. (not in a straight line)

I see DR only important for very fast gametype, that require a high precision
(Shooter, racer).
All others can use a more precise "lag behind" method. (RTS, tactical games)

Just to be clear, the "lagging behind" method means that that you send to your clients an update that is X number of timesteps behind so that the clients are always "lagging behind" the simulation, right?

If that's the case, there is a better explanation than "precision" for your correct choices.

In an RTS, you aren't aiming and the time response is not "real time". That is when you send 10 tanks against 10 hummers, each vehicle will fire on it's own and the path it takes is set by the controlling algorythem and thus both are completely predictable. As well, when both units engage in combat, you won't be doing any "fine tuning" and if you do, a difference of 200 ms won't amount to anything.

But in any game that has human interaction (FPS, RPG), then the movement and aiming is set by the player and thus unpredictable. Under this circumstance, the computer has no idea what you intend to do and thus it has to DR to "best guess".

So human control is one factor. As well, if your game has high inertia (very large mass or very fast), then it become easier to predict where it will be and thus you can adopt a lagg behind method more easily. Therefore a racing game could in principle be well served by a lag behind method because there is little change to the simulation in each frame. In counterdistinction, a game that has low inertia (low mass or slow speeds) would require the DR since it is likely to violently change direction based on collisions and interaction to the point where the lag behind method would fail to capture the correct simulation state.

I just wanted to clarify that "lagging behind" is only a valid technique when there is little human interaction with units and/or high inertia while DR is valid when there is a lot of unpredictable interaction and/or low inertia. It doesn't have to do with the precision but note that a RTS has high inertia and no direct human control while a FPS has low inertia and human control... I think this is a better way of seeing and deciding which routine is better for your game.

I'm updating 4 times per second and the traffic stays pretty low so far.
I dont think you should aim for 56K modems , because when you finish your game they might be out of use...all my friends have better connections for lower prices.

Quote:

---

...you sometimes miss the enemy...
...But since I'm not doing direct traces, but instead I use a scan and do back-traces, the whole thing is pretty tolerant.

---

You scan from one player for hit and then scan again from the other player to see if they're close enough ?
And , what does sometimes miss the enemy That sounds like you're doing FPS...

PS.: I've slowed down my mp development for a few days , because I needed some definitions of my concept. I now have the full list of features (What the player can do in the game) for my game , but I'll probably add more options later. I'm currently thinking how to manage the players. So far I have a skill to identify the ent as a 'player ent',but still testing to get some client ID's. Any ideas ? Oh, and btw , the MySQL dll is for older versions of MySQL , so dont count on that for registering/logging already tested and failed.

Luckily I have an old concept which I'm now partly porting to Lite-C and multiplayer, so I don't have to sketch everything out again. Nonetheless I'm basically rewriting evreything - the A5 WDL code is an ugly bastard from hell

I'm not doing a FPS, but indeed there are realtime short ranged weapon realtime battle sequences. I do a scan, because I can scan whoel segments - which allows multiple attacks at the same time without doing several dozens of traces.

Unfortunately scan goes through walls, so each scanned entity checks back using a trace whether the hit counts (no pbstacle inbetween).

Sometimes update is not fast enough and therefore the server shows a too much different situation than the client which owns the attacking player.

To overcome this I've hacked some sort of fast update (comparable to ent_sendnow) which I can trigger sends at important moments, but it makes the multiplayer code more and more messy.

I already have a whole lot of functions and slowly its gettings difficult to debug...
I'll continue until I fail - don't think this will take much longer

I'm still using C-Script , but from what I understand 3DGS is limitless with lite-C in every aspect of programming
You're talking about what I called 'forced' update in some of my posts I'm wondering how did you do it? I did it regulary,like my usual updates,but called at an exact moment between 'regular' updating. The only difficult thing (wich wasnt very difficult) was to make it run no more than 3 times between regular updating at (like regular updating) certain intervals. (Eg. splitting the time between a regular update to 4 parts (the fourth being the regular update) and sending only on the other 3 exact moments if needed).
The only thing messy using this concept is a counter in my regular updating that counts the frames passed since the last regular update in order to synchronise the forced updates.
If you run into problems , I'll gladly help you with my (still very limited ) knowledge of MP programming (I mean for debugging).
And , if you fail and decide to abandon that project (I hope not), I'd like to offer you to team up on a 'learning' project for MP programming Turn-based concept for 2 or maby 8 players (not much of a diffrence).

I have a coutner running which times the regular updates. If I need an update at once, I just reset the counter

(reseting the coutner means skills are sent)