Hero's Tale Deliverables Specification
Authored by Trevor Bechtel (Jan '97)
This document describes the current set of known required
deliverables that need to be resolved in order to design and implement
the Hero's Tale game. Throughout this document, the word
"Project" refers to the Hero's Tale game. All deliverables
expected are marked with the word Deliverable in a bold,
italic, and underlined font.
Please forward any comments you have about this document to the java-games alias.
Make sure you put "[Java game] deliverable spec" in the
subject line.
Administrative Issues and Deliverables
-
Servers
-
The following is a list of the various types of servers that will be
required to implement and maintain this project. It's possible that two
or more of the following servers may end up sharing the same machine.
The only end result that matters is that the functionality required
exists.
-
Source Control system & server for the Project
-
The project requires a central location from which to check-in,
check-out sources from to facilitate code sharing.
-
The system used should make it easy to manipulate 1 or multiple files
at a time.
-
If there's no solution that's within easy reach, then we might want to
design something like a web-based RCS system.
-
Deliverables:
-
A working system that developers of the Project may use to:
-
Check out files (without locking them)
-
Lock files
-
Merge files
-
Check in files
-
Review revision history
-
Create files/directories
-
Destroy files/directories
-
A server that house the source control system and sources
-
Build Server
-
The project requires a machine somewhere to build images on a regular
basis.
-
The build server could live anywhere as long as it has access to:
-
The source control system
-
The distribution server
-
Deliverable:
-
A server responsible for building images
-
A system for building images
-
A system for uploading images to the distribution server
-
A notification system to notify interested parties of the success or
failures of any part of the check-out, build, or upload processes.
-
Distribution Server
-
The project requires a central point from which people developers,
testers, and eventually users may get the latest built images.
-
Deliverables:
-
A publicly accessible server that may be used to house images
-
Any software required to maintain the distribution server.
-
Test Server
-
The project requires a machine somewhere publicly accessible to run
tests on.
-
The test server would be responsible for running tests and reporting
the results of the tests. These results would be sent or posted to
interested parties.
-
The test server would be a web site that allows one to download and run
an applet.
-
The test server would be responsible for running the game server.
-
Deliverables:
-
A publicly accessible server responsible for test installing images
-
A system for testing installed images (automated and/or manual)
-
A notification system for distributing test results
-
Web site for accessing & running the project
Design & Implementation Deliverables
-
User Interface
-
There are a number of parts that needs to be worked in the user
interface portion of the project. These largely consist of a
combination of 2-D graphics, 3-D graphics, sound effects, and music.
-
Here is a rough sketch (mockup) of one possible user-interface

-
Main Viewer
-
Provides a top-down 3D view of the playing area. Displays a view of a
player's character and how it interacts with it's environment.
-
Might use raycasting techniques, liquid reality, or something else.
-
Ideally achieve the same level of detail and performance of Loaded
(a Sony Playstation game).
-
Ideally texture maps would be used to help add more detail to a scene
-
The resolution should probably be at least 320x200 with 20 frames/sec.
-
The goal of reaching 20 frames/sec should be valued more highly than
the resolution.
-
Will support some kind of overlay plane for displaying iconic idiot
lights.
-
Will need to interface with the client-side game engine to determine
how it will display what it needs to display.
-
The mockup shown above shows a bunch of people fighting. The scale
shown (people vs. viewer size) is not set in stone. A smaller scale
would probably be preferable so that one could take in more of the
surrounding environment. The game Loaded allows one
to dynamically scale the contents of the viewing area up and down as
one sees fit. This zooming capability would be a nice feature, but
isn't necessary.
-
If it turns out that a 3D is not feasible, then the view should
probably be some kind of orthographic view.
-
Items that one is able to pick up should be draggable into the
inventory or equipped views.
-
Items in the equipped or inventory views should be droppable or
throwable in the Main viewer.
-
Must develop control interface for moving characters around (either
mouse or keyboard based).
-
Deliverables:
-
A decision on exactly what the view should look like & what
features it will support
-
A decision on what tools/libraries will be used to construct the main
viewer (Liquid Reality, home-grown, or other).
-
A top-down view that shows a character and his/her surroundings.
-
Drag-n-Drop support with regard to items
-
Animation Engine
-
The animation engine is responsible for controlling the animations of
objects in the Main Viewer. It handles animating the actions of
characters, creatures, objects, and fixtures (like doors).
-
The exact architecture to be used for animation needs to be determined.
-
It's probable that the animation engine would be tightly coupled with
the Main Viewer.
-
It's unclear whether animations should be centrally driven by the Main
Viewer or whether each object being viewed in the Main Viewer should
have it's own animation engine which is responsible for drawing itself
into the Main Viewer. I'm leaning toward the latter.
-
Note that this does not include the actual artwork that is to be
animated. The animation engine should be given some behaviors and
bitmaps, it shouldn't specifically know about how specific animations.
-
Deliverables:
-
An architecture for animating objects within the Main Viewer
-
An implementation of this architecture.
-
Equipped view
-
The equipped view displays a character as he/she looks with everything
that he/she is wearing or wielding.
-
The equipped view might also display what a character's current health
is in terms of how happy the character looks.
-
Users should be able to drag items from the equipped view and drop them
in either the Main Viewer or the Inventory View.
-
Users should be able to drop items from the Main Viewer or Inventory
Views into the Equipped View.
-
Deliverables:
-
A working implementation of the equipped view
-
Drag-n-drop support with regard to items
-
Inventory View
-
The inventory view displays what a character is carrying
-
This view should implement a 'bags within bags' view. That is, if one
considered this view as a bag, and one put a bag inside of it, then one
should be able to double-click on the inside bag to explode a view of
it's contents. Then when one is done looking in this sub-bag, one
should be able to zoom back out to the outter bag. (Think: lists within
lists)
-
Items in the inventory view should be draggable to the equipped or main
view.
-
Items in the equipped or main view should be draggable to the inventory
view.
-
Because there will likely be an encumbrance limit of how much a
character can carry, there probably should be some kind of indicator of
how encumbered a character is. The solution to this might be to simply
use an idiot light in the Main Viewer, which means nothing would
actually be done in the inventory view.
-
Items should be drag-n-droppable into and out of bags within the
inventory view.
-
Deliverables:
-
A working implementation of the inventory view
-
Drag-n-drop support with regard to items
-
Spell View
-
The spell view allows the user to select and cast spells. It
effectively is a spell book for characters that can cast spells.
-
The interface for this is not described in the mockup above. One
possible idea is to integrate it with the inventory view (make a book a
kind of bag which contains spells), but one needs to be careful that
this isn't too cumbersome to use.
-
The spell view should allow the user to cast directed and undirected
spells. Perhaps by interacting with the Main Viewer.
-
The spell view should show an icon for the spell to cast and some kind
of indicator about how much mana a spell would cost to cast.
-
The spell view (or perhaps one of the status bars) should convey how
much mana is available to use.
-
The spell view should be simple enough to use in a real-time
environment, yet allow for a large collection of spells.
-
Deliverables:
-
A working implementation of the spell view
-
Status Bars
-
These are simply status indicators that are represented by some colored
bar and prefixed with some icon that's descriptive of what the bar
represents.
-
We should avoid using text as is shown in the mockup to avoid the
problem of internationalization. Instead, we should probably use
descriptive icons.
-
It will need to be determined what status bars will really need to be
displayed. In the mockup, typical D&D stats are shown, but it may
be that some of these are not necessary.
-
Deliverables:
-
A status bar class
-
Determine what information should be displayed to the user in this
manner
-
A status bar view which contains status bars for 'important' information
-
Idiot Lights
-
Idiot lights are 2-D UI elements that overlay the Main Viewer's
graphics.
-
Idiot lights are only display when something critical has happened,
such as:
-
A character is poisoned
-
A character is hungry/famished/starving
-
A character under the effect of some spell (like 'slow').
-
Deliverables:
-
An idiot light class
-
Determine what idiot lights are necessary
-
Integrate idiot lights into the Main Viewer
-
Character Message View
-
The character message view displays messages received from and sent to
other players.
-
The character message view will have control a characters' volume of
speech (whisper/normal/scream).
-
The character message view will not be responsible for determine what
'volumed' speech looks like to other players. The game engine will
handle the problem of dropping characters at farther distances for
ranged communication.
-
Note: This might be integrated with the game message view (as is shown
in the mockup)
-
Note: Messages from other characters will not be localized. Whatever
language a character types in will be the language that he uses.
-
The character message view needs to support unicode i/o.
-
Deliverables:
-
A text box which displays messages from other characters
-
A speech volume control
-
Game Message View
-
The game message view displays message from the game system about
system events.
-
Things such as monster hits, noises, and results of some special
actions (like failing to cast a spell) would be displayed here.
-
Messages from the game system will need to be localized
-
The game message view needs to support unicode output.
-
There is no input needed for the game message box.
-
It's possible that the game message view will be integrated with the
character message view.
-
Deliverables:
-
A text box which displays message from the game system
-
Localization strings for english implementation.
-
Localization strings for other languages provided we have the expertise
in the group.
-
Map View
-
The map view shows maps.
-
By default, the map view will show a map of the current world or
dungeon level that a character is standing in.
-
Maps will show where a character has been.
-
Maps will display indications of living entities that are within
line-of-sight of the characters (i.e. other characters or monsters).
-
The map view will offer a technique for flipping through all of the
maps a characters knows about.
-
The map view will offer controls for panning & zooming a map.
-
It's undecided as of yet exactly where the map view will fit in the UI.
It could be one of the following (I lean towards the third or fifth
option):
-
An overlay over the Main Viewer
-
A temporary replacement of the Main Viewer
-
A separate pop-up window from the rest of the client applet.
-
A separate, but very small, window within the client applet.
-
Part of a tabbed deck in the main viewer
-
The map window should ideally allow a user to add annotations to a map
-
Note: This is just a view of a map, the map implementation will be
handled elsewhere, but the map view will need to know what the
interfaces to maps are.
-
Deliverables:
-
A decision on where the map window fits in the UI
-
A map view implementation
-
Map annotation support
-
Graphic Artwork
-
Graphic artists will be need to create polished versions of the various
artwork in the game.
-
Ideally, the artwork for displaying creatures (characters &
monsters) and items worn/wielded by the characters would be done in a
mix-n-matchable way. Similar to the cut-out paper dolls one might find
in a doll book.
-
Artwork for characters should include male & female counterparts.
-
Artwork for characters in the equipped view would include basics like
bodies, hair, eyes, bone-structure, and other distinguishable body
parts. Different versions of faces for a particular character might
convey how healthy a character is.
-
Deliverables:
-
Textures (if appropriate) for Main Viewer
-
Item artwork for Main Viewer
-
Creature (Character & Monster )artwork for Main Viewer
-
Character graphics for the equipped view
-
Worn or iconic item graphics for the equipped view
-
Iconic item graphics for the inventory view
-
Border and frame artwork
-
Audio Effects System
-
The Audio Effects System is responsible for loading, editing, and
playing audio effects.
-
The system should support multi-channel audio effects, which I believe
the java VM already takes care of.
-
Some research will be required to determine if it's possible to
manipulate audio effects via either the standard java api or by some
home-grown work.
-
One idea that I've come up with is to subclass from the AudioClip class
to gain access to the .au data by rewriting portions of our audio clip
class. Then one might be able to dynamically process .au data to induce
volume and pitch changes.
-
Another area to look at is the 1.1 JDK to see if any improvements have
been made for audio support in general. This is unlikely, but it's
definitely worth checking.
-
Manipulations/edits of audio effects at a minimum should allow one to
change the volume and/or pitch of an effect.
-
When one desires to play an audio effect, one should pass arguments for
the audio effect, volume level, distance from effect source, and pitch
of the effect. The audio system should be designed to handle these
parameters regardless of whether the underlying implementation can
handle them or not. This way, some time in the future we'll be able to
eventually take advantage of more advanced effects.
-
The volume level, distance from source, and pitch should probably be
bundled into some kind of audio effect attribute structure so that we
could potentially expand the types of controls on effects in the
future, such as doppler effects and other fun stuff.
-
Audio effects will typically be played as a one-shot effect;
non-continuous and short.
-
In the worst case, we won't have any fine controls over audio effects,
but we should be able to play unmodified effects.
-
Deliverables:
-
Results of research into the ability to manipulate audio effects at
runtime.
-
An audio effects systems that at the minimum just plays sounds, but
provides an interface for doing more complex actions when they become
supported.
-
Music System
-
The music system will be responsible for playing mood music in the
background.
-
The feasibility of this system is directly dependent on the results of
the audio effects system research regarding the runtime manipulations
of audio effects.
-
The music system would likely be akin to a midi-playback system which
sequences and play notes with the proper pitch, volume, and sound
effect.
-
An alternative would be to play a large .au file, but this is probably
too inefficient given the medium that the game will be played in.
-
Deliverables:
-
Pending the research in the audio effects system, create a music system
which builds on top of the effects system to play background music.
-
Audio Specialists
-
Audio specialists will be needed for creating sound effects for the
various types of audio events than can take place in the game.
-
The audio specialists will need to help identify areas in the game that
could be augmented with audio effects.
-
Types of effects that might be implemented are:
-
Sword hits
-
Monster bite
-
Door opening
-
Grumbling
-
The audio specialists will also be responsible for creating background
mood music. Ideally, there will be about 6-10 songs to loop through,
but if we can get just 1, that would be OK.
-
Deliverables:
-
List of required special effects for the game
-
The special effects themselves
-
Background mood music
-
Networking
-
Design one-server/many-client network model for the project
-
Determine techniques to work around firewalls
-
Design low-bandwidth protocols for client-server communication
-
Assume low end of 28.8Kbaud
-
Implementation could use whatever's feasible (sockets, RMI, etc)
-
Deliverables:
-
A set of classes, engines, and/or interfaces for allow the clients
& server to communicate.
-
A basic client side applet/application with just the networking support
-
A basic server side application with just the networking support
-
Internationalization/Localization Framework
-
The internationalization framework should make it possible to easily
localize any strings used in the game.
-
One possible implementation is to create a translator class (perhaps
subclassed from String) which handles translates strings based on
lookups in some kind of language resource data file.
-
The internationalization framework should specify how localization will
be done.
-
The team working on the internationalization framework will be
responsible for creating an English localization dictionary at a
minimum. They will not need to fill in the contents of this dictionary
as the developers who need to write a string will do this, but then
need to have a dictionary in place that can be accessed and modified by
developers.
-
Translations to other languages will not be a requirement, but if there
exist people who can perform the translations needed, then that would
be helpful.
-
The team also needs to determine how a local can be determined (perhaps
the JDK already has a technique for this).
-
Deliverables:
-
A technique and implementation for allowing other developers in the
project to internationalize their output strings.
-
An English localization dictionary.
-
Core Game Engine
-
Character Messaging System
-
The character messaging system provides the ability for characters to
communicate with each other.
-
It receives textual input from a client-side applet, the volume level
at which a character is speaking, and a position of that character.
-
It finds the location of potential listeners with listening distance
from the source character and sends a filtered version of the message
to each listener.
-
The filtering mechanism filters the text based on a function of
distance between the source and target of the message and the vocal
volume of the message.
-
The filtering mechanism will use some algorithm to make a message less
coherent the further away the source and target are from each other.
Perhaps characters will randomly (or non-randomly) be dropped from a
message.
-
There should be some minimum threshold that needs to be attained
distance-wise before a message becomes less coherent.
-
Deliverables:
-
A system for creature to creature communication that takes into account
vocal volume and distance.
-
AI for Computer controlled creatures
-
AI will need to be developed for controlling entities that are not
controlled by any players
-
At this point, the minimum requirement is that the AI provides a small
challenge to players. This goal can be raised if there are enough
people working on this aspect who think they can do more.
-
The AI should include combat strategies, such as 1:1, zone, formations,
attack the first thing you see, etc.
-
The AI should utilize the character messaging system for communicating
with players. Exactly how this is done will need to be specified
further by this team.
-
The AI will be important for both monsters as well as merchants and
other NPC's.
-
The AI should be aware of noises in the environment, such as speech,
closing doors, and things that go bump. It should also be aware of the
volume of these noises. For example, if a wondering monster is
patrolling the dungeon looking for yummy adventurers, it's likely to go
investigate the sound of clashing swords and raised voices.
-
The AI should convey the attitude or demeanor towards other monsters
& players; whether an entity is friendly or not.
-
AI's will likely need to be tailored towards specific kinds of
creatures/NPC's. Ideally, one should be able to abstract the
commonalities to a higher level.
-
Deliverables:
-
An AI system that provides the means to control the behavior of
entities not controlled by a player.
-
Client/Server Framework
-
While, the networking team will be working on the communication issues,
the core game engine team needs to decide what form the resulting
executables will take. At least on the client side of the game. Should
the client be an applet or an application?
-
Applets have the advantage of accessibility and that of having sound
support built-in.
-
Applications may have to instantiate an applet just to play sounds, but
they have the advantage of levering a downloaded-once/play-many mode of
use. This means, that if the client application was running locally
that graphics and sound could be richer without using up precious
bandwidth.
-
Another item to consider is whether Castanet is a viable technology to
leverage.
-
Deliverables:
-
A decision on what form the client will take; whether it's an applet or
an application.
-
Whether the client could or will utilize Castanet technology.
-
Player Characters & Other Creatures
-
Player characters and other creatures, such as monsters or NPC's need
to have the following attributes or capabilities.
-
Motion (walking/running/jumping/flying/swimming)
-
Modify inventory; Pick up, carry, drop, or throw things.
-
Eat something edible (rations/dead creatures)
-
Rest, get sick, cure, heal, and regenerate, hit points
-
Attack (hands/weapons/teeth/claws/breath weapon/etc.)
-
A combat system needs to be defined an implemented
-
Communicate with other players/creatures
-
Cast magic spells
-
A mana-based magic system needs to be defined and implemented.
-
Character will have some degree of mana available (like hit points)
that can be used and regenerated over time.
-
Trade with other players/creatures; money, items, or information (like
maps)
-
Be affiliated with one or more groups of players/creatures. i.e. party
of adventurers or an organization like a thieves's guild.
-
Persistent. A character or monster must be savable and restorable in
the state that it currently exists (perhaps taking advantage of java
bean serialization).
-
Have a character class association (fighter/thief/cleric/magic-user)
-
Have physical attributes such as strength, dexterity, wisdom, etc.
These will need to be determined on a case-by-case basis to make sure
they are really needed.
-
Have a notion of experience points and/or experience level.
-
Please refer to the inheritance diagram to see where player characters
and NPC's fit in the scheme of things. (NOTE: this
diagram isn't available yet)
-
Has memory and as such is able to construct a map (see the automapper)
and refer to it (see the map viewer). A player may trade map
information to other players.
-
There should be a basic set of monsters implemented
-
Players, NPCs, and monsters are a subclass of items.
-
Deliverables:
-
A set of classes that implement players, NPCs, and monsters.
-
Combat system implementation
-
Mana-based spell casting system implementation
-
Core game engine
-
At some core location, there may need to be an update loop that runs
through and updates the world environment on a loop-by-loop basis. Each
loop could be considered a 'turn'. The loop should be tight to achieve
real-time performance.
-
An alternative might to be make the game completely event driven, but I
don't have a clear picture of how we'd make sure that things that need
to be updated would be updated in this model. Perhaps with a dedicated
thread which controls the AI of creatures and the physics of moving
objects.
-
The core game engine will be responsible for sending updates to clients
about changes in the environment.
-
The core game engine will be responsible for starting up all the
appropriate pieces of the game to get things running and then run it.
It will similarly be responsible for shutting down the game.
-
The game engine will be responsible for adding or removing players to
or from a world
-
A technique will need to be defined on how to handle players exiting a
world and jumping back in.
-
One possibility to only let players enter and leave the world in 'safe'
rooms.
-
The time model will be handled by the core game engine. The time model
should be real-time based and scaled to whatever is convenient. (Such
as 1 second of real time = 1 minute game time).
-
The core game engine is responsible for running a world.
-
The core game engine will provide multiplayer support via the
networking model and whatever else needs to be done.
-
Deliverables:
-
A core game engine as described above
-
Items
-
Items are objects that exist within a game world
-
Items may or may not have the following attributes:
-
Have some visual appearance
-
Confer some special effect (magical or not)
-
Be picked up, dropped, or thrown
-
Have some special non-standard use (such as a whistle)
-
Be edible
-
Be carryable (weight/encumbrance)
-
Items are a superclass of players/monsters
-
Items should be demand-loadable at run-time. This means that we won't
need to have everything in the world loaded into the game in order to
play. Rather, we load items when we need them.
-
Deliverables:
-
An implementation of a basic item class
-
Identify types of objects (beyond players, creatures, and NPCs, which
may include scrolls, books, wands, weapons, armor, rings, boots, etc.)
-
Implement the types of objects that were identified that could be
properly inherited from an item class.
-
World Engine
-
A world is a place where players can interact with creatures, NPCs and
other players.
-
Worlds maintains 0 or more modules (0 is a very boring world).
-
A world contains dungeons, which are typically associated with modules.
-
A default dungeon likely exists which is 'the outdoors'. The 'outdoors'
would contain entry points into towns, dungeons, and/or buildings.
-
Things that might likely exist in a world are:
-
Town
-
Taverns
-
Taverns are sources of rumors about existing modules
-
Shops
-
Arena (for practice/training)
-
A world is persistent so that it could save it's state and restart
where everything left off. This means saving the state of modules and
dungeons, which in turn means saving characters, objects, etc.
-
Some of the things in the core game engine might be more appropriate to
put in the world engine.
-
Deliverables:
-
An implementation of a world class
-
Modules
-
Modules define goals for characters to meet and set up the scenario in
order to meet those goals.
-
Need to define methods for defining goals and detecting whether or not
they are achieved.
-
Creating a module will likely result in creating a dungeon somewhere in
the world.
-
Modules will have rumors which will be fed to the taverns of the world.
-
Will need to come up with a technique for measuring the difficulty of
reaching a goal to be able to provide the appropriate amount of
experience points to player characters.
-
Parties will need to have a technique to associate themselves with a
module so that they may obtain the proper experience from achieving the
goals of the module.
-
Deliverables:
-
An implementation of a module class
-
Dungeons
-
A dungeon is a collection of dungeon levels
-
Dungeons are persistent
-
A technique for measuring or controlling the obtainable experience in a
dungeon needs to be defined. This will likely be defined in terms of
the dungeon levels it contains.
-
Deliverables:
-
An implementations of a dungeon class
-
Dungeon Levels
-
A dungeon level is the actual playing area where characters and
creatures move around
-
A dungeon level contains fixtures such as walls, sinks, doors,
buildings (outdoors), rooms, stairs, altars, fountains, and traps.
-
If a dungeon level is an outdoor dungeon level, then the insides of
buildings would not be viewable until a character enters that building.
-
Similarly, characters should only be able to see areas that are within
line of sight. Areas that are not with-in line of sight should be
grayed out if the character has seen this area before or simply blacked
out if not.
-
A dungeon level needs to implement and/or use a dungeon map
-
There should be some way to control and measure the difficulty of a
dungeon level.
-
Dungeon levels are persistent.
-
Deliverables:
-
An implementation of a dungeon level and corresponding map.
-
Automapper
-
The automapper will automatically create a map of where a character has
been and what he has seen.
-
Deliverables:
-
An implementation of the automapper.
-
Map Generator
-
A map generator will need to be constructor to generate random dungeon
levels
-
One parameter in creating a map would be the desired difficulty of the
dungeon level
-
Whether or not the dungeon level is indoor or outdoor should be taken
into account.
-
Outdoor map generators should generate towns with shops, taverns, and
arenas as well as wilderness features such as trees, rocks, and rivers.
-
Indoor map generators should generate rooms, corridors, doors, traps,
etc.
-
Map generators would also define starting positions for monsters,
players, and NPCs.
-
Map generators define where various items may be found.
-
The group working on the map generator should also define what a map is.
-
Deliverables:
-
A map generator for generating random dungeon levels
-
A map class implementation
-
Module Editor
-
A map editor let's a user create or edit his own modules, complete with
dungeons, dungeon levels, and quests.
-
Deliverables: