Skip to content

[EFP 11] Orryx Alpha Stage #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
BenCheung0422 wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

[EFP 11] Orryx Alpha Stage #21

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d57de22
EFP: Create: Orryx Alpha Stage
BenCheung0422 Mar 21, 2026
d53a983
EFP 11: Complement details for v0.0.1
BenCheung0422 Mar 28, 2026
0b110b1
EFP 11: Complement sections for Alpha 1
BenCheung0422 Apr 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
201 changes: 201 additions & 0 deletions efp/efp011/main.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,201 @@
<?xml version="1.1" encoding="UTF-8" ?>
<efp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../efp.xsd"
efp="11" created="2026-03-21" category="process" status="draft" title="Orryx Alpha Stage">
<metadata>
<pullRequests>
<pullRequest id="21"/>
</pullRequests>
</metadata>
<body>
<section title="Introduction">
<content>
<p>
Alpha and Beta Stages of Orryx would be proposed separately. Until the end of the Stage,
its proposal would be held <b>Provisional</b>.
</p>
<p>
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.
</p>
</content>
</section>
<section title="Version Schedules">
<content>
<p>
All versions are incremented only on the minor version in the Primary Version, starting from
version 0.0.1.
</p>
</content>
<section title="v0.0.1: Physics">
<content>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</content>
<section title="Structures">
<content>
<p>
Different classes should hold different responsibilities precisely.
<code>TerraModulus</code> hold a major <code>GuiManager</code> and another manager that
is unrelated to User Interface (UI) as <code>World</code>.
Since the implementation of World is demonstrative and temporary, related classes shall be
placed under <code>net.terramodulus.void</code> package.
</p>
<p>
<code>GuiManager</code> shall hold <code>Window</code>, <code>RenderSystem</code>,
<code>ScreenManager</code>, and temporarily <code>InputSystem</code>.
In each frame, all pending Multimodel UI (MUI) events shall be polled and analyzed,
including storing all key events and processing them through <code>InputSystem</code>.
Then, <code>ScreenManager</code> shall update and refresh events to prepare for rendering.
Eventually, Window's Canvas shall be cleared and rendered with contents of
<code>Screen</code>(s) before swapping framebuffers.
</p>
<p>
In <code>World</code>, there shall be an isolated <code>Thread</code> ticking Ferricia's
<code>World</code> 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.
<code>PhyEnv</code> and <code>PhyWorld</code> must be created accordingly, with objects
generated afterward. Objects shall be stored in a map with <code>ObjId</code> 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 <code>World</code>,
an instance of <code>Ymir</code> 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.
</p>
<p>
<code>GameplayScreen</code> handles initialization of <code>World</code> and rendering of it.
This includes the construction of <code>Ymir</code> and related <code>VoidGeom</code> classes.
In the Screen, a helper dummy Component <code>GameplayRenderer</code> is used to render
World objects after sorting, via <code>renderGwrGeo</code> from Ferricia.
A representative of player character as <code>PlayerVoidGeom</code> shall also be stored
in the <code>GameplayScreen</code>, though, it should not be a responsibility of a Screen.
At the same time, objects stored in <code>World</code> must also provide ability to access
information for rendering information without having to implement actual rendering-related
functions and interfaces directly in <code>World</code>, isolating rendering responsibility.
Events related to World should be handled in <code>update</code> functions, while others
related to UI should be handled via event listeners; controlling of player-directed events
shall also be handled via <code>GameplayScreen</code>.
</p>
<p>
<code>ScreenManager</code> initially adds <code>LaunchingScreen</code>, showing an animation
of logo of the host organization. Then, it transits to <code>ResourceLoadingScreen</code>,
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
<code>TitleScreen</code>, but at this stage, <code>GameplayScreen</code> generated by
<code>RenderSystem</code> instead; though, it is not ideal to pass <code>RenderSystem</code>
through <code>update</code> functions.
</p>
</content>
</section>
<section title="Physics">
<content>
<p>
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.
</p>
<p>
An instance for each of <code>PhyEnv</code>, <code>World</code> and <code>HashSpace</code>
would be created on start of application. All <code>Geom</code> 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.
</p>
<p>
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.
</p>
</content>
</section>
<section title="World">
<content>
<p>
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.
</p>
<p>
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.
</p>
<p>
Cubes shall be generated randomly in three colors, plain red, plain green and plain blue,
while the sphere shall be in full white.
</p>
<p>
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.
</p>
</content>
</section>
<section title="Rendering">
<content>
<p>
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 <code>GameplayScreen</code> via functions of GWR.
</p>
<p>
For rendering, orthogonal projection over the level of the player character would be done;
all objects shall be rendered without perspective transformation and culling.
</p>
<p>
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.
</p>
</content>
</section>
</section>
<section title="v0.0.2: Menus">
<content>
<p></p>
</content>
</section>
<section title="v0.0.3: World">
<content>
<p></p>
</content>
</section>
<section title="v0.0.4: Generation">
<content>
<p></p>
</content>
</section>
</section>
<section title="See also">
<content>
<list>
<li>
<a href=""></a>
</li>
</list>
</content>
</section>
</body>
</efp>