[Ohrrpgce] (no subject)

[James Paige]

On Fri, Jan 30, 2009 at 03:35:54PM -0800, Jay Tennant wrote:
>    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?

All this seems like good design for a game engine in general, but I 
really see absolutely nothing OHRRPGCE-specific in this plan. This could 
just as easily be a design for any game.

---
James Paige