Diablo creator David Brevik is back with a new game: It Lurks Below
polygon.com
polygon.com
Some other team members such as Max Schaefer and Erich Schaefer (co-designers of Diablo and Diablo II) went on to make Torchlight so many consider it to be Diablo's spiritual successor: https://en.wikipedia.org/wiki/Torchlight
He did hellgate london (pile of shit) and Marvel Heroes (kinda a mmo successor to the marvel ultimate alliance games but deeply diablofied (didn't play much but it seemed .. ok))
Particularly he had a lot of experience with the rogues which heavily inspired the original Diablo. Because of this he was initially opposed to making the game real-time as opposed to the traditional turn based, enemies only move when you do rogue style.
However as he tells the story he programmed real time movement in a few hours on a Friday night just to see what it would be like. When he tried it out for the first time and clicked the mouse; almost magically the warrior walked over and smashed a skeleton into a pile of bones.
He was convinced right then that real-time was the right choice.
That moment may have been the birth of the ARPG genre.
Gauntlet (1985) had real-time combat, and predated Diablo by at least a decade. If that isn't RPGish enough, Ultima Underworld came four years before Diablo.
Diablo definitely perfected the ARPG, though.
The first graphical game I played that leveraged the need for a lightsource similar to Moria. Not sure if you also needed food for your team.
Like a mix of rouge-likes and isometric/3d real-time with a pinch of "eye of the beholder".
In his own words: https://www.youtube.com/watch?v=VscdPA6sUkc
https://en.wikipedia.org/wiki/Ultima_Underworld:_The_Stygian...
If you are interested you really should check the postmortem from the GDC a few years back https://www.youtube.com/watch?v=VscdPA6sUkc
From my experience programmers influence the way a product looks like, they are not merely "engine creators". They have too kill some "features", create new ones that designers didn't think of.
Programming is not a simple assembly line, where designers create the whole product and workers do it as they are told.
Don't leave us hanging, is there a hidden cow level in the Diablo 1 source?!
What are you working on these days? Are you still in the games industry?
But also thanks for your work, still playing D2 :)
> Don't leave us hanging,
Yes, don't leave us hanging!
Did you ever work on the problems of item duping on Closed Battle.Net?
I never understood why some games were "bugged": Certain characters would leave a game and find that their inventory would not save. This meant they could go back in the game, drop all their items, leave the game, and repeat this while the characters that did save could pick it up, creating copies of good items. The mule character could even join another game where it would save, stock up on good items and drop those.
I also never understood what would trigger a bugged game. We used IRC for announcing whenever a "run" turned out to be buggy for a single player. And I wrote an IRC bot for keeping track of item trades for some dudes who gave me several accounts full of characters full of really good items. I gave it to my brother who eventually made thousands selling those items.
> is there a hidden cow level in the Diablo 1 source?!
Diablo I has a ton of lost treasure hidden in diabdat.mpq. I recall that they shipped the game prematurely and simply dropped a large chunk of the storyline; full characters, dialogues, items, plot triggers. Some of that storyline ended up in Diablo II. I can't find a good archaeological overview online - perhaps this isn't as well-documented as I assumed.
If anyone feels nostalgic, there's a really good Diablo I mod called The Hell out there. I believe mods are written by disassembling the original game, extending this with your own, custom assembler code, and reassembling it. What a beautiful consequence of the simplicity of writing games in C.
A lot of the features we added to D2 were things the original creators wanted to do in D1 or even the D1 expansion, the D1 expansion was outsourced and they were really unhappy about the quality of the add-on and were determined to make things right with D2 and do the expansion in house as well. I finished my work early so I added the keyboard customization feature for fun. There's a making of book about Diablo 2 that interviews the guys who also started Blizzard North/made Diablo 1 so a lot of information about the process is in there.
This desynced state resulted in a ton of commonly known dupe methods in 1.11 and 1.12 where you forcefully disconnect the GS from MCP. The popular one was spamming bone wall (creating entities on the map), then spamming AoEs which interacted with said entities. The game server would have to loop over all entities for each AoE spell you cast to determine if the spell applied to it, which caused the single-threaded game server to spend too long in each iteration of the main game loop that caused it to desync from the MCP. Blizzard eventually "fixed" this by adding a check for how long the main game loop took to complete. If it hit a certain value, it would disconnect all players from the game to despawn entities and 'prevent' dupes.
There were more fun bugs between GS <-> MCP as well. For example for many patches there was a size limit on your character. If your character data was over a set size, the GS wouldn't even try saving your character to the MCP and would roll it back to the last valid save. If you joined a game near the limit, dropped an item, picked up an item that was larger in size (had more stats etc) which pushed you over the limit, then left the game, the server would revert your save back to when you had the original item.
D2 was full of esoteric exploits like these. It was made worse by some Blizzard developers going rogue and abusing the buggy state of the codebase to assist third party item sellers for personal profit.
I vaguely remember the strike team talking about those game server issues, it's been so long I totally forgot about it. We had the servers on racks in the data centers running Windows NT and I remember the very first problems were trying to get the game to support hundreds of games per server and finding all sorts of memory issues and network issues that caused the games to crash or run out of memory. I was unaware of the developers going rogue - that's wild.
But there was one guy in our office who got hauled away by the FBI because he was hosting a file sharing node using the office T1.
“I wanted more of a point to a lot of those games,” Brevik said. “I wanted to make an RPG, with classes and leveling up, random items, where you get more and more powerful as you go down into the core of the world and fight baddies.”
Oh, that sounds right up my alley. I might have to look up the twitch stream of it he's doing this weekend later when I have time.
I'm relatively confident with programming in general, but I don't know where to start with something like this. Did he use an existing engine or framework like Unity? Is that the best place to start game development?
This game looks amazing and I'd like to try to draw some inspiration from it.
Game site: https://papadar.itch.io/eatvolve
Playthrough of an older version here: https://www.youtube.com/watch?v=s9JgvTus0O0
GameMaker Studio: https://www.yoyogames.com/gamemaker
For the kind of game presented in the article, Gamemaker Studio would be more reasonable. Unity has a lot you don't need, which obscures the path to making something simpler like this.
I'm sure there are other good options too. I think there's a JS-based platformer-oriented engine out there.
Writing game engines is a blast, but they're the ultimate in feature creep/nerd sniping. You'll spend all your time building the engine rather than focusing on gameplay.
But I also think that for most small games (1-2 developers) it can also a be a good idea not to use an off the shelf engine either.
Write the absolutely minimum that you can get away with to achieve the gameplay and look you want to achieve. Hard code everything for your specific game.
It's true that if you want to write an engine you can distract yourself from focusing on gameplay. But I think you can actually fall into the same trap using an off the shelf engine too. You end up spending a pile of time learning and working with the advanced tools and not focusing on gameplay either!
The basic rendering APIs are actually not that hard to use if you forget about generalising everything for some future that never arrives, and there is a hell of a lot to be said for working on a code base that one person entirely understands. The development speed benefits of this should not be underestimated.
Out of curiosity, why do you bother writing a statement like this? Is it to assuage your ego? If you haven't done game development before, it's safe to assume there are gaps in your knowledge and you're better off admitting it outright.
https://github.com/dungeons-of-moria/umoria/blob/master/READ...
I loved Diablo 1!
"It Lurks Below combines Diablo-style dungeon-plumbing mechanics with sandbox-style worlds that let players dig and construct, à la Terraria and Minecraft. In an interview with Polygon, Brevik said he’s a big fan of those games (and Starbound), but wanted to add something of his own to the genre.
“I wanted more of a point to a lot of those games,” Brevik said. “I wanted to make an RPG, with classes and leveling up, random items, where you get more and more powerful as you go down into the core of the world and fight baddies.”"
It’s the right time too, if they make it good.