Dungeon Mode Rendering Design in Unified Modeling Language Dungeon Mode Rendering Design in Unified Modeling Language

Table of Contents

This document provides a Unified Modeling Language version of the design for rendering dungeon-mode maps as Scalable Vector Graphics.

1 Two Pass Rendering

Sorry, your browser does not support SVG.

In the pencil and paper game we express Dungeon maps on graph-paper. Most commonly taking an 8x10 inch block, most of a US letter sized sheet of quad-rule, for each Dungeon Level (dlv). As the party of player characters move about within the system of dungeon levels (or "Maze") the game must reveal information by adding or redrawing features, mimicking the players taking notes from the Dungeon Master's oral descriptions.

Our MPTP will render dungeon maps as SVG from sources extract from org-mode. As players move, using keyboard commands, etc., we reveal additional areas of the map by adding to our master path element, representing corridor and chamber walls and most doors, and SVG elements which are generally used to add decorations such as text labels or fill color.

The two pass approach simplifies fog-of-war concerns such as ensuring the privacy flags (implemented as :keywords punctuating the draw code).

  • Clear separation of concerns.
  • Maybe cache features after scaling the to the user's display settings.
  • Re-rending efficiencies

1.1 Re-rendering

Changes in game circumstance may require redefining Features. For example the party could suddenly learn the location all of the Secret Doors on a level. This may require replacing some large chunks of the master SVG path element. In the case of Default Maze, we have implemented visibility predicates for all of the draw code that creates the "Secret Doors" throughout the maze.

To complete this we must, and assuming single-pass render that does not want to scale images on the remote side of a network connection:

  • iterate the maze cells the player has seen on this level
  • create the new draw code, ensuring that we get the :elf and not :default variants
  • edit or replace the master path
  • deal with new/add/changed SVG elements
  • send the updated draw instruction to client to scale and render

Note this punts on the question of transacting a delta, perhaps not supporting it or else requiring the client to keep a cache of the original draw instructions and compare them to calculate offsets.

For Default Maze a small set of features provide variable draw code. The first phase, after evaluating game circumstances and potentially bouncing action back to the Party or Dungeon Master, results in a collection of draw code and referenced feature definitions per current play conditions.

The second pass, executed on the Emacs instance where the graphic is (or will be) displayed. The phase must consider a cache of features along with a cross reference of cells which use them, perhaps along with markers into the scaled rendered path, in order smoothly update an image already displayed, e.g. inserted into a buffer.

Naturally, much depends on the composition of draw code into features into a given level, an area where we currently plan much flexibility, and thus complexity. More then, perhaps, depends on the complexities ultimately expressed in the MPTP and driven out while examining it.

2 First Pass

Illustrations for (nominally) Server Side processing. Nominally in that we need to support the case of local rendering as well; however, efficiently transacting updates to player is within MPTP scope.

2.1 Server Side (first pass) Variables

Sorry, your browser does not support SVG.

2.2 First Pass Predicates

Sorry, your browser does not support SVG.

2.3 Resolve Paths

Sorry, your browser does not support SVG.

3 Second Pass

These illustrations represent work to perform just before display. We'd like to be able to consider different client-side caching, for example of drawing commands after scaling.

3.1 Request to Server

Sorry, your browser does not support SVG.

3.2 Response from Server

Sorry, your browser does not support SVG.

3.3 Client Response Handler

Sorry, your browser does not support SVG.

3.4 Update Buffer or File

Sorry, your browser does not support SVG.

=====

This document provides a Unified Modeling Language version of the design for rendering dungeon-mode maps as Scalable Vector Graphics.

4 Two Pass Rendering

Sorry, your browser does not support SVG.

In the pencil and paper game we express Dungeon maps on graph-paper. Most commonly taking an 8x10 inch block, most of a US letter sized sheet of quad-rule, for each Dungeon Level (dlv). As the party of player characters move about within the system of dungeon levels (or "Maze") the game must reveal information by adding or redrawing features, mimicking the players taking notes from the Dungeon Master's oral descriptions.

Our MPTP will render dungeon maps as SVG from sources extract from org-mode. As players move, using keyboard commands, etc., we reveal additional areas of the map by adding to our master path element, representing corridor and chamber walls and most doors, and SVG elements which are generally used to add decorations such as text labels or fill color.

The two pass approach simplifies fog-of-war concerns such as ensuring the privacy flags (implemented as :keywords punctuating the draw code).

  • Clear separation of concerns.
  • Maybe cache features after scaling the to the user's display settings.
  • Re-rending efficiencies

4.1 Re-rendering

Changes in game circumstance may require redefining Features. For example the party could suddenly learn the location all of the Secret Doors on a level. This may require replacing some large chunks of the master SVG path element. In the case of Default Maze, we have implemented visibility predicates for all of the draw code that creates the "Secret Doors" throughout the maze.

To complete this we must, and assuming single-pass render that does not want to scale images on the remote side of a network connection:

  • iterate the maze cells the player has seen on this level
  • create the new draw code, ensuring that we get the :elf and not :default variants
  • edit or replace the master path
  • deal with new/add/changed SVG elements
  • send the updated draw instruction to client to scale and render

Note this punts on the question of transacting a delta, perhaps not supporting it or else requiring the client to keep a cache of the original draw instructions and compare them to calculate offsets.

For Default Maze a small set of features provide variable draw code. The first phase, after evaluating game circumstances and potentially bouncing action back to the Party or Dungeon Master, results in a collection of draw code and referenced feature definitions per current play conditions.

The second pass, executed on the Emacs instance where the graphic is (or will be) displayed. The phase must consider a cache of features along with a cross reference of cells which use them, perhaps along with markers into the scaled rendered path, in order smoothly update an image already displayed, e.g. inserted into a buffer.

Naturally, much depends on the composition of draw code into features into a given level, an area where we currently plan much flexibility, and thus complexity. More then, perhaps, depends on the complexities ultimately expressed in the MPTP and driven out while examining it.

5 First Pass

Illustrations for (nominally) Server Side processing. Nominally in that we need to support the case of local rendering as well; however, efficiently transacting updates to player is within MPTP scope.

5.1 Server Side (first pass) Variables

Sorry, your browser does not support SVG.

5.2 First Pass Predicates

Sorry, your browser does not support SVG.

5.3 Resolve Paths

Sorry, your browser does not support SVG.

6 Second Pass

These illustrations represent work to perform just before display. We'd like to be able to consider different client-side caching, for example of drawing commands after scaling.

6.1 Request to Server

Sorry, your browser does not support SVG.

6.2 Response from Server

Sorry, your browser does not support SVG.

6.3 Client Response Handler

Sorry, your browser does not support SVG.

6.4 Update Buffer or File

Sorry, your browser does not support SVG.

Author: Corwin Brust

Created: 2020-02-09 Sun 15:28

Validate