Presentation on theme: "The Server Technology Of Eve Online: How To Cope With 300,000 Players In One World Kristján Valur Jónsson Senior Software Architecht (CCP Games) Most."— Presentation transcript:
The Server Technology Of Eve Online: How To Cope With 300,000 Players In One World Kristján Valur Jónsson Senior Software Architecht (CCP Games) Most MMOGs separate their players onto multiple servers in order to scale; these servers are often called shards. The shards are essentially instances of the game world and the player base is thus broken into segments, based on which shard (server) they are playing on. EVE Online takes a different approach: the technology and the game is developed around the goal of one unified world. All the players log onto the same server cluster and play in the same world. This session will explore the technology developed by CCP to achieve this goal and discuss the technology choices made by CCP, focusing on the software side. Topics include Cluster Technology, Stackless Python, Networking and Database technology.
The server technology of EVE How to have players on one server
About EVE One world, one server cluster Launched in May 2003, has been steadily growing ever since Currently at over 360,000 players (~300,000 paying subscribers, trials account for rest) Peak Concurrent Users (PCU) record at 60,453 That’s a lot of people!
The Network Effect The value of a service to a potential customer is dependent on the number of customers already using that service Value of a network equals approximately the square of the number of users in the system EVE Online is inherently a better game with subscribers than subscribers Size Matters! Network effect Metcalfe’s law Ergo
EVE China Launched in 2006 The Serenity cluster is Tranquility’s little brother This talk is about EVE International, running on the Tranquility cluster in London.
More info EON Magazine:
I could talk all day! Game design Operating systems Multicore Multiprocessing IPC Winsock OLEDB Switches/Routers SQL Introspection Revision control Profiling Racist bike shops Live debugging Compression Session propagation
But we have to be practical! I will focus on a few key aspects These are deep and complex topics. I will skip some of the dangerously complicated details. There will still be technical stuff Demos and videos Additional reference material provided at the end.
The main reasons for EVE’s scalability Database system Stackless Python Destiny and space partitioning Hardware configuration
EVE‘s foundation is the database Efficient management of data in an un-sharded MMOG is crucial All game-related data is stored in a single database Provides final synchronization of game logic EVE database is currently at 1.3 terabytes Database transactions are usually around 1500 per second, reaching 2000 per second at peak hours ‘Items’ table receives over 9 million insertions in a day (not counting update and select statements)
EVE demands an enterprise level DB Microsoft SQL 2008 x64 (enterprise edition) IBM X-series 3850 M2 brick server 128 GB RAM 2 x CPU, each six-core at ?? GHz 2x 128 GB RamSan 400 (solid-state drive) 1x 2TB RamSan 500
…and enterprise level DB engineers Tables and procedures are carefully designed Constant monitoring (through DB traces, health checks on DB server) to watch for bottlenecks and optimization opportunities Optimizations sometimes trickle all the way up to game design Recently created robust versioning system for DB content, you will eventually need this.
Application DB model Stored procedures for everything – Hand crafted by DB Engineers – Lowest possible run-time cost – All DB logic in one place Simple application model – Integration with Python – Looks like regular synchronous function call – Return highly optimized Rowset objects
What is Python A dynamic programming language Simple intuitive syntax Easily embeddable and extendable Rapid dynamic programming environment with dynamic reloading of code (in-house tech) Open source For more info, go to
But what is Stackless? An alternative version of Python Forked from the Python code Completely backwards compatible Contains additional features: – Supports a “tasklet” based application programming model – Enables many logical tasks – Allows the user to use an imperative, procedural programming model instead of an event driven model to achive parallel IO
Why stackless? Lightweight cooperative “threading” using tasklets Allows you to write robust procedural code, without the boilerplate and machinery of an event-driven model Allows switching of running of both python code and also C code, using stack slicing. – Extends to third party libraries, C/C++, etc.
Tasklet essentials Execution context, not threads! – Only one is running at a time – An application can have active tasklets or more. – An application can only have relatively few threads Co-operative switching – Context switches occur at known point, almost no need for locks! Can even switch C Extensions! – Windows overlapped, asynchronous IO looks like synchronous calls.
Co-operative multitasking (demo) import stackless def func(string): for i in xrange( ): print string stackless.schedule() t = stackless.tasklet( func ) s = stackless.tasklet( func ) t(“foo”) s(“bar”)
Stackless python is cool No more this:
Stackless python is cool But this:
Destiny Divide and conquer Space Partitioning dynamically calculates the causality bubble for each ship in a fast way Deterministic Allows state to be evaluated by the EVE client, knowing only initial state and time Differential Equations Ships are essentially balls rolling around in vector fields
Hierarchical space partitioning Binary space partitioning in three dimensions. Each sphere belongs to only one box – the smallest box that is able to contain the spere. becomes:
But it is more complex than that The time-extrusion of a sphere determines what space partitions it can interact with (causality bubble) Collision is defined as the intersection of two time-extruded spheres (cylinders with dome shaped end-caps) Collision response is highly elastic (conservation of momentum )
And here the details: QED
Evolving time The server solves the system of equations for an entire “system”. The client only solves the equations for the causality bubble that it belongs to. Server regularly sends updates to the initial conditions for a time step. The client can work its way backwards to adjust for changes in initial conditions and derive how they affect current state.
This gives defines scaling: A client scales based on the population in a causality bubble A server scales based on the population in the “system” that we need to solve the differential equations for How are these concepts defined in EVE? Answers after this break!
The EVE Universe Solar systems typically consists of a dozen of planets, surrounded by moons and asteroid belts Routes connect them into constellations that themselves form conglomerates called regions EVE consists of over 5000 solar systems
Creating solar systems EVE solar systems are created using the disc accretion model Gives convincing enough results and is possible to calculate them all in less than 24 hours
Large scale design The large scale shape of the eve universe is defined first and foremost by Routes. Routes define how pilots can travel between systems. Position of the planets is derived from this.
Routes make it interesting! Designing the layout, we wanted interesting properties: Settlements Stratetic value Hierarcical properties
Diffusion Limited Aggregation Successfully used to model various growth processes Extended to work in 3 dimensions and have multiple seeds.
Implications for scalability The smallest unit of scaling is a solar system Some system are busier than others – Pass-through systems – Strategic access to trade Occasional tuning of routes necessary
Scaling with increased hardware A unique combination of software and hardware layers Tiered architecture allows software to scale well with increased hardware Make maximum use of worker threads and IO Completion ports underneath micro-threaded Stackless Python logic
Adding more hardware Architecture can be split up and distributed to more hardware: – Solar systems – Space stations – Market regions – Corporation services – Proxy services …
EVE runs on a supercomputer! Active servers~195 Weight2.5T #CPUs>420 cores, >1 THz RAM>7.6Tb FLOPS>7.5TFlops Bandwidth~ 400Mbps
Summary Structure your application in ways that promote scalability – Make it as granular as possible, so that load balancing is more efficient, and you can add more hardware. Chose a powerful, expressive programming language – Allows you to restructure key areas as needs arise with the least possible engineering effort. Design your database system wisely – Be one step ahead, so that it doesn’t become a bottleneck for scaling – You are using a DB, aren’t you?
Burt Reynolds says:
That’s it! Additional information: – – – – – (google for “stackless python in eve”)