|
Khalzaam a publié le 2 février 2016 cette actualité sur le site Star Citizen :
Citation :
|
02/02/2016, 17h53 |
|
Aller à la page... |
[Actu] 10 questions pour Chris Roberts - Episode 76
Suivre Répondre |
|
Partager | Rechercher |
Duc / Duchesse
|
Merci pour la trad
|
02/02/2016, 17h53 |
|
Bagnard
|
Le gag continue.
|
02/02/2016, 19h27 |
|
Sisters Of Mercy |
Voir le profil public |
Trouver plus de messages par Sisters Of Mercy |
#57536
Invité
|
Faut vraiment qu'ils changent le générique, dur de faire plus austère.
|
02/02/2016, 20h47 |
|
#57536 |
|
Stop penser a ca, vous pleurer tellement a longueur de journée serieux =)
Qu'est-ce que c'est pénible... |
02/02/2016, 21h31 |
|
|
Il est cool, ce TFTC ! Merci Khalz !
|
02/02/2016, 21h35 |
|
|
oh à coup sur ca dépend de la méthode de contrôle qualité appliquée!
|
02/02/2016, 23h47 |
|
#348657
Invité
|
Message supprimé par son auteur.
|
03/02/2016, 00h36 |
|
#348657 |
Roi / Reine
|
Citation :
http://massivelyop.com/2015/10/21/as...n-controversy/ plutôt optimiste du coup. et aussi ce post : " Been thinking of the 64 bit implementation on Star Citizen and how it would impact Star Citizen as an MMO and to be honest struggling to see how it would be implemented. Let’s look at how CIG want to implement their Persistent Universe and how large it is expected to be. Looking on their website I’ve come up with some calculations. I’ve simplified the figures below. Based on how I knew things worked at the time: Based upon their 32 bit figures and their universe explorer using 64 bit implementation at minimum the universe or grid in 3d space would be 15.2GB (assuming nothing is moving, and assuming all data is static, this is a very conservative estimate here). The maths behind this is the basic grid of data under 32 bit (this was calculated by CIG for their previous plans as 500MB maximum per instance (to hold the world only when it was literally just the 3d matrix “the world you fly around in”) that was based upon the projection of 50MB per grid, that’s 10 grids at 5000×5000. Now under 64 bit it would be twice the size (100MB per grid – assuming the grid is the same size at 5000×5000), now the universe in the PU map is a grid size of 152, that would mean 100MB * 152 = 15.2GB. This is VERY big. Now the above is just the world size in 3d space without any objects loaded into memory, assuming nothing is being streamed (unlikely on the server side) this means one instance at minimum would be occupying 15.2GB of memory alone just for the 3d world in co-ordinates, the trouble would come in the form of adding objects into the world (space stations, planets, NPCs), assuming conservative estimates again, let’s say each object has a 32x 32 bit array (under 64 bit) of properties (i.e. IsPlanet, IsNPC, Team, Description, NPCName etc) that would be 8MB per object unstreamed, based upon the size of the world 10,000 entries (again very conservative), 8MB * 10000 = 80GB! Now you can under IsPlanet, IsNPC you cut this down to a boolean after speaking to some devs I know – BUT you are still left with 32 bit arrays taking 64 bit address space. I base the 8MB on the 32 properties set in the cryengine under the modifications for Star Citizen – I would say 4-6MB could be shaved off but I am going by their figures. Now let’s say for arguments sake you can get past all this (or the above calculations are wrong, or way off), you still have to account for the rest of the server software (connections, overhead, protocols, main API calls, logging, persistent server data held in memory, is AI handled by the server?, overhead), you would add at least 50% to any figure you come up with (if you have any sense so you don’t run out of virtual memory and end up using swap), so going with the above figures 15.2GB + 80GB = 95.2GB + 50% = 142.8GB personally I don’t see a single instance of this being possible on one node. We have the problem and thinking about the solution, how about we have a number of the grids loaded on a specific instance. i.e. 10 grids per node. Now it becomes possible to host, BUT you have to redo your architecture and your platform. Let’s assume for arguments sake we have done this already. 100MB * 10 = 1GB for the world alone, 80GB / 16 = 5GB for objects + 50% = 9GB per instance BUT over 16 instances, this becomes very expensive, plus it only hosts a number of players per instance with a cap – let’s assume we add 16 players per instance, how many instances would we need to allow 100 players to play in the same area at any one time? It would be 6.25 duplicate instance of the same grids, say 6 to round that number down (conservative) 16 instances for the entire world * 6 instances for the amount of players in each area = 96 instances (very very expensive) considering the memory requirements for such a setting would be 96 * 142.8GB = 13.71TB and this is for less than 100 players in each instance, limited to 96 instances. I cannot see how this would be possible without massively scaling down the persistent universe size or using nasty workarounds like streaming data from disk on the server (very bad (may lose data)), or storing areas where the players are not in to hard disk (slow), or running from SSD storage to stream to memory where needed (sensible but would be prohibitively expensive). It would also be very costly to maintain. " Qui lui est plutôt négatif. Après je ne suis pas un spécialiste de la question, mais ça semble dur de trouver des infos sur le sujet sans tomber sur des gros trolls ... Et comme dit dans le lien : "But Smart’s vehemence is less baffling than David Braben’s apparent silence, and the gaming press either neglecting to ask him for comment or failing to elicit comment. If anyone outside CIG is in a position to judge the challenges Star Citizen faces, Braben’s name would surely head that rather short list. " Si il y en a bien un dont l'avis sur le sujet serrait intéressant ça serrait celui de David Braben. |
03/02/2016, 01h18 |
|
Légende
|
Je trouve super-inquiétant que le code réseau n'en soit qu'à ce stade...
|
03/02/2016, 10h36 |
|
|
Moi j'aimerai avoir l'avis de Derek Smart sur la question apparemment il s'y connais bien en jeux video !
|
03/02/2016, 10h37 |
|
|
Attendons qu'un web dév de CMS nous éclaire davantage. C'est plus sûr ainsi.
|
03/02/2016, 11h20 |
|
|
Danke Schön pour la trad
|
03/02/2016, 15h15 |
|
|
Citation :
|
03/02/2016, 16h18 |
|
|
Citation :
|
03/02/2016, 16h40 |
|
Prince / Princesse
|
|
03/02/2016, 17h43 |
|
Prince / Princesse
|
Oué un web dev de CMS qui a déjà fait des applications réseaux client/server en Java (saisie de schéma électronique à plusieurs en temps réel + tchat) et en C++ (mini jeu Xbox 360 juste pour le fun en directX) et des bots IRC en PHP avec des tests à plusieurs milliers d'utilisateurs ensemble, bref...
le post de [font='Helvetica Neue', Helvetica, Arial, sans-serif]Tarkahn[/font] fait présomption que tous est dans le serveur ce qui n'est jamais le cas pour du netcode, sur le pipeline réseaux entre le client et le serveur seul transitent les informations nécessaires à mettre à jour des deux côtés. C'est aussi le but des instances où une à plusieurs tâche est associé au traitement des informations Toute l'astuce consiste à minimiser, et compresser ces informations (traitements par lots). L'histoire du 32 joueurs vient des parties en multi a crysis et autres je supposes... mais en fait li y a aussi Aion en cry engine qui exploitent du client/server pas trop mauvais donc on peut espérer quelque chose de bien malgré tout (hey pour une fois je critique pas le jeu ni les réponses je fais un effort ) Pour une fois j'ai bien aimé ces questions/réponses... à suivre... (bon là dernière maj bien fait rigoler avec le F7C qui tourne tout seul dans le hangar et qui se cogne à tous les murs mais chut) Dernière modification par nadorator ; 03/02/2016 à 19h15. |
03/02/2016, 17h54 |
|
Suivre Répondre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|