Quote:Original post by hplus0603
I have heard of people trying it but giving up on it. The main project actually using it is Wonderland, which is currently undergoing a major rewrite.
I don't like it because it doesn't support ad hoc queries, and you can't use it for real.time properties (only transactional state).

I'm trying it out now to get a sense of what would be involved to create a multiplayer version of my next game. Could you elaborate on the problems you're aware of?

What are the complaints you're hearing from people who have given up on it? Are they going to a different platform or rolling their own?

The above analysis is fundamentally flawed.

The flaw is that it misunderstands the Project Darkstar model. Minor state changes are simply communicated between clients over the channel system. Transactions are only invoked for game-state significant changes.

The proof of the pudding is in the tasting, as they say. You can see a demonstration of this model in action by downloading the "Project Snowman" demo action game from the PDS community site. It has been tested to scale to 3000 simulated users and 2000 AI opponents on a four-core AMD server.

In general you will get more knowledgeable responses to questions about project darkstar in the PDS community forums:

http://www.projectdarkstar.com

P.S. Many thanks to the moderators for resurrecting this thread so I could post this response.

This was a reply to other thread which got locked or deleted in between.

Quote:Original post by jeffpk
The flaw is that it misunderstands the Project Darkstar model. Minor state changes are simply communicated between clients over the channel system. Transactions are only invoked for game-state significant changes.

What if all changes are significant? For example, fully deformable terrain, full physics interaction?

The fact that MMORPG model can scale to 3000 users on single box is not new. Single core can support thousand, or more, many emulators prove that, the Ultima emulator written in C# supposedly holds that many. And as long as the world can be split into disjoint pieces, achieving thousands is not really a problem.

Quote:The proof of the pudding is in the tasting, as they say. You can see a demonstration of this model in action by downloading the "Project Snowman" demo action game from the PDS community site. It has been tested to scale to 3000 simulated users and 2000 AI opponents on a four-core AMD server.

I'm more impressed at the client being able to render 5000 actors at the same time. I know that even the best video cards have trouble rendering this many units. Or are those players not within range or visibility of each other?

Users metric doesn't say anything. Chat servers have 10,000 or more per thread. What matters is the complexity of interactions and overall complexity of simulation. That post talks specifically about physics heavy simulation, which are not trivial to distribute.

The description makes the game sound like Scorch/Worms style gameplay. Those are trivial to scale, since each client only emits an action once every few seconds.

Is there a server running anywhere, where one could join and test this live?

Edit:

">I found this. Seems to be an action per second for attack + movement and no collision detection. Picking up the flag and turning also seems to take a second or so. It looks as if each actor performs one action each second.

I'm not bashing the project, I'm just trying to figure out the exact simulation model.

This was a reply to other thread which got locked or deleted in between.

Quote:

Quote:Original post by jeffpk
The flaw is that it misunderstands the Project Darkstar model. Minor state changes are simply communicated between clients over the channel system. Transactions are only invoked for game-state significant changes.

What if all changes are significant? For example, fully deformable terrain, full physics interaction?

In general "game state significant" can be defined as "that which if cheated changes the outcome of the game in any meaningful way". But that is a somewhat circular definition.

In the end it really depends on your specific game. For instance in Snowman all changes in motion vector direction are significant but all the traversed space along a given vector is not because it is easily calculable at run-time from the point, time and vector of last change. I use a similar system for my DarkMMO project (http://worldwizards.darkmmo.com) which has had a lot of discussion already at the PDS forums.

To answer some of your other questions...

No reason why deformation of terrain couldn't be sent if it is actually significant to the game play. If not, then why bother. Let everyone's system simulate it locally.

The fact of the matter is that physics in MMOs is a largely un or at least undersolved problem. Different MMOs take different approaches. City of Heroes is the only MMO game I know of that does true server side physics. They do that *only* for movement. Everything else is locally simulated window dressing. They had to do server side physics for movement because they wanted to have flying, leaping tall buildings, etc and make it cheat proof. They accomplish this by running a completely separate and independant physics process from their main game server. There is no reason you could not do the same with a Darkstar based app.

Age of Conan (and many others) just give up and run the physics on the client and hope people don't cheat it.

Quote:
The fact that MMORPG model can scale to 3000 users on single box is not new. Single core can support thousand, or more, many emulators prove that, the Ultima emulator written in C# supposedly holds that many.

Comparing the processor and system resources needed to run UO to that required to run a 3D action game is a lot like comparing the number of users an LSI-11 can handle playing "trek" to a modern FPS server. They are a totally different scale of problem. UO is fundamentally a text mud with some over-layed 2D graphics. MMOs since Everquest have had a one-zone-per-server model because of the heavy burdens of managing a 3D environment.

Quote:

Quote:The proof of the pudding is in the tasting, as they say. You can see a demonstration of this model in action by downloading the "Project Snowman" demo action game from the PDS community site. It has been tested to scale to 3000 simulated users and 2000 AI opponents on a four-core AMD server.

I'm more impressed at the client being able to render 5000 actors at the same time. I know that even the best video cards have trouble rendering this many units. Or are those players not within range or visibility of each other?

Note that I said "simulated" these are headless clients sending to the server and receiving from the server all the traffic a player generates and receives. (This is an absolutely standard way in the MMO industry to do first-order scale testing. Even at Sun it would have been hard to scare up 3000 players at once.)

Quote:Users metric doesn't say anything. Chat servers have 10,000 or more per thread. What matters is the complexity of interactions and overall complexity of simulation. That post talks specifically about physics heavy simulation, which are not trivial to distribute.

Exactly, which is why these were really simulated players, doing the actions a real player would do, and real production game code on the back-end handling them.

I made my first name in the Java space by writing one of the definitive books on Java Performance Tuning. (http://java.sun.com/docs/books/performance) before that I had 15 years in the game industry and I've been back doing game coding for the past 2 years. Trust me when i tell you I know the difference between a real benchmark, a micro-benchmark, and "benchmarketing."

As for physics, I answered that already for you above.

Quote:
The description makes the game sound like Scorch/Worms style gameplay. Those are trivial to scale, since each client only emits an action once every few seconds.

I'm not going to spend any more time arguing pointlessly the difference between two-d ascii-graphics and 3-d action games. Either you already know that's ridiculous or I wont change or your mind. Download and run the real game and then Ill be happy to discuss the tradeoffs we made in its design and implementation.

Quote:
Is there a server running anywhere, where one could join and test this live?

Quite a few of the community members have it set up and running so you might try asking in the forums. Not being in the game operation business, its not really a good use of the PDS team's time to maintain a game site. They are busy baking a cutting edge piece of research technology. But the example is there for you to download and play with on your own and it was shown live at last AGDC.
(I don't know if it will be at this year's AGDC as, as I mentioned, I'm back on the user side of the fence these days. But again you could ask the team at the PDS site.)

[Edited by - jeffpk on September 10, 2009 1:22:22 PM]

Quote:
Edit: I found this [www.youtube.com]. Seems to be an action per second for attack + movement and no collision detection. Picking up the flag and turning also seems to take a second or so. It looks as if each actor performs one action each second.

I'm not bashing the project, I'm just trying to figure out the exact simulation model.

Actually, its an event-driven model, which is a big part of the trick of achieving server side scale. Like just about every MMO there is server side collision between actor and environment but not between moving actors. This turns out to be a necessity due to the imperfect knowledge a client has of another player's position during motion. (Einstein at work. Think of lag as "light seconds" of distance between users. Exact knowledge of the physical position of a moving object at distance is an impossibility.)

Some MMOs again cheat this by doing local blocking of player v. player. This is especially true of MMOS that do local physics. (AoC as an example, again.) but we opted instead to really expose what was an optimally uncheatable game model.

Environment collisions are a clever dodge based on our (VERY simple) server side vector physics model. We calculate when a moving obejct is GOING to hit a server side object and set a callback event. When it rings we check to see if the prediction came true or a change in velocity changed the motion.

Snowballs are effectively beam weapons. We use the vector motion model to determine if the line segment (beam with range) currently intersects any combatants.

Most problems CAN be reduced to events present or future. For those that can't, you can escape down to the Service level of the system, which is kind of like drivers in an OS, and those can do anything. The caveat is that they lose the nice distribution properties of app code and, if they are going to distribute load, have to do it themselves.

EDIT:

Important distinction here btw...

The PDS is not a game server. Its a container system for near real-time event driven apps. Which is to say its kind of like a "game server OS' that does its best to solve all the really hard parts of the problem for you. (Persistence, load balancing, fail-over, data integrity.)

The Darkstar code model can be summed up as a "low latency high job rate" event processing system where each event is atomic and all Managed Objects are (almost) transparently persistent, supported by a highly efficient publish/subscribe channel system. Underneath that is a second layer which I referred to above as the Service layer, which has a traditional code model.

All the rest of this are examples of how you USE this coding environment to simplify your MMO coding life.

[Edited by - jeffpk on September 10, 2009 4:47:02 PM]