Entity System code in engine and gestalt

chapp007

New Member
Contributor
Why is there duplicate entity system code in Gestalt and the Engine modules? Is there a migration in progress to make the engine depend completely on Gestalt? If not then what is the difference?
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Extraction in progress :)

Gestalt is the target of frameworks that might be useful outside the engine if extracted. The asset and modules systems have been completely extracted and made available, even applied to our other project Destination Sol (still pending some fixes for Android usage - works fine on the DS PC version)

The entity system is the current effort by @Immortius, and it is going through some refactoring on the way out. Our UI system has been reviewed for extraction by @Rostyslav Zatserkovnyi but is on hold as it has some dependencies on the entity system
 

chapp007

New Member
Contributor
@Cervator thanks for the response.

I've been playing with the world gen code in my JMonkeyEngine game. I've maintained the org.terasology package names to not seem as though I'm trying to take credit. I simply want to play with the code and learn. I hope that's cool. That's how I stumbled upon the two entitySystem packages.

I think a lot of the world gen code could be extracted into a separate module. I've actually been able to move many pieces into my project with very little difficulty. Although I'm not trying to make it as modular as terasology at the moment because I'm really just learning. Is the world gen code something you guys have thought about moving out? I really think it's doable as long as the scope is limited to the most important pieces. It can start small and other pieces can be teased out when possible.

If that piece were in a separate module then essentially I could create a game in JMonkeyEngine that depends on the following:
  1. TeraMath
  2. Gestalt
  3. TeraWorldGen(The new module)
Maybe we could then have a TeraMonkey project :). I've also noticed there is some talk of moving to LibGDX in the future. Obviously the more modular this thing is the easier that kind of transition would be.

What are your thoughts on doing something like this?
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
That's absolutely fine and cool! jME contacted us once curious if we had considered using some of their stuff, but we're probably too deep in at this point to rearchitect the basics. But a new learning project is fine, @Marcin Sciesinski also "rewrote" a Terasology from scratch based on LibGDX to get some good ideas on entity system improvements and such.

The facet based world generation hasn't really been considered for extraction before (to my knowledge) but that's likely more simply because nobody has thought to spend effort on it. I'd love to see it extracted and made reusable for worlds in other games! And if it shows some new potential with jME that'd also be super cool to see :)

I might suggest naming the new thing something like "gestalt-worldgen" (packages org.terasology.gestalt.worldgen?) and would be happy to make a repo under the MovingBlocks org for you if you're interested. The current Gestalt repo is all-in-one partly just from the convenience, we might split it back apart into one-repo-per-lib later when there's some time to organize the logistics (like easily embedding the pieces into a Terasology master workspace, or something different like it)

On LibGDX - yeah there is some hope to make it onto Android that way. And admittedly that might involve an equally comparable challenge to rebase on top of jME. Really either option just hasn't been investigated deeply so far from lack of available effort. Yet we've tried to get Gestalt running on LibGDX as mentioned above, via DestSol.
 

chapp007

New Member
Contributor
That's absolutely fine and cool! jME contacted us once curious if we had considered using some of their stuff, but we're probably too deep in at this point to rearchitect the basics. But a new learning project is fine, @@Marcin Sciesinski also "rewrote" a Terasology from scratch based on LibGDX to get some good ideas on entity system improvements and such.
One thing that intend to do is try to figure out why I get a really low frame rate when running the game. I run the 8GB run configuration on a machine with 24GB of RAM. I know my graphics card isn't great, this is my work computer for development and not a gaming computer. However, my game runs fine on it and minecraft runs fine. Anyway, I don't want to get us down a rabbit hole here, I just wanted to mention one of my goals.

I might suggest naming the new thing something like "gestalt-worldgen" (packages org.terasology.gestalt.worldgen?)
Do you think we should keep the same package names as they are in the engine for a while? If we did that then it wouldn't be a breaking change to remove the classes out of engine as long as engine depended on gestalt-worldgen. Then we could rename the package in a major release. Although I'm thinking in terms of semantic versioning. Does Terasology practice SemVer? On the other hand if you are thinking of creating this module in parallel and not making the engine depend on it until much later then it won't be a problem to rename the package. I don't have a problem doing it either way you'd like, just wanted to throw that out there.

The current Gestalt repo is all-in-one partly just from the convenience, we might split it back apart into one-repo-per-lib later when there's some time to organize the logistics (like easily embedding the pieces into a Terasology master workspace, or something different like it)
So I won't have to create a separate module just submit pull requests to a new gestalt sub-module?

I will mention that I'm a Subversion/Maven/Eclipse for 10 years and starting to use Git/Gradle/Intellij so please bare with me on that.

Thanks for being open to the idea! Just let me know what you need me to do to get started.
 

chapp007

New Member
Contributor
Looks like Region3i needs to move out of the engine and into TeraMath no biggie there. However, CoreChunk is needed by the WorldRasterizer. CoreChunk needs Block and to set Blocks you need BlockManager. To me it seems like world-gen sort of needs a world-model to be able to work.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Would be nice if you could troubleshoot those performance issues on your system better. Used YourKit before? It is all kinds of awesome for profiling and we can give away free open source licenses if you'd like one :)

Keeping package names the same at first is ideal, just the library name is important up front. We'd probably rename packages way later when engine goes v2.0.0 (so yep, we practice SemVer!)

The new module could be either standalone (new gestalt-worldgen repo) or integrated with the multi-project gestalt repo. If you think it'll be fairly self-contained it might be better to go standalone, easier to manage. I can help hook up the Gradle magic to make it easy :)

Region3i, CoreChunk, and so on gets a bit deep into architecture land for me. @msteiger @Florian , or @Rostyslav Zatserkovnyi might be able to advise. @Immortius or @Josharias as well but may be mostly unavailable.
 

chapp007

New Member
Contributor
Would be nice if you could troubleshoot those performance issues on your system better. Used YourKit before? It is all kinds of awesome for profiling and we can give away free open source licenses if you'd like one :)
I'll start a new thread about performance and mention you since this one is growing legs. :)

Keeping package names the same at first is ideal, just the library name is important up front. We'd probably rename packages way later when engine goes v2.0.0 (so yep, we practice SemVer!)
Great! Exactly what I was thinking.

If you think it'll be fairly self-contained it might be better to go standalone, easier to manage.
I think it makes sense to have it in a separate repository because it's release cycle probably won't line up with the other gestalt components since they mostly unrelated. In other words, when something in gestalt-module changes it's really unrelated to worldgen so why should the worldgen version change? Plus, you could give me full access to the new repository without the worries of me totally messing something up in gestalt.

I can help hook up the Gradle magic to make it easy :)
That would be great! I tried to get Intellij to add a new module to gestalt last night to no avail. I started manually creating it based on how the other projects looked and it just felt wrong. I would appreciate if you could get a project started. I will mention that I think it should be multi-module. Not sure if you need to know that up front but I definitely see that there will need to be a world-model(or whatever you'd like to call it) project.

Region3i, CoreChunk, and so on gets a bit deep into architecture land for me
Region3i doesn't seem to depend on anything else in engine. All it's dependencies are vector classes that reside in TeraMath. CoreChunk definitely needs input from you guys.

I'll create a separate thread focused on discussing the implementation of the worldgen project. I'm excited to get started on it!
 
Top