OpenRPG2 Road map

Currently on Hold. Development is continuing on OpenRPG1

Development Status and Priorities

Type	Item	% Completed	Priority	Notes
Core System	Networking	96%	5	Basically Complete
Core System	Internal Messaging	80%	5	Message Structure and handling established. Module init/filtering routines in development
Core System	Base Module Class(es)	10%	5	Server default relay and network modules roughed in
Core System	Application Level Logging System	65%	5	Functional system based on Java Logger in place. DevConsole logging in place.
Core System	GUI Management Subsystem	28%	4	Initial GUI capabilities and support for multiple GUI modes have been established
Core System	Module Management System	65%	4	Basic module system in place with simple core loading mechanism
Module	Document Tree	0%	2	Basic Document Tree System with hooks for other modules to access
Module	Map	0%	2	Basic Map interface & handler system
Module	Chat	0%	3	Basic Chat interface & handler system
Utility	Dieroller	60%	2	Basic (but extensible) die roller/parser exists

Priority Level: 1-lowest, 5-highest

Application Design Overview

OpenRPG2 will be very modular in construction though solid object oriented design. All of OpenRPG2's basic functions as well as third party plugins will be separate 'modules'. These modules will communicate with each other though a messaging system with a basic 'discard message if handler does not exist' schema. Modules that have visual gui components (like chat, map and document tree) will each manage their own gui elements and will supply a simple JPanel reference to an underlying GUI manage that will, using user preferences, layout the screen as dictated by the user. Modules will have access to a library of generic utility classes (such as dierollers) and will be able to send messages internally (module to module) as well as to the client/server (module to network).

One of the most attractive parts of the OpenRPG2 design is the messaging flexibility. Each message is routed and directed using a well defined header segment that is automatically encoded and decoded by the network code. This header is String based, unicode compliant, and has an arbitrary length. Each message also contains a pure binary data segment of arbitrary length where any type of data may be transmitted. The flexibility this message schema provides means that plugable modules are not limited to the size or type of data sent.

The server network is based on the non-blocking aspects of the java.nio package and will (eventually) use a more elaborate dynamic thread pool to service all connected clients.

Distribution will be in the form of a single executable JAR file custom built for either the client or the server portions of the application.

OpenRPG2 Design Concepts

OpenRPG2 Specific Goals and Development Targets

GENERAL

User Configurable/Customizable
Simple & clean interface elements

CLIENT

CHAT SYSTEM
1. HTML Based with link and image support. (CSS support would be ideal)
MAP SYSTEM
1. Layer based with specific layers limited to GM use only
2. Properly Implemented Fog of War
3. Show/Hide feature for various layers (i.e. to be able to hide the whiteboard)
GAMETREE (DOCUMENTATION) SYSTEM
1. Private character sheets
2. Live shared character sheets (possibly with read-only for others)
3. Scripting System
4. XML export for saving nodes

SERVER

FEATURES
1. GUI & console modes
2. Banning (permenent and timed)
3. Stealth monitoring (ability for server op to monitor a room without room occupants being aware)
REMOTE ADMINISTRATION
1. Lightweight Remote Server Administration application