DRL > Requests For Features
Intuition
BDR:
For my idea on how the determination of threats with Int 3 should be handled, I think that these presumptions are likely correct:
1. The program always has the map on hand (nearly full maps are dumped on death, and there's also the Computer Map powerup).
2. The program can tell how far away the enemies are from the player at all times (a little stretch, but a credible one since you can get exact measurements within sight range; why wouldn't this be possible all the time?).
The most general logic, which could apply on any map (even before we discuss power, red doors, groups vs. singles, and such), is that the game looks to see what's around in the range of one normal vision range past the player's natural sight range (8 squares past the player's, which can be increased with Cateye even though the extra range of Intuition cannot be increased by Cateye, which is likely simpler to program than the alternative of allowing Cateye to directly affect Intuition range [and technically we could make it even simpler by making it so the computer assumes the player has no Cateye ever, which probably wouldn't be a huge deal balance-wise]), and upon finding a monster compares it to the axes; if x/y are zero or equal to each other, there's no more work to be done and the computer puts a green light in the relevant cardinal direction, and if not then the numbers of the cardinal directions are compared to the numbers of the enemy, and whichever cardinal direction is closer gets the light, and if both relevant directions are equidistant, then the computer will make the arbitrary preference of the relevant diagonal direction. Three examples:
1. Player is at 5, 23; Monster is at 17, 23. Game checks the axes, finds that the monster position relative to the player position is 12, 0 and sticks a green light in the square to the player's right.
2. Player is at 5, 23; Monster is at 17, 25. Game checks the axes, finds that the relative monster position is 12, -2, figures out that 12, 0 is closer to that than 12, -12, and sticks a green light in the square to the player's right.
3. Player is at 5, 23; Monster is at 17, 29. Game goes through this up to the point when it finds that 12, -6 is an equal distance between 12, 0 and 12, -12, shrugs its shoulders and sticks a green light in the square to the player's bottom-right.
Of course, I am not a programmer, so I may be missing something crucial, but from what I know of it that seems easy enough to pull off. The green light is as far as I can tell the only potentially clumsy part of that (either it covers up items, or it necessitates tiles (one copy for no light and one copy with a light), and I only use that because I'm not sure what else would work better for a *basic* rendering of the idea. The next part of that is to compare monster proximity; that could be done by comparing single relative monster positions to each other (within the detection range of Int 3, obviously). Monsters within normal sight range (8 tiles as I understand it) of each other are, for the sake of simplicity, considered a part of a group. This is probably not the best way to do it, and ideally walls/doors would be taken into account, but as I said, I'm not a programmer, so I'm trying to go a bit slowly here. Also interesting to me is the idea that Intuition 3 can still be considerably useful even if it (and perhaps because it) incidentally overestimates the danger, so it may not be a problem to have this behavior to begin with. As for determining group strength... well, that seems like a tough case. Either too much gets into the formula and it becomes crazy convoluted, or not enough gets in and the players disagree. I'd take armor, damage, health, and experience into account, but that may be too much... not sure how I'd fix that.
007bistromath:
Counting the number of monsters in a room/area should be trivial. That's not just a blob of spreadsheet cells you're walking across; maps in roguelikes are created by fitting together predefined "pieces" of a dungeon, with the possible exception of cave levels. With this in mind, simply create a function which takes the XP total of all the monsters in each "piece," and colors the entryways to that piece (door or not) accordingly.
PS: I agree that Int3 should show the stairs. If paired with some kind of "threat monitor" concept such as we are toying with in this thread, it would bring some tension to the game by encouraging the player to take calculated risks.
Const:
--- Quote from: BDR on October 26, 2007, 18:34 --- Monsters within normal sight range (8 tiles as I understand it) of each other are, for the sake of simplicity, considered a part of a group.
--- End quote ---
Not so easy.
How about such thing:
#......#O.
#......#..
#......#O.
+......#..
#...@..+O.
#......#..
#......#O.
#......#..
#......#O.
#......#..
How your Intuition must show that Cacodemons?
--- Quote from: 007bistromath on October 26, 2007, 19:57 ---Counting the number of monsters in a room/area should be trivial. That's not just a blob of spreadsheet cells you're walking across; maps in roguelikes are created by fitting together predefined "pieces" of a dungeon, with the possible exception of cave levels. With this in mind, simply create a function which takes the XP total of all the monsters in each "piece," and colors the entryways to that piece (door or not) accordingly.
--- End quote ---
Entering to room, player can stand before strong monsters from adjacent rooms, if there are some breaches in walls. It's very bad to enter to "safe" room and stand before three AV. False information is worse than no information.
Potman:
--- Quote from: Const on October 27, 2007, 12:47 ---Entering to room, player can stand before strong monsters from adjacent rooms, if there are some breaches in walls. It's very bad to enter to "safe" room and stand before three AV. False information is worse than no information.
--- End quote ---
That'd give its own awesome spicing to the game, don't you think? Never being sure about what awaits you on the other side of the door.
Const:
--- Quote from: Potman on October 27, 2007, 13:45 --- Never being sure about what awaits you on the other side of the door.
--- End quote ---
And what can be a sense of the perk, if it gives very unreliable information? It would be better to take another perk, which has undeniable usefulness.
Common part of all proposed intuition*3 in what, that all of them have very questionable usefulness. It's better to cap intuition by 2 level, than to create hard-programmed useless perk.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version