All topics are a leaf of some component. What I found when searching is the basic components that make up a game engine are specific to the engine itself. No two engines refer back to the same basic components.
There is some overlap that was obvious like,
@asser_fahrenholz I am not sure so thats why I ask, what component would it fall under if its not a component itself?
As @oxplay2 says, Rendering vs Graphics. So Graphics should be a component as listed and remove rendering.
A module can be looked at as a Book. The topics are chapters in that book. No two modules/books contain the same topics.
It is extremely subjective as your post helps to illustrate. Try searching on 3d game architecture and see what you get. Everything is specific to the engine itself.
Having one module is what we have now. Everything is lumped into this one module. If all we were going to do is use this one module then what was the use in converting to a modular system in the first place?
So to summarize your thoughts, these are the core components of the jme engine.
I really like the detail given in your post but I am surprised you list physics as a topic/chapter rather than a component/book given you have a complete site built around this one subject. That is one thing all engines had listed as a component, physics.
As I mentioned before, I was not sure how to word this properly so maybe this will help clear things up. I know it may seem like a trivial matter, but it is very important to get this right.
That’s a nice analogy, but it doesn’t help us decide how to divide the wiki into modules. Paper publications are split into books for reasons that are irrelevant to a website. Once we understand what modules are for, I suspect the answer to your question will be clear.
You’d know better than I would! Your post indicated a desire to have offsite modules maintained by independent owners. If that’s what modules are for, then perhaps modularization should be based on repositories and/or owners.
That’s an interesting point. Actually my website consists of 2 modules. There’s a “minie-library-tutorial” module that walks you through using the Minie physics library in a JMonkeyEngine game, and then there’s a “ROOT” module for all other aspects of the Minie Project. My thought was that all the “minie-library-tutorial” topics would eventually be shared between my site and the JMonkeyEngine wiki, while the “ROOT” topics would not be shared.
Modules are an organizational method that are intended to hold topics that only apply to the module they live in. When done right, it should be intuitive for a contributor to know where a topic should live. If we match the engine design, this will occur naturally. The wiki will have a certain flow that just feels right. Maybe this will lead to more contributors. This will also help expose where we have holes in content that need to be filled.
For a physics module example, physics related topics and the module itself match a specific design element of the engine. The goal is simplification when adding, removing or editing content. We want the relationship to be obvious.
Take sound. We know this module represents something specific to the engine architecture, thats an easy one.
As was pointed out though, we have rendering and graphics. Is terrain one or the other or should Graphics be all encompassing, including filters, shadow and light? When looking at the engine source, there are terrain, lwgl and gui modules. Do all these have a common element that they spring from? If not then they should be components themselves.
In your use of I/O you lump networking in yet other engines consider that a module all in and of itself. This is the reason I brought this up. Those who are arms deep in the engine guts know best about the core design, not me.
I want to narrow each module down to what makes the most sense, the lowest common denominator so to speak.
In the case of physics, there’s a very clear division between what’s physics and what isn’t. So clear that the physics code could be moved to a separate repo and released on its own schedule, as I’m doing with Minie. The independent release numbering implies to me that Minie physics, at least, has to be a separate module.
With sound, I don’t think it’s so clear. Sound-related code is found in at least 5 Engine libraries: jme3-core, jme3-jogg, jme3-android, jme3-android-native, and jme3-nifty. If you modularized the documentation based on the Engine architecture, you might wind up with audio documentation in 5 different modules, which wouldn’t make things easy for contributors.