Customizing a Hab, FXGL, LibGDX client

[mokun]

Currently, each building has a standard look and configuration, as defined in buildings.xml

By definition, a habitation module is supposed to be a highly customizable building.

So where do we start to add customization to buildings such as Lander Hab ?

[Urwumpe]

Yes. Just look at how the ISS looks inside after some years of living there - that is what habitation means, even from a psychological point of view.

And if you want to include a more first-person perspective like commander mode, adding personal decorations and equipment to your own quarters inside a hab would also make sense to increase immersion.

As starting point, what about having a type of non-functional gear, that can be attached to walls. And once this works, we can go on giving the gear functions or psychological effects.

[mokun]

@Urwumpe

As starting point, what about having a type of non-functional gear, that can be attached to walls.

So, say, we want to visualize an EVA suit. It's easy since we already have EVASuit class, which inherited from Equipment class . Now it's a matter of showing it in the Settlement Map.

But let say I need a floodlight that can illuminate the inside and outside of a building.

And we can also install these floodlight in an outside site station or have a line of them will illuminate a road between buildings.

So, for small item such as a floodlight, an EVA suit or even a chair, is there a better way to track it instead of using the Equipment class to create an object out of it ?

Btw, it's really long overdue for adding in the logics for these movable furniture inside each building.

[Urwumpe]

Well, my 2.5 cents (Euro) there: Lets assume, we have no EVA suit lying around on the ground in the base, if we do things properly.

We have a EVA suit station, where an EVA suit can be stored, when not in use, which would be a piece of furniture in the base, with a state. This furniture object would refer to a FurnitureDefinition object for defining its properties in game as data. I think, you agree, that avoiding too many special subclasses would be better for getting things done, if we could also do things by composition there.

For making Equipment show up on top or inside furniture, we should associate it with a "VisualizationSpec" object, that defines the important data that is needed for a client to display it. For which graphic files should the client look by just naming the identifier and revision to look for, maybe with hierarchy of increasingly abstract graphic identifiers, so that clients, that not yet support the precise visual for this Equipment can still display a more generic substitute until it gets its update.

In a perfect world, the graphics client would ask its own graphics repository server, if the graphics exist and download it, while displaying the locally existing data as temporary deputy.

For placing an Equipment on or into furniture, we need to tell the simulation, how large the item is. This could be done in the Equipment class or ideally in a "geometry outline" class, that allows it to be more compex. Next, the simulation needs to know, how this object can be placed. There could be multiple ways (laying on top of a table, hanging on a wall, using a Siemens air hook), so it makes sense to define this in an object and associate it with one or more Equipments. I have no idea yet, how to fully describe what is possible, so I don't attempt it. We should extend the enum of valid identifiers for how to place Equipment as needed. Once we know how large it is, we can think about how to store it best. Do we use a grid? Simply a volume that gets magically reduced by just the volume of the object? This could depend on how the object will be stored: Socks carefully placed flat on a table require a different layout compared to just stuffing them into a drawer - while storing a ladle in a drawer would be a pleasure for the goddess Anoia.

Finally, I think we should wrap the Equipment actually into a "PlacedEquipment" class object when put into or onto furniture that acts as decorator pattern. This would have the elegant side effect, that we could easily define different states of the equipment without changing the equipment object. A carefully folded EVA suit would be a new PlacedEquipment object, instead of having to handle special states for equipment that can be folded.

Maybe an EVA suit needs to be disassembled when doffed and reassembled when donned - then the Equipment EVA Suit would be created when donning it, while the Furniture actually only knows the PlacedEquipment objects that describe the components of an EVA suit and the EVA suit object would be destroyed, when doffing it and storing its parts in the EVA suit locker. In that case, the StoredEquipment could be completely unrelated to Equipment that can be used, in contrast to for example, a microscope in the lab or a microwave in the kitchen.

To be efficient, such layout decisions should only be done ONCE and kept stored as long as they are not changed.

And finally, the client used to view the simulation should decide how to render things. An Roguelike terminal client for Mars Sim (like the console?) would not care about the graphics information at all maybe, and only handle PlacedEquipment information, or could use the VisualizationSpec just for displaying an image or a rotating 3D model of the object in a side window. While a full 3D client for Mars Sim could display the whole scene in glorious 3D using all the information the core simulation passes to it and maybe even adds some temporary data to accelerate the rendering. Or a simpler client could just ignore it completely.

Also, the simulation engine could be made customizable to only support layout algorithms of a certain quality. Like, for increased performance, just using user predefined slots on furniture surfaces, instead of deciding by a more complex calculation, if and how a piece of equipment could be placed there - and leave it to the player setting the simulation up, how complex he likes it. If a layout calculation is not supported by the engine, its specification would be ignored in the Layout information for an object and only the supported modes will be used. And also the other way around: If we forgot to update the layout information for an old piece of equipment to support a new layout engine, only the supported modes could be used to still be able to place the object, even if more complex calculations would be supported by the engine. And just log a warning to the developers ONCE that the object needs more work.

For placing lights and other objects outside the base - we could define them as light-weight buildings, maybe just having only the most necessary information for such objects in a common super class, and define the old complex large buildings and underground structures as "new" Buildings. While storing them in a trailer or on a rover would again be the same use case as inside buildings and into or onto furniture.

So, the actual handling of such layout decisions should be in a component object for both buildings and rovers, instead of writing the same code twice. Maybe this means that the inside of rovers can be customizable for free. Well, why not?

[mokun]

You can see I do have the gdx64.dll and the two jars in the Build Path.

I suppose the gdx-natives.jar is NOT needed, since I already have the gdx-backend-lwjgl-1.10.0.jar

[bevans2000]

@mokun Did you mean to commit the JAR & DLL files to git?

[mokun]

Feel free to delete that. I was trying to see if libgdx is purely mavenzied and can be loaded and run in that way

[mokun]

My question is, why aren't those two class files get imported properly ?

You can take a look at this screenshot. Both class are inside that jar file.

[mokun]

Just saw you removed the scope xml tag here and it works now.

[mokun]

@Urwumpe

But my own preference of development would rather be in the backend, like including remote depots and outposts.

Sure. but we can already build separate daughter mining outpost, etc.

I guess what you want is to be remote depots to function UNIQUELY and they will supplement what's missing from its main settlement in terms of having some missions and tasks for settlers to go there to do things.

[Urwumpe]

AFAIR, this function is still blocked - we can't found new outposts during simulation that operate similar to the old ones (buildings, inventory, life support)

Yes, the main difference for me would be setting a different strong focus on the function of the site. No permanent habitation, little recreation, lots of storage for tools and rovers, only limited automated production, no own management. They would be just "colonies" for satifying the demands of the, well, other colonies.

[mokun]

this function is still blocked - we can't found new outposts during simulation

Fixing this now at here.

[mokun]

@Urwumpe

Or having a process in which the AI engineers upgrades of the existing bases, like new construction missions.

But what are the mission aspects of expanding a typical settlement ?

I almost feel like we need to CLEARLY DEFINE goals for players to follow through, instead of just giving them a sandbox to play whatever they want.

[Urwumpe]

I don't opposite this tutorial idea, but I think we can also have it in sandbox.

My idea there would be that there is a feedback loop including the minds of the settlers, that specifies which demands on the settlement they have. My earlier suggestion was using a ERG model there for modelling how demands change, while maybe learning from Maslow, what kinds of specific demands could exist. Additionally, for the beginning, we could also have Earth specifying their demands and assisting in survival. Which might be a good extension point for scripted tutorials as well.

[mokun]

My earlier suggestion was using a ERG model there for modelling how demands change, while maybe learning from Maslow, what kinds of specific demands could exis

So, you see the value of giving each settler on Mars desires, much like the Sims, right ?

Say, under the Command Mode, one of the goals of the player is to help fulfill these individual desires under the Maslow Hierarchy.

When a desire is met, the player can get more leadership points, for instance.

The settlers who have the desires fulfilled will also be more motivated to do the player's bidding, etc.

But you're saying there's also a layer of the overall settlement's demand that the player needs to meet.

If fulfilled successfully within a certain period of time, the player can get promoted or score more or something.

[mokun]

@Urwumpe

And we still have no use for the ERVs (why should we, the settlers die faster than they could return to Earth).

Yes since MarsOne is now out of the picture, we need to piece together in how the ERV can be used, instead of making it like a resource processing plant.

But to do so, we need to take a look at the current weight of each item and sum them up to see if it makes sense to bring them to Mars and if it's feasible on the kind of payload space we envision...

May be only after we add in new codes to check for the space and weight requirement, then we can work on using ERV to return people and items ?!

What do you think ?

[mokun]

@bevans2000 ,

What change in the current code architecture do you envision to enable the ERV to return back to Earth ?

[bevans2000]

The key aspects when do the people go out of scope. Once the ERV takes off then they have to be removed from the updating pulse logic.

[mokun]

The key aspects when do the people go out of scope. Once the ERV takes off then they have to be removed from the updating pulse logic.

Sure.

What if we create a virtual location called earth as well as the moon base ?

Then we can build some rules for the settlement on Mars to trade resources with these two super remote locations

Also, we can think of offloading people there for vacation and/or business or work visit , or even setting up contractual agreement to (re)hire them to come back and forth to Mars to work.

This will be more realistic for corporations that may be expanding off-world locations

[Urwumpe]

What do you think ?

Well, maybe it would already be enough to start at the ERV with two functions:

1. Source for produced fuel for return trip. Has to be fueled for return.
2. Return settlers to Earth after their time on Mars.

For the first one, we should have pretty much everything in place already.
For the second function, the Settlers would first need a specification of how and how long they stay on Mars. Maybe give them different "Mars tickets", with the types of possible Mars tickets initially being configured in XML.

Next, we should give them tasks at different intensity and priority to prepare for leaving Mars as the end of their stay approaches. Packing their bags. Preparing the ERV, getting suited up, leave mars. Missions and new research projects would have to be banned for them as soon as the departure approaches.

At one point, there might be more or less seats available in a ERV for the astronauts to leave Mars, maybe we need some kind of smarter logistics there then, aside of just letting a settler spend more time on Mars.

[mokun]

For the second function, the Settlers would first need a specification of how and how long they stay on Mars. Maybe give them different "Mars tickets", with the types of possible Mars tickets initially being configured in XML.

Sure. To do so, we need to figure out the REASON for anyone coming to Mars, or going to the Moon.

Their rationale will drive their actions, right ?