Yes, but they use a huge number of individual servers that do not interact with each other. That’s the key difference! They don’t even access the same files for identical data streams, there are lots of copies because the servers can’t all read simultaneous from only one drive. You are studying computer science for gods sake, how can you not know that??
Yes, procedual or not, it would be complete news to me that any game regularly streams graphics assets during multiplayer sessions, that doesn’t even make sense (not including a background downloader of course which downloads files from a whole other server). I agree, continuing this debate is useless.
Lets wait for the kickstarter video. I am sure they are aiming towards 100 - 200 max players per battle. Hey, maybe I am completely wrong and by some dark magic we will see battles with thousands of players.
But an MMO across a galaxy size does not need to run on a single server – each system could be a shard, or even multiple systems per shard based on how the server performs. So when you have a battle, more servers take parts of the system and handle the game logic there; if you have a group of lonely explorers, a single server can probably handle a large number of independent systems. It is a matter of building good scalability and plays into concurrency issues etc. You don’t need to have the whole game run in a single main game loop; only the database must be persistent, and that is a solved problem (see any search engine or database service).
Wait, did anyone ever say anything else? They’ll probably be aiming for a higher number for the MMO (which I have been arguing for based on your opening post), but for I:BS I think the number was as you stated.
There was this experiment about three years ago for a “1000 players FPS”. IIRC, it was 2 teams of 500 respawning players, reportedly atrociously unbalanced and not very fun, but it was a success as they ran a 1000 players battle fluidly, and didn’t require a particularly high-end connection.
So it’s definitely possible to have hundreds of players in one battle, as it was done already. Given that Flavien and Keith clearly know what they’re doing, I don’t see what’s unreasonable in their goal there.
No-one said thousands. Instanceless servers are possible via sharding. EVE doesn’t have instances, but splits the load between servers to keep things running all smooth-like. Keeping data consistent between shards could be tricky, especially if you want them distributed geographically for latency issues, but it’s not like that problem hasn’t been solved before.
Define friendly. The state of the station may change after the player leaves it. That’s what I meant when I said that the system can be exploited. Attack a station. Have the players inside transported to your station by making it friendly (or do it through a proxy pretending to be friendly. Wait for target ship(s) to leave station. Make station auto-attack nearby “hostile” ships.
Obviously I die in CounterStrike. But I expect that I will, because I’m not the best FPS-gamer in the world. It’s a frustating experience too sometimes, as I lose my gear and don’t get so much money in the next round.
But what it does is teaches me caution. If I know I’ve not got great equipment, and my enemy is better equipped, I will play a lot more carefully and move more carefully, but ultimately the reward at this point is greater than the risk. If I am well equipped, I know I will generally be able to take on an enemy I encounter. If I get injured, I will attempt to retreat from battle until I can seek advantage or the round ends, in order to preserve my gear and funds. I’m fine with having a similar system in games like Elite and Infinity if the combat itself is relatively fair.
Perhaps. But it depends on the reward. If large corps have some kind of benefit for fighting over stuff (like resources on planets or profitable trade lanes), then those corps will be more than happy to wage war to get those rewards. EVE works in a not too dissimilar way, with the many player corporations fighting to control territory, even though the cost of failure and the cost of losing ships is high enough that it has a measurable real-world monetary value on it. Some of the epic battles of the like reported in gaming media have run up expenses in the thousands of pounds range.
Penalty of dying can be high without putting off larger battles so long as risk of dying is low.
If you need to send a big chunk of your fleet to chase down and destroy a single fleeing ship that’s had it’s weapons disabled, you risk loosing the battle. People would let ships flee until the diehard core of the fleet slugged it out to the bitter end or engaged in a full retreat and covered each other in getting away. It would make dying in a large fleet battle incredibly difficult to do unless you were grossly incompetent or were willing to sacrifice your ship for a greater cause and knew it was going to happen ahead of time.
If you can give them a few million dollars American no strings attached I expect them to get on it. But like they said, doing I:B first gives us (them) practices. If we do well enough on I:B, learn enough, then we (them) have the experience to make a MMO.
And that’s all I read of your tomb. And that’s not a quote.
*Just wanted to point out that it’s standard practice to use square brackets when adding additional information to quotations (despite your statement of it not being a quotation, you presented it as such) and refer to referred parties by name rather than ‘they’ or ‘them’. Ideally, if you were quoting someone directly, it would look more like this:
“If we do well enough on I:B, learn enough, then we [I-Novae Studios] have the experience to make an MMO.”
Sorry, but this sort of thing has been driving me mad on unprofessional gaming news-sites lately.
Please don’t use my name for spreading lies. You’re off by an order of magnitude, and as mentioned those were the brute force “send everything to everyone every 50ms” numbers.
How am I off exactly?
Sending 1000 users each a stream of 7 MB/s amounts to a total upload of 7 GB/s.
This is not off by any means. I read that the total upload of the 1000 player fps was 256 Mbits/s spread over 8 with each other connected servers. This game used a complicated system to lessen the load and the rate of the updates wasnt that high. Btw: This game got a world record with that technique, which means it is not easily replicated without knowing the workings of the code.
I think you are using Bytes instead of bits so 7Mb and 7Gb is what @Runiat calculated instead of 7MB and 7GB that you are claiming and that is 8 times the data.
I don’t think that a game studio should assume user transfer rates anywhere above 1Mb/s, lots of people have such lines.
You were using a capital “B” which is a denotation for a Byte, a small “b” is a bit, so you were off by the difference between a bit and a byte which is 8x.
Such a small mistake and such a big difference, it’s common to make that mistake though.
Great. Now fix it, or remove mention of my name, please.
The reason for using 64 bits in my example is that one of the defining characteristics of the INovae engine is 64 bit location precision.
Which is where “not brute forcing it” comes in.
For example, there’s no way consumer hardware is going to render 1000 ships (or even 100 ships) in full level of detail, so I’d expect many of the smaller and further away once to be little more than dots. The obvious thing would be to remove the orientation data from their packets as the orientation of a dot is largely unimportant (~15% less bandwidth, now doing 6Mb/s).
Beyond that you could probably reduce the frequency of updates and infer it’s velocity vector by analysing it’s last few known locations (at least with a high enough precision to fool someone who isn’t paying attention to it). Now using 1Mb/s.
Speaking of rendering techniques, you could cull all ships hidden behind other objects or simply out of your view (BOOM 50-80% average bandwidth reduction for less than 512kb/s), reduce the update frequency of ships at the edge of your view, etc. etc.
It’s really not that hard to make a 1000 player battle take a few hundred kbit/s for each client, and getting a server with a few hundred mbit/s of bandwidth is just a matter of being willing to pay. If you’re not willing to pay… well, then you need to get really creative.
It might be possible @Runiat, I remember some discussions from the old forums and you seem to have covered it pretty well. I think one of the things that we struggled to come to terms with is the behavior of players, if a player really wants to go to a spot where there are too many people, there needs to be a hard barrier that prevents him from doing so when the server or client can not handle it. Gameplay mechanics can go a long way to ensure that players are distributed, but they are not a guarantee.
This however is still a huge claim, especially without any hard evidence like mass testing, it’s theoretical at best.
Funny @ThornEel, but I remember that test being a complete failure, even remember some accounts of the people playing it, they couldn’t move and the server crashed a few minutes after opening. There was some critique from the professional side too, with people arguing that they were using existing techniques and failed to describe their advancements in any detail. Anyway, seems nothing came from it, that was in '12 and they only ran that one test iirc, so something isn’t right there…
Well, you can have a hard barrier, or you can use EVE’s system of slowing the game clock, or you can use ArcheAge’s system of simply not rendering more than a certain number of characters.
Admittedly I’m really not a fan of either of those approaches, but if a game is designed to encourage gameplay of up to however-many-players-it-can-support in one location, dissuade larger numbers than that, and has a less-than-ideal-but-better-than-invisible-wall backup plan in place for when people decide to gather the entire server population in 1 spot just to see what’ll happen… well that’s about as good as it’s going to get.
I would prefer a combination of gameplay and time dilation.
Battlefield and Planetside have shown how map design can mold the flow of players.
A high concentration of players at one spot weakens defences somewhere else and smaller groups of attackers are able to flank. This in turn persuades defenders from the main battle to split off and retake the lost map area.
If for some reason a Battle goes over the network limit (Which was epic when it happened to me in Planetside, though a little laggy)
Time dilation can be used in such a situation. That will further allow forces to flank as the people inside the “time bubble” can now react even slower. This is a huge incentive to splitt the battle and still allow huge battles.
