Maxis attempts to explain why SimCity is always-online as players discover code for 20-min offline force-shutdown timer
"In many ways, we built an MMO."
Maxis has attempted to explain why SimCity requires an internet connection to work amid more tinkering from players, this time resulting in the discovery of a 20 minute force shutdown timer for offline play.
Maxis boss Lucy Bradshaw took to EA's website to list what it is that the servers actually do for the game, which has been heavily criticised since its disastrous launch.
In a post called "Straight answers from Lucy", Bradshaw insisted SimCity's always-online requirement was "fundamental to the vision we had for this SimCity".
"It didn't come down as an order from corporate and it isn't a clandestine strategy to control players," she said.
"From the ground up, we designed this game with multiplayer in mind - using new technology to realise a vision of players connected in regions to create a SimCity that captured the dynamism of the world we live in; a global, ever-changing, social world."
EA, Maxis and Bradshaw have come under fire for what appear to be contradicting messages about SimCity's always-online.
Amid the launch chaos Bradshaw told Polygon the servers were required for performance issues.
"We offload a significant amount of the calculations to our servers so that the computations are off the local PCs and are moved into the cloud," she said. "It wouldn't be possible to make the game offline without a significant amount of engineering work by our team."
But, following that interview, a source close to the project told Rock Paper Shotgun that the SimCity servers weren't integral to the game's performance.
"The servers are not handling any of the computation done to simulate the city you are playing," the source explained. "They are still acting as servers, doing some amount of computation to route messages of various types between both players and cities. As well, they're doing cloud storage of save games, interfacing with Origin, and all of that. But for the game itself? No, they're not doing anything."
In her latest post, Bradshaw explained what, exactly, the servers are used for, but, importantly, didn't mention anything about offloading calculations from local PCs. Instead, as expected, the servers are used for multiplayer features and cloud saves only.
"We put a ton of effort into making our simulation and graphics engines more detailed than ever and to give players lively and responsive cities," she said. "We also made innovative use of servers to move aspects of the simulation into the cloud to support region play and social features. Here's just a few:
- We keep the simulation state of the region up to date for all players. Even when playing solo, this keeps the interactions between cities up to date in a shared view of the world.
- Players who want to reach the peak of each specialization can count on surrounding cities to provide services or resources, even workers. As other players build, your city can draw on their resources.
- Our Great Works rely on contributions from multiple cities in a region. Connected services keep each player's contributions updated and the progression on Great Works moving ahead.
- All of our social world features - world challenges, world events, world leaderboards and world achievements - use our servers to update the status of all cities.
- Our servers handle gifts between players.
- We've created a dynamic supply and demand model for trading by keeping a Global Market updated with changing demands on key resources.
- We update each city's visual representation as well. If you visit another player's city, you'll see the most up to date visual status.
- We even check to make sure that all the cities saved are legit, so that the region play, leaderboards, challenges and achievements rewards and status have integrity.
"Cloud-based saves and easy access from any computer are another advantage of our connected features," Bradshaw continued. "You can pop from work to home, play the game and have your cities available to you anywhere."
Bradshaw said "almost all" players play with connected cities, but some play alone. "But whether they play solo or multiplayer, they are drawn to the connected city experience. And Always-Connected provides a platform for future social features that will play out over regions and servers.
The game we launched is only the beginning for us - it's not final and it never will be. In many ways, we built an MMO
Maxis boss Lucy Bradshaw
"The game we launched is only the beginning for us - it's not final and it never will be. In many ways, we built an MMO."
Many have called for an offline mode. Again, there have been mixed messages on this point, but it appears it's off the table for now.
Bradshaw admitted Maxis could have built a subset offline mode, "but we rejected that idea because it didn't fit with our vision".
"We did not focus on the 'single city in isolation' that we have delivered in past SimCities," she said. "We recognise that there are fans - people who love the original SimCity - who want that. But we're also hearing from thousands of people who are playing across regions, trading, communicating and loving the Always-Connected functionality. The SimCity we delivered captures the magic of its heritage but catches up with ever-improving technology."
Bradshaw's comments come amid more revelations about the troubled game.
Last week a player managed to access SimCity's debug menu and mod the game so it could be played offline indefinitely.
He did this by simply removing the game's in-built timer that forces SimCity to stop working after a period spent disconnected to EA's servers.
Now, players have uncovered the code that governs this, proving that Maxis set a 20 minute time limit of offline play after which the game kicks the player out.
The code for this shutdown time is below, posted to NeoGAF by EmCeeGramr. For modders, removing this always-online code is a simple job. EA, Maxis and Bradshaw will be holding their breath as they wonder how their city simulation will be tweaked next.
- kNoRepeatNetworkAlertSeconds : 15,
- kNetDownForceQuitAfterMinutes : 20,