New MMOFPS from NetDevil:

[Lantyssa]

Too much smoke and mirrors means three feet of visibility when anything significant happens.  It would get old fast.

Maybe if they have somehow designed a procedurally generated terrain deformation (Help, I sound like that Morgan fellow!) which tweaks the physics involved it could happen.  I cannot imagine an easy to reproduce algorithm that allows lots of freedom in what you can destroy.  I remain wary.

[geldonyetich]

NetDevil may not have ensnared the hearts of millions in either of their two earlier projects, but I'm not against the idea of a MMOFPS being made by a company with past experience.  Auto Assault's gameplay may not have impressed, but it was a pretty solid game on a technical level, delivering some fairly good content on a massively multiplayer scale.

Now, the question is if NetDevil can make an entertaining game or not.   It's kinda hard to screw up a MMOFPS, even Planetside has it's moments and it's basically just a striped down Tribes.  If they can make a game of the sophistication of Tribes 2, Battlefield 2, or Battlezone 2, and take it massively multiplayer, I'll give it a spin.  If they can surpass my expectation and make something even better, Huxley has some competition.

[sinij]

(Help, I sound like that Morgan fellow!)

Don't worry I have a graph.

[Sky]

Maybe folks should work out the issues of deformable gameplay-affecting terrain in single player games, work it up to limited multiplayer and then worry about how to do it to a bunch of clients.

Or zomg!mmo.

Sacrifice had deformable terrain in a networked environment (and so does Second Life?). You could cast a spell in Sacrifice and a volcano would grow up out of the ground.

Sacrifice had the best spells evar. Volcano and Tornado set the bar that's yet to be matched in any game I've seen. If it weren't for the stupid manawhores, it's be on my hard drive still. It got a lot of mileage on our LAN but got old because of having to dick around with manawhores. Wait, that didn't sound right.

[Morat20]

I wonder if they're attempting to use procedural generation to get around the problems of synchronization of elements. You'd lose a lot of the pluses of having a physics engine in your card, but if you could ensure that for a given state every client will generate the exact same result (AKA: I make a creature in Spore -- it walks the same for everyone who d/ls it as it does for me, but no one downloads a "how the creature walks" description) -- maybe you could do it.

But it'd probably look pretty crappy compared to what people are used to in single-player games.

Or maybe they're just using it as a meaningless buzzword.

[Stephen Zepp]

Can you please explain why having exactly same explosion is important? You blow something up, you get a lot of eye candy and then server updates your client (oh btw you got killed by flying anvil) with results. Big explosions take some time to 'play out', you might have enough time to update clients with significant outcome. That and you can tell client to show all or most possible outcomes that will end up as false positives ('eye candy' effects) when server updates with real data.

The problem is that the side of the building which just cleaved off is now part of the terrain.  If it falls straight down on one client, but tumbles then lands twenty feet away on another client, synch them back is going to look very strange for someone.  If the server decides something else, it is going to look odd for everyone.  Instead of people sliding across the landscape, the landscape itself is jumping all over the place.

One way they could hide some of the predicition and synching is by producing a lot of smoke, eye-candy debris, dust, and fireworks.  Really though, the obfuscation would have to be overdone and a significant portion of using the physics card would be lost.  (At least the explosions would be pretty.)

I got back late to the discussion today, but this is exactly the issue.

Or to make it even more obvious:

Put two "destructable" walls 5 feet away from each other and parallel. Put a moving vehicle (player driven, marked as A) rushing at the wall, and put a hapless victim on the far side:


A ---> ||...|| X

Now, let's have some common networking scenarios in an MMO environment:

Client A has bad packet loss :

--let's say that client A sees the wall at the last minute, and on his computer, he swerves to avoid the wall. On his simulation, no contact occurs.

Unfortunately, his packet doesn't make it to the server in time, and the server (who is authoritative remember) determines that the vehicle does in fact hit the wall. Assume for a moment that he was driving directly at the wall, and we see that the collision "explodes" the first wall, and given enough force, the flying bricks from the first wall then destroy the second wall, and the fliying bricks from that wall kill player X. All of these are world changing effects, and can't be "unwound" once client's A's laggy move finally shows up at the server. Not only that, but since Client A's simulation is (normally) not aware that it's de-synched from the server excessively, once the update packets from the collisions (and the resultant wall destructions) make it back to Client A, he gets a "WTFBBQ!" immersion breaking re-wind.

Client B has a very high latency and/or high packet loss connection:

--same scenario,except client A is able to swerve, and the server confirms, and sends out those updates (of client A's vehicle) to Client X. Unfortunately, let's assume that only the update from the very first swerve control input makes it to Client X...meaning that while on the server the vechicle swerves enough to miss completely, on Client X it swerves just enough to destroy the first wall, but the force given to the brick debris is not enough to destroy the second wall. Remember that for realistic gameplay, Client X has to predict what is going to occur, and modify their simulation approporiately.

Now, Client X hears the explosion on the other side of the wall, and triggers a bomb he has placed against the second wall, blowing it up. His simulation blows up the second wall, the first wall was already destroyed so the bricks go flying everywhere, ending up on top and around Client A's vehicle. He then runs across and up the vehicle.

However, of course on the server the first wall isn't actually destroyed--so the bricks...well, you get the picture I hope!

It's simply not trivial, no matter how much hardware you throw at it. And it gets much worse if you try to not network all the individual bricks, but instead use client side hardware to do the physics themselves, since they de-synch so rapidly.

[Krakrok]

I wonder if they're attempting to use procedural generation to get around the problems of synchronization of elements.

You could bake a physics simulation done on the server as a straight animation or script and just send that to the clients.

---

But hold up. Doesn't Second Life do synchronized physics? They aren't calculated on the clients. Which is why they can only have 40 users per server? If they were using a newer version of Havok I bet their servers might be able to benefit from the physics card.

And doesn't EVE do physics or is EVE purely fake client side physics collision detection?

[Stephen Zepp]

I wonder if they're attempting to use procedural generation to get around the problems of synchronization of elements.

You could bake a physics simulation done on the server as a straight animation or script and just send that to the clients.

---

But hold up. Doesn't Second Life do synchronized physics? They aren't calculated on the clients. Which is why they can only have 40 users per server? If they were using a newer version of Havok I bet their servers might be able to benefit from the physics card.

And doesn't EVE do physics or is EVE purely fake client side physics collision detection?

Server side physics (of any sort) combined with networking the results of the physics, and interpolating/predicting said results on the client is relatively trivial--it just carries the normal bandwidth restrictions inherent in mmo's in the first place.

The problem is that like I mentioned at first, and the press release implies, designers think they can get more, easily, by throwing hardware around, without really studying the low level issues.

[Typhon]

I'm confused.  What I read you saying earlier was that the final solution was calculated first, then the individual cards decided how the pixels look getting to that state.

Apparently my reading skills suck.

I guess my question is: why can't you do it that way?  Have final solution be calculated on the server side, and have the players cards fill in how wold state gets from pre-destruction to post-destruction?  If some folks are laggy, they will like see quick or "instant" destruction (not ideal, but as someone else said, better then we have now), but all machines will agree on end state.

[Miscreant]

What makes anyone, including the functional rich retards who gave them the money to develop this, think that NetDevil can make a good fucking Pong MMOG, much less an MMOFPS? They made Webster's add another line in the dictionary for the definition of inept.

Auto Assault was not technically inept, it is actually pretty well done.   They just guessed wrong to the questions "Who wants to be car?", "Is dark brown a good look for an MMO?", and "Is 'some post-apocalyptic something or other' enough hook?"

[bhodi]

I tend to agree. There's a big difference between being able to code a stable backend, engine, and client, and designing a fun game. You need both. If you keep the coders but replace the designers, you might have a winner.

[Stephen Zepp]

I'm confused.  What I read you saying earlier was that the final solution was calculated first, then the individual cards decided how the pixels look getting to that state.

Apparently my reading skills suck.

I guess my question is: why can't you do it that way?  Have final solution be calculated on the server side, and have the players cards fill in how wold state gets from pre-destruction to post-destruction?  If some folks are laggy, they will like see quick or "instant" destruction (not ideal, but as someone else said, better then we have now), but all machines will agree on end state.

Two things: user lag perception, and real network lag.

user lag perception: if the client does no prediction at all, you'd press a button and it could take up to 300-500 milliseconds (standard network) before your character would even move if the client relied completely on server "final solutions" before doing anything.

real network lag: if the server has to calculate the entire solution (not so slow), but then network each and every object that was modified back to each and every client connected, that's a huge amount of network update information to be transmitted.

I'll give an example with Torque since I know it the most:

One of the big reasons that Torque's networking is so strong, and user perception of lag is so low, is that we pack the update information to be sent into the absolute most compacted bitstream possible...whenever a developer can, he uses bits instead of bytes to deliver information. Network update packets are delivered to clients every 200 milliseconds (stock)--and that is actually a long time between updates when you think about it. We get away with this with strong, determinstic prediction and interpolation physics, which almost by definition are anti-physics, as in physics solution packages...and the reason for that is because we need to be able to interpolate/predict with the minimum amount of information transmitted, which completely precludes use of total solution solver physics systems.

We also only ever send packets that are roughly 200 bytes of data--and that's not a lot of data available at all when you are talking about hundreds and hundreds of objects. When an update packet is full, it's shipped off immediately, even if some object updates didn't make it into that packet. Any updates that got "skipped" will gain a bit of priority for the next update packet to be delivered, eventually assuring over time that all updates necessary are eventually delivered to the clients.

To sum:

Torque networking (an example, many other networking systems are similar) is optimized for user reaction, minimum bandwidth, and low network cost client/server simulation synchronization.

Physics solver systems require not just a lot of information, but all of the information to remain synchronized and accurate. There isn't any real capability for "rough interpolation that will be corrected soon", or prediction of client control object response to user input for accurate player control.

The biggest challenges any developers have when trying to integrate a physics solution with MMO-style networking is just about by definition the two are incompatible...so you need to find the middle ground where your networked physics don't cause rediculous bandwidth and user perception of responsiveness--yet still give the shiney "real world physics!!!11!one1!" that so many people think they want.

[Modern Angel]

I disagree. AA didn't work because it was Just Another Diku. That's fine, I like Diku (see: subscriptions, EQ2 (lapsed), WoW) but I don't need fifteen Dikus on my hard drive. People read between the lines of their press releases and thought deep in their lizard brains, "Oooohhhhhhh.... car that heals means PRIEST." I think the setting was just a small slice of it, though I (sadly) think it was part of it.

And that's why I don't trust them. They're saying it's going to be different when I don't think it can be.

[Sky]

AA sucked ass, it tried to be a diku when it should've been more like driving one of those Marauders in Planetside.

[Endie]

The trouble with moving away from the diku method is that you get MCO: when skill counts more, eight people win all the races and everyone else's permanent loserhood becomes obvious.

[Modern Angel]

They didn't have to do that. Twisted Metal was hell on wheels fun that wasn't difficult to master. Add in some die rolling mechanics beneath the hood to fudge it just a little bit and you have your game. That's not to say that AA was going to sell a million copies off the bat or anything; I tend to think that if it were good you would have an EVE situation where word of mouth turned it into a hit after people got over the weird premise.

[Sky]

The trouble with moving away from the diku method is that you get MCO: when skill counts more, eight people win all the races and everyone else's permanent loserhood becomes obvious.

That's a very limited example, since races are very win/lose based gameplay. In games like UO and Planetside, even complete retards and newbies can add positively to gameplay. Then again, I'm a non-competitive type and like games that don't punish with death penalties and whatnot, because for me the gameplay is the thing, not the win.

[Typhon]

Physics solver systems require not just a lot of information, but all of the information to remain synchronized and accurate.

Thanks, that's clear.

I guess in my head I was assuming that the actual terrain would be fixed, and buildings/walls/stuff would be dynamic (which is not what you were talking about, my bad) and a "vector" would be communicated to each client that was a lookup for a solution for that building.  So I guess I was assuming a certain level of "cheating".

[Mantees]

And I'm dubious that terrain will be as deformable as they imply in the end.

Well, Wish is a low budget MMORPG and they seems to have a good example of deformable terrain. So why not?

[Venkman]

Because Wish closed two years ago?

[HaemishM]

And sucked a whole army of goats?

[Sunbury]

They are talking of doing all these physics things with destructable terrain - yet they could not get the physics correct on the main object of play in Auto-Assault!

The reason I didn't buy it (in both senses of the word 'buy') is half the game felt like 'god mode'.   You could turn the wheel sharp to the side and the car would just make a wider turn - not flip over or skid.

You could drive off a cliff at top speed and slam into a granite wall - and gently land on the ground and drive off.   OK so they are simulating magic or super-tech cars --- but then how can a guy in shirt-sleeves with a 38 pistol damage my car?   Or how can running into that guy (if its higher level) damage my car?

I don't expect a perfect real world model, but I do expect some consitent model!

[UnSub]

Necroing this thread to say:

NetDevil have updated the site regarding release date (this year), price (free) and with movies / screenshots.

[Engels]

I live for dynamic cloth.

[Akkori]

Is this similar to BF2 or 2142 in it's multiplayer gaming?

[Pennilenko]

Techy stuff from multiple posts

Thank you, I learned alot.

[HaemishM]

Did anyone else think that video mostly looked like dogshit? A few of the buildings disintegrating due to shooting were cool, but the models were assy.

[Mrbloodworth]

umm...i do not read anything that says its an MMO, looks like a FPS to me, and thats what they say it is.

Networked deformable terrain? Lots of examples of that...

[schild]

Netdevil.

[Mrbloodworth]

Netdevil.

I know but that doesn't mean they only do MMO's... (even if thats all they have done)

Don't you think MMOFPS would be all over the press releases ETC?

[schild]

Netdevil.

[Mrbloodworth]

Netdevil.

What are you trying to tell me here?

[Venkman]

Heck, that actually looks pretty fun. Whether it'll be any good remains to be seen. AA without the useless ground game (and free) woulda been ok for a bit as a car-FPS-lite maybe.

Maybe it's because I'm on a extreme-mod COD2 binge, but having destructible buildings would radically change things, like those nuts that go for the turrets just outta view and are too far away for grenades.

[WayAbvPar]

Netdevil.

[Grand Design]

Netdevil.

What are you trying to tell me here?

I think that he's trying to say Netdevil.