more importantly... why does the server need "physics"....

shouldnt the server just compare entities and update based on that?

a server needing to run its own physics simulation doesnt sound right.

Quote:Original post by AverageJoeSSU
more importantly... why does the server need "physics"....

Because you pretty much have to assume the clients as being unreliable, else you're promoting a high probibility of false data. It'd be too easy to hack the system if you client data was always assumed to be correct and safe. The server needs to be the final autority on what is happening, and the only way it can do that is by running stuff like physics itself.

Quote:Original post by bzroom
The first last only project i used with signals and slots was a build nightmare. I dont know how much of that was attributed to the signals and slots, i'd say not much, but it definitely left a sour taste in my mouth.

I'm not a Qt addict, just used some of their tools recently and reading a bit more about some others made me believe that this could prove handy. But definitely things with slots and the like would require more thought.

Quote:Original post by bzroom
Besides signals and slots, my main point on your topic is that you can't make a useful engine without knowing how to make a game first. The high level architecture which doesn't mention any gameplay mechanics leads me to believe that you dont.

There's a high chance indeed that I don't.
But I would fiercely argue against the fact that any diagram not showing something would lead anyone to believe anything ^^

Quote:Original post by bzroom
but if you like pain then by all means proceed

:angel:

Quote:Original post by EJH
The client probably needs no threading at all [...] unless [...] or a seamless world streaming scenario.

you named it :)

About what you said for the server side, well :
Like the client, it has to perform seamless decompression of terrain, then there is physics too, as it was mentioned by another poster (yes, on the server side), which I may want to keep tiny at first, but who knows how heavy this could become ? And there is also an A-Life simulation to run on the whole world.

But anyway, I'm in the process of re-thinking the threading approach on both sides in the light of what phantom pointed out about tasks and stuff.

Quote:Original post by AverageJoeSSU
more importantly... why does the server need "physics"....

Quote:Original post by Rattrap
Because you pretty much have to assume the clients as being unreliable [...] The server needs to be the final autority on what is happening

Precisely. And then some :
The amount of data going through the network (which is the main bottleneck, as was pointed out by EJH) needs to be kept small. I believe that in NeREIDS, the server side, in order to keep on with what's happening, needs to run a simulation of everything (from physics to RPG rules) based on a very lightweight representation of the player's intents, in order to know if the chair that was thrown by A towards B's head will twirl and present leg-first before hitting his skull. The same kind of algorithms have to be present on the client side, so that they can also extrapolate from lightweight representations of events.

[Edit] @EJH and lightbringer, about a server GUI :
I envisaged some kind of austere admin GUI on the server, yes... but this is waaaaay below a lot of hot stuff on my list of "to-be-addressed" issues ^^.

Quote:Original post by ddn3
Somewhat offtopic , what did u use to make those charts TiPiou ?

MS Visio mostly.

[Edited by - TiPiou on March 17, 2010 1:01:34 PM]