+ Alpha and Beta Stages of Orryx would be proposed separately. Until the end of the Stage, + its proposal would be held Provisional. +
++ In Alpha Stage, versions are under the theme of "Basis of Basics", with the major version zero. + During this Stage, no storage systems and customizations would be implemented, but rather + demonstrations of basic mechanisms of Orryx. This is unlike demo testing. +
++ All versions are incremented only on the minor version in the Primary Version, starting from + version 0.0.1. +
++ Demonstration may be basically based on physics implementation of Simple Terra with certain + extra features to interact with the World. At least, some functionalities should have been + available in this version. +
++ Random bodies may be generated to test for collisions and various features. Those bodies may + resemble certain kinds of Tiles and Entities. Players may control a sphere around the World. + For bodies, it may be possible to test for mechanisms for continuous Tiles in physics. + Tiles may be kinematic to be static for other moving bodies. +
++ On start, there would be no menus, but directly in a physics World after an animation. +
+ Various functionalities would be reserved for later implementations of other features. + However, for basic functions, basic body, mass and collision information should be done. + Later in the future if possible, it is possible to also test Bullet's Engine, as a comparison. +
+
+ An instance for each of PhyEnv, World and HashSpace
+ would be created on start of application. All Geom instances would be added
+ to the same Hash Space, with a Body of a Sphere the Player-controlled. Those instances
+ would include Boxes, Spheres, Capsules and Cylinders. There would also be a Plane at y=-100,
+ without other World boundaries.
+
+ Some Objects in the World would not be associated with any Body to be static. Certain Geom + may also be implemented as Composite Bodies to test for difference in functionalities. + Some Bodies with sets of continuous cubes with length of one meter with 3D random patterns + may also be generated in the World. +
++ For rendering, parallel projection over the level of the player character would be done. + Also, players would be able to fly around and move on the surface in any way. +
+- On start, there would be no menus, but directly in a physics World after an animation. + On start, there would be no menus, but directly in a physics World after a startup animation. + The content of the animation is yet purely demonstrative and not ready for production.
+ Different classes should hold different responsibilities precisely.
+ TerraModulus hold a major GuiManager and another manager that
+ is unrelated to User Interface (UI) as World.
+ Since the implementation of World is demonstrative and temporary, related classes shall be
+ placed under net.terramodulus.void package.
+
+ GuiManager shall hold Window, RenderSystem,
+ ScreenManager, and temporarily InputSystem.
+ In each frame, all pending Multimodel UI (MUI) events shall be polled and analyzed,
+ including storing all key events and processing them through InputSystem.
+ Then, ScreenManager shall update and refresh events to prepare for rendering.
+ Eventually, Window's Canvas shall be cleared and rendered with contents of
+ Screen(s) before swapping framebuffers.
+
+ In World, there shall be an isolated Thread ticking Ferricia's
+ World at a constant rate of 20 Hz. Ideally, time deltas should be calculated
+ for more accurate ticking, ensuring expected ticks being processed for a duration.
+ PhyEnv and PhyWorld must be created accordingly, with objects
+ generated afterward. Objects shall be stored in a map with ObjId using randomly
+ generated unique unsigned integers, with objects other than random test cubes created in
+ a fixed way for main character and spawn point cube. In the creation of World,
+ an instance of Ymir as the representative of preceding management in Client
+ with association to rendering and its properties. Ideally, generations of objects shall be
+ in parallel such that progress may be tracked on UI, without any invocation to OpenGL
+ during generation but after the end of generation when the role of generation handed back
+ to the main thread.
+
+ GameplayScreen handles initialization of World and rendering of it.
+ This includes the construction of Ymir and related VoidGeom classes.
+ In the Screen, a helper dummy Component GameplayRenderer is used to render
+ World objects after sorting, via renderGwrGeo from Ferricia.
+ A representative of player character as PlayerVoidGeom shall also be stored
+ in the GameplayScreen, though, it should not be a responsibility of a Screen.
+ At the same time, objects stored in World must also provide ability to access
+ information for rendering information without having to implement actual rendering-related
+ functions and interfaces directly in World, isolating rendering responsibility.
+ Events related to World should be handled in update functions, while others
+ related to UI should be handled via event listeners; controlling of player-directed events
+ shall also be handled via GameplayScreen.
+
+ ScreenManager initially adds LaunchingScreen, showing an animation
+ of logo of the host organization. Then, it transits to ResourceLoadingScreen,
+ showing the logo of TerraModulus; it is intended to track progress of resource loading, but
+ at the moment, there is no resource to load, a period of a second to stay on the logo without
+ showing a progress bar may be realized instead. Eventually, normally it should transit to
+ TitleScreen, but at this stage, GameplayScreen generated by
+ RenderSystem instead; though, it is not ideal to pass RenderSystem
+ through update functions.
+
@@ -66,11 +125,49 @@
+ In World, there shall be a sphere as the player-controlled character, a spawn point cube + and randomly generated cubes. While the sphere and the spawn point cube are always generated + at fixed positions, as (0, 1, 0) and (0, 0, 0) respectively; the sphere should be just placed + on the spawn point cube. Random cubes as test objects are generated using a fixed algorithm + with sets of random continuous patterns for each five meters apart; those cubes are generated + like maze generation that are branched from the origin and other branches. +
++ All objects must be in unit size of one meter in range of [-1,1] for local space. + However, for unit objects with only a single shape, its dimensions must align the limits. + This means the diameters or widths of the shapes should be two meters. As unit objects, + rotation and scaling may be identity, but must be scaled half in model transformation. +
++ Cubes shall be generated randomly in three colors, plain red, plain green and plain blue, + while the sphere shall be in full white. +
++ The sphere shall move at the speed of pi meters per second for each direction without + unit vector normalization. At each frame, the position of objects are fetched to render + the geometries, especially for the sphere. Also, players would be able to fly around and + move on the surface in any way, affected by collisions with other objects. +
+
- For rendering, parallel projection over the level of the player character would be done.
- Also, players would be able to fly around and move on the surface in any way.
+ Basically, since menus are incomplete at the current stage, temporary solutions for rendering
+ shall be employed just for basic startup animations and Gameplay World Rendering (GWR).
+ World rendering shall be handled by GameplayScreen via functions of GWR.
+
+ For rendering, orthogonal projection over the level of the player character would be done; + all objects shall be rendered without perspective transformation and culling. +
++ For camera and sizing, standard scaling shall be 64 screen pixels per meter in World space, + while normally it is expected that each Tile is rendered as 32-pixel width textures. + This means each texture pixel should be rendered as two times two screen pixels.