# Miso Notes -*- mode: outline -*- # # $Id: design.txt 2236 2003-02-04 03:33:38Z mdb $ * Notes Consider making MISO sufficiently sophisticated to allow the cluster stuff to be implemented as an extension. This would included allowing the XML scene stuff to allow extensions, the scene editor to allow extensions and of course extending the MisoScene class itself. * Discussion Date: 07/10/01 Venue: General discussion in vast sweeping loft area. Participants: mdb, shaper. Main game play uses an isometric graphical view to display the current game area. This section of the screen is referred to as the "scene" hereafter. Targetting a screen resolution of 800x600. Toolbar and info areas may be on the right side of the screen, below, or both, still TBD. Scene display area will be either 600x600 or 640x480 correspondingly. Will use JDK 1.2 or 1.3 allowing us to make use of Java 2D and the new Java Sound APIs, among other happy things. Scenes are non-scrollable. Exits are expected to be placed largely, though not exclusively, around the borders of the scene (esp. at building entrances.) Moving the mouse over an exit causes an arrow to appear flashing to illustrate that clicking on the exit will move the player to a new scene. Characters will be displayed in the scene using "fine" coordinates (an additional grid within each tile) to allow them to move smoothly. TBD: art details, how many frames of animation, what kinds of things can be carried, paper-doll-ing of character clothing, possibility of color-replacement to allow increased re-use of clothing art. * Design ** Scene Description - sid: unique scene identifier - name: scene name - version: scene description file format version - tile array: full NxM set of tiles for L0, sparse for L1+ - hot spots: the "zones" wherein people congregate in each scene, a set of scene coords - exits: set of scene coords and associated sids that the exits lead to ** Potential Classes SceneIDBroker: dynamic scene creation and obtaining/tracking scene ids SceneManager: scene retrieval, caching TileManager: tile retrieval, caching Config: tileset/tile info ** Tile Sets and Tiles General high-level categories of tiles: 3 * outside (three prospective themes) ship } item (potentially present in all) house Tiles will be identified by a combination of a 16-bit tile set id and a 16-bit tile id within that set. Estimating: 400 tiles per scene 1000 scenes = (approx) 1.6 MB (highly compressible) Tileset config info associated with each tile set includes, for each row of tiles in the tile set, the "row height" (height of the tiles in that row), and the "tile count" (number of tiles in that row). Buildings in the scene, as an example, will then be comprised of a contiguous grouping of tiles that are the same width as all other tiles, but of greater height than the ground tiles. The scene editor tool could automate the placement of buildings by allowing pre-defined groupings of tiles and facilitating rotating building tile entities, etc. as needed, but we'll wait on doing fancy things like this until/unless we decide we need it since it's not yet clear that we need particularly fancy scene design tools. Note that the scene editing tools should be designed such that they can be used in part within the game itself, since players will be allowed some degree of freedom w.r.t. designing and placing their own homes (and perhaps landscaping?). Tilesets are intended to be used as an entity that contains tiles corresponding to whatever logical groupings seem reasonable. E.g., perhaps one tileset will contain all "ground" tiles; "spanish house" tiles; etc. Split tilesets as necessary (multiple ground tilesets if/when we have enough to warrant it.) Perhaps number the tileset identifiers into meaningful groupings, i.e., all ground tilesets have a tileset identifier in the range of 0 - 999, all building in 2000 - 3000, etc. Character animation frames may be performed by passing fully qualified tile id and number of frames to animate, frames must be contiguous tiles thereafter. character images will likely be handled as a special case above and beyond our general tile antics. Look into using PNG file format for images. PNG supported in JDK 1.3+ and probably JAI 1.1 for earlier JDK versions. use PNG alpha-channel rather than separate masks for handling image transparency. Look into perhaps using bitmap masks to reduce the drawable area needed for drawing tiles (e.g. exclude corners of iso squares), but only if noteworthy perf gain achieved. Perhaps other similar worthwhile uses. ** TBD *** Resource mgmt When is scene data and art loaded, how big are the chunks of data downloaded, what's the user experience during download like. *** On-screen "map" display of the surrounding scenes The scenes comprising a town, etc. potentially impacts how we allow placement of exits in a scene since allowing folks to place exits to their houses/bldgs willy-nilly may make map generation wacky. perhaps useful for game designer use as well when laying things out and "surveying the landscape." * 1/14/2003 ** Ground zero - Render all ground and fringe tiles (unprepared) into a single offscreen buffer and use that to repaint the ground instead of going from the original tile images * 1/28/2003 ** Scene revamp - Objects without actions are largely inconsequential (in the model, they exist only as fqtid and coordinates) - Objects with actions have extra data: + the action string + a location and orientation associated with the object (for building facades this would be the entrance portal location, for "stations" this would be where the user stands when occupying that station) - Scene model is not used by anyone but the scene impl (so that more sophisticated models and impls can come to exist)