1
Design / Re: Who's published a game and found my 'Roguelike Intelligence' articles useful?
« on: July 25, 2017, 02:24:07 PM »
Also didn't Binding of Isaac and Spelunky use some of that material?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Design / Re: Who's published a game and found my 'Roguelike Intelligence' articles useful?
« on: July 25, 2017, 02:13:39 PM »
The series of articles on my blog:
http://dillingers.com/blog/2014/05/10/roguelike-ai/
http://dillingers.com/blog/2014/05/11/roguelike-ai-2/
http://dillingers.com/blog/2014/05/12/roguelike-ai-3/
http://dillingers.com/blog/2014/05/14/roguelike-ai-4/
http://dillingers.com/blog/2014/05/15/roguelike-ai-5/
http://dillingers.com/blog/2014/05/16/roguelike-ai-6/
http://dillingers.com/blog/2014/05/28/roguelike-ai-7/
http://dillingers.com/blog/2014/05/29/roguelike-ai-8/
http://dillingers.com/blog/2014/06/15/roguelike-ai-9/
I had almost forgotten about the copies on roguebasin. The ones on my blog get a lot of hits from India and Japan, but absolute silence in terms of who's using them over there. I think somebody's using them for course material. And I see a fair number of hits from Reddit, but again silence in terms of who's using them.
Does anybody else remember that the guy who was working on "Dont Starve" used to hang around rec.games.roguelike.development while he was working on it? He was in Finland, and talked a lot about the survival challenges of winter and finding food and so on in the context of his emergency training there.
I was looking yesterday though, and every mention of his name and "Dont Starve" has been scrubbed from the Google Groups archives of rec.games.roguelike.development. It looks like they're selling hard the story that that game was strictly developed at or for "Klei", about two years later.
I hope they paid him well for it, but I'm a bit upset, because he credited my articles with a lot of the AI ideas while he was working on it, but now the posts where he said so are gone. If "Klei" is now pretending that it's all developed in house, then obviously they're not even crediting him any more.
http://dillingers.com/blog/2014/05/10/roguelike-ai/
http://dillingers.com/blog/2014/05/11/roguelike-ai-2/
http://dillingers.com/blog/2014/05/12/roguelike-ai-3/
http://dillingers.com/blog/2014/05/14/roguelike-ai-4/
http://dillingers.com/blog/2014/05/15/roguelike-ai-5/
http://dillingers.com/blog/2014/05/16/roguelike-ai-6/
http://dillingers.com/blog/2014/05/28/roguelike-ai-7/
http://dillingers.com/blog/2014/05/29/roguelike-ai-8/
http://dillingers.com/blog/2014/06/15/roguelike-ai-9/
I had almost forgotten about the copies on roguebasin. The ones on my blog get a lot of hits from India and Japan, but absolute silence in terms of who's using them over there. I think somebody's using them for course material. And I see a fair number of hits from Reddit, but again silence in terms of who's using them.
Does anybody else remember that the guy who was working on "Dont Starve" used to hang around rec.games.roguelike.development while he was working on it? He was in Finland, and talked a lot about the survival challenges of winter and finding food and so on in the context of his emergency training there.
I was looking yesterday though, and every mention of his name and "Dont Starve" has been scrubbed from the Google Groups archives of rec.games.roguelike.development. It looks like they're selling hard the story that that game was strictly developed at or for "Klei", about two years later.
I hope they paid him well for it, but I'm a bit upset, because he credited my articles with a lot of the AI ideas while he was working on it, but now the posts where he said so are gone. If "Klei" is now pretending that it's all developed in house, then obviously they're not even crediting him any more.
3
Design / Who's published a game and found my 'Roguelike Intelligence' articles useful?
« on: July 25, 2017, 05:09:10 AM »
Hi.
I know I've been gone for a while, but I wanted to drop by and ask: Have the authors of any published roguelike games found my 'Roguelike AI' series of articles useful? And if so, would you mind if I put the names of your games somewhere on the articles, or on my webpages?
I know I've been gone for a while, but I wanted to drop by and ask: Have the authors of any published roguelike games found my 'Roguelike AI' series of articles useful? And if so, would you mind if I put the names of your games somewhere on the articles, or on my webpages?
4
Player's Plaza / Re: Roguelike With Psionics?
« on: November 02, 2014, 03:36:19 AM »
Sorry if I was being dense. For me game design (mechanics) questions are entirely separate from setting, etc, so I was wondering (in terms of game mechanics, because I'm a wingnut who doesn't really see anything else) what you meant.
So are you mainly looking for good flavor text? Art assets?
So are you mainly looking for good flavor text? Art assets?
5
Player's Plaza / Re: Roguelike With Psionics?
« on: November 01, 2014, 10:28:57 PM »
In many roguelikes, there are effects called "Magic."
Every developer of such a game decides how "Magic" in that game ought to work. And whatever mechanics someone proposes for "Magic" would work equally well for "Psionics." From a game designer's point of view, there's really no distinction between them beyond whatever distinction you choose to make.
In effect you're asking us here whether there's an example out there that suits your idea of the game mechanics you'd choose to call "Psionics" but you haven't told us what set of game mechanics those are. Whatever game you find an example of those mechanics in, that game is more likely to call it "Magic" than to call it "Psionics" but that's fairly irrelevant.
The serious question then, is what set of game mechanics are you talking about? Is this just a re-branding of "spellcasting" into "psychic disciplines" so you can fit the same game mechanics into a different genre, (like "The Force" in Star Wars)? Do you want to have both Magic and Psionics as things that work by completely different rules and offer a very different set of gameplay decisions for players to make? If so what are the differences?
Or are you going with the seriously old-skool original definition of "Psionics" as high-tech electronic devices that are worn or implanted and do things, or control other devices, based on directly sensing the neural firings inside the user's head -- like the Predator's shoulder gun that can tell where he's looking and when he wants it to fire based on a direct neural interface?
Every developer of such a game decides how "Magic" in that game ought to work. And whatever mechanics someone proposes for "Magic" would work equally well for "Psionics." From a game designer's point of view, there's really no distinction between them beyond whatever distinction you choose to make.
In effect you're asking us here whether there's an example out there that suits your idea of the game mechanics you'd choose to call "Psionics" but you haven't told us what set of game mechanics those are. Whatever game you find an example of those mechanics in, that game is more likely to call it "Magic" than to call it "Psionics" but that's fairly irrelevant.
The serious question then, is what set of game mechanics are you talking about? Is this just a re-branding of "spellcasting" into "psychic disciplines" so you can fit the same game mechanics into a different genre, (like "The Force" in Star Wars)? Do you want to have both Magic and Psionics as things that work by completely different rules and offer a very different set of gameplay decisions for players to make? If so what are the differences?
Or are you going with the seriously old-skool original definition of "Psionics" as high-tech electronic devices that are worn or implanted and do things, or control other devices, based on directly sensing the neural firings inside the user's head -- like the Predator's shoulder gun that can tell where he's looking and when he wants it to fire based on a direct neural interface?
6
Design / Re: Story Driven Roguelike (Based on the Hero's Journey)
« on: October 27, 2014, 10:08:06 PM »I don't see this so much as a game I'm producing which people will play upon release, more an experimental game design, answering the question "can a computer write a story?"
Actually, that's a fascinating question in itself, and a great project for the procjam coming up. It is something that could be awesome in games, though probably not all that awesome for scripting the game's central quest itself, because, as I pointed out, the player can go off in some other direction from the story it scripts. It would absolutely shine though, if you use it to make up legends and backstory, different for each game, that are tied to or introduce procedurally generated elements and artifacts.
7
Design / Re: Story Driven Roguelike (Based on the Hero's Journey)
« on: October 26, 2014, 11:25:00 PM »
It sounds like you want elements from Interactive Fiction -- in addition to, or instead of, roguelike games.
If you can do a decent IF engine that procedurally generates scripted story and encounters, that would be awesome. But Interactive Fiction tends to be game as story, where roguelikes tend to be game as contest, so mixing elements is easy to do badly and hard to do well.
Can you make a coherent hero's journey where the hero dies in the middle of the first act? In a classic roguelike game, it's a contest, and the player character can die at any time. In a classic story format, it's a story and the hero can't die until the story reaches a satisfying conclusion. So there's a fundamental tension.
Maybe you'd be happier doing a straight Interactive-Fiction game?
If you can do a decent IF engine that procedurally generates scripted story and encounters, that would be awesome. But Interactive Fiction tends to be game as story, where roguelikes tend to be game as contest, so mixing elements is easy to do badly and hard to do well.
Can you make a coherent hero's journey where the hero dies in the middle of the first act? In a classic roguelike game, it's a contest, and the player character can die at any time. In a classic story format, it's a story and the hero can't die until the story reaches a satisfying conclusion. So there's a fundamental tension.
Maybe you'd be happier doing a straight Interactive-Fiction game?
8
Programming / Re: Neohack progress report - I'm being chased by wolves!
« on: October 22, 2014, 11:12:30 PM »Yeah, this sounds pretty ambitious. Of course, I'd be interested to see even a fraction of what you're contemplating in working game form.
Heh. True dat. I need to actually knuckle down and keep implementing things rather than playing it over and over while it's incomplete.
I have the "nine keys" game almost ready at this point. I just hacked the "death touch" attack and game over. Still need to do scoring, high scores, and some progress mechanics before it's even a complete coffee break game.
But in the longer term, I think it's definitely worth remembering some things -- for example, that a lot of monsters are aligned chaotic hungry rather than chaotic evil, and that throwing them food is not all that bad a tactic if you just want to get by. 'Cos a pot roast is probably cheaper than a healing potion, right?
9
Programming / Re: Neohack progress report - I'm being chased by wolves!
« on: October 22, 2014, 05:38:23 PM »
Well, if you're a low level character, "smart play" sure as heck means NOT trying to fight high level monsters. However, it doesn't preclude making deals with them. Doing something they want done, giving them money, driving a herd of goats into the lair ahead of you so at least when they see you they won't be hungry, and sneaking past are all possibilities depending on what kind of monster we're talking about, though none is without risk.
If you're a high level character, you still have all those options, plus you might be able to kill a high level monster such as a dragon - by setting up an elaborate trap involving a seige engine that fires sharpened telephone poles, by a coordinated sneak attack on a sleeping dragon, with special attacks like stoning or a death touch, by levering big rocks over both exits and then flooding the cave, by causing a cave-in, or some such tactic. But toe to toe? No, that's just insane. Nobody goes toe to toe with a dragon.
Smart play looks like knowing where you're going and what's there, and preparing appropriately. For example, you don't try to steal from someplace called "Dragon's Eyrie" without, yes, finding some source of fire resistance (and preferably some way to fly) first.
Tactically, it means knowing how to ruthlessly exploit a speed advantage, how to guess where a chasing monster is even when you haven't seen it for a hundred turns, having planned routes in the area you've explored that allow you to escape and evade, knowing about how many steps you can take away from them without finding a place to run around an obstacle if something you can't fight starts chasing you, etc. It means knowing you have to sneak or run instead of fighting sometimes, (more the deeper you get) and knowing when.
It means knowing when armor that clanks as you walk along making it impossible to sneak isn't worth the better protection it offers (when the monsters are dragons that can kill you anyway) and when it is (when the monsters are puppy-sized giant ants or venomous snakes whose poison bites it makes you effectively immune to).
And, yes, I want smart play to be at least *AS* important as character level.
If you're a high level character, you still have all those options, plus you might be able to kill a high level monster such as a dragon - by setting up an elaborate trap involving a seige engine that fires sharpened telephone poles, by a coordinated sneak attack on a sleeping dragon, with special attacks like stoning or a death touch, by levering big rocks over both exits and then flooding the cave, by causing a cave-in, or some such tactic. But toe to toe? No, that's just insane. Nobody goes toe to toe with a dragon.
Smart play looks like knowing where you're going and what's there, and preparing appropriately. For example, you don't try to steal from someplace called "Dragon's Eyrie" without, yes, finding some source of fire resistance (and preferably some way to fly) first.
Tactically, it means knowing how to ruthlessly exploit a speed advantage, how to guess where a chasing monster is even when you haven't seen it for a hundred turns, having planned routes in the area you've explored that allow you to escape and evade, knowing about how many steps you can take away from them without finding a place to run around an obstacle if something you can't fight starts chasing you, etc. It means knowing you have to sneak or run instead of fighting sometimes, (more the deeper you get) and knowing when.
It means knowing when armor that clanks as you walk along making it impossible to sneak isn't worth the better protection it offers (when the monsters are dragons that can kill you anyway) and when it is (when the monsters are puppy-sized giant ants or venomous snakes whose poison bites it makes you effectively immune to).
And, yes, I want smart play to be at least *AS* important as character level.
10
Programming / Re: Neohack progress report - I'm being chased by wolves!
« on: October 22, 2014, 05:14:27 AM »
Today I implemented health,, damage, and death routines. I know that the "Nine keys" game requires only a "Death Touch" attack because it's effectively a "one hitpoint game." But I'm implementing a bunch of things that I don't actually need yet just for the "Nine keys" game.
What I haven't implemented about that, yet, is a hitpoint determination algorithm. I spent a good deal of time thinking about it though; How should I decide how many hitpoints a character ought to have, when full up on health? And I have the outline written up, though not yet coded.
I'm deeply unsatisfied with games like D&D where it's simply proportional to level -- that gets ridiculous, where a squishy human has more hits than a dragon, can survive terminal-velocity falls, and so forth. And I don't like the mechanic where due to the extreme differences in hits between low and high level characters, someone who tries to dive with a low-level character, no matter how well they play, will quickly get stomped flat.
From a game design POV, the progression in hitpoints (and damage capabilities) more or less regulates the rate at which players can access new content. In games where finishing characters have upward of a thousand times as many hitpoints as starting characters, most of the time is spent grinding for power as opposed to actually trying to accomplish the real game objectives, because power (HP and damage capability) is simply required for continued EXISTENCE, regardless of brilliant or stupid play, in any areas where real game objectives can be accomplished.
So, I decided to try to balance things very differently. Winning characters, IMO, ought to have maybe about ten times as many hitpoints, and do ten times as much damage per round, as beginning characters. Not a thousand (looking at YOU Zangband). Not a hundred (Looking at YOU Nethack). Ten. You get a third of the hitpoints you're likely ever to have by level seven, you get up to half by level 20, and you asymptotically approach but never exceed the limit the higher you go after that.
Meaning, yes, your 30th level character, if you play really stupid, actually can get killed by a bunch of goblins. And also, yes, your 6th level character, if you play really smart and only a bit lucky, might actually reach and even steal the MacGuffin from (though probably not kill or even hurt) the final boss.
Also, arbitrarily and randomly, some characters both will and SHOULD have above-average hits starting early and persisting for their whole careers, and some will and SHOULD have below-average hits for their whole careers. While this is blatantly unfair as regards hitpoints alone, it gives me the opportunity to differentiate characters by awarding rare, randomly selected powers, bonuses, and abilities to characters who seem doomed to have equally rare low maximum hit totals. Specifically, powers, bonuses, and abilities which are simply not available otherwise, and whose very possibility players might remain ignorant of even after scores of games. There are things that ought to be possible but not to be relied on, and not reachable by any combination of increased level, grinding, etc. and these can be used as compensation/game balance for chronically low hitpoints.
Because, among other things, I really hate thousanduplet syndrome, and I really hate "formula play" where a player can play every character just like the last one.
Much of the pleasure of writing these things lies in trying something different specifically to address your own set of pet peeves....
What I haven't implemented about that, yet, is a hitpoint determination algorithm. I spent a good deal of time thinking about it though; How should I decide how many hitpoints a character ought to have, when full up on health? And I have the outline written up, though not yet coded.
I'm deeply unsatisfied with games like D&D where it's simply proportional to level -- that gets ridiculous, where a squishy human has more hits than a dragon, can survive terminal-velocity falls, and so forth. And I don't like the mechanic where due to the extreme differences in hits between low and high level characters, someone who tries to dive with a low-level character, no matter how well they play, will quickly get stomped flat.
From a game design POV, the progression in hitpoints (and damage capabilities) more or less regulates the rate at which players can access new content. In games where finishing characters have upward of a thousand times as many hitpoints as starting characters, most of the time is spent grinding for power as opposed to actually trying to accomplish the real game objectives, because power (HP and damage capability) is simply required for continued EXISTENCE, regardless of brilliant or stupid play, in any areas where real game objectives can be accomplished.
So, I decided to try to balance things very differently. Winning characters, IMO, ought to have maybe about ten times as many hitpoints, and do ten times as much damage per round, as beginning characters. Not a thousand (looking at YOU Zangband). Not a hundred (Looking at YOU Nethack). Ten. You get a third of the hitpoints you're likely ever to have by level seven, you get up to half by level 20, and you asymptotically approach but never exceed the limit the higher you go after that.
Meaning, yes, your 30th level character, if you play really stupid, actually can get killed by a bunch of goblins. And also, yes, your 6th level character, if you play really smart and only a bit lucky, might actually reach and even steal the MacGuffin from (though probably not kill or even hurt) the final boss.
Also, arbitrarily and randomly, some characters both will and SHOULD have above-average hits starting early and persisting for their whole careers, and some will and SHOULD have below-average hits for their whole careers. While this is blatantly unfair as regards hitpoints alone, it gives me the opportunity to differentiate characters by awarding rare, randomly selected powers, bonuses, and abilities to characters who seem doomed to have equally rare low maximum hit totals. Specifically, powers, bonuses, and abilities which are simply not available otherwise, and whose very possibility players might remain ignorant of even after scores of games. There are things that ought to be possible but not to be relied on, and not reachable by any combination of increased level, grinding, etc. and these can be used as compensation/game balance for chronically low hitpoints.
Because, among other things, I really hate thousanduplet syndrome, and I really hate "formula play" where a player can play every character just like the last one.
Much of the pleasure of writing these things lies in trying something different specifically to address your own set of pet peeves....
11
Off-topic (Locked) / Re: Samsung's brilliant support
« on: October 22, 2014, 01:45:51 AM »Turns out the only thing actually connecting the screen to the body of the laptop was a thin crappy bit of plastic casing, there was no internal pin. So, once the crack reached a certain point there was no longer enough material there to support its own weight and both hinges failed at once.Yes, the hinges on this are deteriorating. I periodically dose them with superglue.
Usually I curse the extra weight of the turtleshell my laptop came in, but you guys are making me appreciate it...
12
Off-topic (Locked) / Re: Samsung's brilliant support
« on: October 20, 2014, 06:12:11 PM »
I have a titanium-cased Toshiba laptop I got secondhand - who the hell puts laptops inside titanium cases, anyway? This thing weighs twelve pounds, and you could probably drive a car over it when it's closed. But anyway, it has a decent 64-bit CPU, a pretty good battery life, there was room for 8 Gbytes of memory (only had 2 when I got it), and it was cheap because the screen is a semi-weird size and smaller than 1080p - it's 1024 x 1200 pixels. So I nabbed it, got the extra memory installed, (I had to buy a special Torx screwdriver with a hole in the middle of the bit to get the turtleshell off and back on) and took it home.
I had to literally remove the internal hard drive and replace it with a blank one before it would allow me to install Linux. The thing has a BIOS setting that makes it flatly refuse to commit writes to the first disk partition (where lay the boot sector and OS, in the original) unless they are signed by some trusted authority whose key I don't have (possibly the same people who put it inside the titanium turtle shell, possibly Microsoft, I dunno) and you cannot turn that BIOS setting off, even with hardware access, as long as there is a drive capable of booting up. That setting isn't even writable except after a failed boot which did not fail because you interrupted it via power cycle or keyboard.
I don't know if that's a feature of the regular Toshiba BIOS these days -- obviously the machine was built by some kind of paranoid organization, so it might have a custom BIOS installed -- but it was the first time I had run across anything like it.
I had to literally remove the internal hard drive and replace it with a blank one before it would allow me to install Linux. The thing has a BIOS setting that makes it flatly refuse to commit writes to the first disk partition (where lay the boot sector and OS, in the original) unless they are signed by some trusted authority whose key I don't have (possibly the same people who put it inside the titanium turtle shell, possibly Microsoft, I dunno) and you cannot turn that BIOS setting off, even with hardware access, as long as there is a drive capable of booting up. That setting isn't even writable except after a failed boot which did not fail because you interrupted it via power cycle or keyboard.
I don't know if that's a feature of the regular Toshiba BIOS these days -- obviously the machine was built by some kind of paranoid organization, so it might have a custom BIOS installed -- but it was the first time I had run across anything like it.
13
Programming / Re: Loops on dungeon-type levels
« on: October 19, 2014, 03:55:51 PM »Blindly retrying can be a major source for slowdowns for the generator.Theoretically. In the worst case at least. But that sounds like premature optimization to me.
This actually became a problem with the Angband level generator IIRC -- it was sometimes trying for a long time to generate a valid level. So it's definitely something to consider.
If I had to choose between something that is pretty good at making valid dungeons and easy to retry vs something that is mathematically proven to always be valid, I know which I would choose: the good enough way.
I prefer something that is solidly bounded in compute time - ie, won't do generation more than once. If it's not provable to be mathematically valid, I use a rock-solid validation algorithm to detect the problems, then use "patchups" (such as moving unconnected open spaces together or making additional tunnels to connect anything that's not connected) to alter the output and force it to become valid.
14
Programming / Re: Neohack progress report - I'm being chased by wolves!
« on: October 18, 2014, 03:42:45 AM »
So, I hacked inventory. Now the little @ can pick up items from the floor, and when he looks at inventory, it lists them under a 'carried' column. Other columns cover worn, wielded, and (if we happen to be talking about something odd like @ is a container) contained items.
It goes so far as to count them and list them together if their names (the names the character knows) are identical. So if you've picked up one key seven times, it will tell you in inventory that you're carrying "7 keys" rather than listing "a key, a key, a key, a key,...." Note that the names that guide this behavior are "as known to the character", so things that are different can stack as long as the player doesn't know that they are different.
Right now the amount of stuff you can have in inventory isn't limited. I don't think I *will* limit it in terms of number of slots. I'll try to implement weight/bulk limitations instead.
It goes so far as to count them and list them together if their names (the names the character knows) are identical. So if you've picked up one key seven times, it will tell you in inventory that you're carrying "7 keys" rather than listing "a key, a key, a key, a key,...." Note that the names that guide this behavior are "as known to the character", so things that are different can stack as long as the player doesn't know that they are different.
Right now the amount of stuff you can have in inventory isn't limited. I don't think I *will* limit it in terms of number of slots. I'll try to implement weight/bulk limitations instead.
15
Programming / Re: Loops on dungeon-type levels
« on: October 18, 2014, 03:33:46 AM »
If you want large loops, pick a tile at random and do breadth-first floodfill to find the (walking) distance from that spot. Then pick the most distant tile from it, which will be the last one you get in a breadth-first floodfill, and do a breadth-first floodfill to find distances from THAT tile.
Whichever third tile is furthest from the second tile, the distance between second and third tiles will be the longest walking distance that exists in your map. If you can connect those two points without crossing anything else, you're guaranteed a maximal-size loop. Often that isn't possible, but if you cross other open spaces while trying, look for the tunnel (between two open spaces) that connects tiles whose walking distance (the one you calculated with the second floodfill) has the most difference.
Whichever third tile is furthest from the second tile, the distance between second and third tiles will be the longest walking distance that exists in your map. If you can connect those two points without crossing anything else, you're guaranteed a maximal-size loop. Often that isn't possible, but if you cross other open spaces while trying, look for the tunnel (between two open spaces) that connects tiles whose walking distance (the one you calculated with the second floodfill) has the most difference.