Team

• Trevor Bechtel (trev@bechtels.com)
• Pierre-Yves Bonnetain (pyb@cadrus.fr)
• Jim LoVerde (loverde@str.com)
• Walter Szewelanczyk (Walter@adco.com)
  
  Other interested people:
  
• Frank Buss (frank@esb.mbis.de)
• Darren Fraser (dfraser@fdva.com)
• Mauran Nicolas (mauran%serveur-dil@lim.univ-mrs.fr)
• Bob Troia (btroia@ny.poppe.com)
• Tom Valesky (tvalesky@adams.patriot.net)
• Dan Vogel (dmv@transient.net)

Deliverables

• Core Game Engine
  • Character Messaging System
  • Client/Server Framework
  • Player Characters & Other Creatures
  • Core game engine
  • Items
  • World Engine
  • Modules
  • Dungeons
  • Dungeon Levels
  • Automapper
  • Map Generator
  • Module Editor
    

• 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.
      
  • 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