Action RPG Framework

by Forum_account
Action RPG Framework
A framework for developing action RPGs.
ID:777109
 
From the number of changes this looks like a big update but it's just a lot of reorganization and small changes. The content of the framework is pretty solid now, the only question is how far I want to take it. There are lots of things I *could* add but I'm not sure it'd be beneficial.

For example, the framework could provide a way to manage quests. This would require a few new on-screen interface displays, the objects to represent quests, and the procs to manage their completion. The problem is, if the framework provides this it limits what you'll do - maybe you don't want quests to work anything like what the framework would provide. What'd make more sense is to make the quest system a separate library built specifically to work with this framework.

It's my goal to cover basic gameplay mechanics but the gameplay is ultimately part of the game (part of the project that uses the framework), not part of the framework itself. I'd like to flesh out the sample game that comes with the library just because there's no reason it shouldn't be more complete, but the library itself is my main concern. I'm running out of ideas, so if there's anything you'd like to see added, just ask =)

Here's the list of changes for this update:
  • Changed interaction to use obounds(8, src) instead of front(8), this way it works for diagonals.
  • Made the ShootArrow ability in the demo check if(!user.target || !user.can_target(user.target)) so you can't shoot dead targets. I also added user.target.effect("arrow-hit")
  • Added an arrow-hit animation.
  • Changed the target-marker icon a little to make the edges smoother.
  • Changed the way crafting abilities are defined and moved the definition of CraftingAbility to the framework (in player-crafting.dm).
  • Changed the /projectile type's constructor. The first parameter is still the mob who is firing the projectile. The second parameter can either be a direction, an atom, or null. If it's a direction, the projectile is fired in that direction. If it's an atom, the projectile is fired towards that atom. If it's null, it's fired in the direction of the mob who fired the projectile.
  • Updated the demo to make the Fireball ability be fired towards your target. If you don't have a target, it's fired in the direction you're facing.
  • Changed the range for interacting with objects. It now checks obounds(8) for objects to interact with, previously it checked front(1).
  • Made the space bar close the loot window if there are no more items shown in the window.
  • Rearranged the code for abilities in the demo to make target checking part of the ability's can_use() proc. This way the mana cost and cooldowns aren't triggered if the ability doesn't have a valid target. These abilities now also trigger the no_target_selected() event to fire in these cases.
  • Added the atom/movable/lootable var which is used to determine if an object can be looted. By default it is zero for all objects and only 1 for mobs of the /mob/enemy type.
  • Added a loot indicator. When you kill a mob and it drops loot, a treasure chest icon is shown next to its corpse. Once all of its items are looted, the indicator disappears.
  • Added the ability to clear a key binding in the ability bar.
  • Added the lost_item event for movable atoms. This is called on the object that used to contain an item when an item is gotten by a player. The default behavior is to remove the loot indicator if this was the last item the container had.
  • Changed the way damage numbers are created in the demo. They're now created by the mob's took_damage proc. This is more consistent since the events are primarily for creating custom notifications. Previously the damage numbers were created by the Combat's attack() proc, but that shouldn't worry about what notifications are being created.
  • Also used the took_damage event to make enemies target their attacker.
  • Removed the ai_delay proc. To limit actions performed in a mob's ai() proc you can just use cooldowns. I updated the sample enemy and NPC AI to show how you can do this. This is better because the ai_delay() proc enforced a single delay on the entire ai proc. Using cooldowns lets you create limits for each specific action so that other parts of the ai() proc can still run uninterrupted. The ai_pause() and ai_play() procs still exist.