Gigglers as size 4 monsters?
Moderator: Sophia
Forum rules
Please read the Forum rules and policies before posting.
Please read the Forum rules and policies before posting.
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
Gigglers as size 4 monsters?
It seems like in FTL DM, gigglers tend to always be in the center of the tile, and are not found in groups.
In FTL DM, the monster groups do not change, so there's no risk of two single gigglers meeting and forming a group. In DSB, of course, monster groups do change, so two or more gigglers could form a group.
It seems like a 'traditional' dungeon would want 'traditional' gigglers, so this behavior is undesirable. My thought for a solution was to simply make a giggler size 4 (like a dragon, scorpion, etc.)-- is there some drawback to this that I haven't considered?
(I also don't know if this would make CSB's random item distribution system work better)
In FTL DM, the monster groups do not change, so there's no risk of two single gigglers meeting and forming a group. In DSB, of course, monster groups do change, so two or more gigglers could form a group.
It seems like a 'traditional' dungeon would want 'traditional' gigglers, so this behavior is undesirable. My thought for a solution was to simply make a giggler size 4 (like a dragon, scorpion, etc.)-- is there some drawback to this that I haven't considered?
(I also don't know if this would make CSB's random item distribution system work better)
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
It's a good idea overall, but...
DSB assumes every monster in the group has the same properties as the group boss (i.e., the monster that controls the entire group's actions). If this isn't the case, a lot of strange things can happen.
... I doubt if this one will come to pass.ian_scho wrote:groupable / other race
DSB assumes every monster in the group has the same properties as the group boss (i.e., the monster that controls the entire group's actions). If this isn't the case, a lot of strange things can happen.
-
- Ee Master
- Posts: 688
- Joined: Mon May 07, 2001 7:00 pm
- Location: Indiana, USA
- Contact:
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
Allowing heterogenous monster groups introduces all sorts of design problems I didn't really know how to resolve.Tom Hatfield wrote:Sounds like an unfortunate limitation to me.
What happens if a fast monster and a slower monster form a group? Let's say a muncher and a slime devil. Because of the "boss" mechanism, the entire group's speed will be tied to one of them. So, the slime devil will either be flying around, or the muncher will be held back.
Ok, so one idea is to tie the speed to the slowest member of the group. That works, but now you've got a bunch of munchers being held back by a slow member in their group. Players are less challenged-- munchers are pretty pathetic if you take away their speed. Even worse is that they'll attack as slowly as slime devils too-- and no, putting them on their own attack timers is hardly an option, as it circumvents the whole "boss" system.
What about when one member has an attack method that another doesn't? Let's say it's a vexirk and a skeleton, this time-- the vexirk can throw fireballs from a distance, and the skeleton can't. So, if they're two squares away from the party, what should they do? Close in to attack, and deny the vexirk its range attack advantage, or stay back, and deny the skeleton a chance to attack at all? There could be some calculation of the relative advantages of doing each and such, but that's an AI problem I'm not too eager to dive into.
Of course, the solution to any of these problems could be "disband the group and let the members act according to their own abilities." I agree with that one, and I figure it's not that much worse to just never let them group up to begin with.
- Parallax
- DMwiki contributor
- Posts: 424
- Joined: Mon Aug 28, 2006 7:56 pm
- Location: Back in New Jersey
It seems all your problems stem from the boss system. If one wanted to have a mixed group on a tile, one would want each monster to retain its individuality. Sharing a tile in that case only serves the purpose of enhancing monster mobility.
Imagine you have a hallway with the party at one end, a slime devil in the middle, and a muncher at the other end. Wouldn't you want the muncher to be able to pass the slime devil on its way to attacking the party?
Imagine you have a hallway with the party at one end, a slime devil in the middle, and a muncher at the other end. Wouldn't you want the muncher to be able to pass the slime devil on its way to attacking the party?
-
- Ee Master
- Posts: 688
- Joined: Mon May 07, 2001 7:00 pm
- Location: Indiana, USA
- Contact:
Now that you mention it, that was one of the fortunate limitations of DM: weak monsters could block stronger ones, but then we get back into the "passing rights" idea, where certain monsters don't like to share tiles.
I'm not suggesting you treat a mixed group as a single unit. What I'm suggesting is that each monster should have its own AI and be able to move freely onto tiles that aren't completely occupied. If monsters are of the same type and are inclined to travel in packs, then by all means treat them as one, if that's your thing. You could do the same with certain combinations of monsters, e.g., skeletons defend vexirks by attacking in melee, but otherwise they stay back and let the vexirks shoot.
I agree, the mechanics are complicated, but I figure one of the purposes of this forum is to chuck ideas around.
I'm not suggesting you treat a mixed group as a single unit. What I'm suggesting is that each monster should have its own AI and be able to move freely onto tiles that aren't completely occupied. If monsters are of the same type and are inclined to travel in packs, then by all means treat them as one, if that's your thing. You could do the same with certain combinations of monsters, e.g., skeletons defend vexirks by attacking in melee, but otherwise they stay back and let the vexirks shoot.
I agree, the mechanics are complicated, but I figure one of the purposes of this forum is to chuck ideas around.
The problem with an individual AI system is that monsters are preset to move randomly if they don't sense the player's party anywhere nearby. This is supposed to result in them being in slightly different places every time you play - it makes the dungeon seem "alive".
But with individual AIs, they'll move randomly, so that when the party finally does confront them, more likely than not, they aren't in a group - one is facing the party, one is over in the corner, one is down the hall. So, a potentially deadly encounter with a group of monsters attacking in a coordinated way is reduced to just picking off the beasties one at a time.
The real solution is to push the AI code, or at least pieces of it, to Lua scripts. That way, if a designer wants to use a complicated AI system, they can code one. Default behavior defined by the scripts should match DM as closely as possible, since that's the methodology behind the rest of the scripts. This system has both the advantage of allowing for DM behavior or an individualized AI without the core engine needing an overly complicated AI routine and a large group of arbitrary settings attached to each monster type defining how that routine is supposed to be applied to them.
Of course, I have no idea how the AI routines are currently setup, so I don't know how difficult it would be to Lua-ify them.
*Edit*
OF course, now DSB .23 is out, with AI scriptables, so I guess I should probably look before I open my mouth.
*Edit Again*
But with individual AIs, they'll move randomly, so that when the party finally does confront them, more likely than not, they aren't in a group - one is facing the party, one is over in the corner, one is down the hall. So, a potentially deadly encounter with a group of monsters attacking in a coordinated way is reduced to just picking off the beasties one at a time.
The real solution is to push the AI code, or at least pieces of it, to Lua scripts. That way, if a designer wants to use a complicated AI system, they can code one. Default behavior defined by the scripts should match DM as closely as possible, since that's the methodology behind the rest of the scripts. This system has both the advantage of allowing for DM behavior or an individualized AI without the core engine needing an overly complicated AI routine and a large group of arbitrary settings attached to each monster type defining how that routine is supposed to be applied to them.
Of course, I have no idea how the AI routines are currently setup, so I don't know how difficult it would be to Lua-ify them.
*Edit*
OF course, now DSB .23 is out, with AI scriptables, so I guess I should probably look before I open my mouth.
*Edit Again*
Last edited by Remy on Wed Nov 14, 2007 11:51 pm, edited 2 times in total.
- Sophia
- Concise and Honest
- Posts: 4240
- Joined: Thu Sep 12, 2002 9:50 pm
- Location: Nowhere in particular
- Contact:
Well, that system also has advantages of course. Without it, the monsters would all sort of be plodding pseudo-randomly about the dungeon, as Remy alluded to.Parallax wrote:It seems all your problems stem from the boss system.
Still, it might be advantageous to allow two otherwise unaffiliated monster groups to share a tile for a short time.
Something like this, perhaps-- though I'd keep the AI at the group level. Still, it might not be too much of a stretch to leverage most of the "grouping up" code, simply not promote any monster to be the new boss of the new hybrid group, so they'll all preserve their independent movement.Tom Hatfield wrote:I'm not suggesting you treat a mixed group as a single unit. What I'm suggesting is that each monster should have its own AI and be able to move freely onto tiles that aren't completely occupied.
I'll have to look into the code a bit more before I can say anything too useful on the topic...
It definitely is! I appreciate the input.Tom Hatfield wrote:I agree, the mechanics are complicated, but I figure one of the purposes of this forum is to chuck ideas around.