Have you ever played a massively multiplayer online game?
My first experience with these types of games was with text-based role-playing games called MUDs back in the early 90s.
Well, things have come a long way since then.
Games such as EVE Online have hundreds of thousands of players exploring, trading, and battling within a universe of over 7,000 star systems.
Gameplay in EVE Online consists of beautiful 3D spaceflight within a dynamic universe with many real-world players.
You may have played EVE Online, as it's one of the first major MMOs released back in 2003.
But did you know that Python is at the core of the game, playing a critical role in the backend infrastructure as well as a major role in the client-side game itself?
On this episode, you'll meet Christian Sigibirgsen from CCP Games to dig into Python at EVE Online.
This is Talk Python to Me, episode number 52, recorded March 16, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python.
The language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by Hired and SnapCI.
Thank them for supporting the show on Twitter via at Hired underscore HQ and at Snap underscore CI.
Kristen, welcome to the show.
Thanks for having me.
We're going to have a really cool conversation about games and massive scale of just online applications in general, right?
Yep.
I'm sure that we will.
You guys are doing amazing stuff.
Before we dig into that, though, what's your story?
How did you get into programming in Python?
I came kind of roundabout way into game programming.
I actually applied for a position at CSB as a game designer.
And I started here as a game designer, worked here for two years.
But I've always kind of been interested in programming.
So I started poking around, fixing things.
And then after that, it was kind of no turning back because programmers are always in such a short demand that was so much demand.
That is that I just kind of pulled all of my time over into programming.
And then I kind of just kind of worked my way into being my current position, which is technical director of EVE Online.
And I did that by just attacking every problem that I saw and never giving up on them.
That's really cool.
And you guys do mostly Python there.
Is that correct?
Yeah.
Majority of the programmers in EVE work in Python.
We do have some stuff written in C++ as well as most of our DBA SQL.
But I'd say like at least 75, 80, 80 percent of our programmers spend like vast majority of the time in Python.
Okay, excellent.
And how did you get into that originally?
Is that something you learned when you first started there?
Did you know that before you started?
No, I'd known about CCP.
I knew they were developing in Python.
But the only thing I knew about Python was that white space matters, which I thought was ridiculous at first.
But now I'm thinking it's one of its greatest features because you're going to have the white space that way anyway.
So you might as well have it mean something.
It also kind of forces you to be consistent on it.
Yeah, that's an interesting point.
Like anytime you look at professional code, it's always structured in a way that resembles the way that Python is structured.
You know, if you look at C++ or C# or even JavaScript when it's well written, the white space is in a format such that it could matter, but it doesn't.
Right.
And so I had exactly the same feeling when I learned Python the first time.
I'm like, this four space thing, this is insane to me.
Like, where are the curly braces and the semicolons?
What is going on?
And then I worked in Python for a while and I went back.
I had been coming from C# and I went back to C# and I thought, wait a minute.
Why am I typing all this crap?
This is way less fun to type than I remember.
And it's because I was spoiled by the structure of Python, which really surprises me.
And you can kind of see it from the code when you read like Java code or C# code and stuff like that.
When you have a lot of indentation, you also have a lot of like white space beneath it where you have closing all of those brackets, all of those curly brackets.
And it's also weird because if you see somebody write Java code, for example, and it has an if statement and then two indented lines, but no curly brackets, I can guarantee you that program met both of those clauses to be within the if clause.
Absolutely.
There was some bug.
I think it was in OS X about a year and a half ago.
A really bad like SSL man in the middle bug.
And it was exactly that.
It was like there was an if statement and they didn't have the curly braces, but it was indented.
So people thought it was in one case, but it was actually in a different one.
Right?
Yeah.
I thought this exact thing and I thought this would never have happened in Python.
How interesting.
We'd have different problems, surely.
But yeah, we might have other problems, but the indentation problem, not so much.
Yeah.
And I kind of always liked that about the Python philosophy is that what you see is kind of what you,
the code, the whole idea is that the code is readable.
And what you see on the screen is what actually happened.
Not some like, aha, you forgot the curly brackets.
I say it a lot on the show.
Like you hear about things like JavaScript gotchas and, you know, like languages like C, the mistakes
that people make when they're new to the language that are really bad and not obvious.
And you just don't hear about that concept in Python.
Like people make mistakes, but they like don't work or something.
Right?
The only thing I can think of, and I love showing people that are new to Python this, is the
mutable keyword.
I love that bit.
Nice.
Yeah.
So let's talk a little bit about EVE Online.
EVE Online is a massive multiplayer online game that has to do with sort of like space exploration,
colonization, like a science fiction space future, right?
Right.
Yeah.
It's a massively multiplayer online game.
We focus a lot here on the kind of the player interaction.
We care a lot about how people interact with each other.
So we, and we don't try to interfere that much about it.
But in the end, it's a game where you fly a spaceship, you gather resources, you, you can
shoot other people, you can shoot non-player controlled ships, NPCs.
The biggest selling feature is the whole dynamic market.
We have like a very realistic market.
Yeah.
There's kind of like an economy in the game that is live and not programmed, but it's like
organic in a sense.
Yeah.
And it mimics the real world economies really.
And you can see the same behavior there.
And we actually have like a professor in economics working just analyzing the data.
We still analyze a lot of the data, like the market activity, just to know the health of
the game and what's happening.
Okay.
That's very cool.
Do you have like machine learning type stuff going on in the background or is it more procedural
and you understand it and you tweak the algorithm?
We had, so for stuff that NPCs like the, just we sold on the market, we had something where
we controlled the supply.
We just created the item and sold them so-called like NPC goods.
And what we did there is that we had something where you bought off the supply.
We added a new supply, but at a higher price.
And if it bought a lot of the supplies, we reduced the price.
So it kind of balanced itself out, which created kind of like trade routes.
But that's kind of not the most interesting thing about the market.
The most interesting thing about the market is the player versus player trading where players
sell items to other players.
We don't need any machine learning.
We don't need any fancy mechanics.
The whole dynamic part of it is something that the players provide themselves just by speculating
on the market and stuff like that.
Yeah.
Very interesting.
Like you just have a bunch of people interacting and that is like the artificial intelligence,
although not artificial really.
That is what creates all the kind of variants and dynamics and the interesting conversations.
Like just this other day, somebody showed a fake screenshot of an item, a very rare item
from our test server saying that they were going to be dropped in the next release, which plummeted
the price on that thing.
So just by the market speculation that we might be doing something influenced the price on that
item.
Wow.
Did that person go and buy a bunch of them all of a sudden?
I assume so.
Yes.
But people do that a lot.
And they try to buy all the resources of a certain type just to create a shortage of them.
And we have amazingly clever group of players that do that.
Players that have like economist boards and they have IT departments and all sort of stuff.
Have you had instances where people are selling items in the game, but in real life for real money?
It's a constant problem, really.
We don't support it, obviously.
It's very tricky to stop what we work.
We try to do it as much as we can.
And we've had a lot of success in it as well.
But people always try to sell it.
Sure.
I guess that would mess up your algorithm, right?
Because that's basically extraordinarily high value transaction happening invisible to your
economy in a sense, right?
Like a black market to some degree, I guess.
Yeah, yeah.
But that's not the only reason.
It's also we don't like this kind of it.
It's not secure for our players either.
We also don't want you to be able to kind of buy a hat in the game and kind of skews the whole thing.
This is the philosophy of a game that was made before the last five years of in-app purchases in iOS and these types of games, right?
That has such a different philosophy.
Yeah.
The people that are the most successful in it, they just make a game that is fun.
And then they find a way to monetize that without it being.
Yeah.
And then, of course, there are the other games where you just literally have to pay dollars and then you win.
Yeah.
That is not the same type of game as the.
No.
As even these other ones, right?
I don't know.
It's impure in some way.
So let's talk a little bit more about the gameplay and then we can get into the technical bits.
So there's this sort of economy and this exchange of goods.
And there's a lot of like you had like 7000 star systems or something.
You travel around and you can harvest things.
So what other games is it like?
Like does it relate to like Warcraft Starcraft or other games?
Like can you give some analogies?
So people who maybe haven't seen it are kind of aware.
It's like a massive multiplayer online.
So obviously you're going to draw some comparison with games like World of Warcraft and all the games online and those sort of games.
Those are all kind of avatar based games.
We like to think of them as more of a kind of a theme park kind of game where you go into the game and you have a bunch of rides where Eve is more of a sandbox kind of game.
You can imagine you go to a sandbox and you have a shovel and a bucket and you're just going to have to make some fun out of it.
Both genres are a lot of fun but kind of maybe cater to different needs and possibly just at different times.
Yeah it seems to me like Eve is a game that really appeals to people that are like there for the long term.
Like you're going to build something up over time and sort of grow it and so on.
Yeah and we do have very loyal subscribers.
They've been with us.
Some have been with us for years.
And even some people that have since then quit playing Eve still show up at the Eve Fan Fest, the annual kind of gathering here in Iceland that we have.
Just because they're part of the community and like staying part of the community.
That's really cool that people are like so attached to the community there.
I mean how many players do you guys have?
Give us some stats if you can.
The peak is I think around 30 or 40,000 now.
Wow.
We were in the stats of like 300,000, 400,000 users I think.
Must I know.
Okay.
When you say massively multiplayer that's pretty massive.
Yeah it is.
I mean there are bigger games there.
I think at the time we ranked somewhere between a small multiplayer, massive multiplayer and a large one.
Yeah yeah sure.
Let's talk about Python.
Where does Python fit in the story of Eve?
When they started developing Eve they always wanted like a scripting language to go along with something a bit lower level like C++.
I think they just it was obvious at the time to choose C++.
But that was like back in 97 or something.
It's pre-2000.
There weren't a whole lot of options.
They were looking at JavaScript but they eventually found out about Python and started looking into stackless Python.
And they really liked the idea of the whole micro threads they had in stackless.
Yeah and when you got started this was like probably Python 2 maybe before that right?
I think it was Python 1.6.
Yeah yeah because I think Python 2 was the year 2000.
Is that right?
Yeah.
I think it is.
So when you actually look at a lot of the decisions that were made at CCP with Python you kind of have to color them in that light.
You have to look at the code and see okay so when was this written and what was available at the time.
Right.
The trade-offs you made have to consider like well should we use VB or this.
I mean like these are the other technologies that are around at the time right?
Like JavaScript.
Yeah.
There was no concept of this Node.js thing.
It was kind of a toy right?
So Python is a really good choice I think.
Yeah but it was also I think a pretty daring choice because Python was pretty new at the time.
It wasn't really that stable I would say and it didn't have like all the features that I think they would have needed.
It didn't have as good IDEs and stuff like that.
And I think it was daring but then again there wasn't like a whole lot of other options.
Not for doing like a lot of work in a scripting.
Right.
There are actually quite a few Python implementations these days.
And the show I just had last week was with Brett Cannon from Microsoft talking about Pigeon.
And we talked about things like PyPy and Pyston and Pigeon and all these different choices for alternate implementations.
And one I don't think we really spoke about was Stackless.
But Stackless was one of the few alternative options you had back in that time frame right?
Yeah yeah there wasn't a lot of other implementations I think.
Then there was just the Vanilla Python and Stackless maybe a few others but yeah.
Yeah not many like things like Jython and Iron Python are like circa 2006, 2008 and then onward right?
So yeah.
Why don't you tell everyone what Stackless Python is?
Like what is it?
What's the advantage of it?
Why did you guys choose this over just CPython 1.9 or whatever it was?
The biggest advantage of Stackless Python that people saw here was the kind of the existence of micro threads.
Just very lightweight worker threads that you can even start up and they could do one thing.
The idea being that you could be cold would be a lot easier to read basically.
You could just start up like this one task and it just does this one thing.
Yeah well if you're dealing with 40,000 concurrent connections.
Yeah.
A single threaded you know sort of maybe forked off the 10 or 20 process type of system may well not scale the way you need it right?
So something like this is really helpful yeah?
Yeah that was the biggest reason for choosing this over Vanilla Python I believe.
Are you guys still using it?
Yeah we still use Stackless.
We kind of wish that the rest of the world would have followed us into Stackless but sadly that didn't happen.
And now we have some alternatives in Python so we still are kind of tied to Stackless Python in terms of code.
Yeah it would probably take a pretty major rewrite yeah?
I'm not really sure how major it would be but it would be pretty substantial by the look of it.
Right.
So maybe let's talk a little bit about the architecture infrastructure type of bits.
Could you maybe talk about like the different systems and stuff that's going on in the back end?
I'm assuming that the front end the thing that runs on my OS X machine or Windows that is the graphics and the actual client side game.
It's mostly C++.
Is that a fair assumption?
Right.
Most of the most of the highest high performing stuff is C++ like the graphics engine is C++.
The physics engine is C++.
The DP layer is C++.
Then we kind of have a nebulous layer that handles like files and various things, clocks and stuff like that called blue which is like our own dimension.
We have various third party libraries written in C++ as well.
Yeah.
So most of that is done in C++.
Most of the stuff that we for someone saw that would be a problem.
We also have like a minor things.
There's a feature called planetary interaction where we kind of have a layer over the planets that shows like resource distributions which is implementing the C++ because we thought it would be very performant.
And which would have had a performance problem I think in Python.
But we wrote that in C++.
So we have some options if we want to do something to perform really really fast we can write in C++.
Sure.
And do you have anything on the client side that's Python?
Or is that all backend stuff?
Yeah.
The most of the UI implementation is in Python.
Like it falls on to like C++ some rendering but for the most part UI programmers write stuff in Python.
Oh that's really interesting.
Yeah.
This episode is brought to you by Hired.
Hired is a two-sided curated marketplace that connects the world's knowledge workers to the best opportunities.
Each offer you receive has salary and equity presented right up front and you can view the offers to accept or reject them before you even talk to the company.
Typically candidates receive five or more offers within the first week and there are no obligations.
Ever.
Sounds awesome doesn't it?
Well did I mention the signing bonus?
Everyone who accepts a job from Hired gets a $1,000 signing bonus.
And as Talk Python listeners it gets way sweeter.
Use the link Hired.com slash Talk Python to me and Hired will double the signing bonus to $2,000.
Opportunities knocking.
Visit Hired.com slash Talk Python to me and answer the call.
When I thought about how you guys were using Python I of course thought all right the back end is probably a lot of Python and things like that.
But like I said the front end mostly C++.
Can you elaborate on that?
Like are they using a custom sort of plug into your own rendering engine or are they using some kind of widget windowing system or maybe talk about it a bit?
This is all kind of custom made here at C++ so the low level objects like the drawing of the stuff is in C++ and then we can actually just and I think at least it used to be the case that you would just kind of inherit from them.
The Python object could inherit from the C objects and you would.
I can't remember what we were using for it whether it was boost or.
Sure.
That sounds really really cool.
How about on the server side like what type of interaction does the game from the client side actually have with the server and what does a request sort of look like from sort of systems and infrastructure and so on?
Right.
We have our own kind of a networking layer which we call Matsunet and it kind of handles the server and client communication as well as communication between nodes on the cluster.
Both from the proxies to the sole nodes as we call them which are really just the worker nodes where everything happens.
The proxies sit out in front and receive requests from the client as well as the communication between nodes as well.
This is all done in Python actually.
Okay.
Yeah.
No, no.
It was rewritten some time ago.
C++.
But with the Python layer on top so you can know this.
Right.
Very cool.
And is this in your own set of data centers or are you hosted in like some kind of cloud place?
Like AWS or something?
No, no.
It's in our own data center and we actually moved data centers recently.
There's a big blog on that on the website.
It might be interesting for attack might be able to read that.
It was actually quite an operation.
We had to both move data centers and we had to buy whole new hardware in it.
And we were just moving between like London.
And then I heard you say you were using SQL server somewhere around there.
Is that right?
Yeah.
That's correct.
Okay, cool.
Are you hosted on Windows or on Linux?
We're hosted on Windows.
We're probably one of the rare instances where we actually use Python and Windows, I guess.
Yeah.
Very cool.
Okay.
The world has changed since 1997 in terms of databases pretty dramatically, especially
in the last five years.
I'm sure part of the reason that you guys are on a relational database has to do with the
fact that you started on a relational database.
But do you think if you could start totally from scratch, would it make more sense to be
on like a NoSQL database or stick with a RDBMS like SQL server?
I think if I were forced to choose like a single database, I would probably still go with a
relational database.
We've made so many changes recently in terms of this microservices architecture that I wouldn't
really see a necessarily need to do that.
I would try to split up the clusters a bit more into these functional areas than when I'm
storing data that needs a relational database.
I would store it in a relational database, otherwise a NoSQL database or a graph database
or whatever.
But I think if I had like a 1db catch all, I would still go with relational database.
Makes a lot of sense.
The world is definitely moving towards this concept of microservices.
And I don't think I've spoken very much about that on the show.
I think maybe a little bit when we had the Docker guys on way back in show nine, but also
had a conversation with Sam Newman that actually the audio went so bad we couldn't put it together
specifically about microservices.
I'm sorry about that, Sam.
But maybe you could just tell us really quickly for those people are like microservices.
Those sound like small services.
What's that?
Maybe describe that a bit.
It's essentially that it's small services.
It's this idea that you spin off a service for a specific need that your total ecosystem needs.
So in terms of EVE, then we, for example, have a market.
Maybe the market could be its own microservice.
Maybe it doesn't have to need to connect to the cluster.
The cluster would only need to know how to talk to that microservice and that Microsoft
service to talk to that cluster.
I don't think I would really, really do it justice, but it's really just a matter of that,
of breaking up your kind of the total application into like multiple smaller services.
Yeah, the thing that I think that's interesting about that is, you know, I ask you about what
is the right database?
And the answer may well be, well, certain types of architectures that are proving to be powerful,
like these microservices, the answer could be many small ones.
And then it even matters less because when you're, if you're, let's say, just modeling only the
economy, which I'm sure is still massive, but just the economy, not every possible thing
that could go on in the game, then you might have smaller database performance needs and
so on, right?
Yeah.
And in some cases of data, you actually need everything to be always up to date, but maybe
sometimes you just need like eventual consistency on that data.
So you can pick database solutions based on the need for that particular feature rather than
choosing it for everything and hoping it all matches.
Having said that, I don't suggest that everybody makes changes to their architecture from like
single monolithic application to a microservices.
It's something you, you exchange one problem for a set of other problems, but it can make
a lot of sense.
And one of the things that I love about it is that it allows you to change, you know, decisions
that you thought you were kind of rooted into that you thought you would never, ever going
to change.
Yeah, that's, that's interesting.
And it's good advice, right?
Like design patterns and these larger architectural patterns are super powerful, but they almost
always have a context that goes along with them.
If you have a billion lines of code and this level of huge complexity, you can make that complexity
more manageable by breaking it apart.
But if you've got like 5,000 lines of code, maybe a microservice just means more servers and
things to maintain, right?
Right.
It's more service.
It's more things to maintain.
It's in theory that those servers should require less maintenance as well.
And they're easier to comprehend.
But you also need like infrastructure.
Maybe you need to have a message queue in there.
Maybe you need to add in a bunch of technology that you wouldn't have needed if you had a monolithic
application.
Yeah.
And performance as well, right?
Like if previously the call to get data about like the price of an item in your economy
was within the same machine or, or something to this effect within the same process even,
but it still hits like a database maybe.
That's probably a lot faster than actually going across the network, finding another machine,
doing a whole HTTP thing, and then asking that same question, right?
Yeah.
Absolutely.
I think, yeah, you just have to, you have to tread very carefully.
I think it's easy to get really, really excited about microservices and, but you really have
to make sure that's the correct solution for you.
Yeah, absolutely.
I certainly see those tied together with Docker and the whole container space.
But again.
Absolutely.
They've made this thing a lot easier.
Nice.
So one of the things that you said that you guys had done, I thought was pretty interesting
is you said you had written your own importer.
Is that, like if I say import space some module name, like import OS, you rewrote what that meant?
Well, sort of.
It's not really maybe such an importer as much as like a bootstrap.
Okay.
I don't know actually what the state was in Python 1.6, but I'm thinking maybe it didn't actually
know how to import packages and that whole dunder in it.
Oh, interesting.
Okay.
So that was pretty interesting.
And so what they wanted, and they wanted like a shallow namespace for these things.
So what they actually did was they wrote something that would just loop over the file.
It would, you know, read, execute that file and import it into like a namespace that they
created.
So they basically just injected into CSTOck modules.
Interesting.
Okay.
So what was the benefit there?
Do you remember?
One of the benefits was that we'd have auto-reloading of modules when we changed them.
And it was actually quite nice to work with E at the time.
And it still works that way.
It's just now it's a Python solution instead of like a home-cooked one.
But just changing something in code, you don't have to restart your survey, don't have to
restart your clients or anything.
You just re-execute whatever you're doing.
You click the button again.
Okay.
Now you got my attention.
That's pretty intense, actually.
Yeah.
And that's still the case today.
But now it's like with a Python implementation of it.
Did you have to do...
I guess you almost have to.
Either you say you can't use these types of features or you have to deal with things like
static variables and static class fields that have been set previously.
And then if you reload the module, what did you do there?
It wasn't completely foolproof.
Like if you...
And it still isn't.
If you already bound the method to something, it doesn't actually reload that.
If you like pass in a method of an object into something else, then it's already bounded
and it doesn't reload it.
But for the most part, for the most code you are changing, it actually just changes it.
I've had issues where some data was actually stored on a module level, like a dictionary
on a module level.
And whenever that got re-imported, it would clear that.
And those sort of things.
I mean, it happens.
You need to restart your server and client.
And when you're trying something out and something funky comes up, that's something what you do.
You just restart everything and try again.
Yeah.
Interesting.
So you have like two levels.
You're like, let's just try to hot patch it.
If that doesn't work, give it a hard kick, right?
And we've done that in production as well.
Like if there's a problem that we really want to fix, and that's actually one of the drawbacks
of having a monolithic application.
If I have a problem in the market, I need to take everything down to patch it up.
Right.
We've actually live fixed stuff like that.
Just going in console and just creating a new method and attaching that to the class.
Okay.
That sounds really, really powerful and interesting.
Is any of that sort of open source or blogged or written about that people can check out?
No, no, no.
None of this is open source.
I don't think we've ever blogged about this.
I think.
Okay.
Well, it sounds interesting.
I know.
I talked to David Beasley.
I think it's show 12 about modules and packages and this whole concept.
And it was like, oh, we're not really sure that this is going to work.
If it can be done.
So to hear that you guys are doing it on this real app, this is very cool.
I think people might get kind of caught up in the idea that, well, it's not going to work
every time.
But that's okay when you're doing development.
You just want like rapid feedback, really.
Yeah.
If it works 95% of the time and it saves you a ton, then maybe it's worth it, right?
Yeah.
I guess coming back to the microservices thing, if you build for something like microservices
and you do need to sort of hard restart some piece, it probably has a smaller consequence
because you're not restarting the entire thing, right?
Yeah.
Well, but the flip side of that is that you have to write everything now as in nothing
is guaranteed to be up.
Yeah, right.
If you do that, then you kind of, you're always guaranteed to have something down.
And if your whole, if nothing works, when one of the bits is wrong, you're going to
have constant downtimes.
Yeah.
That's straight off again, right?
Yeah.
It's a trade off.
Like, it's not a silver bullet.
And I think people have been pretty, pretty vocal about that.
Like, the experts on this have been pretty vocal about that.
And I think every paper and every talk I've seen about microservices always starts with
that.
This is not like a silver bullet that will fix all your problems.
Okay, cool.
So one of the things that happens in the game is there seems to be a lot of people
that group together to form like a fleet.
And then sort of in real time with voice communication, they'll go in and they'll have like these fleet
battles, right?
How many people end up in those battles?
How many different players?
SnapCI is a continuous delivery tool from ThoughtWorks that lets you reliably test and deploy your code through
multi-stage pipelines in the cloud without the hassle of managing hardware.
automate and visualize your deployments with ease and make pushing to production an effortless
item on your to-do list.
Snap also supports Docker and M browser debugging, and they integrate with AWS and Heroku.
Thanks, SnapCI for sponsoring this episode by trying them with no obligation for 30 days by
going to snap.ci.com.
SnapCI slash talkpython.
It can, Lars, I think the largest we had was like 4,000 people, I think.
Wow.
Then it can get pretty laggy, but...
What's the sort of performance characteristics as you add more people?
I mean, it can't be linear, like 2,000 people versus 4,000.
It's more like combinatorial or something really expensive, right?
Like, how's that work?
We've done a number of optimizations over the years of that.
It actually performs quite well.
I'm not sure if it's linear, but it's not N2 or anything like that.
But it's also very difficult to predict on that because it matters a lot whether everybody
is shooting at a structure, maybe, that doesn't die for a long time, or if people are shooting
at each other and people are getting killed and then removed from that solar system.
That creates more load.
It matters if people are shooting from guns or using missiles.
Right, because guns presumably are instantaneous, but missiles sort of cruise through space.
Yeah.
Right?
You've got to track them for everyone and see them go by and so on.
Yeah, yeah.
They don't collide really with anyone except the person that they're meant to collide with.
That's one of the optimizations we did a long time ago.
There's a lot of factors.
It's very hard to say, like, you can look at a thousand people fleet fight and see no lag,
and you can see another one that has a massive amount of lag.
It's very hard to measure that.
One of the most reliable kind of metrics we have is the market up.
We have a single system that, you know how people are, they kind of just all gravitate.
And because a lot of goods are there for sale, people think it's worth it for them to put
their goods up for sale.
So it creates this market up, which is a solar system called Jita.
And there we have like a constant influx of people.
We had like a maximum of 3,600 people there the other day.
That's a lot.
Because of some server optimization we had been doing, the CPU actually never went above
50%, I think, on that.
Yeah, yeah.
That's really cool.
So you said one of the challenges you have with some of the scaling has to do with the dreaded
global interpreter lock or the GIL.
What's the story there?
We basically can segment our cluster up into, well, it's probably easier to explain by solar
system, right?
That's the smallest unit we can run.
We can't distribute the load within one solar system to multiple processes, really.
Right.
Okay.
That's going to be a bit problematic because that means we can only use really just one
core on the machine.
So it doesn't really matter.
And it's very problematic because the hardware industry is actually moving more towards more
core and maybe less clock speed.
What we really desire is more clock speeds.
Yeah.
I mean, the clock speeds, I think, are, if they're not slower, they're definitely not any faster
than what they were in like 2005, right?
They're not getting faster.
I can tell you that.
Yeah.
I mean, they may even be slower.
I know they got higher and they started to melt.
They kind of went down.
All right.
That's it.
Eight cores, lower, lower gigahertz, lower clock speed.
Yep.
Very interesting.
Would Docker type stuff or virtualization sort of let you sort of break that up, at least
not dedicate a whole machine to it, but say, okay, well, we're going to isolate, you know,
Windows.
I guess Docker is doing stuff with Microsoft these days, but maybe it's, I should say,
Windows containers that's coming out soon.
Would that be a way to partition this so that you can still get everything you want out of
those machines without dealing with the threading?
Yeah.
It's an interesting thought.
It still requires like a lot of programming work to actually do it, but you'd have to segment
what the cluster is doing within the solar system into like something logical units,
which you can scale, which doesn't chapter too much between each other.
We actually have an idea about that, but yeah, we'll see if we get there.
As it currently stands, we're not really that pressed for performance, or at least it's
not as high priority as some other stuff we want to do.
Right.
When you're doing performance analysis, like you just look at the slowest thing, the bottleneck.
Right.
If the stuff behind it is slower, but still fast, you know, slow, but faster than the bottleneck,
then who cares, right?
Yeah, right.
And there's something to be gained looking before we start looking into splitting really
this into multiple processes on the same note.
But we have like a better lead than that.
So one thing you said you're really into is test-driven development, unit testing, and so on.
And this code is super old.
You must have some interesting challenges writing tests for a code from this long ago, yeah?
Yeah, and the importer or bootstrapper, which we appropriately named Nasty at the time,
was of course like a huge, huge burden on us for that, because we couldn't really import
any of the EVE-specific code without using that Nasty importer.
And that Nasty importer really had to throw through everything and really just run a full-scale
client or a server.
Yeah, so you were almost like forced to the point where you're doing integration tests
because you had to start the whole thing anyway, right?
Exactly.
And we did manage to create like an interpreter that did that, but we had me and another program
who were writing tests, and I think we were up to like 100 tests, and they were taking 45
seconds to run, which was just terrible.
Yeah, that's pretty long for unit tests, right?
Yeah, yeah, and it's unusable if you want to use it for like a quick iteration feedback.
Yeah.
When developing, you really need something in less than a second time or like close to it.
But there was some initiative to actually get rid of Nasty.
They actually managed to do it in like one summer.
They managed to do it in, I think, two weeks.
Oh, nice.
And now testing is much easier?
Now testing is a lot easier.
It's still a lot of coupling, and there are other things other than creating our own
bootstrapper slash importer that we did, like shoving stuff into buildings and stuff like
that that make testing harder.
But usually always you can extract the code that you want to test out, and you write tests
for them.
Right, okay.
Nice to hear that you've got that sort of cracked open so you can test it.
Yeah, yeah.
It's been like once that came in and once I started being able to write tests like that,
it kind of really opened my eyes towards testing and development and automatic testing in general.
All right, cool.
So let's talk about a little bit about CCP, the company that makes EVE Online.
Yeah.
You guys are primarily based out of Iceland, right?
Right, mostly out of Iceland.
We have offices in Núkastúl, Shanghai, and Atlanta, but everybody that works on EVE is
stationed in Reykjavík.
Very cool.
I've never been to Iceland.
It's definitely one of the places I'd like to visit, though.
Yeah, it's definitely interesting, although I lived here most of my life, so...
It seems very natural to you, right?
Very normal, but...
It seems very normal.
Yeah, with all the winter and the volcanoes, and I think that'd be super cool to go check
out.
Nice.
So you guys use an Agile approach, is that right?
Do you use Scrum, or what's the story there?
Yeah, well, we started with Scrum, and then we kind of...
It's morphed into something that's like Scrum, but it's mostly...
Scrum is really the basis of it, but I think we allow every team to really put their own
flavor on it and do kind of whatever works for them.
Agile practices are really funny, because if you don't pay attention to them, they will
just deteriorate, and you'll start getting worse at them.
So it's something that just kind of requires constant putting.
And of course, it's part of the Agile to have retrospective and constantly be trying to
improve yourself.
Right.
I think a lot of people lose sight of that.
I mean, on one hand, there's not necessarily a single Agile process that is exactly right
for everyone, right?
I mean, that's a little bit about being flexible and Agile and so on there.
But then if you're going to go and sort of walk it up to the edge of the absolute minimum
amount of documentation, rules, structure, that means if you fall apart just a little bit,
you're probably falling out of the minimum amount of structure that you need, right?
Right.
It's a little bit like that.
I kind of like starting with Scrum.
I think Scrum has like, if you understand why the rules of Scrum, then you have the power
to change them as they make sense to you.
But I've seen also seen a lot of companies or heard from like a lot of my colleagues here
around Iceland is that they've implemented Scrum, but they really didn't get what Agile was.
So it just goes through the motions.
And then, hey, this Agile thing sucks.
It doesn't work.
Yeah, right.
Yeah, well, maybe you didn't follow it.
You guys said you also have a kind of interesting learning and development philosophy.
What's the story there?
Well, it's not.
I mean, we do try to foster kind of the culture of having like what we call a community of practice.
We had a Python community of practice, for example, but we kind of retired that because
people weren't really showing up that much.
But it's actually very difficult because people are so invested in their job.
They're so invested in what they're doing that they don't see that they can spare an hour here
to do stuff like that.
What we've been doing is maybe a bit weird, which is different than sending people to conferences
and getting consultants here is that we've been kind of running this video series.
Uncle Bob.
Oh, yeah.
Robert Martin's awesome.
Yeah.
We've been running that and we've been having like talks after it.
That I think has been very good.
I definitely recommend for companies to do that.
It's probably one of the cheapest learning and development you can get, like in terms of bang for buck.
Yeah, I totally agree.
I think one of the things that people, companies, teams, individuals, like on all the levels,
don't necessarily realize is if you just spend like half an hour a week or half an hour twice
a week making sure you polish your skills, you learn something new.
After a few years, that really adds up.
Absolutely.
There have been other initiatives in the past.
Like we had, like on Friday, people had code cutters where they would meet up and they would
get like a task and then go in groups of twos and they would do something like write these
features, but don't use classes.
Stuff like that.
So these initiatives, they come and go.
I had a kind of a mob programming session, which was all about pulling code out and write tests for it.
Very interesting.
You know, I don't think we've talked about mob programming on this show.
I know what it is, but I don't think we've ever mentioned it.
Can you just give me like the really quick elevator pitch?
Like what is mob programming?
Basically what it sounds like, it's like one guy and a keyboard and he takes a test and people shout at him.
But of course, there's one driver and he probably knows a bit where he's going and then he kind of just listens to,
okay, so what do you want to do here?
Do you want to create a new method here?
Do you want to create a class or whatever?
Would you say it's kind of like paired programming, but many people on the pair side?
Yeah, and probably a lot, lot less efficient, but it sparks up a good conversation.
Right.
It's more, it's not necessarily like paired programming.
The expected output is solid code that you're going to ship.
Yeah.
Where I think mob programming is more about mutual understanding.
Yes.
And skill development and so on, right?
Yeah.
Also just getting people to kind of voice their opinions about how code should be.
Because that's, we actually just don't do that.
We write code, we put it up to code review.
But without me understanding what your agenda or what your philosophy about code is,
then chances are we're going to disagree on a lot of like fundamental things.
I would say so.
Yeah.
It sounds like a cool approach you guys have going there.
So one thing I wanted to ask you about, do you have any stories about like when there was
some giant unexpected rush of new traffic or new customers, like maybe like, you know,
a new release came out that was really popular or something like that?
Well, we had the other day, we had a new item come out that was very popular on the market.
And then that meant that everybody brought to that note, that cheetah note to sell stuff
and buy stuff on it.
Way more than what we've usually been expecting.
The thing is, we have a cup on that note.
We have like, we allow like max 2,000 people, I think, on it.
Because if we get more, or when we used to get more, then the game would be pretty unplayable
for everybody involved.
So we thought it was better to actually limit the amount of people that could be in there
at any time.
And their experience would at least be a little bit better.
And people can always play and be in other systems.
But because of a number of performance, like a big performance upgrade we've done, we kind
of saw that the server wasn't actually...
So we started increasing the cup.
We increased it first by 2,500.
And then we started reaching that.
So we increased it.
So we're thinking about increasing it to 3,000.
But instead, the development director said, like, looking at the graph, I think we should
just go to 5,000.
We can support 5,000 based on these numbers.
So that's what we did.
And we got 3,600 people there.
The CPU never went above 50%.
But the memory was actually getting to the limit.
Wow.
And that was actually like a...
It's a weird thing because we've gone from being memory restricted on a PC to almost not
having to think about it at any point.
Eve has this weird thing where we restart the cluster every day at 11 o'clock.
So whatever memory we have cast, that gets flushed out.
So the programmers on Eve have never really considered memory so much.
So we just cast it and then we never release it because we've never really had to release it.
So it's weird that when you have a lot of people coming in, we just saw the memory increasing and it never went down.
Oh, wow.
Nothing ever released that memory.
Yeah.
What I think is interesting about that story is when I think of some system getting hit with lots of traffic and having unexpected growth, I see it as an all or nothing type of thing.
Like the website now has a lot of visitors and so it's busy or not.
But the way you guys have structured your world, it's like there's a little node over there somewhere where a bunch of people went into that part of the universe and now that part is too busy.
That's an interesting way to think about scale.
Like I suspect most places don't.
Yeah, yeah.
It's always been a...
And it's both...
It's very funny to look at the kind of the overall CPU utilization of our clusters and you can see like it's using 10% CPU on average.
But still, you know that there are some people, there are some node there that is 100% and people are experiencing lag and you're seeing 10%.
Yeah, it's almost like you need sort of a mountain range type graph instead of just a level or something like this.
Very cool.
And in our old data center, what we used to have is that we had one node that was...
We called it the Everest node.
It only ran that one JETA solar system and it was a bit beefier than all the other nodes and it was just dedicated to running that particular node.
Yeah.
In the new cluster, I think all the machines are better than that old machine.
That was the good one and now it's old and crusty.
Very cool.
So I do have just a few more questions before we kind of wrap up the show.
Yep.
I was told on Twitter, thanks, I think it was Kyle that sent a message that said, I should ask you about the big red button.
Yeah, I always get that.
I'm a bit of a, I guess, infamous in the EVE universe.
So what happened is that I was just happily developing on my local clusters and I needed to do something.
Normally when I shut down the cluster, I just kill the process and start it off again.
But there is some logic that happens when you shut down the cluster, some persisting logic that I wanted to test.
So I go to the web page of the cluster and I shut it down properly or properly.
It's called an emergency shutdown and I gave it a minute timer.
So I did that and then I go back to my client and I don't see the normal message that I get when I shut down the cluster.
Like the cluster is about to shut down.
So I look at the page again and I realize I'm on the production clusters and I'm shutting down the production clusters.
Oops.
So I, and the only way to cancel it is to go to that page again.
So I did that and I canceled and I didn't know how long time had passed.
I knew I put a one minute timer there, but I just frantically clicked that button.
And it turns out I managed to stop the shutdown.
It never actually shut down.
But everybody that was logged in got that message that the EVE was shutting down and people really don't like that.
I'm sure they don't.
They really don't like that.
So they went on the forums immediately and said, like, CCP, what the hell?
Why are you shutting down the server?
Why do you have a one minute timer?
Because people want to get their assets to safety and stuff like that.
Right, of course.
Yeah.
So I did what just came naturally to me.
I just, I just went into that forum thread and saw, look, sorry, this is my bad.
I thought I was shutting down my development cluster.
And I'm being ridiculed by my coworkers now.
Yeah, I'm sure.
But it's really, really funny.
Because EVE players are like that.
They do get very emotional about it.
But they also are pretty cool people.
And honest mistake like that, they just let it slide.
Yeah.
And they're pretty technically savvy.
They are technically savvy.
They understand.
Some of them probably did this once.
And I think this even happened like a week after when someone in operations of QA, I can't remember, was going to shut down the test server and shut down that.
But he didn't go to the forums and apologize.
Yeah.
And didn't claim, you know, public responsibility and say something.
And I think that people like to remember that story as something.
Yeah.
This is messed up.
But I'd like to think that I just, I did the right thing by apologizing to people and explaining just exactly what went wrong and why I was being stupid for doing it.
Yeah.
It all happens to us.
One time I was teaching a training class.
And I'll try to not put any details about any place.
And I was somewhere in Chicago, let's say.
And I was teaching this training class at a financial place.
And they, for some reason, didn't have a proper room that they could use for all the 20 people that were in my class or whatever.
So they had given us this weird, like, secondary server room where there's all these servers along the wall.
But they weren't, it wasn't obviously the main data center.
It was just, like, servers that ran internals within the company, you know?
Yeah.
And I had this little squishy ball thing that I would use to, like, work out your hands or whatever.
And I was walking around.
It slipped out of my hand.
And it was odd shaped.
So it bounced like a crazy ball.
And it bounced along the students' desks, over along the wall, hit the wall, fell down, and hit a power strip that killed an entire wall of servers.
Oh, my God.
You hear it go quieter.
Oh, my.
That is bad.
So we quick turn them all back on and just go back to the class.
And about 10 minutes later, some guys rush in, like, what happened to the servers?
Everyone's like, we don't know.
So, yeah.
I've turned off the servers as well on accident.
Yeah, yeah.
Luckily, the students had my back.
All right.
Two quick questions before we go.
If you're going to write some Python code, what editor do you use?
I use PyCharm now.
I've used Sublime and Wim in the past.
But I think in terms of, like, a good IDE, I think nothing is better than PyCharm.
Yeah, I'm with you on that.
I love PyCharm.
That's what I use as well.
Awesome.
And then if you're going to go and look at PyPI, all the packages, I think there's like 75,000 of them now.
Are there ones that are super useful that you think maybe people don't know about that they should?
Well, what to choose from?
I love the request packets.
I think it kind of puts the simplicity in making, like, HTTP call.
Yeah.
What's interesting about that is it's, like, so simple, you can almost not appreciate how cool it is.
Exactly.
I really love that packet.
Mostly because I have probably used the other libraries.
And they are probably more flexible and stuff like that.
But sometimes you just want to make a get request on a resource.
Yep.
Request.get.
And you're good to go.
Awesome.
So if people want to get started with EVE Online, how do they do it?
Visit eveonline.com.
That would be the first step.
And I want to highlight a feature of that is that you can download the launcher.
And it starts downloading the game.
But it only downloads the stuff it needs.
So it only downloads the code and, like, a minimum set of resources.
So you can be within the game in, like, 10 minutes from there.
Oh, yeah.
That's awesome.
Yeah.
I definitely want to start playing and check it out.
It sounds really cool.
And after that, it just downloads the resources as it needs it.
So if you want to try it out, go to eveonline.com.
Sign up for a free trial and check it out.
It should take you less than 20 minutes on a decent minute connection.
Very cool.
Kristen, it's been fun to learn about what you guys have going on with Python.
A lot of cool stories.
Thanks for sharing them.
Yeah.
Thanks.
Thanks for having me.
Yeah.
Take care.
Bye-bye.
This has been another episode of Talk Python to Me.
Today's guest was Kristen Siger-Bergsen.
And this episode has been sponsored by Hired and SnapCI.
Thank you guys for supporting the show.
Hired wants to help you find your next big thing.
Visit Hired.com slash Talk Python to me to get five or more offers with salary and equity presented
right up front and a special listener signing bonus of $2,000.
SnapCI is modern, continuous integration and delivery.
Build, test, and deploy your code directly from GitHub.
All in your browser with debugging, Docker, and parallelism included.
Try them for free at snap.ci slash Talk Python.
Are you or your colleague trying to learn Python?
Have you tried boring books and videos that just cover topics point by point?
Check out my online course, Python Jumpstart by Building 10 Apps, at training.talkpython.fm.
And have a great time learning Python.
You can find the links from today's show at talkpython.fm/episode slash show slash 52.
And be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right near the top.
You can also find the iTunes and direct RSS feeds in the footer of the website.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
You can hear the entire song on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
Smix, take us out of here.
Stating with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
on first developers
of color
ٌ
For the content