Early systems that saved only on disconnect tended to also save periodically while the player was active. In those systems, typically MUDs (Multi-User Dungeons), the character was maintained in memory until they were periodically dumped to a file.

This meant that if a user disconnected without "camping", they usually found themselves several rooms away and missing a bunch of loot, XP, etc, from the last time they saved. In that regards, it behaved a lot like how console RPGs play today (you have to save your game without turning off the console, or you lose everything since the last time you saved).

The system worked for its intended purpose, because characters could not interact with each other, except possibly by way of a "mail" system where they could send messages and items to each other. The chance of losing items and progressed tended to be pretty significant, but only affected one character at a time in most cases.

The worldsave feature came about because characters were eventually able to directly interact with each other, so all of the characters playing had to be in a consistent state, or item duplication and deletion could occur. This wasn't a problem in the MUD scenario, because it was difficult to abuse the system in a way that resulted in item or currency duplication, but it was incredibly easy to do in early MMO MUDs. Player A gives player B an item, player B saves and player A disconnects without saving. Instant duplication.

Worldsave is not a performance benefit, but designed to prevent cheating. I recall playing on systems where the worldsave event was literally announced in advance, and often hung the entire system for a minute while the server updated all of its files. While this prevented cheating, it was not very convenient for the users of these systems.

That leads us to the current state of affairs. Today, we don't use worldsave type functions. We use databases. This allows us to make sure that duplication and deletion is minimized as much as possible. The characters exist as records in a database, and each transaction between players is a literal database transaction; either the action is fully committed or it will be rolled back.

Barring unusual bugs in the system, you get the benefits of saving individual character files (quick save times) and the benefits of worldsaves (no cheating), without the drawbacks of either (losing significant progress and item duplication).

When designing a modern MMO, you would want to create stored procedures in a database, and use those procedures to perform transactions. For example, when doing a trade between two players, it might look like this:

start transaction;
insert into inventory values(playerid=111, itemid=222, quantity=1);
delete from inventory where playerid=111 and itemid=444;
insert into inventory values(playerid=333, itemid=444, quantity=1);
delete from inventory where playerid=333 and itemid=222;
commit;

(Note: this may look like SQL, but probably isn't, and is only meant to be an example).

In this way, if there's a crash before the commit, the system rolls back to a state where player 111 and player 333 still have the original items, while after the commit, the trade is completed. There's no opportunity for duplication, because the characters are saved at the same time, as guaranteed by the database.

Early systems that saved only on disconnect tended to also save periodically while the player was active. In those systems, typically MUDs (Multi-User Dungeons), the character was maintained in memory until they were periodically dumped to a file.

This meant that if a user disconnected without "camping", they usually found themselves several rooms away and missing a bunch of loot, XP, etc, from the last time they saved. In that regards, it behaved a lot like how console RPGs play today (you have to save your game without turning off the console, or you lose everything since the last time you saved).

The system worked for its intended purpose, because characters could not interact with each other, except possibly by way of a "mail" system where they could send messages and items to each other. The chance of losing items and progressed tended to be pretty significant, but only affected one character at a time in most cases.

The worldsave feature came about because characters were eventually able to directly interact with each other, so all of the characters playing had to be in a consistent state, or item duplication and deletion could occur. This wasn't a problem in the MUD scenario, because it was difficult to abuse the system in a way that resulted in item or currency duplication, but it was incredibly easy to do in early MMO MUDs. Player A gives player B an item, player B saves and player A disconnects without saving. Instant duplication.

Worldsave is not a performance benefit, but designed to prevent cheating. I recall playing on systems where the worldsave event was literally announced in advance, and often hung the entire system for a minute while the server updated all of its files. While this prevented cheating, it was not very convenient for the users of these systems.

That leads us to the current state of affairs. Today, we don't use worldsave type functions. We use databases. This allows us to make sure that duplication and deletion is minimized as much as possible. The characters exist as records in a database, and each transaction between players is a literal database transaction; either the action is fully committed or it will be rolled back.

Barring unusual bugs in the system, you get the benefits of saving individual character files (quick save times) and the benefits of worldsaves (no cheating), without the drawbacks of either (losing significant progress and item duplication).

When designing a modern MMO, you would want to create stored procedures in a database, and use those procedures to perform transactions. For example, when doing a trade between two players, it might look like this:

start transaction;
insert into inventory (playerid, itemid) values (111, 222);
delete from inventory where playerid=111 and itemid=444;
insert into inventory (playerid, itemid) values (333, 444);
delete from inventory where playerid=333 and itemid=222;
commit;

(Note: this SQL, isn't written in a practical way and is only meant to be an example).

In this way, if there's a crash before the commit, the system rolls back to a state where player 111 and player 333 still have the original items, while after the commit, the trade is completed. There's no opportunity for duplication, because the characters are saved at the same time, as guaranteed by the database.

What you may have seen in regards to saving "files" and "saving every X minutes/hours" or some such was probably related to MUD (Multi-User Dungeons) and MUD-based MMOs that were common in the 1990's and early 2000's.

MUDs were typically those that had limited to no interaction between players, were often in text (later evolved into graphical interfaces), and were very primitive in terms of commands, as well as having limited computation resources and developed by inexperienced developers.

Databases were still basically for mainframes, not hobbyists, and MUDs were incredibly "fragile" in that they would often lose data if the user did not "log out" (e.g. if they just disconnected). I remember playing a number of these in the late 1990s on various BBSs and some early web sites.

In order to minimize data loss, these games would periodically save the character files for connected users, so that if the user was disconnected improperly (power outage, network issue, etc), they wouldn't lose all the progress they'd made since they logged in, but instead would only lose a few minutes of effort.

Note that saving character "files" is largely inefficient and unreliable, and does lead to the problem of duplication and deletion of items, currency, etc, especially when multiple characters are involved. MUD systems typically had no interactions between players, so duplicating items was not possible in these early file-based system. Many MMORPGs today instead use a database.

Unlike using raw files, a database organizes the transactions into discrete chunks of logic; either the entire transaction is successful or fails, with no "in between" state where items are duplicated or potentially missing if a crash occurs at just the right moment.

Player X trading with player Y can have problems no matter how the code is written if X and Y are in separate files. Items can be either lost or duplicated. This will happen unless the engine can guarantee that both files will save or neither will save. It's pretty hard to make this sort of guarantee when working with raw files.

In a database, however, you'd put all of the transactions into a single commit, like this:

start transaction;
insert into inventory values(playerid = x, itemid = 123, quantity = 1);
delete from inventory where playerid = y and itemid = 123;
insert into inventory values(playerid = y, itemid = 456, quantity = 1);
delete from inventory where playerid = x and itemid = 456;
commit;

(Note: While I have dabbled in SQL, this is not meant to be 100% real code).

If something happens after the "start transaction" but before the "commit", the entire transaction will never have happened, while if something happens after the "commit", the database will guarantee that that the transfer was successful and no items were lost or duplicated.

It also makes it easier to do backups, since databases are able to perform exports with consistent snapshots. When backing up normal files, in comparison, if player X and player Y are in two different files, and the server performs real-time backups, it's possible that X and Y will exist in two different states, again leading the possibility of duplicated or missing inventory.

With databases, you can instead do online backups, binary logging, etc to allow you to recreate the system state at any given second. Item loss would be incredibly rare (mostly in the form of loot you didn't pick up in time), and duplication would ideally never occur (barring, of course, the occasional developer bug).

Early systems that saved only on disconnect tended to also save periodically while the player was active. In those systems, typically MUDs (Multi-User Dungeons), the character was maintained in memory until they were periodically dumped to a file.

This meant that if a user disconnected without "camping", they usually found themselves several rooms away and missing a bunch of loot, XP, etc, from the last time they saved. In that regards, it behaved a lot like how console RPGs play today (you have to save your game without turning off the console, or you lose everything since the last time you saved).

The system worked for its intended purpose, because characters could not interact with each other, except possibly by way of a "mail" system where they could send messages and items to each other. The chance of losing items and progressed tended to be pretty significant, but only affected one character at a time in most cases.

The worldsave feature came about because characters were eventually able to directly interact with each other, so all of the characters playing had to be in a consistent state, or item duplication and deletion could occur. This wasn't a problem in the MUD scenario, because it was difficult to abuse the system in a way that resulted in item or currency duplication, but it was incredibly easy to do in early MMO MUDs. Player A gives player B an item, player B saves and player A disconnects without saving. Instant duplication.

Worldsave is not a performance benefit, but designed to prevent cheating. I recall playing on systems where the worldsave event was literally announced in advance, and often hung the entire system for a minute while the server updated all of its files. While this prevented cheating, it was not very convenient for the users of these systems.

That leads us to the current state of affairs. Today, we don't use worldsave type functions. We use databases. This allows us to make sure that duplication and deletion is minimized as much as possible. The characters exist as records in a database, and each transaction between players is a literal database transaction; either the action is fully committed or it will be rolled back.

Barring unusual bugs in the system, you get the benefits of saving individual character files (quick save times) and the benefits of worldsaves (no cheating), without the drawbacks of either (losing significant progress and item duplication).

When designing a modern MMO, you would want to create stored procedures in a database, and use those procedures to perform transactions. For example, when doing a trade between two players, it might look like this:

start transaction;
insert into inventory values(playerid=111, itemid=222, quantity=1);
delete from inventory where playerid=111 and itemid=444;
insert into inventory values(playerid=333, itemid=444, quantity=1);
delete from inventory where playerid=333 and itemid=222;
commit;

(Note: this may look like SQL, but probably isn't, and is only meant to be an example).

In this way, if there's a crash before the commit, the system rolls back to a state where player 111 and player 333 still have the original items, while after the commit, the trade is completed. There's no opportunity for duplication, because the characters are saved at the same time, as guaranteed by the database.