4 ms·

It of course depends on the demand, but very low in general. During periods where I don't have a lot of player activity even a single vCPU is enough to host abo

It of course depends on the demand, but very low in general. During periods where I don't have a lot of player activity even a single vCPU is enough to host about 2.000 simultaneous players.

yazaddaruvala 7y ago
> It of course depends on the demand Do you require downtime to scale or is it seamless?
- ItsFirefly 7y ago
  Migrating requires downtime since the game server runs as a monolithic entity. I migrate between dedicated servers and VPSes based on expected demand. Right now we're running on big metal to be able accommodate many players coming while I'm more actively promoting it. When the hype settles down I'll probably move back to a small VPS. I always joke that Angeldust and the server would even run on your toaster. I bet it would even be able to serve hundreds of simultaneous players before turning into toast.
  - plasma 7y ago
    Not sure how your backend works, but I read a neat technique by I think Second Life, where each actor is in a zone, and a zone is managed by a server. If a player leaves the zone, their entire code stack and current state is shipped to the next zone (script hand off) without the player noticing. They mentioned because each actor is running in a VM/scripting language, the servers can pause/resume the VM for that actor on any machine they move to - pretty neat.
    - ItsFirefly 7y ago
      You can read a bit about the Angeldust backend architecture in this comment chain (I have no idea what to call this): https://news.ycombinator.com/item?id=21858618 https://news.ycombinator.com/item?id=21858618 The Second Life approach sounds like a very good solution if you're having to, and willing to use multiple servers because of performance reasons. I think Angeldust's architecture is a bit cleaner and more straightforward due to different design goals. I specifically wanted to reduce complexity and keep a simple infrastructure so that I could code, debug and manage everything on my own. I also have the luxury of using a single, big, many-core server if necessary. When Second Life started I don't think 32+-core servers were a thing, so their scaling model was probably also born out of sheer necessity.

It of course depends on the demand, but very low in general. During periods where I don't have a lot of player activity even a single vCPU is enough to host about 2.000 simultaneous players.

yazaddaruvala 7y ago

> It of course depends on the demand Do you require downtime to scale or is it seamless?

ItsFirefly 7y ago
Migrating requires downtime since the game server runs as a monolithic entity. I migrate between dedicated servers and VPSes based on expected demand. Right now we're running on big metal to be able accommodate many players coming while I'm more actively promoting it. When the hype settles down I'll probably move back to a small VPS. I always joke that Angeldust and the server would even run on your toaster. I bet it would even be able to serve hundreds of simultaneous players before turning into toast.
- plasma 7y ago
  Not sure how your backend works, but I read a neat technique by I think Second Life, where each actor is in a zone, and a zone is managed by a server. If a player leaves the zone, their entire code stack and current state is shipped to the next zone (script hand off) without the player noticing. They mentioned because each actor is running in a VM/scripting language, the servers can pause/resume the VM for that actor on any machine they move to - pretty neat.
  - ItsFirefly 7y ago
    You can read a bit about the Angeldust backend architecture in this comment chain (I have no idea what to call this): https://news.ycombinator.com/item?id=21858618 https://news.ycombinator.com/item?id=21858618 The Second Life approach sounds like a very good solution if you're having to, and willing to use multiple servers because of performance reasons. I think Angeldust's architecture is a bit cleaner and more straightforward due to different design goals. I specifically wanted to reduce complexity and keep a simple infrastructure so that I could code, debug and manage everything on my own. I also have the luxury of using a single, big, many-core server if necessary. When Second Life started I don't think 32+-core servers were a thing, so their scaling model was probably also born out of sheer necessity.