Print

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

[IndigoFenix]

Added a new option for items: the ability to apply an effect sprite when equipped.  In addition to magical effects, this allows you to make visible objects that "stick" to the player when an item is equipped.  As with other effects, these objects can have their own independent behaviors, though their motion is locked to the player (unless you set their _host to 0, "detaching" them).

Using this feature, I made the game's first proper weapon - the Sealer Sword.  It's a sword that attaches to the player sprite and sticks out in front of them, damaging enemies it makes contact with.  It's packaged, so feel free to put it in your world or copy it as needed - using the same system it is very easy to make a new weapon simply by changing the graphics and stats.  I intend to add a bunch of features to this particular sword as new item features are added.  (It's not called the "Sealer" for nothing...)

[Kamani]

Neat! I ended up switching the theme of the second half of the dungeon from caves to a cliff. Gives me a better opportunity to use a rope anyways. I felt like the caves were getting a bit dull.

[IndigoFenix]

Added some more options allowing effects to be rotated relative to their host's facing direction.

You can also target the sprite of an equipped item using {$itemname._sprite}

Combining this lets you make techniques that swing or spin a weapon.  This is demonstrated in the Sealer Sword.

Note: the Sealer Sword has some independent AI.  Don't copy its techniques for ordinary weapons.

[IndigoFenix]

Elemental weaknesses and affinities have been added.

Sprites can now have elemental damage multipliers, which causes them to take extra or reduced damage from a given element, and elemental affinities, which multiply all of their hitboxes with a certain element.  Elements can be anything, they are evaluated through a simple string comparison.

Each hitbox can have one or more elements associated with it, each in different amounts.  The total damage of the hitbox will be distributed based on the elements' relative values.

So for instance, you can have a hitbox that deals 50 base damage, and has the elemental values of 1 physical, 4 fire, and 5 lightning.  This means it will deal 5 physical damage, 20 fire damage, and 25 lightning damage.  If the attacking sprite has a x2 lightning affinity, the 25 lightning damage will be multiplied by 2.  If the attacked sprite has a x1.5 weakness to fire, the fire damage will be increased to 30.  The total damage in this situation will be 85.

You can also target a sprite's weakness or affinity for a given element using the keywords _weak.elementname._value or _elem.elementname._value.  For example, creating effects that multiply a sprite's affinity for using a given element or applying an effect if the target sprite is weak to a particular element.  If a sprite does not have a specific weakness or affinity to the specified element, the value will be automatically regarded as 1.

I think I'm going to start making some demo spells now.

[Kamani]

Cool! I don’t think I’ll use elements in my current project (I am behind enough), but I’ll definitely use them in the future.

[magmaholic]

Is the sprite layer always below the character or can it be changed?

[IndigoFenix]

Is the sprite layer always below the character or can it be changed?

.
You can change the draw order of a sprite under the "graphics" tab.  Sprites with the same draw order will be drawn based on their Y position.

[Kamani]

Okay, small glitch. If a projectile that should break upon hitting walls is shot from a topdown block into a fall wall, it doesn't break, and it doesn't keep going. It should probably break instead of just sitting around.

[IndigoFenix]

Fixed.

I also added a new cutscene event with several options, such as disabling combat AI or freezing all physics.  There will also be a way to "unlock" a sprite, allowing you to make cutscenes where some things are frozen and others are not.

[Kamani]

Okay, good. Having the flames attacks just floating in air was a bit silly.

Neat!

[magmaholic]

Does it support tiles other than 32x32? Is collision detection for tiles completely block based? Does it handle half-transparency/alpha channel thing? I can make tiles opaque,yes,but does it handle the opacity from file?

[IndigoFenix]

Tiles are always 32x32.  A regular alpha channel is handled properly, or you can make an entire tileset semi-transparent using the opacity parameter.

Tile collision is completely block based, yes.  You can make sprites that pass through solid blocks by giving them the "ghostly" property.  Sprites can function like tiles with more complex rules; tiles are meant for quickly rendering large numbers of objects so they are much simpler.

[Eschar]

PTW.

[IndigoFenix]

So for the next step, I'm going to make a shop system.  Because that would make distributing new items much easier.

This will also likely involve the ability to equip multiple items at once, which will necessitate kind of system to organize their cumulative effects.  For stat shifts this is less of an issue, but when items change the player's abilities it can become complicated.  I guess the most sensible method would be to prevent multiple items from being equipped if they all alter the abilities of a particular button.

[Kamani]

A. Yay!

B. In addition, for multiple items, allowing items to use slots might be nice. In other words, adding a value for items (or multiple values), and anything with a matching value couldn’t be equipped. That way, you could say that your boot armor that reduces damage is slot one, and so are your fast boots that increase speed, and that way, people can’t use both. Sorry if this was explained poorly, especially since I haven’t had the time to work on my project for a while.

Edit: Well, after getting some more done, I have one note: My gosh, balancing is HARD. I keep fighting the same like 7 enemies to figure out how it needs to be made easier without ruining difficulty. Oh, side note. When working with projectiles with special movement (IE, _update movement) and drop tiles, you probably want to set those to ghostly. Otherwise, projectiles that move straight up towards drop tiles act... Oddly. They loop up until something else would cause them to destroy. They might anyways, of course, as projectiles and drop tiles aren't really supposed to be connected with topdown tiles, but this makes it a little more likely that they will not mess up.