Questions for other enemy designers

[PokerChen]

I'm working on a small set of additional enemies.

1) Are there plenty of enemy graphics waiting for entities, so I can submit ones with just placeholder graphics?

2) Can I make a normal enemy stop only when it's firing? None of the existing enemies do this.

[Misery]

I'm working on a small set of additional enemies.

1) Are there plenty of enemy graphics waiting for entities, so I can submit ones with just placeholder graphics?

2) Can I make a normal enemy stop only when it's firing? None of the existing enemies do this.

Yes, there's *alot* of graphics available.  I'll probably assign them myself (Chris is hyper-busy right now) after I've had a look at them.  So just use art that's already there, that's fine.

As for enemy movement, it's nearly uncontrollable right now.  It's all run by pre-set AI, so one way or another, you have to just deal with what's there. Yeah, I know, it's kinda annoying. A better way to do this may be coming later, but not in time for release.  The closest you can come right now is with the attacker behavior, but that sets them to stop moving based on distance, not attacking, and they'll begin movement again the moment the player moves further away.

Whenever you've got some that are ready, go ahead and just send them to me.  I'd rather Chris and the others not have to use up their time on something I can easily handle myself.  I may make small tweaks to the things before fully uploading them.

[Pepisolo]

2) Can I make a normal enemy stop only when it's firing? None of the existing enemies do this.

You actually can do this in the current engine. What you need is a OnUse modifier. Something like this:

<modifier target="OnUse_ParentEntity" type="MovementSpeed" math="set" magnitude="0" duration="1"/>

If you put this on a system to trigger OnUse, the parent entity will have its movement set to 0. Then just specify a duration.

[Misery]

2) Can I make a normal enemy stop only when it's firing? None of the existing enemies do this.

You actually can do this in the current engine. What you need is a OnUse modifier. Something like this:

<modifier target="OnUse_ParentEntity" type="MovementSpeed" math="set" magnitude="0" duration="1"/>

If you put this on a system to trigger OnUse, the parent entity will have its movement set to 0. Then just specify a duration.

I swear, that XML documentation is a freaking labyrinth.

This has been in there the entire time and I never noticed?  Ugh.

I mean, not that it's surprising that I didn't notice something, but still, it's a maze in there.

[Pepisolo]

I swear, that XML documentation is a freaking labyrinth.

This has been in there the entire time and I never noticed?  Ugh.

I mean, not that it's surprising that I didn't notice something, but still, it's a maze in there.

Yeah, there's some interesting stuff in there. A lot of time I learn stuff just by copying what others have done, heh. Just learnt about the attach system to shots thing, by looking at your testthing stuff, for example. Lots of untapped potential in the engine. Some movement stuff was added recently, but I haven't had the chance to test it, yet.

From Keith:

"*movement_driving_pattern (bullet_pattern)
**when this mode starts, the entity switches to using the first bullet node of this pattern as its driving movement pattern; you probably don't want a "die" node, and you may want to put it in a loop with -1 (infinite) iterations
**when this mode ends, if that pattern is still the driving movement pattern it will be cleared
**this allows fairly precise control of the entity's rotation and movement"

[Misery]

I swear, that XML documentation is a freaking labyrinth.

This has been in there the entire time and I never noticed?  Ugh.

I mean, not that it's surprising that I didn't notice something, but still, it's a maze in there.

Yeah, there's some interesting stuff in there. A lot of time I learn stuff just by copying what others have done, heh. Just learnt about the attach system to shots thing, by looking at your testthing stuff, for example. Lots of untapped potential in the engine. Some movement stuff was added recently, but I haven't had the chance to test it, yet.

From Keith:

"*movement_driving_pattern (bullet_pattern)
**when this mode starts, the entity switches to using the first bullet node of this pattern as its driving movement pattern; you probably don't want a "die" node, and you may want to put it in a loop with -1 (infinite) iterations
**when this mode ends, if that pattern is still the driving movement pattern it will be cleared
**this allows fairly precise control of the entity's rotation and movement"

Yeah,  I know about that one.  I used it for the Warden's minefield pattern.   That's about it though... the precision still isnt there.   And even for that one, it's just using the Persistence movement; just to give it a different type of "following" action.  But even that has issues and there's no way to link the movements to the attacks, which for my design style is basically the entire reason why most of the bosses do not move; that and a lack of being able to send the thing to precise points without warping or other things.  It worked with that ONE pattern from the Warden, but it's probably not going to be used again.  And even that one pattern is likely to run into problems on the higher difficulties.

[PokerChen]

Hmmm... ...is there a way to tell a system to shoot only when it has a direct line of sight to the player?

I seems to have invented a nastier pattern to force the players towards the guard bot (that requires the shots themselves to ignore terrain), but don't want it to unfairly trigger if the player cannot actually get close enough to avoid the pattern. The player can also dodge back out if they're relatively quick, but several rooms are also built for close quarters.

[ptarth]

requires_line_of_sight_of_player_to_fire (bool, optional)
this system has to be able to see the player (not going through obstacles) to be able to fire

[Misery]

Hmmm... ...is there a way to tell a system to shoot only when it has a direct line of sight to the player?

I seems to have invented a nastier pattern to force the players towards the guard bot (that requires the shots themselves to ignore terrain), but don't want it to unfairly trigger if the player cannot actually get close enough to avoid the pattern. The player can also dodge back out if they're relatively quick, but several rooms are also built for close quarters.

Huh, interesting concept.  I can sorta imagine how something like that might work, though the last 2 times I attempted to do that same idea, something else ended up being the result.  One of which is, uh, Staccato I think, and the other is the mass of confusion called Centrifuge, which is the one boss that I made where I dont entirely understand how the hell the pattern forms.  This makes as little sense as it sounds like it does.

Overall though, with terrain-crossing bullets, as long as you're not going totally overboard with them (and a line-of-sight requirement is a good way to keep them under control) it sounds usable.

[PokerChen]

 Oh, there's no need to imagine... The zipped version is one where I doubled the bullet pattern (on my way to figuring out how to trigger them randomly or one at a time). This 2x version is a bit much, I think. (P.S. the testing room name need to be altered, as it's not in the zip file)

[ptarth]

The Anklebiter is pretty cool. You might want to increase the range, right now you can just snipe him out of his range. Also, with the next version, the player's default weapon is getting another 200 units of max range.

[PokerChen]

 I've increase them a little, but don't want to go overboard. These aren't meant to be a threat by themselves.

 Misery, can you look over these when you have a bit of time - it's not possible to send an attachment by private message, so I attach it here. Unzip in Configurations. These will be the submissions before release, as far as I can forecast free time.

 I've done some preliminary balancing and information on floor spawns, there's three enemy varieties and 1 "familiar" with placeholder graphics. I'm hoping for a circular bullet image for the familiar, but we'll see.

[Misery]

I've increase them a little, but don't want to go overboard. These aren't meant to be a threat by themselves.

 Misery, can you look over these when you have a bit of time - it's not possible to send an attachment by private message, so I attach it here. Unzip in Configurations. These will be the submissions before release, as far as I can forecast free time.

 I've done some preliminary balancing and information on floor spawns, there's three enemy varieties and 1 "familiar" with placeholder graphics. I'm hoping for a circular bullet image for the familiar, but we'll see.

Sure, I'll go have a look at it as soon as I start work on this today, which I'm probably going to do in about 20 minutes or so as of this post.  I'll mention any issues I might have with it, and I might make a couple of tweaks, but it sounds like you've put alot of thought into these, so I'm rather doubting that that'll be necessary.  Mostly, I just need to make sure things are categorized right, which is the hard part.   That and choosing ship art.  Seriously, there's SO much of that available right now.

I'll probably stick the things into the game immediately, so likely they'll be up and ready to go for the next build that everyone gets.

[PokerChen]

Feel free to make the changes you need. The current categorisations are:

Javlineer - 3x3 wanderer. Could be a sniper, but is intended as a source of mobile, long-range pressure.

Ankle Biter - 1x1 local guard. A little beast who wants to hug you with teeth. The dead-zone in-front is actually quite large, so I was considering adding a short-ranged death explosion, especially if its weapon range is increased further. Tweak range by either by adding more bullets (more work), or tweaking the speed and angle settings (less work).

Cold Mage (name change?) - 5x5 Attacker. Meant to be a top tier 5x5, like the 7x7 Flak launcher, but with introductory forms on lower floors that are far more manageable. Has its three attacks, one of which is its signature spell borrowed from Diablo 2. I've noticed that the category of the Frozen Orb (EnemyFamiliar) can spawn health drops at a very low probability, so this is a potential exploit. Note sure how to fix.

[Misery]

Well, I've put the things in now, sent them in, with full images and everything.

For the most part, I didn't see the need to make many changes.  Minor stat alterations, that's about it.

It's possible their categories may need changing later; I *think* they're fine but that's the hardest bit to be sure of.   The Ice things in particular may need to be Chaos instead of Wander, but for now I've left them as they are to see what happens.  Since they only attack on line of sight they'll likely be fine.

Anyway, they should be in the game with the next update!