[quote1362860192=John.]
O jogo é foda demais....Más não dá pra jogar.
Por isso não entendo as notas. Deviam avaliar o jogo em si , não o serviço da EA.
Devia ser algo assim , nota do jogo 9,5 , nota do serviço de DRM da EA 0.
Juntam tudo ai fica parecendo que o jogo que é ruim , o que não é verdade.
[/quote1362860192]
Jogo é o serviço da EA, tudo é o mesmo produto. E se o jogo/serviço não funciona como prometido é mais que justo as notas baixas.
E se um jogo que não funciona não for um jogo ruim não sei o que é um jogo ruim.
Há quem interessar pessoal no reddit ta tendo uma discussão mais técnica sobre a parte cliente servidor desse jogo.
[blockquote]Okay, I'm looking for input on this working theory of what's going on. I may well be wrong on specifics or in general. Some of this is conjecture, some of it is assumption.
What we know:
The SimCity servers are hosted on Amazon EC2.
The ops team have, in the time since the US launch, added 4 servers: EU West 3 and 4, EU East 3 and Oceanic 2 (sidenote: I would be mildly amused if they got to the point of having an Oceanic 6).
Very little data is shared between servers, if any. You must be on the same server as other players in your region; the global market is server-specific; leaderboards are server-specific.
A major issue in the day(s) following launch was database replication lag.
This means that each 'server' is almost certainly in reality a cluster of EC2 nodes, each cluster having its own shared database. The database itself consists of more than one node, apparently in a master-slave configuration. Writes (changes to data) go in to one central master, which performs the change and transmits it to its slaves. Reads (getting data) are distributed across the slaves.
The client appears to be able to simulate a city while disconnected from the servers. I've experienced this myself, having the disconnection notice active for several minutes while the city and simulation still function as normal.
Trades and other region sharing functionality often appears to be delayed and/or broken.
While connected, a client seems to send and receive a relatively small amount of data, less that 50MB an hour.
The servers implement some form of client action validation, whereby the client synchronises its recent actions with the server, and the server checks that those actions are valid, choosing to accept them or force a rollback if it rejects them.
So the servers are responsible for:
Simulating the region
Handling inter-city trading
Validating individual client actions
Managing the leaderboards
Maintaining the global market
Handling other sundry social elements, like the region wall chat
The admins have disabled leaderboards. More tellingly, they have slowed down the maximum game speed, suggesting that - if at a city level the server is only used for validation - that the number of actions performed that require validation is overwhelming the servers.
What interests me is that the admins have been adding capacity, but seemingly by adding new clusters rather than adding additional nodes within existing clusters. The latter would generally be the better option, as it is less dependent on users having to switch to different servers (and relying on using user choice for load balancing is extremely inefficient in the long term).
That in itself suggests that each cluster has a single, central point of performance limitation. And I wonder if it's the master database. I wonder if the fundamental approach of server-side validation, which requires both a record of the client's actions and continual updates, is causing too many writes for a single master to handle. I worry that this could be a core limitation of the architecture, one which may take weeks to overcome with a complete and satisfactory fix.
Such a fix could be:
Alter the database setup to a multi-master one, or reduce replication overhead. May entail switching database software, or refactoring the schema. Could be a huge undertaking.
Disable server validation, which consequent knock-on effect of a) greater risk of cheating in leaderboards; b) greater risk of cheating / trolling in public regions; c) greater risk of modding / patching out DRM.
Greatly reduce the processing and/or data overhead for server validation (and possibly region simulation). May not be possible; may be possible but a big undertaking; may be a relatively small undertaking if a small area of functionality is causing the majority of the overhead.
Edit: I just want to add something I said in a comment: Of course it is still entirely possible that the solution to the bottleneck is relatively minor. Perhaps slaves are just running out of RAM, or something is errantly writing excessive changes, causing the replication log to balloon in size, or there're too many indexes.
It could just be a hard to diagnose issue, that once found, is a relatively easy fix. One can only hope.
Thoughts?[/blockquote]
http://www.reddit.com/r/SimCity/comments/19xx7d/trying_some_technical_analysis_of_the_server/