On since: Tue May 17 03:37:01 2022
Login name : Lailoken Real name : q
Status : Admin Domain : None (esper)
Spouse : None
Web Page : None
WWW page on MUD: http://www.eternalfantasy.org/home/lailoken
E-mail : Not viewable from WWW.
Mud mail : [ Unread : 0 Total : 2 ]
== Event Dispatcher ==
I have two candidate versions for an event dispatcher system.
The first would be added to the /std/object/ob and each object would be
responsible for managing its own events. The main drawback to this is that it
would be part of almost every object in the game, even if it wasn't being used.
The second is a deamon that manages all events. A daemon keeps the code
isolated, but it adds limitations to what can be done with the events. Function
pointers cannot be used, so anonymous functions cannot be added as a handler.
All event handlers assigned must be functions that exist on the listening
object. There is a function to clean up the event mapping (ie remove events for
non-existent objects), but it's only called when the daemon is updated.
== Cooldowns ==
I have code for a cooldown system in ~lailoken/cooldowns.c
The code would be included into /std/organism/organism, and the
check_cooldowns() function would need to be added to heart_beat(). Adding a
cooldown: add_cooldown(string name, int seconds);
Checking a cooldown: query_cooldown(string name);
Returns seconds remaining; 0 if the cooldown has ended.
== Summons ==
I am modifying the std/summon/basic code in order to simplify eidolon
functions and formulas. The formulas for calculating things like stats,
upkeep cost, astralflow cost, etc. have been reduced, but retain
similar outcomes. I have also separated eidolon skills out into their own
directory. So far I have only updated Chocobo to inherit the new basic eidolon.
Features Added I've included an affinity system. There are 5 affinity levels. A
summoner's eidolon gains affinity the more the summoner uses it. More affinity
points are required at higher levels, and for higher tiered eidolons. I have yet
to incorporate the affinity system into anything else, but it would be
relatively easy to check the affinity level and use that to gain bonuses in
other areas, such as eidolon stats, ability power, etc.
Eidolons can equip gear. They have 2 slots: armor and weapon. The equipment
gives the eidolon additional stats, like a normal piece of equipment would.
Eidolon equipment can only be equipped by a specific eidolon. Eidolon equipment
is saved to the eidolon (for re-summons) and can be swapped out for different
equipment at any time.
Astral Flow abilities can be used whether an eidolon is present or not. If an
eidolon is present, then only that eidolon's AF abilities can be used. If no
eidolon is present then any AF ability that are currently available to the
summoner can be used. If the summoner uses Astral Flow without an eidolon, the
cooldown time is increased by half.
== Abilities ==
I have rewritten the ability system to create some standardization. Most
features of current abilities have been incorporated into this system.
The abstract ability object handles the preparation and execution of the ability
based on settings defined in the ability's create() function. Abilities have
regular parameters, such as "name", "charge_duration", "weapon_required", etc.
They also have Guards and Procs.
A Guard is a small object that can be added to either pre-charge or
pre-execution. The Guard object has a function to determine if the guard passes
or fails. If the Guard fails then a message will be displayed. Each Guard has
a default message which can be overridden in the ability file. An example of a
Guard is "no_target" which checks to see if any of the ability's targets still
exist and are alive. If there are none then the message "You have no target!"
will be displayed.
A Proc is an object that contains the meat of the ability. More than
one Proc can be added to an ability and they can be executed individually or
one Proc can trigger another. Procs are divided into various types, such as
Physical damage, Healing, HP Drain, Status Effect, etc. They contain all of the
information about the ability's behavior (e.g. hit/miss, power, messages).
I have also written a set of targeting functions to standardize how ability
targets are selected. There is a function to return all living objects in an
environment (optionally based on a list of IDs) and several filter functions
that reduce the array to only monsters, or only players, etc. There are also
functions for determining random target(s) for confused players.
Included with the ability files is a message parser. Originally written by
Caytwell and then adapted by me to be used with the abilities. The parser uses
common tokens for things like proper nouns, posessive nouns, subjective nouns,
etc. and converts the string to one of three perspectives: User, Target, and
Others. For example:
$N @leap@ at $n, but $s @!dodge@ out of the way!
USER: You leap at Imp, but it dodges out of the way!
TARGET: Lailoken leaps at you, but you dodge out of the way!
OTHERS: Lailoken leaps at Imp, but it dodges out of the way!
* Implement message parser library
* Implement targeting library
* Implement new Ability object
* Gradually convert existing abilities to new object
* Implement new Class object
* Map existing zones/areas to show level distribution
* Re-tool existing zones/areas for better player progression
* Create generic armor/weapons for levels 1-99 (steps of 5 or 10) as filler