Castle Paradox

[TMC]

[Bob the Hamster]

Maybe slightly off-topic, but if I wanted to re-write custom from scratch (not saying I do) I would start with David Gower's ohrrpgce.py, and then I would implement something very similar to 'Plan for an Editor Editor' using pygame.

[TMC]

Just pygame? Minimal GUI elements?

How about we meet halfway: write editedit in whichever language you care to (and you could even generate either python or FB code) and create new menus in Python using ohrrpgce.py and an ohrrpgce-custom module, embedded in FB-Custom, which continues to handle all the menus and upgrade routines, etc, noone cares to rewrite.

Hmm, instead of rewriting half and adding a bucket of glue, rewriting all probably wouldn't be more work.
_________________
"It is so great it is insanely great."

[Bob the Hamster]

[Hieran_Del8]

I should clarify the design approach. It is drastically different from the previous approaches. Here was the proposed list for the modules for handling the reconstructed system:

File IO
Plotscript
Window
Graphic Renderer
Surfaces (most everything is a surface, and surfaces may be rendered differently in different OS's, etc.)
Audio Renderer
Human Interface Devices
{
Mouse
Keyboard
Other
}
Game Editor
Game Player
Network (in case of multiplayer, or streaming file IO over a network, or streaming other modules?)

The goal of the modular design is for maximum compatibility. It allows for faster deployment and upgrade. It allows a content-driven approach, and a team implementation focus. A brief explanation of the design:

1. File IO
This module is responsible for opening files, reading data (perhaps interpreted to a newer version for compatibility), and writing data. It represents the module interface with the file system. It is not restricted to resident files. Perhaps the files are streamed over the internet, etc. The file system module can be arranged for whatever system the module is ported for. In this way, the calling module retrieves the data it is expecting, no matter what source system.

2. Plotscript
This module represents the plotscript interpreter. This module can be updated and added to the system to allow for easier upgrades to the plotscripting system (no overhead of rewriting the custom.exe or game.exe).

3. Window
Represents the window that the modules request to work with. The window module handles all necessary interfaces and messages, perhaps using callbacks to the proper modules. The calling modules do not need to know what sort of window system they are interfacing with.

4. Graphic renderer
The graphical rendering system. This receives data supplied to it (or calls to certain interfaces) and translates it into a rendered graphic for display on whatever system. The calling modules (ie. Game editor or Game player) do not need to know the specifics of the rendering. They just supply data and issue high-level commands.

5. Surfaces
The surface module encapsulates a surface, including possibly its dimensions, color data, format, pallette, etc. The Surface module is called to allocate and manage surface resources, such as sprites, tilesets, etc. This module works mostly with the File IO and Graphic renderer. The Game editor and Game player modules will issue higher level commands for utilizing surfaces via the Surface module. The only reasons I mentioned a separate surface module is because of compatibility and the fact that most data within the editor and player is a surface.

6. Audio renderer
The audio rendering system. This module is similar in design to the Graphic renderer module. Perhaps a submodule could be built that encapsulates a sound stream?

7. Human Interface Devices, including Mouse, Keyboard, and Other
Manages input from some outside source to the editor and player modules. Purpose is to allow for the case that, say, a bluetooth device (ie. cellphone) can register as a valid input for those said modules. Perhaps a joystick wants to be used? Maybe one of those drawing pads? In any case, it translates the input to valid calls to the other systems.

8. Game editor
A data management system responsible for issuing high level calls and managing high level interfaces (the other modules) for building the game data. This does not include a GUI system. It is strictly the data management. Perhaps a GUI could be another module?

9. Game player
Data management for issuing calls and managing high level interfaces, for playing the game data. A different GUI module (perhaps different from the editor's GUI module) could be proposed.

10. Network
An afterthought. Perhaps multiplayer support could be added to the games. Maybe server data could be streamed to the games (ie. high scores, user messages, mmo?). Another usage includes streaming other modules. Perhaps the File IO module actually interfaces across a network (like playing a game from a website without downloading the game.) Maybe other modules could be streamed (for updating purposes, or allowing a user to select the modules they prefer?) An after-afterthought: perhaps all the modules could be streamed. (Effectively, this is like amd-ati's new fusion concept.)

This is a highly modular design. It takes the rendering, surface management, GUI, file IO, plotscripting, etc. completely out of the hands of the editor and player. Again, this allows for faster deployment and upgrade. It allows a content-driven approach, and a team implementation focus.

TMC: The only editors I've built have been keyboard driven, as the first good one was QBasic, and the second good one was C++ with directX. Btw, I'm using "good" in a relative sense to other editors I've built. This is the first editor I'm working with such an object-oriented approach. I've built modules in this object oriented approach, but never an editor. As long as the design phase works out the high-level kinks, the coding will be a breeze.

[Inferior Minion]

[Hieran_Del8]

Inferior Minion:
I see. The framework is very similar. It may be advantageous to continue work on the OHR++ instead of rebuilding. However, there are certain differences in design.

I broke the Window, Graphic renderer, HID, Game player, and the GUI filter into separate components instead of combining them into a single module. I would sow them together in an application, but it is intentionally separate here for modularity. A diagram illustrates the connections between the modules.

*The component labelled "Editor" and "Player" is exclusively the Game editor or the Game player. Both modules cannot run simultaneously.

The benefit for breaking the items into separate components is easier upgrades and a more diverse set of plugin customization. The downside is there are more modules. What are your thoughts on that?

The design of the Game editor and Game player modules allow them to strictly manage data and make high-level interface calls. They currently are not designed to pair with a window. They can work with windows indirectly (through the chain of modules to the Window module), but it would be unnecessary. The editor and player are designed to interpret data from a user, the files, and a GUI filter. (The GUI filter seems to be in a slightly wrong place, btw. It seems to be missing something.) What are your thoughts on this design?

Regarding the Network module, perhaps it could fit roughly like so:

*where any resident modules would bypass the Network interface. If the Graphic Renderer module is being streamed, the Window module would still need to be resident. However, it would render the graphic in a simple stream blit.

Honestly, I only included the Network module for theory and experimentation. It would be neat to implement, but I think the design needs tweaking. What do you think?

The last two modules you mentioned (rpg and internal) are necessary. Interestingly, through the current design, they are already implemented through the editor/player modules. Those modules specifically handle only data, user input, and a GUI filter. They would manage the states, etc. This is slightly different from the OHR++ modular design because these modules are not Window subclasses.

Another note: these modules are not classes necessarily. Instead, several classes/structs/objects will make up each module. I'm sure this is similar to OHR++ in that regard. (I will analyze it in more detail.) What are your thoughts on this design?

[TMC]

[TMC]

Sorry for the late reply.

I've already commented on a lot of your modules on the mailing list.

[Bob the Hamster]

[Newbie_Power]

During playtesting of my own game, I had attempted to use a game pad with dual analog joysticks, and the analog joystick was uber sensitive to where barely moving it would cause menu items to scroll too quickly.

Button pressing was also uber sensitive. During calibration it accidentally set both "OK" and "Cancel" to the same button, and I was prohibited from bringing up the calibration screen to re-assign the buttons.
_________________

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?

[TMC]

[Hieran_Del8]

TMC:
Excellent ideas! I read through the comments on CP and the mailing list and began compiling a new diagram to represent the connections. Here it is:

The Network module now is an extension of the File IO. Therefore, if the file is on a server, or parts of data are from the server, then they are streamed. Otherwise, the Network module is transparent.

From your suggestion about editing the file while playing the game, the editor is now an extension of the player. Therefore, if a file is editable, a player can modify the game, save changes, and return to the game. (Password protection still applies for whether a file is editable.)

I'm having difficulty connecting the renderers and the HID to the rest of the modules via the GUI system. I know a GUI system should be mediating somehow, but I'm not sure if this is the correct implementation. Mental block. Some of that may be due in part to an incomplete understanding of a GUI system. Please comment on this.

The idea's been tossed around that multiple languages could be used, and that "glue code" would hold it together. Understanding how that is to be used will become important once the design reaches phase 3. How are multiple languages currently "glued" together? (I've only used c++ calling a full module, not the module's functions.)

[Hieran_Del8]

Been researching foreign function interfaces (FFI) for gluing code. Are you guys using SWIG, or do you use an interface definition language (IDL)? Or are you linking by other means? Or are you bribing the little gnomes that press the buttons and switch the levers in the computer case with various grades of cheese?

If there aren't any further thoughts on the design phase 1, phase 2 can begin. Specific class definitions can start taking shape. I'll be compiling all comments related to the design into some uniform layout. Please comment, though, on the design if you have another idea, perspective, or criticism.

[Bob the Hamster]

Definitely the Gnomes & Cheese one.