What, HYPOTHETICALLY, would be needed?

[LadyVamp]

it is very unlikely they they had 1 account for all games.  more than likely, each domain was a child of nc's parent gaming account domain if they were linked at all.  Highly doubtful they were linked.  As for any privacy issues, it's a non-issue.  You chose to give ncsoft your information when you signed up for the game.  by extension, you agreed to having that information sold to anyone who bought the game.  Same thing happens when a bank sells your loan to another bank.

did I forget to mention mice love peanut butter?

[Codewalker]

Account Data != Character Data

Now, proving which characters actually belonged to you might be troublesome if someone bought one but not the other.

Not to mention all the microtransaction stuff from the later days. Whoever bought it would need to have a solid plan for that can of worms.

[LadyVamp]

It's doable with a single account.  Your account's id (likely a uuid) would be a foreign key in the character table which is probably how they tell which characters belonged to each account if a single account for all games.  It's possible for a single account across multiple databases but that's error prone.  The game server would have to login two databases at the same time to get the info it needed.  As for the database, each game would have a unique database.  Probably a single server or a pair in a cluster.  each game would have its own database hosted on the database server and unique accounts for each game.  Just one "master" account to administer the game accounts

VMs, possible but I don't think so.  Compared to today, VM tech wasn't that strong 10 years ago and blade servers with a Terabyte of ram where unheard of outside of mainframes.  A VMware or Xen or KVM cluster today would rock running gaming vms but that's today.  I would guess those servers where single core xeon (probably 2 to 4 cpus) running 500-700MHz or so with maybe 16GB of ram if that much.  dual cpu with 16 cores each with hyperthreading to make it look like 32 CPUs and 768GB of ram on a single server just didn't exist back then.  Today, that's $20k.  10 years ago, that was a server room worth of servers.

[Codewalker]

Given what I know (well, theorized with a high degree of confidence) about how the game works, running mapservers in VMs wouldn't make much sense. They can already be reasonably balanced between physical hosts without the added overhead. OTOH, dedicated mapserver hosts wouldn't contain any useful data that gets permanently stored on them anyway; they just run the game logic based on client input.

There's supporting evidence (IP logs) that mapserver hosts were not limited to serving zones or missions for a particular shard. So the same server hosting Freedom's Brickstown could also be running a villain mission or iTrial for Virtue without a problem. That kind of pooling allows for fairly decent load balancing to happen automatically. It would work best for a large-ish installation with lots of players spread across lots of shards.

Mapservers also make up the bulk of the hardware needed, since they do ALL of the heavy lifting.

Now, virtualizing the "shard" servers that people log into and coordinate mapservers, or global stuff like chat and auctions does make more sense. I wouldn't be surprised to find out that those were VMs.

Actual database servers... maybe, maybe not. If it's SQL, many server admins I know have a phobia of visualizing that due to perceived I/O issues that don't really exist.

[Ironwolf]

I wasn't very complete in my answer on account data.

There is a vast difference from taking over an existing game and just porting it over to new management versus a closed game that has been off the books for over a year now. I would not be sure they could link the account and character information now. You are saying they still hold all the credit information for 100,000 people on a closed game? Many of those cards will have changed now - my own has for a certainty.

Now your login account may still exist and that could possibly still link to the characters. In all honesty it depends on how they saved everything - I mean in reality how much data for the game would there be, 100 gb? You could have all that on one drive or tape. So the entire game could be on a shelf in South Korea, wrapped in anti-static material and gathering dust.

[LadyVamp]

The credit card data would be hiding in their accounting system on whatever backup media they used at the time.  Out of date?  I would think so.  They would at best have the old dates which is part of what the credit card processor needs.  If the game were active now, that information would likely be delivered to the buyer of the game.  Since it is no longer in service, very unlikely ncsoft would provide it.  It would be a very bad business practice.

As for the actual data you'd need to reconstruct the game, it's not much more than the code repository they used for revision control.  Probably Git or SVN.  Without our accounts, the toon data is worthless.  Any stories written in AE is about all the player created parts of the game they could salvage.  My guess would be all of game's repository would fit on 2 or 3 DVDs and most of that likely is the artwork and sound effects/music in the game client.

[LadyVamp]

Based on what I remember from the maintenance outages, I would say they had each server carrying 2 or 3 complete worlds.  They always seemed to be down in pairs or triples.

Now, I like the idea of the servers as VMs since in theory you could (provided you had the capacity in hardware) spin up VMs for high load situations.  You could even set it up so that a fixed number of public mapservers existed that run only the public maps.  When someone started a private map, players on the team transfer to the VM handling just that map or perhaps a variable number of maps with a fixed max for the private mapservers.  If you hit the max, spin up another VM in the waiting for work pool and grab one that's in hot standby for work from that pool.  These private mapservers would handle private maps for all public map mapservers.  Basically, have 2 private mapservers in that waiting pool.  When someone starts a private map and there is a need to grab a server from that pool (all currently working private mapservers can't take another private map), grab it to start their mission and start another VM for that pool.  The pool would always have say 2 private mapservers with no work waiting.  If capacity would push that pool to greater than 2, spin down VMs or pause them so that only 2 are on hot standby if desired.

Where I work, we actually do that in a semi automated way with our testing environments.  A set of programmers can order environments for testing code.  They order it, it's cloned from libraries, configured as needed, and in their hands in 30 minutes or less.  We could have it done in 2 minutes where it not for all the configuration work.  But, there's no work done by us.  Our automation handles all of it from submitting the order, through life cycle, and the expire/release resources cycle.  We're even considering setting up automated code testing where the programmer submits his/her code to a testing server with a battery of desired tests.  The testing server will order an environment, run the tests, kill the environment, and report test results in a completely automated way.  No humans beyond the programmer submitting his/her work for test.