7 ms·
Wow they didn't use any DB at the start of UO, that is amazing haha "As Raph also notes, there were no databases originally involved in the storage of game sta
by Globz 11y ago
Wow they didn't use any DB at the start of UO, that is amazing haha
"As Raph also notes, there were no databases originally involved in the storage of game state or player data for UO (disregarding analytics here), everything was kept in flat files. Backups worked by flagging a moment in time where no one was allowed to cross server-boundaries -- during that moment, each areaserver was commanded to fork(), essentially duplicating itself in memory (it's more complicated than this, thanks to Copy-on-Write, but let's simplify). After everyone had fork()ed, the "lock" preventing boundary-crossing was cleared. Then each areaserv began to dump out its huge chunk of memory-state into a file on an NFS server. Those files were then all tarred together and kept as a "backup" of the state of the server. These heavyweight backups happened at half-hour intervals, I believe."
- pmelendez 11y agoThis website (as far as I know, I don't know if they changed that) since the beginning uses flat files instead of a database. Depending on the case it might actually work and be a valid strategy for persistency
- madez 11y agoI also think flat file storage is a valid solution. If you are abke to use advanced filesystem features like snapshots and online replications, the use-cases for databases shrink even further.
- Globz 11y agoYeah I have no doubt that flat file are a valid solution, I think the only headache was related to a dupe bug. "Server-boundary crossing edge-cases and race conditions persisted for a long time -- allowing for gold and items to be duplicated, though I think we had largely eradicated the big ones by the time I had moved on to UO2."
- moonchrome 11y agoI built a content pipeline and CMS on top of flat files (json) and mercurial. You can get repository level transactions by committing on each consistent state (squashing before push) this lets you do undo/redo and recover from failed operations easily - databases sort of give you this - but only for the stuff they actually contain (so unless you're putting your asset files in to the DB you don't get this).
- SixSigma 11y agoSQL is so fancy you can get a long way with join, awk & grep http://man.cat-v.org/plan_9/1/join http://man.cat-v.org/plan_9/1/join
- herge 11y agoTransactions are really fancy too.
- deleted 11y ago[deleted]
- Alex3917 11y agoTheir initial strategy involved purposely losing an hour of player data every day. Everyone used to troll newbies by pretending to be nice and giving them free stuff around 11am, and then by 12pm it would suddenly all disappear and revert back to the original owner.
- eleonardo 11y agoAs mentioned in some of the replies to the Quora question, this was also a great time to mess around in PvP and put on all of your best equipment (armor of invulnerability, and weapons of vanquishing) and head out to the dungeons to cause chaos. Or taking 80+ purple explosion potions with you and hucking them at groups of people still fighting in the dungeons. If you died, oh well, like you said everything that happened in that hour got reverted.
- logicallee 11y agofork - the original NoSQL
- Shivetya 11y agoOh the days of the Chesapeake shuffle, what many us used to call the lag spikes and rollbacks the afflicted the game early on. You could tell your servers cycle time with little effort and there were days when everything was just out of sync and even movement from certain areas was not a certain event. This model apparently allowed for quite a few dupe bugs, one of which I published on an old fan site. It was quite involved, in fact I wrote it up so deliberately convoluted that what you were doing was obvious. Did it work, I wasn't quite sure but I did suffer both duplication of items and loss from their system through no effort on my part. Its kind of funny to learn how they did it this late, reminds me of mechanisms we employed with some early multiplayer door games on BBSes. Supporting multiple players for some early titles was a bear, the least of which was the lack of stability of most connections just plain bad code that bit you in the butt more often than not.
- codingdave 11y agoI'm not so shocked... I'm a web developer, not a game developer, but databases were avoided as part of production stacks in the 90s. Most people tried to stick to flat files. A database layer added complexity and decreased performance. Even most content management systems had an option to write everything to a flat file to serve via a web server. Those were the days that Apache servers and a huge pile of flat files was the norm. Once web content began to be personalized, that was no longer realistic. Databases became a required part of the stack, web servers ran applications instead of just serving file, we gained massive amounts of functionality, and haven't really looked back.
- eli 11y agoBy most defintions, I think structured "flat files" in a filesystem IS a type of database.
- TeMPOraL 11y agoIt is, but it adds the requirement for installing and configuring another application running in the background. Before SQLite, flat files really seemed like the best option for small projects.
- eli 11y agoI don't understand what background application you're referring to. If I have an app that reads and writes to a bunch of CSV files how is that any different from using libsqlite3 to read and write to an sqlite file?
- outworlder 11y agoThat's clever. Freeshards usally went with a stop-the-world-worldsave. Which means they were infrequent and easily corrupted, leading to "timewarps".
- mackal 11y agoNeither did EQ AFAIK
- jerrysievert 11y agoMUDs, the both spiritual and technological precursors to UO also used flat files for storage of both maps and users. it's not too surprising the UO storage was the same.
- SCdF 11y agoHN itself uses flat files for each of these comments! Somewhat off topic, but one the pieces of code I'm most proud of was effectively a recursive XML scraper that resolved each leaf (each node was a web request) into a line (like a file path) of a massive text file, which was then grepped when a user searched for something. I hacked it together really quickly to solve a problem, which is solved orders of magnitude faster than commercial solutions that tried to be overly clever. I like it because while it was gross and bad and would be embarrassing to read, in reality grep is crazy fast and the OS cached the text file once you'd read it once. It's a nice personal reminder to me that you don't always need to build some Grand Design, especially when you're just building a tool that has no future evolving path.