Menu
▾
▴
openrpg-v2-dev — Developer mailing list for OpenRPG2 (Java)
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(46) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(86) |
Apr
(77) |
May
(21) |
Jun
(11) |
Jul
(16) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(48) |
Oct
(1) |
Nov
(4) |
Dec
|
|
From: <sn...@ga...> - 2004-05-24 23:01:28
|
The following is a purposed structure for
OpenRPG2 to use for its files. I'm looking for
feedback on this before setting up the skeleton
directory structure in the CVS in prep for the
new code to be started.
-------------------------------------------------------------
Project: OpenRPG 2
Topic: File/Package Structure
Author: Snowdog
Date: May 24, 2004
Outlined below is general package layout
(directory structure) for the ORPG2 project.
openrpg2
|
+-- core
| |
| +-- base
| +-- interface
| +-- layers
| +-- modules
| |
| +-- translation
| +-- command
| +-- interface
| +-- network
| +-- util
|
+-- docs
|
+-- modules
| |
| +-- translation
| +-- command
| +-- interface
|
+-- config
| |
| +-- default
|
+-- resorces
| |
| +-- image
| +-- sound
| +-- filter
| +-- gamedef
|
+-- logs
NOTES ON DIRECTORY USEAGE
openrpg2\core\base: generic core elements
(aka foundation classes)
that are used solely by the
core codebase
openrpg2\core\interface: contains core files related
to the base GUI/UI(s) used
by OpenRPG2
openrpg2\core\layers: contains the base layer code
for implementing the various
major sections of the OpenRPG2
'core' layers
openrpg2\core\network: contains all networking code
openrpg2\core\modules: each subdirectory contains each
layers respective core
modules. These are modules required
by openrpg to run. The are
separate from extension modules.
openrpg2\core\util: utility/helper classes
to support the extension modules
openrpg2\docs: all documentation; licenses, developer
information, help files, etc.
openrpg2\modules\*: each subdirectory contains each
layers respective extension
modules. This separates them
from the core code modules.
openrpg2\config: storage for main (sitewide)
configuration files
openrpg2\config\default: default configuration files
(for generation of new config files)
openrpg2\resources\*: various resources for
distribution with openrpg2
software.images and sounds
are self explanitory filters
are language filters (REGEX)
gamedef contains game-specific
definition files (assuming OpenRPG
has notion of game-specific
elements)
openrpg2\logs: contains error and/or various
dedicated server logs
Numerous users requested per user data and/or
site wide installs for the OpenRPG 1 project
So OpenRPG2 sould have that facility built
in by default
[user 'home' directory]
|
+-- openrpg2
|
+-- config
+-- gametrees
| |
| +-- default
| +-- [gametree 1 name]
| +-- [gametree 2 name]
| +-- [gametree n name]
|
+-- map
+-- files
| |
| +-- temporary
|
+-- log
NOTE: this structure illustrates gametrees being little
more than a directory reference. This concept
helps separate gametrees more logically and would
allow for cleaner node management than large gangly
XML files. Each file within a gametree directory
would be an independent node. A config file at each
gametrees root level ( _treedata.xml ) could be used
to maintain information pertaining to which nodefiles
the gametree uses and their relative positioning within
the gametree.
[userhome]/openrpg2/config: contains users configuration files
[userhome]/openrpg2/map: contains user created map files
[userhome]/openrpg2/files: contains 'shareable' files
(assuming peer to peer file transfers
are one day a reality) Temporary
subdirectory would be for peer to
peer miniature/map backgroun sharing
and would be used to store images
retrieved from other users
[userhome]/openrpg2/log: contains gamelogs and user-spawned
server logs
|
|
From: <sn...@ga...> - 2004-05-24 21:44:54
|
> I like your original way of doing it. We just have to think about how to > package the modules. Just my thought. > > Tom Maybe if we distributed add on modules as ZIP files then had a generic utility application (or an ORPG2 integrated feature) to unpack and install the new modules where they should go. I just want to make sure we make ORPG2 as user friendly as possible and hide as much of the technical aspect from the "everyday joe" as possible. |
|
From: Baleno <tb...@wr...> - 2004-05-24 21:26:29
|
I like your original way of doing it. We just have to think about how to package the modules. Just my thought. Tom > sn...@ga... wrote: > >>I just responded to snowdog's message on the list and then I noticed I > >>got a reply from him before my message showed up on the list. A quick > >>review of the message headers showed that Reply-To was not set for > >>messages to this list. > >> > >>Could this be changed? > >> > >>Thanks. > >> > > > > > > I set the redirects to the list address. > > Thanks again. > > If you feel there was anything else productive in my responses to your > earlier posts, feel free to repost it here... Half the time I have no > idea what I'm talking about, so maybe it was all just total blather, I > dunno. > > (I'll shut up now.) > > >> Mark > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Openrpg-v2-dev mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openrpg-v2-dev |
|
From: Mark T. <ma...@ly...> - 2004-05-24 18:38:44
|
sn...@ga... wrote: >>I just responded to snowdog's message on the list and then I noticed I >>got a reply from him before my message showed up on the list. A quick >>review of the message headers showed that Reply-To was not set for >>messages to this list. >> >>Could this be changed? >> >>Thanks. >> > > > I set the redirects to the list address. Thanks again. If you feel there was anything else productive in my responses to your earlier posts, feel free to repost it here... Half the time I have no idea what I'm talking about, so maybe it was all just total blather, I dunno. (I'll shut up now.) >> Mark |
|
From: <sn...@ga...> - 2004-05-24 18:30:53
|
> I just responded to snowdog's message on the list and then I noticed I > got a reply from him before my message showed up on the list. A quick > review of the message headers showed that Reply-To was not set for > messages to this list. > > Could this be changed? > > Thanks. > I set the redirects to the list address. |
|
From: Mark T. <ma...@ly...> - 2004-05-24 18:15:27
|
I just responded to snowdog's message on the list and then I noticed I got a reply from him before my message showed up on the list. A quick review of the message headers showed that Reply-To was not set for messages to this list. Could this be changed? Thanks. >> Mark |
|
From: <sn...@ga...> - 2004-05-24 16:39:52
|
Submitted for peer review and commenting.
-------------------------------------------------------------------------------------------------------
Project: OpenRPG 2
Topic: Network Message Structure
Author: Snowdog
Date: May 19, 2004
The following document details the network message structure for the OpenRPG2
project.
The design for the OpenRPG2 network messages separates the data component of a
message from the network routing information of the message. A short message
header will detail information about the message type and routing in such a way that the
OpenRPG server(s) can route the network message properly even if the server itself is
not able to understand, parse, or otherwise decode the message itself.
Message Structure:
[A][B][C ...][D ...]
A: Overall message length in bytes [32 bit integer]
(sum length of components B, C and D)
B: Header Length in bytes [32 bit integer]
C: Header [XML string]
D: Data Segment [message dependent format]
Detail of Header structure
Format: <HDR ID="X" TO="#,#,#">
==> Element "ID"
This is the identifier of the message type. This identifier will determine what "module"
the message is routed to on the client/server for processing. This element is required.
==> Element "TO"
This is a comma separated list of client IDs to which the message should be sent.
Servers without a module to support the ID TYPE of the message will automatically
route the message though to the clients specified in the TO element. Servers with a
module capable of handling messages with this ID TYPE will process the message first
and the TO element may be overridden by the server by the processing module. A
missing TO element in the header will cause the server to discard (ignore) the
message. A blank TO element designates a message intended only for the server and
should not be relayed; if the server cannot handle the message ID TYPE intended for
the server the message will be discarded (ignored). Special descriptors in the TO
column could be used to simplify addressing such as "ALL", "GROUP", "ADMIN",
"MOD", etc. to specify special addressing conditions like sending message to ALL
members of a server, an entire GROUP on a server, all administrators on a server, or
all moderators on a server.
|
|
From: <sn...@ga...> - 2004-05-24 16:36:29
|
Ok, people.. in preparing design documentation for the revised ORPG2
project I'm coming across some possible design level changes that
should
be hashed out before we commence work on ORPG2.
ORPG2 Module Implementation In Java
One problem with the design of OpenRPG2 is that the various layers
each
require separate module objects to function properly. While this modular
structure affords good object/task abstraction OOD/OOP wise it could
cause
problems in distribution. The problem would be in distributing the
modules
to end users as each new "module" would need to be added as a
separate
entity to the users code base. Would a single unit distrobution method
be
better?
Java Packages (.jar) offer the needed encapsulation should we choose
to go
that route.. Wrapping each trio of modules (Translation, Command, and
GUI)
into the same package file allows a single drop in unit.
So.. my question to the rest of you is, should we stick with the original
separated design to allow easy swapout of a given layers module or
should
we rework the design to compartmentalize the trio of modules into a
single
drop in unit to make client side useage easier?
(the following diagrams should be viewed with a fixed width font like
courier)
original design:
ORPG2-+
|
+-- translation layer --+
| |
| +-- Module 1 Translation Object
| |
| +-- Module 2 Translation Object
| |
| +-- Module n Translation Object
|
+-- command layer ------+
| |
| +-- Module 1 Command Object
| |
| +-- Module 2 Command Object
| |
| +-- Module n Command Object
|
+-- Interface layer ----+
|
+-- Module 1 Interface Object
|
+-- Module 2 Interface Object
|
+-- Module n Interface Object
proposed design:
ORPG2-+
|
+-- translation layer --+
| |
+-- command layer ------+
| |
+-- Interface layer ----+
|
+-- Module 1 --+
| |
| +-- Translation Object
| |
| +-- Command Object
| |
| +-- Interface Object
|
+-- Module 2 --+
| |
| +-- Translation Object
| |
| +-- Command Object
| |
| +-- Interface Object
|
+-- Module n --+
|
+-- Translation Object
|
+-- Command Object
|
+-- Interface Object
|
|
From: Mark T. <ma...@ly...> - 2004-05-19 02:24:50
|
subscribe |
|
From: Ben Collins-S. <su...@re...> - 2004-05-18 21:29:27
|
Is this thing on? |