Development Roadmap

[mokun]

A. Introduction

The development of the Mars Simulation Project began in early 2000s. We have strived to paint a picture of what the first generation of settlers might look like in terms of what they will do operationally to survive and build up their settlements on the surface of Mars. Therefore. mars-sim aims to perfect the simulation of the operational story of establishing human settlements.

Although we have deepened the fidelity of simulation on various aspects over the years, it's by and large one big sandbox simulation seemingly without clear, overarching objectives.

Initially, we were brainstorming what might be the missing links in simulation aspect of mars-sim in #734. What seemed to be the limiting factors or the gap is NOT how deep the simulation models we should develop but the lack of clear objectives and the scopes for simulation.

B. The Four Chapters

In light of this, it may be advantageous to propose the following development roadmap for the future of mars-sim :

Chapter	Topic	Description
1	Exploration & Base Building	Establishing the day-to-day operation for settlers. Mission Planning for surface exploration. Sample Collection. Making human presence as self-sustainable as possible on Mars.
2	Settlement Expansion	Simulate population in terms of people group. Model settlement income, expense and revenue. Drafting and enacting settlement polices. Establishing industrial zones. Strengthening infrastructure redundancy. District and community planning.
3	Large Sector Planning	Engineering sociopolitical environment in settlements. Large-scale human migration and settlement. Rise of tourism industry. Societies and ideological divide. Citizenship and voting right. Simulating political factions. Modeling private ownership and taxation. Simulating interdependence of businesses. Modeling resources supply chains and trading. Simulating traffic, cargo and passenger movement between settlements.
4	United Mars and Independence of Mars	Establishing the first Mars Republic and develop a stable, central authority. Planetary-scale environmental engineering. Stock Market, Corporations and financial investment. Political relationship with Earth, Moon and Off-world colonies.

Should our overarching objective(s) be related to developing mars-sim in such a way that it will eventually encompass the aforementioned 4 chapters ?

C. Current Development

Obviously, according to the section B above, we may classify what mars-sim has been focusing on developing as Chapter 1 of this project.

What achievement goals do you have in mind to implement for players for the purpose of wrapping up chapter 1, before we start chapter 2 ?

D. Future Development

Let's discuss what kind of developmental groundwork should be done in our codebase necessary for us to make a transition from chapter 1 to chapter 2. Shall we ?

[mokun]

@bevans2000 @larsnaesbye @Urwumpe @shirishag75 @jbosmans

Do feel free to provide your feedback and comments. Thanks !

[bevans2000]

I think is a good approach to have a roadmap of the objectives but we need to consider how we deliver the simulation.
At the moment it is a single-user on a desktop. I feel that we need to get a multi-user aspect to the simulation particularly for Chapter 3. This would allow multiple user to cooperate in the same simulation universe. The only way forward is to create a web UI client for the engine.
Previously I played with a prototype but I'm no UI developer
https://github.com/bevans2000/mars-sim-rest-pilot

[mokun]

consider how we deliver the simulation.

Yes. We can certainly work on providing additional Game Modes (hot-seat or network multi-user, or massive multiplayer online (MMO), etc.) in parallel to the suggested overarching goals above.

[mokun]

@bevans2000

So the picture is that, for each chapter, we first develop it in single-player mode. Later, we add other game modes.

Now in setting the groundwork for Chapter 2, shall we make it the default for using JavaFX or OpenJFX ?

Piecing together UI components using JavaFX can be time-consuming. So I'd like to opt for using FXGL to potentially save a lot of UI development effort.

Also, we may only need to develop one jar that works on JavaFX from the ground up (instead of having one for console and one for Swing in Chapter 1).

Question: will this approach be compatible with compiling the jar into a docker image as well as continuing your work on the Rest server and ReactJS client?

[bevans2000]

In my opinion the longevity in a desktop client is limited so I wouldn't put any effort in changing from Swing unless there is a fundamental problem. Having separate ui client and shared back end is a significant change. The headless middle on top of the core module provide the foundation

[mokun]

In the past, we have said that we will improve the interactivity of mars-sim. It means that we would build UIs that would allow players to make important decisions.

In light of this, we should craft Chapter 2 and 3 in such a way that players' decisions will heavily affect the outcome of the simulation.

Below are some of objectives on what we may and may not want to have in Chapter 2/3 :

A. Will do

1. Allow players to exercise decisions as the mayor or the commander of a settlement using his influence/leadership points.
2. Give players executive power to allocate resources of a settlement as a whole to fund projects. e.g. allocate time, resource and manpower over various categories of construction projects and capital improvements.
3. Let players propose/manage major and minor polices of a settlement among various categories (economic, human right, political factions, etc.) and allow NPC settlement officials to vote on initiatives.
4. Set up a pool of talented individuals for hire. Allow players to pick them to take on major settlement projects and missions.
5. Model the dynamic of political factions and manage inter-settlement relationship.
6. Manage relationship between settlements, namely, allow collaboration and competition between settlement and political factions
7. Track income and revenue. Set up tax policies.
8. Allow zoning and community planning. Rehearse scenarios for disaster planning.

B. Will no longer

1. Simulate the individual action of each settler on each frame.
2. Model the mission of each vehicle.
3. Simulate the mission planning and results of each vehicle mission.
4. Track each manufacturing, food production and resource processes.
5. Model how system function works on each building.
6. Model the growth of each crop.

[mokun]

This thread of discussion aimed to take into consideration the sociopolitical aspects during the design and engineering phase of the placement of critical (or life support) resources in a settlement.

Also, we may begin modeling the emergence of societies and political factions in Chapter 2.

How societies and factions will build their power base will certain exert sociopolitical influence over all settlements with varying degrees of success.

Feel free to contribute to this discussion.

[CiberNin]

My main interest in the project has always been production chains. Brick and steel. What sort off machinery needs to be imported to achieve closure?

[bevans2000]

I agree for me the interest is the autonomous simulation of the entities including the production aspects. The user interaction is to guide the approach of a Settlement. But ideally I want the simulation is to become shared so multiple users can interact with the one simulation.

[mokun]

What sort off machinery needs to be imported to achieve closure?

Currently, we haven't got the chance to deepen the fidelity of simulation on exactly how steel and brick are manufactured in detail and what exact tooling to be used.

For now, it's more of given certain input resources, the workshop will come up with output resources if power and work time are provided.

So do you have anything in particular you would like to share/suggest with regard to the production chains ?

[CiberNin]

Well you have an induction furnace of a certain size. Small / simple ones could only melt down meteoric iron, but for mid scale where you want to reduce real ores you will probably want hydrothermal reduction in a vacuum chamber. You don't get into traditional methods like arc furnaces until you get really large scale and can have the extra factory dedicated to producing carbon electrodes.

For aluminum it's all hydrothermal reduction all the time. For decades industry has been looking for viable alternatives to the Bayer process, and hydrothermal reduction in a vacuum is the most promising alternative, which also happens to be more energy efficient if you already have a free source of vac like on mars.

And from your molten metal, how are you going to finished part?
printed plaster casts are viable for many aluminum parts with a little machining to clean things up, but what about wires? You can't cast those directly. Gotta have a rolling / slitting / drawing mill. And then a machine to weave all the strands together. And then you need to insulate them which means producing and spinning and weaving rockwool insulating jackets.
For structural steel parts you can't do to much with plaster. To high temperatures. Green sand carving machines exists, but green sand implies lots of water usages, which means you need an air tight if not human habitable workspace. And with steel you need to forge and roll to really get the most of it's structural properties.

[bevans2000]

One "disappointment" I have is that the simulation never starts any Construction activities. We have logic to build extra Building but it's never triggered so we need to look at this and understand why.

[mokun]

I just came across a multiplayer engine out there called spacetimeDB.

They kind of follow a data-oriented approach with a relational database. Their platform supposedly simplified the making of a multiplayer game.

See also https://spacetimedb.com/.

It has a GitHub repo as well.

[bevans2000]

Here's an idea i had over the weekend. We should adopt Jpackage to create complete exes for users to use. Removes the need to install java first.
We can create these automatically off the release GitHub action https://github.com/sualeh/build-jpackage/tree/main
Still offer the zip deployment for those with java

[mokun]

That sounds fabulous ! Let's do it !

The thing is a lot of people are still having problems with the Java path environmental variables.

It's a nightmare when you already have an old version of java installed and when installing a new version, the java path won't get set up correctly.

Sometimes uninstalling the older version of Java is needed first.

If mars-sim can run on top of a dedicated version of Java (or a subset of Java preferably), then problem solved !

[bevans2000]

Exactly, don't know why I haven't thought of it earlier. Let's get close to ending 3.10 and then I'll jump on it

[mokun]

May be we can also use JReleaser for putting together the big 3 platform-specific packages (Win, MacOS, Linux).

- Windows: MSI installers
- macOS: Homebrew taps or DMG files
- Linux: DEB/RPM packages
- Cross-platform: ZIP archives with native launchers

See https://jreleaser.org/guide/latest/index.html and https://www.youtube.com/watch?v=Ur-5gprgrIo.

Whichever is better.

[bevans2000]

@mokun there has been a steady rise in the number of issues reported by SonarQube, can we be mindful of it with commits.
In particular a massive increase in use of System.out.println. We shouldn't be using this.

[mokun]

ok I didn't know it catches System.out.println from unit test. Will delete them.

[bevans2000]

@mokun I want to change how we use Labels for our Issues. GitHub Issues now have types:

• Bug
• Task
• Feature

These overlap with our Bug & Feature Request labels. Labels should identify the area addressed by the issue.
So I want to remove the Bug & Feature Request labels and force reporters to use the correct GitHub Issue types. The key labels are:

• Build - relate to Maven or packaging
• Code - changes to the core engine logic
• Config - configuration logic of the simulation, config classes and/or XML
• Java UI - Swing front end
• Design Change - big changes
• refactoring - reworking the Java code to improve performance/readability/efficiency of code
• internationalization - running in different languages

[mokun]

These overlap with our Bug & Feature Request labels

Yay they overlap.

The new categories that you suggest sounds great.

Will there be an automated way to transfer the labels from old issues to the new label system ?

[bevans2000]

What's the main focus of 3.11 then? For me there are 2 mandatory items

• Future of Java UI #979 Make a start on improving the UI
• No construction of new buildings #1642 Complete reworking the construct building logic. This has a lot of sub tasks

What about Tourism? I think we need to create a Project so we can track all the various changes

[mokun]

When it comes to missions, I see the need to patch the elevation resolution ASAP. Thus I see these two are supposed to be of highest priority :

1. Implement path finding and path tracing on the surface map  #959
2. Create super high resolution artificial elevation data around known destinations #916

[bevans2000]

Ok, these sound reasonable. I've started to tag some issues with 3.11.
But if we do complete a new Swing first end we should bump it to 4.0, let's see how we get in over the next months

[bevans2000]

If we redesign the UI I wonder if we should call the next release 4.0? Because it will be a major change.
I want to finish the work over Christmas when I have more spare time.

[mokun]

Yes we could.