[Ohrrpgce] Proposed port to c++

[Ralph Versteegen]

2009/1/31 Jay Tennant <hierandel8 at crazyleafgames.com>:
>
> Sorry, I accidentally sent a (no subject) mail. Here is the email again:
>
> 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?

Not sure if this is what you meant, but you could just use a dummy
audio component instead, so you can always rely on an audio renderer
being present. That's how the OHR's audio and graphics backends work,
and has worked very well and saved us many, many times. Of course, the
backends are only selectable at compile time, and I get the idea that
you're talking about runtime?

>
> 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?

Ah, yes. I didn't realise you were talking about the interpreter. That
all sounds reasonable. It would indeed be a good idea to separate it
since it looks like there could be several available interpreters.
However it wouldn't be necessary to use it for the purpose you
mention; the OHR interpreter will have to be able to handle any legacy
scripts and emulate any required bugs.

Mike did suggest plotscripting plugins, this isn't an official plan but an idea:
http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_plotscripting_plugins

> 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?

By file you mean module? There are many dirty details to wrap when
going from state -> save file and back again, such as what should be
saved (I anticipate eventually there being settings to produce much
better save files containing the state of all maps and even the
currently running scripts), and scripts can also manipulate save
files.
I think how far you want to separate out save files depends on the
save file format. IM wants, I think, to support the current OHR SAV
format, which is probably far worse than any of the file formats used
in RPG games. I don't really see why he has to, though. I hope we get
around to switching format really soon. The cleanest way to implement
that format is probably to write the loading/saving code far away from
everything else. Except I'm told this breaks OO principles (grr...)

On the other hand, the most natural way to read and write the new
format would be (naturally) for every class, such as shops, to read
and write its own data.

> 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?

The OHR has a fair amount of graphics related code, but the truth is,
it shouldn't. Other graphics libraries (fbgfx, SDL, Allegro) could do
more, and we could have much thinner wrappers around them.

All your modules except for player/editor and IO just seems like
wrappers around libraries from here, meaning rather little is being
designed at the moment.


If I were to rewrite Game AND Custom, and knew that my most ambitious
plans would succeed, I would plan ahead for the many features which
would be very difficult otherwise, like your network abstraction idea:

Firstly, I'd want to (eventually) be able to edit and play a game at
the same time. Playtest your game, discover an NPC doesn't call the
right script, fix it in the map editor and reload either the whole
map, or to be really ambitious, just the script setting on that NPC.
Also, editing the current game state without touching the RPG file.
In fact, why not run multiple playtesting instances of the same game at once.
Similarly, to extend editedit, it would be great to edit the editors
menus while using it. This would be very convenient for creating a
translation. Oh yes, the editor should support language packs as well.
Collaborating on games is quite annoying at the moment, there are no
tools aside from ohrgfx, or support in Custom. If two people make
changes to the same copy of a game, the changes can be impossible to
merge except by copying by hand. Instead, the editor could load two
games are once, compare them, display the differences to the user
perhaps as a list or a special editing mode which affects all menus
(???). Plus integrated support for version control.

To achieve all this, I suppose I'd want to split the editor into small
pieces, especially divorcing the interface from the data. A one to one
correspondence between data in the file formats and menu items in the
editors is, in my opinion, the biggest problem with Custom. A separate
module responsible for drawing menus and letting the user interact
with them would allow translations and multiple front ends to the
editor to be developed, or even modified during use as described.

The state of the game player would also have to be highly manipulable
by means other than playing the game, and the source RPG data also
abstracted.
As pointed out by James, C++ isn't a very convenient language to do
this sort of thing, you'd want something more powerful (scripted and
polymorphic).

However, that was all just an exercise in designing for extensibility,
and you'd be crazy to put all of that in the spec (maybe some of it
could sneak in).

The reoccurring theme throughout the entire time I've used the OHR,
from long before the source was available, has been about working out
how to overcome flaws: missing engine features, bugs, the real mode
memory limitation, creating a DOS version with sound effects, hacking
strings and arrays onto hamsterspeak, adding features to and
maintaining appalling code with no objects and mode X graphics, the
limits of first QuickBasic and then FreeBASIC, buggy libraries and
worst of all backwards compatibility. Figuring out how to implement
the above features with a minimal of rewriting is the sort of
challenge I expect to face. It can be done, much more possible than
you'd think, but at some point it's obviously less trouble to rewrite.