Castle Paradox

[TMC]

Another late reply. I had a reply typed out the other day, and then my browser crashed.

Just let me point out again that if you want to start over and rewrite the OHR from scratch in C++, you're likely to have some trouble recruiting people because it'll be pretty depressing. However considering your modules and the OHR's existing code, I think that the OHR would benefit from having the equivalent of several of your proposed modules rewritten from scratch. It *might* be possible to replace them with pure OO C++. In fact, just about everything except Player, Editor, and Audio. Our music backends have problems, but improving on them doesn't seem likely. If you/we do write just some of these modules, to slot into the existing OHR (or even OHR++), you can always do the rest later as well if you feel up to it.

However, the only thing I care to focus on is the graphics backend/HID/GUI.

[Hieran_Del8]

Indeed! Those are some major flaws. Thankyou for pointing them out TMC!

The suggestion that the Surfaces and Video renderer are two halves of the same module are reasonable. The design should be adjusted so that both components are contained within a singular module, ie. Graphics. It would load the surface types from the file IO and manage their allocations and rendering.

The same could be applied to Sounds and Audio renderer, ie. Sounds.

Finally, the GUI. I've been researching GUI systems quite a bit now. I understand the concepts a little better, and IM's presentation was quite a good approach in OHR++. The Graphics module should probably be contained within the GUI. It would be nice if the GUI's layout was customizable (as in James's editedit suggestion). Also the HID would be contained in the GUI. As regards the Window module, that may need to be wrapped inside the Graphics module. Callbacks could ensure that basic window functions (including window menus) are still executed in the GUI. I still feel the Game editor and player should be separate from the GUI as they represent strict data management and high level commands.

With regards the editor being wrapped inside the player, it is a valid argument. This is how Torque3D wraps their editor--inside the player. Interestingly, in Torque's design, game state could still be present in the editor.

Essentially, the design now appears as:


In studying Torque, as well as many other Networkable engines, a simple game is broken into a Server and Clients. Even if the game is single player, both Server and Client operate on the same system. This design allows for easy extension from single player to multiplayer to mmo. This technology can extend to both playing of the games and editing the games. Imagine a team of developers (with different layers of authority) being able to edit a game simultaneously. At the same time, other users could play the game, receiving streamed updates to seamlessly integrate the changes.

In studying Javascript, and Javascript in ASP, it is of benefit to consider both client side and server side scripting, that is plotscripting. Perhaps certain plotscripts would run on the server, such as global events, time, weather, new random quests, etc. Then client side plotscripting would run local events, such as battles, vehicles, npc interaction, story, etc.

Those elements would be neat to integrate. What do you think?

With regards approaching "phase 3", I'll clarify. I used a design model which broke the design into 3 separate phases: brain storming, modular concepts, and implementation. I mistakenly reported this development in the first phase whereas the current development was in the second. I suppose the ideas are mostly established in the current OHR. I believe I did not give ample consideration to the brain storm phase, however. This, compounded by a unclear understanding of certain programming principles (ie. GUI, FFI, etc.), has led to backwards development and confusion at my fault.

To correctly put it, we should probably still be just about into phase 2: modular concepts. And then the implementation. However, there's still room for brain storming!

Quite a bit of brainstorming has already occurred in the OHR development plans. I'll continue reading through the development plans. What other thoughts do you have with regards the design (brainstorming or modular concept)?

[Hieran_Del8]

Well, just finished Lesley Anne Robertson's Simple Program Design: A Step-by-Step Approach, and found a better method for program design.

To summarize the book in 6 statements:

1. Define the problem (what to do, not how to do)
2. Group activities into subtasks or functions (top level subtasks)
3. Construct a hierarchy chart (modules, and relation to each other)
4. Establish logic of the main line (initialize, main loop, close)
5. Develop psuedocode for each successive module in hierarchy (top level working downwards)
6. Desk check the solution algorithm for each module/function

This design mechanism came highly recommended. And the book was very persuasive in its usage for large projects.

OHR wiki has many entries that define the problems and group activities into high level functions. Is there a database of all the features of the current OHRRPGCE and OHR Game?

[Bob the Hamster]

[Battleblaze]

You all realize that if the easy to usenes sof OHR had MMO creation capability the world would break and the HamsterRepublic would resume its once great and terrible rule over the earths (free) game creation engines.

Also OHR Land...Online.

Shudders of awesomeness. There could be a real in game HamsterRepublic. I could get real estate in Lord Hasims old Kingdom. We could have live oHR house...(goes off imagining)
_________________
Indy OHR! and National OHR Month Contest going on now!

"Aeth calls PHC an anti-semite; PHC blames anti-semitism"
-squall

[Newbie_Power]

You all realize that if the easy to usenes sof OHR had MMO creation capability the world would break and the HamsterRepublic would resume its once great and terrible rule over the earths (free) game creation engines.

If the OHR could make MMOs, we would likely create the greatest MMO ever since we could just get rid of glaring flaws MMOs tend to have.
_________________

TheGiz> Am I the only one who likes to imagine that Elijah Wood's character in Back to the Future 2, the kid at the Wild Gunman machine in the Cafe 80's, is some future descendant of the AVGN?

[Battleblaze]

And then there would eventually be soemthing equivalent to AFENHOUSE ONLINE FURREVAR
_________________
Indy OHR! and National OHR Month Contest going on now!

"Aeth calls PHC an anti-semite; PHC blames anti-semitism"
-squall

[Hieran_Del8]

Regarding mmo, that would be cool.

For dynamic linking, I am a bit confused as to freebasic's usage. For instance:

[Bob the Hamster]

I have never done runtime linking to a dll in FreeBasic, but I think the command you want is DYLIBLOAD

You can't do it in QuickBasic 4.5 That is a 16 bit compiler.

[Hieran_Del8]

Well, as it turns out, rewriting is a little too ambitious right now. So I've turned my attentions to a freebasic to c++ converter.

TMC, I know you've done work on that. I'm currently working data management, including data representation, scope, threading, etc. Soon, I'll be ready to begin functions and commands. What sort of work have you done?

Some of the code is available at http://www.crazyleafgames.com/miscWork.htm under the programming division, under the heading "General Interpreter". I still need to give the DataObjectBase class a reference count (like COM) to remove itself when references drop.

If you've already done work, I'd much rather collaborate than build it by myself.

[TMC]

~delay delay delay~ (I'm sorry)

[TMC]

[Hieran_Del8]

Well, it's not an FB interpreter, per se. Eventually, it's supposed to convert code into a generic language of data types and commands. Those can either be interpreted or converted into a target language.

I do plan to emulate threads, and yes, it is terribly inefficient if it runs as an interpreter. A struct template is a struct definition. It is not a structure instance, just the definition.

I have never used a parser generator before. Site visited, interesting, I'll study peg/leg more.

I was intimidated by the translation mechanisms and files at the repository. Probably study those after I have a better understanding about what is happening.

Regarding the GUI wrapper, that's pretty neat. It was rather difficult to read through the files, and some of the classes I couldn't locate. Could you rewrite/reorganize them to be broken into modules, then linking them together? Currently, such as in the w.cpp, source code files are linked together, as in:

[TMC]

Hahah. Don't worry, I'm not some sort of cave programmer who doesn't know about header files. I just did that because the windows computer I was using is pretty slow, the wxwidgets headers are enormous, and I couldn't get gcc to successfully precompile them. Early on, heavy experimentation means I would probably have to recompile several modules every time.

Anyway, the code is stabilising (I've been picking at it in some form since last year) so I think I'll add headers next time I work on it. Also, like I said, I'll diagram the structure/operation of the program and post it here when I get around to it.

[Hieran_Del8]