Hero's Tale Deliverables Specification

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:
      • A map editing tool