I don't think it's very smart to just start one big massive project and expect it to be fully feature capable right away. I think it might be smarter to break into smaller unit groups for piecing together the needed components.

Firstly though, I'd suggest folks get acquianted with how C macros work in Unreal (if we are decided on that engine). The easiest place to start, is with modifying "Pawns" by extending the object class. Then you can actually drop your new class straight into the editor.

It's powerful. You can create functions that control your pawns that are accessible from Blueprints, so you can program things to happen both with code and with the visual editor. Getting good at using the engine means knowing when to use each method. I find that Blueprints are good for prototyping, while C is good for performance and refactoring. Certain calcs should take place with C though because Unreal has arbitrary float/int byte limits that you WILL go over if you're doing any conversions between meters and AU.

I'll provide more input on this as I am available, which I am not super available until mid July.

Here's my thoughts though on how people might split the learning process:

• MOD-Support: Folder Crawler and simple API for importing models into the Editor. Simply put - this is just as a means to ensure we can accomplish our ultimate goal of being Mod-oriented. This may also go hand in hand with the next project, the Scripting Wrapper.
• Scripting Wrapper: adding layer for C#, Lua, Python, etc - (start with just one but we could add more later) and having that script layer support control over objects in Unreal - maybe starting with simple translation/animation
• Physics Engine: make a simple toy solar system where bodies move based on either Keplerian motion or gravity ( I've done this before - beware of Event_Tick - look into animation curves and VectorInterpolation )
• Level of Detail System: Making a real-scale planet isn't easy. There are projects out there that offer partial solutions and I will share them as I find those old links. There is problem with any moving origin and rotating planetary frame - but it might be best to just start with dynamic terrain loading on a static sphere based on camera position.
• Construction Hangar: This part is also hard, but not impossible. Unreal actors/pawns have something called sockets which function as connection points for child actors/pawns. You can also define 'skeletons' and use them for rigid body stuff
• Networking / Multiplayer: Unreal has multiplayer built in, but usually that's just for small scale private network matches. If we wanted to do something monumental or massive in scale. You also have to compete with all the other packets on the internet so most people pay for a service like PubNub and it's EXPENSIVE. SO, what I think we should do is recruit crypto-'currency' devs, to implement something using Status.im or something like it but with position vector updates for spacecraft and resource/cargo data.
• Asset Production: there's probably enough non-Kerbal models available from modders, but we may want to have a few modellers/artists focused on creating core components and learning how to optimize them for Unreal. We could even use eventual fundraising to implement something like PBRs/Quixel to have textures that gradually fade/age over time.

So to summarize - those are the worklines which I think could be started all as independent projects. Each one could be it's own Git project on our Github group page.

Once proficiency is accomplished in each, that component of the tech will qualify as "Mission Ready" and as soon as enough of them are ready, they could all be rolled into a version 0.1 by whoever takes up the mantle of programming lead. Whomever that is should be good at unit testing and source management.

I'll post this and jump on the Discord, but wow am I slammed today at work. I just needed to get this out during my lunch hour.

Cheers!