Paul Kwiatkowski
Back-End/Front-End Liaison
Quest Design and Development Document
Wednesday, November 26, 2008: 7:00 pm
Eric and I ran around in circles for 3 hours about quest design and came up with a
very distinct set of tasks to accomplish in order to implement them. Quests will be, for
our purposes, treated not as an explicit entity, but as an installer for a set of permissions
and interactions that facilitate a cohesive chain of events.
The design we put forth is, admittedly, a bit shy of ideal. It is instead the most
cleanly encapsulated design we could achieve without having to significantly alter other
structural systems (notably storage).
Quests provide three distinct functionalities:
1. The set of definitions upon which the quest is dependent, aka the delegates for
both permissions and interactions that must exist within the game world for the
quest to be implemented. These should be made available for use by the installer
in two separate methods:
·One for retrieving permissions paired with a named permission identifier (we
presently lack a PermissionIdentifier class, but this is essentially what we
need). It has been decided that the IPermission interface be expanded slightly
to allow convenience methods returning a permission identifier (for both
convenience in use as well as storage). The resulting code change resulting
from this is slight and a similar implementation was already created (but not
implemented) in the PermissionDelegateConstants class.
·The other should provide pairings of the interactions required along with their
interaction identifiers.
2. Be able to present a structured request (a design detail I left up to Eric) for more
information to the installer (aka respond to a “what do you need?” method call
with “I need an item ID for a vendor and key master.”).
3. An install(…) method that installs the quest interactions on the proper items and
the permissions on the proper interactions, be they general or gameitem specific.
Please see the design note about this method in the “Design Decisions” section.
A Quest Installer will also be created to facilitate the addition of these elements to
the game world.
Two important classes need to be created:
1. Quest Interface (with concrete implementation).
2. QuestInstaller class.
The following tasks have been assigned:
·Paul:
