Trivia: Diablo 2 stores its data as tab-separated value files. Some of those files have more columns than Excel could support at the time… so the modding community made their own editors.

I don’t understand how editing a number in an excel file is any easier than editing a number in a text file. What was it that made the difference?

Probably table representation. It's relatively hard to implement something similar using text format. You can have row for every unit in the game with columns corresponding to various characteristics. It looks very natural in Excel, but it would require quite a lot of formatting and errors with text file. Also Excel could have formulas which might be useful somewhere and supporting formulas in config file is another level of complexity and almost certainly it'll be worse than Excel.

Then use a real database. You probably have a SQLite dependency anyway, so take advantage of it.

Or don't, since SCMs are much better at diffing plain text than either.

> Also Excel could have formulas which might be useful somewhere and supporting formulas in config file is another level of complexity and almost certainly it'll be worse than Excel.

You'll have an easier time reimplementing Excel's formula system than basic arithmetic? I find that hard to believe.

> You'll have an easier time reimplementing Excel's formula system than basic arithmetic? I find that hard to believe.

I'm not sure you understood what the parent was saying? This seems like a non sequitur.

In a spreadsheet, derived values can be updated instantly. Say you want to upgrade a bandit from leather armor to chainmail (6 or so equipment items changed), and then verify that his total defense and modified movement speed are still within reasonable ranges for the part of the game where he appears. With a text file, you've got some arithmetic to do. With a spreadsheet, it's there at a glance.

Or say your enemies are missing too much, and you want to give them +10% accuracy across the board, for all of 50+ enemies. In a text file, that's a lot of cursoring around. In a database, you could knock together a query to do it, but that still might take a couple of minutes, depending. In a spreadsheet, I could do it in 15 seconds. (And if I screw it up, a couple of Ctrl-Zs puts everything back where it started. That's not so easy in a database.)

And, y'know, a lot of programmers really underestimate the value of good formatting. A database can spit out nice columnar tables easily, but a spreadsheet can do things like put borders between stat clusters related to different categories; automatically color-code data so you can see at a glance what the highest and lowest values in a given column are, or spot out-of-range derived values; add alternate-row shading to make it easier to scan across a long row; and on and on. That is useful. It lets you find and correlate the data you want faster with fewer errors. Not everything has to be viewed in flat text.

Your first couple of points reminds me of a talk[1] about using a graph database for tracking all sorts of entity and quest dependency relationships to assist in game balancing and content creation.

[1] https://www.airpair.com/neo4j/posts/modelling-game-economy-w...

All this sounds very useful! If I ever decide to make a game I will definitely use a spreadsheet as database.

I have tinkered with modding Diablo II (which uses tab-separated values for parameters) and the classic Command & Conquer series (which uses INI files).

Both approaches have tradeoffs:

- TSV files can have so many columns that you can't really edit them in a text editor, you'll never find your place. Some of these in D2 have more than 256 columns.

- INI files don't give you a full list of configurable parameters, so you might not even know what flags the engine supports if they're mentioned only once in the entire file or not mentioned at all. Some object types in Red Alert 2 support over 700 flags, not all of them are actually used in the default config…

- two items described in a TSV file are easier to compare than two INI sections, with INI you need a second editor window and some ordering of the keys to make sense of things.

- on the other hand, diffing a TSV file for changes is a lot more challenging.

At the time, I remember thinking how a proper database would make this easier.

---

I have also seen a game where a \n was used as a record separator and \r was used to insert newlines into the text string within a record. Fun times when your text editor tries to "intelligently" handle and normalize line endings.

You could have json and a schema. VSCode for example does this, all settings is just a settings.json but it still has auto-complete inside it so you always know what settings are available.

Aside from the UI advantages others mentioned, another possible benefit is that, with the right formulas set up, you can instantly eyeball the combined effect changing one factor has on every other factor that’s derived from it. I don’t know how important that normally is, but I play a lot of Paradox games, and those games are almost entirely governed by numbers that have combinatoric effects on gameplay.

Quickly changing a few stats would probably be easier in an excel file, every stat is directly below the next, one key press to move to the stat and change it.is faster than scrolling 3 or 10 lines to the next one then placing the cursor on the correct character etc. I can see how it would be faster for some use cases. If someone is doing it then it is probably because they found it to be effective.

Because non developer is able to find it at glance. And then he is able to see how related values chaged - at glance with zero effort and delay.

And non developer can easily write own formula to next cell whenever he feels like and don't need to wait for programmer, don't need to explain and don't need to fight if programmer happen to be stubborn.

Even seeing what depends on what is easier with right excel plugin then debugging scripting code.

I agree. Text file edit seems much quicker.

Back when I worked on cars, the configuration parameters the firmware devs used for the control units were all in excel spreadsheets, with some plugin or other and a bunch of macros to flash the hardware. As far as I could tell, the main benefit of this setup was that the devs didn't have to build their own UI that looked good in a table, and allowed searching and sorting.

Text files or Excel for the game data?

Pardon my ignorance, but why aren't they using some sort of database for the data? Or at least storing the data in some sort of master database and exporting it to text files for the game to read? It would be lovely to hear the techniques and reasons from anyone in the know.

I don't know exactly, but I wrote a post about some hypothetical advantages here: https://news.ycombinator.com/item?id=18153661

(IIRC it's for convenience in development. I doubt the game ships with an embedded Excel file.)

Modding tools (supposedly based on real SDK) for Homeworld (don't recall if 1 or 2, I think 2 since I recall switching some crucial values to make game easier for last mission) used Excel with extensions.