Penrif

Important to pair with that though the practice of writing code to a human reader. If the code is going to be the documentation, I would argue it is more important that it be understandable to a human than be perfectly set up to be optimal to a computer.

Fair enough!

It was scary to write too.

How long it would take to do so. Webtech offered the ability to start work immediately, while going the game tech option would have required an unknowable amount of up-front development work to create the framework for content implementation before anything else could be done.

Having now put in that work in service of TFT mobile, we know how much it was. But that's not something that could have been known before actually doing it. Software development estimation is notoriously fraught.

Bingo. Hindsight being what it is, it's possible to think through what the other option would have taken and think it was obviously the right choice, but that's using information that was not available at the time, which is deeply unfair to the individuals that made the call in the moment.

"Never" is not applicable here. It is a large effort, but League has invested in large efforts like that before - we just don't do so lightly.

Please take a deep breath and re-read my post. At no point am I blaming the backend, and the fundamental change of going to native is what most of the post is talking through. The part you quoted is covering the idea of re-implementation without any fundamental changes - ie, take another swing using the same tech stack, which I think you'd agree would be folly.

Native by default, with CEF to cover the pieces that truly are best covered by JS stack. Best of both worlds.

Don't suppose you have a magic wand I could borrow?

It's not using Electrion ;)

It's built on top of the Chrome Embedded Framework, with a custom-built foundation underneath.

As to your larger question of why the JS stack is sometimes picked over native solutions - I can't possibly speak for the entire tech industry on that, but I'm happy to give my personal opinion based on what I've seen in general industry trends.

I think there was a lot of hype super early in the development of the interactive web that had people believing the future of the native application was limited. The Google suite in general gave that a lot of ammunition - if you can compete with MS Office using web tech, what can't you do? That's a sane, reasonable conclusion to make if you aren't aware of the massive amount of work that goes into making those products as smooth as they are. As with much tech industry hype, there is a lot of value inside of it. Web-based applications are hugely valuable and solve many problems that ...

Addressed in a different reply

The major difference is being implemented with game engine technology vs web technology, for the most part. This allows for all the optimizations and standards that make the game run smooth to apply to the out-of-game experience as well.

I went into a fair amount of detail as to where League's on that in a different reply.

Thanks for the question! This is a deep one and is going to take a bit of history, so let's go for a little walk.

League, since the very beginning, has had two pieces of client software - the out-of-game client and the in-game client. For brevity, let's just refer to "the client" as the out-of-game one - the in-game one isn't what this AMA's about. Originally this was implemented on top of Adobe AIR, and went through a major rewrite a few years back, implemented on top of web technologies.

This split is not something that many games do. I struggle to think of an example really - the vast majority of games, including the other ones Riot makes, implement their out-of-game experience in the same piece of software that the in-game experience is delivered on. This has a lot of benefits, but the biggest of them is that the same experts that are tasked with making the in-game experience snappy and responsive can apply the same techniques to the out-of-game experience....

Sorry I haven't really cultivated my audience much =/

o7 m8

http://matt.might.net/articles/phd-school-in-pictures/

We may be at different angles off the center, but that doesn't make our specialties any more or less "smart" than the other

It's a popular open source framework. Reckon rolling your own clustering is quickly becoming like rolling your own crypto - just don't.

That'd have to be something else entirely - the game servers don't run in the container cluster presently. I didn't see any major network issues with NA last night - possible that y'all are on the same ISP and they were having issues?

It's very spread out - the examples you call out in a single champ select are spot on correct. There's a few more but I'm fuzzy on the exact splits so I hope you'll accept a bit of handwave there. In the core game loop we also have other services like the one that manages parties, one for matchmaking, and on the flip side there's separate services for processing mission results and storing your match history, for example. Very much in the microservices style of architecture.

We're nearly done moving to a different container scheduler entirely, and that one has much more expressive constraints that will allow us to problematically ensure exclusivity on host across shards with a bit of configuration. Until the edge services can be transitioned over however, we've set up alerting that prompts us to do a manual remap if problematic crowding occurs. That's been working well for the past couple weeks since this incident.

Glad you liked it! If you have any questions, I'm happy to help clarify anything