Hero's Tale

Trev's Vision of the Project

Goal of the Project

• The primary goal of this project is to create a substantial, but fun piece of software that we can all say that we worked on. This goes along with the same spirit as SimStar
  
  [SimStar was a project that I started while I was at Cal Poly. This project was an all volunteer effort to produce a starship simulation similar to a Star Trek experience. There were two rooms filled with networked PC's (286's at the time), large project screens, plus a couple of Amigas for graphics and Apple II GS's for sound. Each room was the bridge of a starship and each of the PC's in a room was a station on the bridge; i.e. Navigation, Science, Engineering, and Weapons. It's been over 5 years since I've graduated from Cal Poly ('91) and the project is still alive in the form of SimStar IV (running on SGI boxes). There have been roughly 40 people associated with the project at one time or another.]

Resources Required

• Who / And what do they get out of it
  • I'm looking primarily for people interested in java games development.
  • There's no money to be had, but there is the gratification of a job well done and perhaps even some net fame.
• Hardware
  • For development, anything that will run a java compiler
  • For users, anything that will run a java capable web browser on the internet.
  • For server, anything that can run a web server as well as run a java application.
  • Preferably we'll get a mix so that we can uncover any portability problems
• Software tools & libs
  • java compiler
  • java debugger (optional, but recommended)
  • libs? Don't know yet...probably the standard java API for now. If anyone finds any really useful classes/packages on the net, then we'll grab those.
    • Liquid Reality from DimensionX?
    • OrbixWeb from Iona Technologies?
    • Cosmo3d from Silicon Graphics? (Unlikely at this time)

Target Market

• Public domain
• Users enjoy fantasy adventure arenas with a touch of action.
• No money will be made (only net fame)

Typical setting of where the game is played

• A user at home or work brings up their java-capable web browser and connects to a special server. This server will download the game and off they go...

Trev's Vision of the Game Itself

Title of the game

At the moment, I'm calling this game Hero's Tale. But this isn't really set in stone, if you can think of a title that I like better, then I'd be happy to use it. I currently consider Hero's Tale to be better than my last title, which was mprogue, or multi-player rogue. I feel that Hero's Tale will probably be a good name because it reflects the fantasy elements of the game as well as the element of character development. As one plays the game, they may develop a sense of history associated with their character, hence the 'tale' portion of the title.

Object of the game (this is really two games in one)

• Short term goal
  • To complete a module. To complete a module, one must fulfil that module's quests. Each quest is some goal that must be attained; such as finding the amulet of Yendor, killing a boss monster, freeing a peasant from the dungeon...
• Long term goal
  • Build up ones character to a specific level so that it may retire and achieve notoriety in that character's home town.
• Ending the dungeon level, module, or game
  • A Dungeon Level does not cease to exist until the entire dungeon has ended.
  • A Dungeon ends when there's no player characters in the dungeon any more or if all of the ones that are in it are dead.
  • A module is done when all of the quests in it have been fulfilled by a party or individual. A module may involve multiple dungeons.
  • The game is over when the gamemaster (server) decides the game is over
  • A character's game is over when he dies, quits, or attains retirement.

Requirements Specification

• Must support basic functionality of Rogue (simple rogue)
  • Objects in Rogue
  • Monsters in Rogue
  • Magical effects in Rogue
• Must be extensible enough to promote the richness of Nethack in terms of numbers and types of creatures, characters classes, objects, special rooms/levels, types of magic, and fixtures (doors, floors, traps, etc.).
• Unlike rogue, character experience gained may be slower
  • This is to let the character try out several different 'modules' before having to retire.
  • It's possible that this might not be necessary since I expect that the dungeons will be much smaller (perhaps 3-4 levels on average) and as a result, one wouldn't be able to gain that much.
• Unlike Nethack, I really don't care too much for the 'alternate' worlds. They'd be ok to have if people really want them, but I'd rather not...
• Must support multiplayer play
  • Number of players: 1-100 players (arbitrary number)
• Must allow variable sized dungeon levels
  • No limit on size of 2-D map of a dungeon level
• Dungeon levels will only be 2-D
  • We will not deal with arbirtrarily 3-D dungeons
• A dungeon can have any number of levels
• Every dungeon will have at least one goal:
  • Find an artifact
  • Kill a 'boss' monster
  • Find and return a wrongly held prisoner, etc...
• A dungeon should be an appropiate challenge for the sum of the characters within it
  • Not sure yet whether this would be determined on the fly or staticly. If staticly, then characters would pick the dungeon difficulty they want and go find an appropiate dungeon. If they chose a dungeon that was too easy, then they should not benefit very much from it. If they chose one that was too difficult, then they should be rewarded handsomely if they succeed. I like the static idea better, it helps cultivate the idea that there's a realm (many dungeons) that the characters should explore. Note that this implies that the increasing of character abilities/experience will likely need to be non-linear in such a way that it's more difficult to get the same degree of bennies twice in a row. For exampe, a dungeon that potentially provides 1000 experience points might boost a 1st level character to 2nd level, but would do practically nothing for a 10th level character. This is similar to the way experience levels works in TSR's AD&D.
• A world should be the starting point for all campaigns.
  • A world will contain towns, wilderness, and entry points to modules (which could be dungeons, castles, other towns, specific wilderness settings, etc.).
  • A world will have a configurable size. Once set, it can not change unless a new game is started.
• The game must be able to persist beyond the running of the game server.
  • That is to say that the game must be able to restart where it left off when last running.
  • The game must also be able to update the world with whatever important real-time events that may have happened while the game wasn't running. Things like earthquakes, fires, wars, 'troop' movements, politics, taxes, etc. [These details would probably be added sometime after the first version of the software. They are only provided here to show the direction I see this game going once it has momentum.]
• The game will consists of two basic modes of operation which should be made transparent from each other (which really makes this modeless, but that's not the point):
  • A 'dungeon crawl' mode, where adventurers make their way through a dungeon
  • A 'wilderness' or 'world' mode where adventurers move around the world and interact with the wilderness, towns, dungeons. It's unclear at the moment whether the scale of this mode should be different that the dungeon crawl. If it's the same, then we really only need one mode.
• A player or creatures should be able to perform the following actions (within the restrictions or abilities of a specific player or creature)
  • Move; walk around; run
  • Pick up, drop, throw, or use objects
  • Learn, read, and cast spells
  • Eat anything edible (rations, dead creature)
  • Rest, get sick, heal, regenerate
  • Attack; using hands, weapons, teeth, claws, breath weapon, etc.
  • Communicate with other players/creatures
• Objects should be able to (within the restrictions/abilities of the specific object)
  • Have an effect (magical or not)
  • Have an appearance
  • Be picked up, dropped, or thrown by creatures or players
  • Have a specific use
  • Be edible
• Sometimes it will be appropiate for one player/creature to pick up, carry, throw another. So, it's possible that players/creatures and objects should inherit these abilities from a common ancestor class.
• Will need module/dungeon/level/wilderness/town map generators to create maps and populate them.
• Will need to have taverns in towns. Taverns will be a place in which characters are guaranteed to hear about a potential adventure that they could embark on.
• The time model in the game will be real-time based, but will likely be a scaled version of real time. For example, 10 minutes of real time could be 10 seconds in game time. This is important to understand because of the need for characters to be able to get from point A to poiont B in the world in a reasonable amount of time. Note, however, that it doesn't *not* have to truly be a scaled version of real time, if doing so makes the game more playable.
• The interface for the game will consist of these parts:
  • Main viewer - This will be a top-down 3-D raycasted view centered around the player's character. I envision this looking a lot like the game 'Loaded' that I have for my Sony Playstation. This will be where all the real action happens. The character should 'look' the way he/she would look from above (see equipped view below).
  • Status bars - This will contain bars or numbers that show things such as health, experience points, abilities (Str, Dex, Con, Chr, Int, Wis), and encumberance.
  • Status icons - These 'idiot lights' will popup whenever your character is in a particular state. One example is 'poisoned'. These idiot lights might show up as an overlay over the mainviewer with some degree of transparency.
  • Equipped view - A picture of your character and what he's wearing/weilding. Very similar to Ultima Underground and several other games. This will also refect what the character looks like (hair color, eye color, male/female, body shape, etc). If someone polymorphs into something else, then this display should be updated appropiately.
  • Inventory view - A view of all of the unworn or unweilded objects the character is carrying. This will be a kind of 'bags within bags' view, where you see a bag and it has things in it and one of those things could be another bag. If that bag is clicked on the inventory view is blown up to display what's in it. There will also be an icon to close a bag. All of the items will be represented as icons. Icons can be dragged up (out) of a bag and from one bag to another. Item icons in the bag shoud be usable in place (if appropiate), and one should be able to drop or throw an item.
  • Message box - This will be a 1-2 line window which contains chat messages between players and/or creatures. There will also be user-defined 'hot' buttons for sending specific kinds of messages (perhaps tactical maneuver commands). Lastly, there will be a vocal volume control that controls the range of a players words (see Converstation, below). Normally it will be at a 'normal' volume. But it could be set to a whisper or a scream. After the scream/whisper is done, it will revert back to 'normal' speech. The design of this will define the exact semantics.
  • Game message box - This might be shared with the message box, but maybe not. This box will be responsible for related game related messages/event to the player.
  • A map window - this will be a popup window that will give the player an overview of the world as he knows it. It will also serve as a dungeon map utility. All of the known areas will be visible, but the areas outside of line of sight or range of sight will be dim signifying that if any changes have taken place (like a monster moving) in those areas, the player won't be able to see that.
• Artists will be required create all of the item icons, texture maps for the top-down raycasting, character appearance, creature apppearance, items in the raycast view, items in the equip view and a few other miscellaneous details.
• Musicians will be required to create background music for the game. Ideally, there would be several different songs to play (perhaps 6-10) in a loop. It's unclear at the moment what the quality of this music would be. It might have to be midi based in order to compress it to a quickly downloadable form.
• A sound effects creator will be needed for handling all of the possible sound effects in the game. Sword hits, monster bite, opening a door, throw an object (it hitting something), monster grunts, 'magic', etc.
• A tool will be required for playing back songs. In addition, the same or a different tool will be required to produce multi-channel sound reproduction of digitized sound effects.
• A new magic system will be created for this game for spell casting. It will be a mana based system that resembles Stephen D'Angelo's mana rules for D&D.
• A combat system will need to be specified. This will be needed to determine chance of hits and amount of damage done when hit.
• Computer controlled creatures will have the ability to use certain tactiics in combat. This include man-on-man, zone, formations, and communication. Player controlled characters will be able to practice tactics in 'arenas'. Communication is a tool for leaders to bark orders to characters
• Arenas are special places found in towns where characters may practice battle with one another or against NPC's. This is really a 'VR' for practicing as any damage done in an arena is not real, nor are items used up. This is a useful place to practice special tactics.
• Converstation between players will be ranged. When players are near the limits of this range, then the conversation will be filtered in such a way that it's less readable (perhaps missing words or consonants). Normally as long as your in line of sight (up to about 10 scale feet, others should be able to hear just fine). This range is partially configurable by the message box with a vocal volume control. Additionally, walls and doors will diminish the range of sound. This way characters could be in a heavily populated area without getting inundated with messages...but just enough that if they're listening at the right time they might find clues.
• An automapping utility will be required. Levels of automapping will be (1) World, (2) Dungeon, (3) Dungeon level. In addition, players may trade map information when they want to (and are near enough to each other). Also, players in a 'party' will automatically trade information when they meet regarding the dungeon they are in. This way a party could split up and then rejoin and trade map info. It's automatic for party members because they're supposed to be helping each other out anyway...
• Multiple parties or individuals should be allowed to enter the same dungeon at a time. They could even possibly fight with each other.
• All parties are unique. Just because a character is in one party doesn't mean he's in all. A character can only belong in one party at a time (I'm not sure about that -- It might be neat to say have a thief who's a member of the 'theives guild party' as well as his 'adventure party').

Data Dictionary / Glossary of Game Terms

• World - The realm in which the game takes place
• Dungeon - A structure which consists of 1 or more levels of rooms, creatures, objects, etc.
• Module - A scenario which typically involves some dungeon. The module will define one or more quests which the adventures must try to accomplish. It will also provide some background information, hints, clues, and other data which is required to complete the module.
• Quest - A goal for a character or party of adventurers. This could be anything from finding an amulet, killing a dragon, to freeing the town mayor from the dungeon. A quest will have some level of difficulty associated with it and a corresponding amount of experience points to be gained from completing the quest. Characters may take on quests themseleves or with a party.
• Dungeon level - One floor in a dungeon. This usually consists of a several rooms, corridors, monsters, objects, and traps.
• Character - The virtual person in the game which a player controls
• Party - A group of characters that work together to meet some goals.