Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[IndigoFenix]

The issue with your enemies isn't the damage or the HP, but the randomness and the lack of "tells".  There is no warning before the Mushghast or Pyreskull use their attacks, and since they don't come out at fixed, predictable intervals there's no visible "safe" moment that the player can approach without risk of being punished.  This is fine if the player is able to use projectiles, but if they are fighting close-range winning is pretty much up to luck.  There is no way to balance this simply by changing numbers around.

My suggestion would be to add a small graphic effect a few frames before firing a projectile.  There are some explosion effects that can work with the Pyreskull.  Since the Mushghast is constantly moving around normally, making it stop moving (setting _speed to 0) a few frames (say, 8 frames) before firing a spore could also work as a visual "tell".

Another possibility is to "lob" projectiles: upon creating them, make them "jump" toward the player's position over a set number of frames, and then create an explosion at the point of contact.  This way, even at close range the player will have time to dodge.  The robot-armored orc king in Protea uses this method for his bomb attacks.

Your minibosses also have similar randomness issues, particularly the ability where the Shadow Mage randomly teleports the player.  Potentially unavoidable attacks with punishing damage = problematic design.

The golems are fairly balanced out in the open despite their multiplying mechanics, because the player can target the fragments like they are supposed to, but can be frustrating to fight in cramped corridors where it can be difficult to hit the fragments without hitting the golem as well.

As for the issues with drop tiles...well, drop tiles are still pretty buggy in general.  For the cliff area, I'd suggest setting up invisible walls around all tiles that the player is not intended to drop off of (or jump up on).  I'll get around to fixing them at some point.

Your item slot suggestion is what I am planning, though I'm not sure whether I should go with a small number of default slots or a large number.  Probably going to go with a lot of slots.  There will also be custom equipment slots for purposes of making custom player sprites that are able to equip their own unique items.

EDIT: Also, it looks like you changed the ID of one or more tilesets, which made it disappear from some rooms.  Be careful changing the ID of objects that are already in the game.  If you change it back without editing the room that it's missing from, or create a copy with the same name as the original, it should reappear unchanged.

[Kamani]

Fair enough. I’ll work on that. Mushghasts using a more lob style would fit well (hmm... that gives me an idea), and Pyreskull could get a better tell. They currently are on a normal cooldown, but fire 2-5 projectiles per set. They aren’t too bad to dodge when you get used to it, but I suppose it isn’t obvious how they work if you didn’t make them. The spiders also need some tells. Painfully badly. Shadow Mage might get redone to be less annoying. Thanks for the advice.

The golems didn’t seem to tricky to me, but I made them, so I suppose I know the tricks to beating them.

Ugh, I thought I had fixed everything after I changed my tileset IDs so I could keep stuff straight. Bleh.


Edit: Mushghasts are being kind of redesigned, since I don't think anyone is using them right now anyways. They will shoot a mushroom to the target's position that does no damage, but explodes into a cloud of spores that DOES deal damage after a second. The cloud of spores does .6 damage on contact, and since that hits 40ish times a second, that will BURN if you stand in it. But, because of how it is forecasted, it is quite easy to dodge. They are more dangerous if you pair them in groups with other enemies.

But, I am having an issue. I can't figure out how to set the target for the projectile to the target of the original attack (I think I have done it before even, but I just can't remember how. Ugh) so that it works with the formula. I think this would probably even be pretty easy if I could REMEMBER it, but I am having no luck, so I could use assistance.

Thank you. I hope these Mushghasts, as a kind of bulkier support offensive (I'll probably give them a basic tackle/rush style attack with low damage, because otherwise, they are near harmless on their own) work out better, since you are no longer guaranteed to take damage fighting them, no matter how careful you are (what was I thinking, even? I am totally mystified).

[IndigoFenix]

I like what you're doing with them.  {_target} refers to the current target sprite, but I think you're overcomplicating things with one-frame update jumps...you can just make the spore jump directly to the target's position immediately after being fired using a Jump command that aims for {_target._x,_target._y}.

Oddly, the vertical height on this jump doesn't seem to work right...looking at the orc boss, it seems that I ran into the same issue and fudged it by making the bomb fire at a random vertical angle more or less in the direction of the player instead, rather than a proper targeted "lob".  I'm going to have to fix that.

Also, make sure that targeted attack techs only have the "attack" box checked, not "self".  Otherwise the AI might use itself as the target.

[Kamani]

Right, I forgot how jumps actually WORKED when you don’t just set them to 0 frames. Okay, that was foolish of me. Thanks.

Edit: Poorly phrased. I meant that I didn't consider you could use jumps that weren't just short jumps, even though I know it is possible.

Okay.

I think that comes from the gunslinger shoot attack. It shouldn’t be present on this one in particular, since this needs a target to work, but this was originally a shoot attack variant, so that is why (all of my shoot attacks were changed copies of changed copies of the original gunslinger attack because I couldn’t get mine to work back then. Probably could now, but why bother?)
Oddly enough, they don’t use it on themself anyway.

Edit: Okay, one issue. _target._x,_target._y just is read as 0,0. _target must not be working for some reason. Any clue what I am doing wrong?

Edit: Secondary issue: When my Spore transforms into a sporecloud (team was 2, sporecloud team is -1, so it should carry over), it becomes -1, leading it to damage the person who fired it too. It should probably not be changing if the thing it is transforming into is set to team -1?

Edit: Tilesets fixed. Plus, one of the rooms randomly switched thematic tileset, so it was good to change it anyway.

[IndigoFenix]

Oh, I meant the jump action should be in the mushghast's spore shot technique, not the spore's create function.  That won't work for...well, several reasons.

As for damaging its own team, the spore isn't transforming into the sporecloud, it's creating a new sporecloud object and destroying itself.  You can fix this by either making it a proper transformation, or ticking the "As Spawn" box in the Create event.

[Kamani]

Ohh. Oops.

Oh. I thought I had had it transform. Okay, that was foolish. Thanks.

[IndigoFenix]

I fixed the issue with jumping heights.

The equipment options aren't working yet, so ignore them for now.

[Kamani]

Okay. Good.

Okay.

Edit: Edited the Pyreskull. Now they explode 40 frames before they shoot. I want to check this one before I put it up, but, it seems to work well. Also, faced of against 6 mushghasts, which was rather fun.

Edit: So how can I make effects work? I want to apply the BlueInferno effect (lasts 40 frames, does nothing) to an enemy that moves a lot to forecast its big fire attack, but applying it with the effect effect did seemingly nothing. So I don't really know what I did wrong, but I probably forgot something again.

[IndigoFenix]

My mistake for including the "apply effect" event, it doesn't work right yet.  You can apply an effect directly by creating an effect sprite and setting the {_host} variable of the effect to the target sprite (check the spider for an example.)

Nice work with the two enemies, they are much more fair and fun to fight now.  They also have good synergy together, though they can be tricky (though not exactly unfair) to fight in narrow corridors.

I could make some suggestions for overall dungeon design:

Principle of Isolation: introduce new elements on their own, in an area that is easier to deal with them, so the player knows what they are dealing with before facing more challenging areas.

Maybe include an easy area at the beginning of the dungeon, or even before the dungeon proper (in the village?), where you are faced with one or two enemies out in the open on their own.  That way the player can get familiar with their abilities before fighting them in the dungeon''s cramped areas.

[IndigoFenix]

Update:

The equipment system has been rebuilt, so old equipment items must be given appropriate parameters to work (notably whether an item is equippable or not is no longer guessed by the game itself, instead you check a checkbox to mark it as equippable).

The player can now equip multiple items.  Each item can be associated with one or more slots; if the item is equippable it takes up these slots when equipped, if the item is usable it merely requires the user to have the associated equipment slot to work.  There are many default slots, and it is also possible to create custom slots for player transformations.

The default slots are the following (the default avatar has all of them active):

Main hand (i.e. weapons)
Off hand (i.e. shields)
Body
Head
Arms
Legs
Hands
Feet
Neck
Belt
Aura (for equipment that changes the player's magic ability, elemental effects, or other major gameplay changes)
Food (mainly for potions and the like but due to a quirk in how the item slots work it also works as an equipment slot)

If multiple slots are selected, the item requires all of them.  (Example: a 2-handed sword requires both hands, full body armor requires multiple armor slots.)

You can also designate equipment as an "accessory"; this will make the item require the given slot or slots, but not exclude other items on that slot.  (Example: rings can be accessories for the hands.)  To limit the use of accessories (or other powerful equipment items), items can have an "equipment value".  The default avatar's maximum combined equipment value is 100.

Finally, you can add an additional expression that determines if an item can be used or equipped.

Shops coming soon!

[Kamani]

Yay! Now I can make my equipments equiping make more sense.

(Previous Post Responses)

Ohhh. Okay.

Thanks. Glad they should be more fun to fight now.

I tried to introduce enemies one at a time in the first room of the dungeon (Except the Spid's Guard (also redone), which is introduced in the first dungeon room of the second half). I can make the rooms more favorable to the player, if that would improve it.

Ugh, just realized that room 2 wasn't included in the changes because it used special copies of enemies. More copying stuff around. (Need to stop messing this up).

Edit: Well... Instead of using an effect, I just set it to just to the location of it (in the technique) every 2nd frame (to reduce lag, since 1/20 vs. 1/40 of a second probably won't make a difference), but it doesn't seem to be working. Did I make a foolish mistake, or did I fundamentally misunderstand how something works again?

[IndigoFenix]

Hmm...I'm not sure.  Could be a quirk in how the Relative parameter is evaluated when another sprite is the target, I'll have to check.

But using an effect would be much simpler in this case, just {Set blinf._host to _this} right after creating the flame.  (This method will still work once the effect event is functional)

EDIT: So after experimenting with the effects of shops on gameplay I have come to a realization: most non-key items should have limited uses.  Otherwise, it will be extremely difficult to balance powerful items with most players' worlds, meaning that most world builders will not import items, meaning that players will be forced to carry around loads of functionally identical items that differ only in the worlds they can be used in.

So I'm going to make some options for destructable weapons and armor.  This is already possible to make using partitions but I think it should be a default parameter.  This will also require the ability to carry multiple copies of the same item.  I'm not entirely sure how non-stacked items will be specified in expressions, but I'll try to come up with something sensible.

While I'm at it, I'm going to add MP to items as well.  Item MP will recover when the item is not in use and even when the game is not being played.  This will allow you to make, for example, a spell that can only be used a certain number of times in a real-time day.

[Kamani]

Right, _this. I couldn’t remember what I needed to use, so I just used jumps instead.

[RoseHeart]

Sounds awesome. Wish I had a machine I could try it on.

[IndigoFenix]

What are you using?  System requirements aren't that demanding.

I know this update is taking a while, but it'll be worth it.  I'm adding a bunch of new options for items that are all kind of interconnected and require copious amounts of testing.  Features expected to be in the next update:

Any sprite can have an inventory, items can be added to sprites in the world builder
"Pickup" sprites generated automatically from item data, items can be placed directly on the field without needing to create a separate sprite, dead enemies drop their items
Shops with various trading systems (spark-based, bartering, custom currency, limited or unlimited inventories)
Items have HP and MP, and regen speeds for both
Individual copies of the same item class, instead of simply a stack with a number associated with it (each instance of an item can have its own HP, MP, and stored partition variables)