Our project may save you sometime as it will be open source.
Just remember: Open source is way more than just publishing the sources. It also requires the sources and documentation to be in a form that somebody else can work with them. You need clear coding standards, documentation standards and processes for ALCM.
Your project sounds exciting! I love that film!
No project... simply some low voltage design and experimentation so far.
What kind of things are you going to cost?
I wanted to keep it very simple. Only generating TEUs in a pseudo-realistic demand-driven way with each TEU having a destination and delivery deadline. No money in the first iteration at all, fuel will be for free as long as fuel is available at the base. Not even a visible simulation of the containers before they enter the destination spaceport - they just appear at the container storage area and wait for getting picked up, or disappear when they are hauled to the target.
The biggest item that I have in actual development is still the TEU library, a framework for accessing the logistics data of each TEU. And that is just the tiny foundation of all that needs to be done. Just a small DLL that handles containers and their contents and a static link library that permits communication with the containers to "read their labels", "open/close doors", "unload/load" or "paint them".
As you can see: Millions of LOSC are still waiting for having something comparable to you want to do.
The second iteration of this would have been adding passengers to the economic model, and thus employees. The coarse concept is already sketched out along a roleplaying game ruleset that I like, but nothing yet that can be turned into source code. It would be similar to UMMU in its role then, but different in scope and size.
EDIT - Or better: ADDITIONAL WISDOM:
Don't underestimate the need for design and project management for something at the magnitude that you are planning to do. I feel like you want to start coding directly and I can understand that. But better wait, plan things before you code. Organize the project, it is really needed before you start. Don't try to do things on the fly. This works for small projects and ends in serious and demotivating refactoring once your project grows too big for creative chaos. Define interfaces first - how will the player interact with it, how will components interact, etc.
If you want to have stability, define exactly two people who will be project lead and deputy project lead. Select them good, they
must not be coders, it is even helpful of they stay out of the add-on development front line. Make them the accountable and responsible parts of the project. They define the standards and requirements and make sure they last for more than just a year. They can reject changes, they decide which feature branch gets merged with the main development line, which version will be next and how it should look like. Ideally they should even be able to fire a coder from the project, when he refuses to follow the project standards and roadmap. He can do a fork anytime, but he should not be permitted to mess with your project.
The initial documents of the project are the constitution, maybe even the ten commandments of your project, and nobody should join the project before agreeing to these documents. No plan survives the first contact with the enemy and no software development results in the software initially planned. But the philosophy of the project lasts. Maybe not for ever, maybe you need to adapt things carefully when learning that things need correction. But only slowly and never as a one-way decision, there is always a way back. Make sure everybody in the project knows how this will be developed. Don't prescribe technical solutions in your project planning documents, if there is no acute need. Define what the solution should achieve, not what the solution shall be. A screwdriver can open bottles, too.
Get this management done first and then develop according to this.
Otherwise, you will get exactly nowhere. You start with lots of enthusiasm, work fast, but also get into trouble fast and with so much inertia that you will be really deep in trouble before you notice how far you have left the planned trajectory of your project already. And then you will stall. People will start to blame others, finger pointing will replace communication, people from outside the project give the direction for you, finally it will be dead and somebody will restart it. Maybe better, maybe with the same errors in management.
(Yes, I hate management myself. But I have grown too old to not know that the bitter medicine is the best.)
