4 ms·

This brings back the memory of how we used Microsoft Excel to generate the .csv files to drive the game engine in Diablo 2 and stored the .xls files in version

This brings back the memory of how we used Microsoft Excel to generate the .csv files to drive the game engine in Diablo 2 and stored the .xls files in version control, by the time we started work of production on the expansion we only needed about 3 of the 10 programmers (at our studio) to support the work because most of changes could be done by adding lines to the spreadsheets. This might sound rote today but the original, Diablo 1, had a bunch of hardcoded tables in the source code. I still used the Diablo 1 source code as a starting point for a lot of stuff, though. :)

onion2k 3y ago
Diablo 2 was a lot of fun. It's cool to hear about how it was made. :)
- stevenwoo 3y ago
  Here's more useless trivia, my brain is cluttered with superfluous memories, I can't remember every algorithm but I remember the minutiae. I remember our producer Matt Householder telling me the bad experiences they had outsourcing the development of Diablo 1 expansion and ports meant they really wanted to make the Diablo 2 expansion in house. So at one point early in production on Diablo 2, our lead programmer, Rick Seis, had the .csv importing functionality as his primary task which seemed kind of mundane even at the time and now probably standard in most language libraries, and we transformed the Diablo 2 hard coded tables ( we were mostly following Dave Brevik's examples in Diablo 1!) into Excel spreadsheets. Then afterwards Peter Hu was on an optimization crusade towards the end, he made a .csv binary compacter/reader to save runtime.
  - corysama 3y ago
    If you are ever in the mood to do an unstructured brain dump of superfluous memories, https://old.reddit.com/r/TheMakingOfGames/ https://old.reddit.com/r/TheMakingOfGames/ would love to read it :)
    - stevenwoo 3y ago
      Thanks, I did a quick search and found alot from whom should be considered the uber sources of information about Diablo development, David Brevik and Erich Shaeffer. I was just in the trenches for Diablo 2. One thing I remember about the crunch per David's piece on crunch, he neglected to mention that when he gave a speech announcing we would crunch until we finished, and if we finished in time for holiday release that year the entire studio would get a free trip to Las Vegas, or we would get fired. Kelly Johnson, a character artist was standing near me during the meeting and mumbled something under his breath but I don't think anyone thought we would generate the content required for that deadline, but I believe he had to give a speech about it I'm guessing for appearances' sake.
corysama 3y ago
Game designers really like Excel —for good reason. I’ve set up the tech for many games over the decades where we had designers write tiny snippets of code in the cells of Excel spreadsheets. First in a custom assembly-like language (for an N64 game) then in SmallC, actual C++ and mostly in Lua. The general theme was to use the grids to define state machines. Rows are states. Columns represent events. Cells define what to do at the intersection of an event in a certain state. Later games also used Lua code cells as active spreadsheets in the game. The Lua statements would calculate results when queried. The charts didn’t just know about raw numbers and strings. They also could load and manipulate assets in the game. So, a designer could describe which UI asset to put next to the health bar based on the player’s current health stat without bothering a programmer or artist. In the last case, we shipped two very different 3D mobile games using the same executable but different assets. Live hot-reloading of the Lua charts, the UI XML and all the other assets meant that we didn’t even need to bother making an editor for our custom engine. A good text editor window next to the game window was productive enough.
- stevenwoo 3y ago
  As part of the push to involve the designers more in production, I made a scripting engine and language to drive the quests in Diablo 2 roughly as you describe. By the time we go close to the end, none of the designers bothered to use it (we officially only had one at our studio but many people dabbled) so for my convenience I just took it out and replaced it with a function table that was there originally, I really regret that because I imagine the unofficial mod scene would be even more amazing if I left it in. The objects and monsters worked roughly as you describe, adding new ones (without new features) meant just adding and customizing a new line in the appropriate spreadsheets.
- sdwr 3y ago
  That's the dream! Live hot-loading and a text file. I was working on a Lua game a while back, and the feedback loop, although way faster than enterprise development, still got me bogged down when it came to balancing. I was using hardcoded tables for unit stats, and it's a surprising amount of mental overhead to go back and forth tweaking those.
riksteri 3y ago
It was very nice how you let users edit those data files, enabling mods. I started my game development career by editing those same spreadsheets. Naturally, my own games also use user-editable data files. Sometimes very similar spreadsheets, borrowing the structure from you. Paying it forward. Thanks for Diablo II.

onion2k 3y ago

Diablo 2 was a lot of fun. It's cool to hear about how it was made. :)

stevenwoo 3y ago
Here's more useless trivia, my brain is cluttered with superfluous memories, I can't remember every algorithm but I remember the minutiae. I remember our producer Matt Householder telling me the bad experiences they had outsourcing the development of Diablo 1 expansion and ports meant they really wanted to make the Diablo 2 expansion in house. So at one point early in production on Diablo 2, our lead programmer, Rick Seis, had the .csv importing functionality as his primary task which seemed kind of mundane even at the time and now probably standard in most language libraries, and we transformed the Diablo 2 hard coded tables ( we were mostly following Dave Brevik's examples in Diablo 1!) into Excel spreadsheets. Then afterwards Peter Hu was on an optimization crusade towards the end, he made a .csv binary compacter/reader to save runtime.
- corysama 3y ago
  If you are ever in the mood to do an unstructured brain dump of superfluous memories, https://old.reddit.com/r/TheMakingOfGames/ https://old.reddit.com/r/TheMakingOfGames/ would love to read it :)
  - stevenwoo 3y ago
    Thanks, I did a quick search and found alot from whom should be considered the uber sources of information about Diablo development, David Brevik and Erich Shaeffer. I was just in the trenches for Diablo 2. One thing I remember about the crunch per David's piece on crunch, he neglected to mention that when he gave a speech announcing we would crunch until we finished, and if we finished in time for holiday release that year the entire studio would get a free trip to Las Vegas, or we would get fired. Kelly Johnson, a character artist was standing near me during the meeting and mumbled something under his breath but I don't think anyone thought we would generate the content required for that deadline, but I believe he had to give a speech about it I'm guessing for appearances' sake.

corysama 3y ago

Game designers really like Excel —for good reason. I’ve set up the tech for many games over the decades where we had designers write tiny snippets of code in the cells of Excel spreadsheets. First in a custom assembly-like language (for an N64 game) then in SmallC, actual C++ and mostly in Lua. The general theme was to use the grids to define state machines. Rows are states. Columns represent events. Cells define what to do at the intersection of an event in a certain state. Later games also used Lua code cells as active spreadsheets in the game. The Lua statements would calculate results when queried. The charts didn’t just know about raw numbers and strings. They also could load and manipulate assets in the game. So, a designer could describe which UI asset to put next to the health bar based on the player’s current health stat without bothering a programmer or artist. In the last case, we shipped two very different 3D mobile games using the same executable but different assets. Live hot-reloading of the Lua charts, the UI XML and all the other assets meant that we didn’t even need to bother making an editor for our custom engine. A good text editor window next to the game window was productive enough.

stevenwoo 3y ago
As part of the push to involve the designers more in production, I made a scripting engine and language to drive the quests in Diablo 2 roughly as you describe. By the time we go close to the end, none of the designers bothered to use it (we officially only had one at our studio but many people dabbled) so for my convenience I just took it out and replaced it with a function table that was there originally, I really regret that because I imagine the unofficial mod scene would be even more amazing if I left it in. The objects and monsters worked roughly as you describe, adding new ones (without new features) meant just adding and customizing a new line in the appropriate spreadsheets.
sdwr 3y ago
That's the dream! Live hot-loading and a text file. I was working on a Lua game a while back, and the feedback loop, although way faster than enterprise development, still got me bogged down when it came to balancing. I was using hardcoded tables for unit stats, and it's a surprising amount of mental overhead to go back and forth tweaking those.

riksteri 3y ago

It was very nice how you let users edit those data files, enabling mods. I started my game development career by editing those same spreadsheets. Naturally, my own games also use user-editable data files. Sometimes very similar spreadsheets, borrowing the structure from you. Paying it forward. Thanks for Diablo II.