[Ohrrpgce] (no subject)

[Jay Tennant]

TMC, you wrote 1/29/09:
On request (on CP), a look at your modules:

Designing a program starting from the very top, the classes, seems a
bit crazy to me. I've never focused that much on the object orientated
mindset. So I'm really a bit lost as to what the goal of this part of
your design process is, or what exactly the distinction between a
class and a module is.

Wouldn't "Game Player" end up containing nearly the whole engine? I
guess that wasn't your intent since you've listed Editor and Player,
and a lot of the logic would be attached to objects (like NPCs) in
common between them.

BTW, here is the Class List for the OHR++:
http://ohrpp.castleparadox.com/docs/annotated.html
Is this just what you were thinking of?

Why's Plotscript singled out but not Shop, Map, Enemy, Formation,
Attack, NPC, Hero...?

Also, think about abstraction of RPG files, assuming that 'File IO'
mean generic IO. Have you looked at the RPG format at all?
http://gilgamesh.dnsalias.org:8080/wiki/ohrrpgce/index.php/RPG_format
Games can be either lumped or unlumped (files in a folder) Lumps come
in a few different formats, though the data itself is usually a pretty
simple stream of integers and strings. The BINSIZE.BIN lump and
ARCHINYM.LMP affect how/which other lumps are loaded, and FIXBITS.BIN
is used to figure out how the game needs to be upgraded.

Also, what about save games?
End of Quote

The distinction between a class and a module is that a module can be a class, or many classes. The design approach is defining the modules, not the classes, that are to make up the system. After the modules have been determined, the classes will start being defined. However, they will not be coded until the module's classes are finished being designed. This is supposedly a very efficient method of construction. I think I may have caused confusion because earlier in the CP posts I petitioned a class design list, which works against this modular design approach.

Game player, and the Game editor module, are not the full engine. They receive data and inputs, and issue higher level commands to the other modules to accomplish some task. Therefore, a full engine would be the connecting of all the modules. I think the modules should attempt to run without connecting to the others, which would allow for the singling out of certain modules, such as not using an Audio renderer yet still running the rest of the modules. What do you think of this?

The OHR++ is similar in design. However, there are fundamental differences relating to the modular architecture. I'm sure certain classes could be used.

The reason I singled out Plotscripting was because I felt this might be an object to receive more upgrades than the others. Furthermore, in the event that an old RPG game was run, an older Plotscripting module could run. (This means games dependent on the plotscript bugs would function as intended.) Perhaps the Plotscripting module could be extensible? (I don't see a reason for it, but who knows?) The other items you mentioned after the Plotscripting module stand out as classes. I feel they are necessary classes, but not separate enough to warrant another module. What are your thoughts?

I liked the points mentioned about the File IO. Such handlers would be excellent to use in that module, including the save games. Do you think saved games should be in a separate file?

It may be easier to picture the design as a graph of filters. A source filter (such as File IO and HID) pushes data through the central filter (the editor or player and Surface), and then is pushed through the appropriate rendering filter (audio / video renderer). You can see a diagram of the design at http://www.castleparadox.com/ohr/viewtopic.php?t=6115&start=15. What's your take on design? How would you approach the situation?


__________________________________________________
D O T E A S Y - "Join the web hosting revolution!"
             http://www.doteasy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20090130/a5e69ada/attachment-0002.htm>