My name is Joshua, but I go by the username HyperbolicHadron on the Thrive Discord. My background is mainly in computer hardware and FPGA design in Verilog, but I have experience programming in C, Java, and to a lesser extent C++.
My main interests in Thrive lie in the simulation and development of large civilizations as would be typical for the Society, Industrial, and Space stages. I intend to help build out the features of the game that will allow others to develop more parts of the later stages in depth, and creating a complete world generation system is the task that I have selected to work on.
I began researching and prototyping different aspects of the world generator on my own before joining the development team, and I think that I now have enough experience to start discussing the design of the world generator in more depth here on the forums. There is still quite a ways to go before any version of the world generator can be integrated into the game, but I think that now is the perfect time to start the creation of detailed specifications and roadmaps for the world generation system.
I will be writing up my current thoughts on the world generation system design ‘soon’ and will continue to work on various prototypes of world generation and other related systems meanwhile.
Anyway, thanks to everyone who has helped bring the game to its current state, and especially hhyyrylainen for his recent development on the higher stage prototypes, as that has definitely been a major factor in motivating me to work on this area. Looking at the direction this project is going I feel that it has a very good future ahead of it!
Happy to finally be able to talk to you on the dev forums
My main interest in thrive is also simulating the society stage. I almost want to just start working on it now that the prototypes are in place. Sadly those are far too bare bones to works as precursors for a real stage.
Since I am mostly interesting in building the framework and lower level features for the engine in support of the stages, hopefully that will combine well with the developers who want to build the actual game on top. You all will have to make sure to speak up though if I am trying to make unusable game engine components. One of my main goals is to try and make nicely documented and cleanly designed interfaces for the world generator, but as a hardware engineer I might have a little bit different of an idea of what a nice interface looks like than most programmers…
I am trying to design the world generator to be as separate as possible from the main Thrive codebase without compromising on performance or features. (While still designing the features of the world generator specifically for Thrive). This would ideally result in a separate project with a clean interface as a natural result (if designed well). This would mostly be to make the design of the game as a whole more clean and maintainable, as well as more modifiable if you can just swap out the world generator without ripping it out of the engine, but it could potentially be used for other projects as well. This is all similar to the Story Engine you described here: Story Engine which I am a fan of.
I will be describing it more in the thread I make later, but I am currently thinking of the design of the world generator being something like Google’s S2: https://s2geometry.io/ or Uber’s H3: https://www.uber.com/blog/h3/
These are both (part of) geographic information systems built for storing and managing different data layers associated with geographical locations. These include terrain height, city populations, building placement, climates, etc.
The Thrive world generator would then serve as a sort of database that the game would query for both simulation and for rendering. Unlike S2 or H3 though, the world will have features that are generated dynamically (such as new terrain generation) or features that are persistent, such as individual buildings that are placed manually by the player.
Funny story that, I started the prototype world generation in c# with Godot, but then I got slightly annoyed with the documentation on Godot’s procedural meshes, which has gotten a bit more annoying with Godot 3 vs 4 documentation. I have been wanting to write a basic engine in OpenGL for a while, so I had the ‘brilliant’ idea of just doing both projects at the same time, and am now writing both the world generator prototype and my OpenGL renderer in C++. As should have been expected, I have spent far more time figuring out the idiosyncrasies of OpenGL then I have actually coding the world generator, but I have at least learned what I wanted to learn. The OpenGL renderer will of course be irrelevant to Thrive, but the C++ implementation of the world generator should be able to be used in the main Thrive project eventually. The differences between Godot 4 external c++ integration vs Godot 3 will factor into when exactly this would be done.
However, I do plan on translating the prototype world generator back into c# when it is at the point where it can be first integrated into the game. I am really curious to see what the performance differences would be of a fully c# integrated world generator vs c++ external world generator. As for what happens after that, we will have to see then (if any of that even occurs like that).
I actually started on the patch partitioning code before any of the world generation, which I just coded in plain c. That should be integrated into the rest of the world generator relatively early on.
My crazy choices for switching between languages and engines shouldn’t really affect the world generator’s design though, just how long it takes to make. This is partially just a consequence of some of my interests: I like to do a lot of benchmarking and maximum performance optimizations. I don’t foresee any other changes, so you don’t have to worry about me trying to make a FPGA implementation any time soon, though don’t tempt me…
Honestly, it might be kept in c++, given it would likely be somewhat performance intensive and already separated cleanly anyway. Not a sure fact, but something to keep in mind.
I suppose it will all depend on how the discussion on other c++ parts of the project go, if that is going to be figured out before the world generator is ready. I really don’t mind converting any code I make between c# and c++, just so long as both will not have to be maintained concurrently for any significant length of time. I am planning to use that to learn a bit more about c#, as I haven’t really done much in it before.
The OpenGL renderer that I made is incidentally why I haven’t made my code public yet, I don’t want to be responsible for any injuries caused by anyone looking at my rendering code before I have cleaned it up yet.
