Hi matty,
I didn't read your post as a rant and I do understand your concerns. Hopefully I can answer some of them without making things more confusing then they already are.
Quote: "Are Gizmos GUI entities, or were they at one point?
Do they now control everything 2D relating to games, sprites etc?"
Yes to both questions, but, I prefer the term Interactive Entity. Gizmos are 2D/3D Collision Bodies that use Finite State Machine Logic to determine Event State based on collision detection and device input. Event States determine
interactive behavior and execute a scripted
actions. Gizmos can be assigned a Sprite (2D/3D) to visually represent their state and provide mechanisms to control how to the Sprite is displayed. The camera (Canvas) is also part of MAUI, however, to minimize confusion I'll focus on Gizmos.
Quote: "After our last brainstorming session I come away thinking, great, MAUI will take care of all 2D/3D entity relationships and everything will be taken from there as we move forward.
Now I'm thinking MAUI should inherit from a broader set of classes which make up all major components/entities of S3GE."
I'm not sure what you mean by 2D/3D entity relationships, considering we can do anything in 3D. MAUI is powered by the same core systems (ie: physics, particles, solvers, network, etc) other game entities use. Either a Game Entity will will be controlled by some form of AI or User control. If it requires User control or Event-driven Interactivity, a Gizmo can be used as the base object. Its all about Collision, Collision, and more Collision. MAUI collision detection is powered by a 2D and 3D Physics Engine: Box2D and Fulcrum (Physx). These engines provide both high performance collision detection and physics simulation. I also have the option of using a procedural solution. These are complex systems and to make my life easier in the future I'm integrating them now.
Quote: "That said, I don't understand MAUI enough at this point to have a definite strategy which brings me to the idea that maybe we need some UML class diagrams, its too hard and time consuming to go through all that code to try and work out the relationships between MAUI objects."
I like diagrams and I'm all for UML class diagrams, what ever those maybe - lol. Perhaps the diagram above can show the relationships better. MAUI consolidates Interactive Object and User Input (IOU). For example, Dragging a pointer and clicking on 2D Gizmo involves the similar methods required to move a 3D Character and tripping a Event Trigger. Both
user interfaces incorporate a input device, collision, timing to determine events and execute action scripts based on such events. MAUI is designed to consolidate and manage these types of interactions.
I'm concentrating my efforts on getting MAUI functional as a 2D/3D GUI in the typical sense so we can start developing applications with it. Sure, I could have went with a GUI Lib such as
GLO, however I desired 3D Mesh-based Gizmos, Animation, and many other features. I abandoned the DBPro port in favor of a complete rewrite due to the flexibility of C++. I'm relatively new to C++, so it has been a time-consuming challenge in re-writing it, but, I'm making progress. So far, I've integrated LUA, Box2D, IrrXML Libs, and making room for Fulcrum, BitmapFont, XBox360 & Wii Controllers, and Sound Libs.
Quote: "I know we have your original diagram which gives us a broad overview of whats involved but we don't have any documentation on how the engine is/will-be constructed in detail."
This forum is serving as a living document. There are simply too many unknowns and not enough experience to have a full-blown document. However, there are plenty of Game Engines already developed to model our Engine Design from. We already know we need rendering optimization systems, pathfinding, physics, GUIs, etc. Its just matter of selecting or developing them, integrating them, and building higher level systems on top of them. MAUI is one step in that direction.
Quote: "Also, when you say this engine may be a base for other game engines, are we conceding that an all-in-one engine may be impossible due to critical decisions that have to be made along the way which might make it good for some game genres but not good for others?"
The engine is free and open source, thus can serve as the base for other game engines. I have no doubt in my mind that a all-in-one game engine can be developed to support the
basic game mechanics that define a particular genre. To achieve this we identify the common systems and consolidate them. Consolidate, Consolidate, Consolidate, did I mention Consolidate? Consolidation of low level system should simplify consolidating higher level systems. Of course, there are no guarantees, but, there's plenty of evidence in the real-world to support my reasoning. I'm sorta developing backwards, starting with the most complex systems and working downward. My logic is that if i can get the complex system working it can be used to support simpler systems.
Another area for consolidation is in the construction of 3D Entities. Entity assembly and customization is popular in RPGs, Racing Games, etc. I believe that any 3D game can benefit from Entity Assembly (even if customization is not required). The premise is simple: model parts and assemble many entity variations with them. I was designing the Modular Entity Construction System for this very reason. MECS is a System of Parts and Connectors, with Channelized Image Maps (Texture & Shaders), and a Standardized Bone Animation scheme. Its inspired by the Toy Construction Sets such as (Meccano, Tinker Toys, KNEX, Legos) and assembles Non-Animated/Animated Game Entities in a hierarchal fashion. Use MECS to produce a library of pre-assembled entities or to customize the entities within the game world by integrating the Entity Assembler Application as Entity Customizer (developed with MAUI).
The are so many areas for consolidation. How about simply consolidating where data and media is stored. I proposed a centralized Data/Media Repository for this purpose. Storing media and data in central location would simplify accessibility to developers using the Engine, and access for game client to download game content. I could go on about consolidation, but, I'll save discussion on this for a later day.
