Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realm Starting Scenario System #700

Closed
BottledByte opened this issue Dec 28, 2023 · 11 comments
Closed

Realm Starting Scenario System #700

BottledByte opened this issue Dec 28, 2023 · 11 comments
Labels
enhancement Feature request Game mechanics New game feature to game mechanics Graphics Image or animation issue GUI Graphical User Interface issue Wait for verify Issue has been implemented but needs verification that it works.
Milestone

Comments

@BottledByte
Copy link
Contributor

Realm starting conditions are only loosely coupled to race from a logical point of view. When creating a realm/empire, there could be a list of possible starting scenarios, which affect things like what Technology realm starts with, where it starts, and potentially some game-changing elements.

Currently, there is mess in concept of what realm even is and how it starts:

  1. There is an "elder realm" mechanic, which gives the realm a headstart,
    allowing it to "play" before game starts for others.
  2. Then there is the Alonians race, which starts in space, without homeworld.
    And it can find a broken planet (their possible former homeworld) and get a bonus for this deed as a result.
  3. Sporks start with bonus ships.
  4. Mothoids start without some techs.
  5. Greyans start with extra tech.
  6. And finally, Human race may get a predefined system (Sol) when map is generated.

The Starting Scenario system should replace points 2 and 6. The "Elder Realm" system would became a "Headstart" system (what it really is), that could be combined with (presumably any) Starting Scenario.

Starting Scenario should define core behavior of how realm starts and what "extra goals" it may have (i.e. finding lost homeworld, like Alonians). Starting Scenario should be able to take arguments when applicable, one of those arguments being for example "special" solar system (like Humans have).

Such system could massively enhance game generation, leading to new and unique experience across games. It could be used in procedural generation of whole games, creating "stories"/"plots". Starting Scenarios would additionally replace/alter
"background story generation" by a great degree, while having real impacts to gameplay.

Scenario should mostly result in somewhat balanced starting conditions with other scenarios, but it is not required. On the contrary, having few rather unbalanced Starting Scenarios could result in unique situations. And of course, those scenarios then can be scored, to be able to measure how "balanced" they are.
This was inspired by Cataclysm: Dark Days Ahead starting scenarios. 🙂

Finally, such starting scenario system, even a primitive one, IS REQUIRED ALREADY and long due.
The enumeration above shows it nicely. Plus the Alonian "scenario" is completely breaking game's logical structuring, and cannot be represented in a good way with any existing construct in the code (and RaceTraits are not applicable, as Homeless is not a lasting trait, obviously).

Creation of such system should be done after dehardcoding SpaceRaces (part of GH-666), to design the system more isolated and flexible from ground-up. Alonians cannot be dehardcoded without existence of Starting Scenario system.

Logical conclusion is to remove Alonians until existence of such system.

Other races "starting specialties" can be removed without removal of the whole race.
It will also simplify StarMap generation and simplify it's (badly needed) refactor.

@BottledByte
Copy link
Contributor Author

Example of story/plot resulting from starting scenarios follows:

  • Realm A mysteriously appearing in the galaxy ("Homeless" Scenario)
  • Realm B discovering ancient secrets of their homeworld, getting advanced tech at start ("Legacy" Scenario)
  • Realm A is searching answer for their existence/appearance ("Homeless" parameter/argument)
  • Realm A discovers that the answer may be on homeworld of realm B (via pre-crafted anomaly or event)
    • Could use (hidden) PlanetaryStatuses for the planet
  • If realm A captures/acquires homeworld of realm B, it might get a special tech (i.e. Ascension)
  • Realms C to F started as usual ("Normal" Scenario)
    • They will be likely unaware of the "plot"
    • They might fight with Realm B, since it is technologically superior and a threat
  • Realm E started in custom system ("Normal" Scenario parameter)
  • Realm F started sooner than others (Realm got Headstart)

Note that the made-up scenarios "Homeless" and "Legacy" can perfectly work alone, in this particular sample they just randomly combined, creating unique gameplay, where one realm has gameplay-level incentive to capture planet of other realm. Planet with answers could be any other planet of any other realm, but in this case, it "accidentally" created a plot/story.

Here is compiled ideas for Starting scenarios:

  • Normal - Normal evolution and discovery of FTL
    • Param: System - Start in specified system "kind"
  • Homeless - Realm starts without a homeworld
    • Kind: Loss - Realm knows it lost their homeworld, may search for it (like Alonians)
    • Kind: Appearance - Realm appears in galaxy without prior knowledge, may search for answer
  • Legacy - Starts on advanced/ancient homeworld, gets bonus tech/buildings
    • Param: System - Start in specified system "kind"
  • Arrival - Starts with several scattered fleets
  • Disaster - Starts on a dying world, have to find new home
    • Kind: Disease - Diseases are prevalent on homeworld, greatly lowering population (growth)
    • Kind: Natural - Meteorites, sun going supernova soon, etc.
  • Grand failure - High-tech mega-experiment (ascension?) failed, blasting the former super-advanced realm
    into stone age, it's homeworld destroyed. Starts on an underdeveloped former colony, with few, very advanced tech,
    and maybe one advanced fleet, but unable to build more due to lost homeworld, drained resources on the colony and general tech-loss.

Obviously, even combinations those 6 base Starting Scenarios could result in "unique stories" or interpretations, like:

  • Disasters being omen that a Arrival of some "galactic scourge" is coming
  • Homeless races seeking their homeworld which might got accidentally caught in Grand failure of other realm
  • Realms with Legacy being "last chance" for galaxy before invaders who Arrived conquer it whole
  • Realms who suffer from a Disaster trying to save themselves by attacking Normal realms' systems

@tuomount
Copy link
Owner

This sounds good idea, I would not remove Alonians, just remove their starting scenario. I would also limit that all except normal there can be only one realm per game. This would easy making story a bit easier for example single destroyed homeworld is enough. So in sense starting scenario could be done already, just put normal for all.

Could you see trait like "Starting bonus: Extra scout" - This would give extra scout ship on start. Similarly there could be tech boost on every technology category. But I would not worry about too much, since when temperature, gravity and radiation is reworked there might need for balancing.

@tuomount
Copy link
Owner

And this starting scenario should be visible where races, governments and elder realm is being selected, not in possible space race creation.

@BottledByte
Copy link
Contributor Author

I would not remove Alonians, just remove their starting scenario.

I already did locally 🙂 . This removed over 850 lines (less things to break). Except their starting scenario, the race has only bonus to research "in space", but that is quite little to offer. Furthermore, it is speculative if "bonus research in space" is even a trait. On one way, it could be (like species is good working in-space), but this does not apply for Alonians lore-wise. It makes more sense that such bonus is in fact a rare tech, that can be found only through "great loss" (so melodramatic). The Tech approach even makes game more interesting, as other realms might want to get hands on such tech, which they can only hard research by themselves (giving owner of the unique tech a trading leverage).

After such analysis, it is clear that Alonians are just slightly different Spork or Human, and their presence does not bring much gameplay value. It is their "scenario" that adds majority of the value, which will be removed/disabled. And less code -> less things to break.

@tuomount , I can submit PR for Alonian removal on your word or just discard it 😄
It took me less time than fixing Unit tests 🙃

I would also limit that all except normal there can be only one realm per game

The system should be designed to handle multiple scenarios combined where possible. It can be artificially limited, but it should be able handle variety. It adds more gameplay value and keeps doors open for addition of new scenarios.

With the system as I described it, it is also possible to create "Game scenarios" on top of it, where Realm Start Scenarios are specifically assigned and fine-tuned for a specific "global story" (like combinations I described in my previous comment). Basically ability to add new game mode like "Challenge" or something with few hundreds of lines.

So in sense starting scenario could be done already, just put normal for all.

Not really true, as it is needed to model such system before that 🙂. For that to happen, StarMap generation should get refactored somewhat, so it is more clear how to pull that off. Code should be generic first, with some truly rare/edge cases being hardcoded. Not the other way around (like it is in majority of the codebase 😒 ).

Regarding StarMap refactor, I would appreciate that you queue that up in your schedule (after migration to RaceTraits), since those 6000 lines there are mostly incomprehensible for me 🙂 .

Could you see trait like "Starting bonus: Extra scout" - This would give extra scout ship on start. Similarly there could be tech boost on every technology category.

No, no, no... Starting tech level is not related to race, obviously. This is prevalent issue in design of this game. Realm is mixed up with Race.
I am trying to decouple the things, while you are coupling it again with this new tool called RaceTraits. While it is better than doing it with SpaceRace enum, using traits for this should be an "emergency fallback" only, where proper abstraction is not available or too costly (I am aware of flexibility of flagging systems, it is the reason why I added them to the game).

To clarify how RaceTraits should be designed and understood:
RaceTrait is something that is bound to the race's physique and fundamental mentality. Think about it like how would you describe a race's individual. "Smart", "Tall", "Secretive", "Hardworking", "Long-lived", "Eating stones"... mostly adjectives. It is both understandable to players and maintains natural logic.
You would not describe race individual with "Has bonus ships" or "Gets better propulsion tech" -> they are not traits.

And be careful to not overuse with traits describing race mentality!
Why there could not be two realms with same race, but only different mentality. Like lost expedition or something (wow, another starting scenario! 😄 ). That's open, so let's stay conservative here.

But I would not worry about too much, since when temperature, gravity and radiation is reworked there might need for balancing

That's sure thing, and it is yet another reason why systems should be modular as much as reasonably possible, to be able to react on balancing issues, new mechanics additions, etc. GameDev is iterative in nature.

@tuomount
Copy link
Owner

I already did locally 🙂 . This removed over 850 lines (less things to break). Except their starting scenario, the race has only bonus to research "in space", but that is quite little to offer. Furthermore, it is speculative if "bonus research in space" is even a trait. On one way, it could be (like species is good working in-space), but this does not apply for Alonians lore-wise. It makes more sense that such bonus is in fact a rare tech, that can be found only through "great loss" (so melodramatic). The Tech approach even makes game more interesting, as other realms might want to get hands on such tech, which they can only hard research by themselves (giving owner of the unique tech a trading leverage).

After such analysis, it is clear that Alonians are just slightly different Spork or Human, and their presence does not bring much gameplay value. It is their "scenario" that adds majority of the value, which will be removed/disabled. And less code -> less things to break.

Yes, main point of Aloniams was just it starts differently than Human or Spork. So in that sense it makes sense to remove Alonians. And probably add them later, or at least keep graphics for custom race selection.

@tuomount , I can submit PR for Alonian removal on your word or just discard it 😄 It took me less time than fixing Unit tests 🙃

Submit the PR for Alonian removal.

The system should be designed to handle multiple scenarios combined where possible. It can be artificially limited, but it should be able handle variety. It adds more gameplay value and keeps doors open for addition of new scenarios.

True, but there can be some other unexpected issues for example scenario where there is no starting planets for all realms. Domination victory would not be possible, but on the other hand starting such way would be equal to all.

With the system as I described it, it is also possible to create "Game scenarios" on top of it, where Realm Start Scenarios are specifically assigned and fine-tuned for a specific "global story" (like combinations I described in my previous comment). Basically ability to add new game mode like "Challenge" or something with few hundreds of lines.

So in sense starting scenario could be done already, just put normal for all.

Not really true, as it is needed to model such system before that 🙂. For that to happen, StarMap generation should get refactored somewhat, so it is more clear how to pull that off. Code should be generic first, with some truly rare/edge cases being hardcoded. Not the other way around (like it is in majority of the codebase 😒 ).

Regarding StarMap refactor, I would appreciate that you queue that up in your schedule (after migration to RaceTraits), since those 6000 lines there are mostly incomprehensible for me 🙂 .

I could also create in same refactor those traits for gravity, temperature and radiation. So this would affect on mining speed, production speed, troop power and maxrad(This will change the name).

Could you see trait like "Starting bonus: Extra scout" - This would give extra scout ship on start. Similarly there could be tech boost on every technology category.

No, no, no... Starting tech level is not related to race, obviously. This is prevalent issue in design of this game. Realm is mixed up with Race. I am trying to decouple the things, while you are coupling it again with this new tool called RaceTraits. While it is better than doing it with SpaceRace enum, using traits for this should be an "emergency fallback" only, where proper abstraction is not available or too costly (I am aware of flexibility of flagging systems, it is the reason why I added them to the game).

To clarify how RaceTraits should be designed and understood: RaceTrait is something that is bound to the race's physique and fundamental mentality. Think about it like how would you describe a race's individual. "Smart", "Tall", "Secretive", "Hardworking", "Long-lived", "Eating stones"... mostly adjectives. It is both understandable to players and maintains natural logic. You would not describe race individual with "Has bonus ships" or "Gets better propulsion tech" -> they are not traits.

Okay, makes sense. Let's keep this way. RaceTraits are only for physique or fundamental mentality. In that case each race should be able to choose what ever government type, even Hiveminds. This could create situation for example Human AI. Maybe the could be that in some scenario Humans would developed AI where all are connected.

And be careful to not overuse with traits describing race mentality! Why there could not be two realms with same race, but only different mentality. Like lost expedition or something (wow, another starting scenario! 😄 ). That's open, so let's stay conservative here.

What do you mean mentality in this case. I am not sure if I understand this one.

That's sure thing, and it is yet another reason why systems should be modular as much as reasonably possible, to be able to react on balancing issues, new mechanics additions, etc. GameDev is iterative in nature.

True.

@BottledByte
Copy link
Contributor Author

True, but there can be some other unexpected issues for example scenario where there is no starting planets for all realms. Domination victory would not be possible, but on the other hand starting such way would be equal to all.

And for those cases... for those cases we hardcode checks! 😄
And as you say, even in such edge case, the game is technically completely playable, practically adding a new "nomad mode" 😄 .

I could also create in same refactor those traits for gravity, temperature and radiation. So this would affect on mining speed, production speed, troop power and maxrad(This will change the name).

👍 I see nothing wrong when StarMap will get some cleanup WHILE new planetary mechanics are implemented. The tests will likely have different opinion. 🙂

In that case each race should be able to choose what ever government type, even Hiveminds. This could create situation for example Human AI. Maybe the could be that in some scenario Humans would developed AI where all are connected.

Exactly. More variety, more content, more gameplay value, less work! And any potential limits to governmental types can be imposed by RaceTraits, if really needed to keep balance, sense or something.

What do you mean mentality in this case. I am not sure if I understand this one.

For example the tendency towards individualism vs collectivism behavior. Or pacifism vs militarism. Or acceptance of other races. Or aggressiveness. Mostly things that could affect societal structure or large-scale behavior of the race or diplomatic tendencies (You can sort of think in scope of Attitude type in game code).
In other words: RaceTraits should have smallest "behavioral coupling" possible.

For example, there can be a trait "Stealthy", but "Secretive" probably no.

"Stealthy" would give bonuses to cloaking and espionage missions. It would represent that the race can be unnaturally stealthy (like having some chameleon-like abilities or something). This trait would imply that the race's "attitude" should be likely secretive, but it may be actually rather direct. Perhaps because this trait evolved as a reaction to some now-extinct predator, which got extinct because the race changed their "attitude" at some point, and rather than hiding, they hunted and exterminated the predator on their homeworld. This trait has small "behavioral coupling".

"Secretive" could also give bonuses to stealth, but it would bound the behavior of the race to the trait, which should affect things like diplomatic tendencies (which is coupling the design, limiting variety/extensibility). It "could" be a trait, but due to strong "behavioral coupling", it should probably not. (I wrote it previously as a sort of example of possible, but maybe not the best trait).

In your example with Human AI:
We could say that Humans have trait "Sociable" or similar trait, to represent their bonuses to diplomacy.
However, it should not mix-up too much with their mentality, whether they are democratic individualists who value life of their peers, or connected collective mass where life of an individual is worthless.
In this case, trait like "Natural charm" would be more preferred, as "Sociable" has obviously stronger "behavioral coupling". Both are acceptable, but one is just more acceptable than the other as it keeps design simple and more generic.

Is this explanation of how to design RaceTraits in terms of race's "mentality" more clear?
As I said, the mechanism of how to deal with this design-wise is open.

BTW, I would create and put "Stealthy" trait to Theuthidaes, to replace that horrible trait "+10 to cloaking" 😄 . Espionage mission mechanics would also benefit from fact that some races are "just better spies".
And create "Charming" and "Repulsive" traits to represent diplomatic bonus/malus.

If you are OK with that, I will open a PR for those traits.

@BottledByte
Copy link
Contributor Author

I have derailed the issue a little, this should be in GH-673. 😄

@tuomount
Copy link
Owner

👍 I see nothing wrong when StarMap will get some cleanup WHILE new planetary mechanics are implemented. The tests will likely have different opinion. 🙂

In that case each race should be able to choose what ever government type, even Hiveminds. This could create situation for example Human AI. Maybe the could be that in some scenario Humans would developed AI where all are connected.

Exactly. More variety, more content, more gameplay value, less work! And any potential limits to governmental types can be imposed by RaceTraits, if really needed to keep balance, sense or something.

👍

What do you mean mentality in this case. I am not sure if I understand this one.

For example the tendency towards individualism vs collectivism behavior. Or pacifism vs militarism. Or acceptance of other races. Or aggressiveness. Mostly things that could affect societal structure or large-scale behavior of the race or diplomatic tendencies (You can sort of think in scope of Attitude type in game code). In other words: RaceTraits should have smallest "behavioral coupling" possible.

So you would cut of attitude off from the space race and only use attitude from ruler. That would work fine, except when ruler dies and there is no new ruler. This is one reason why there is that default attitude. Of course that could be probably generated from traits, but something else would be better. I just don't know what. Or maybe it could be just randomized at beginning of the game for each AI. But on other hand something like Reborgians probably would not works as diplomatic traders. 😄

For example, there can be a trait "Stealthy", but "Secretive" probably no.

"Stealthy" would give bonuses to cloaking and espionage missions. It would represent that the race can be unnaturally stealthy (like having some chameleon-like abilities or something). This trait would imply that the race's "attitude" should be likely secretive, but it may be actually rather direct. Perhaps because this trait evolved as a reaction to some now-extinct predator, which got extinct because the race changed their "attitude" at some point, and rather than hiding, they hunted and exterminated the predator on their homeworld. This trait has small "behavioral coupling".

"Secretive" could also give bonuses to stealth, but it would bound the behavior of the race to the trait, which should affect things like diplomatic tendencies (which is coupling the design, limiting variety/extensibility). It "could" be a trait, but due to strong "behavioral coupling", it should probably not. (I wrote it previously as a sort of example of possible, but maybe not the best trait).

Makes sense.

In your example with Human AI: We could say that Humans have trait "Sociable" or similar trait, to represent their bonuses to diplomacy. However, it should not mix-up too much with their mentality, whether they are democratic individualists who value life of their peers, or connected collective mass where life of an individual is worthless. In this case, trait like "Natural charm" would be more preferred, as "Sociable" has obviously stronger "behavioral coupling". Both are acceptable, but one is just more acceptable than the other as it keeps design simple and more generic.

Is this explanation of how to design RaceTraits in terms of race's "mentality" more clear? As I said, the mechanism of how to deal with this design-wise is open.

BTW, I would create and put "Stealthy" trait to Theuthidaes, to replace that horrible trait "+10 to cloaking" 😄 . Espionage mission mechanics would also benefit from fact that some races are "just better spies". And create "Charming" and "Repulsive" traits to represent diplomatic bonus/malus.

I just like that +5 cloaking(Just enough to get invisibility at beginning of the game, this should also give bonus for not getting detected in espionage missions.), since it has create such interesting story telling events at beginning of the game. I have had war against some third realm and moved my ships away from my own planet. Then out of nowhere cloaked ship arrives on my planet and I cannot get to orbit anymore. Now my options are start war against those cloaked ships, or research planetary scanner or hope it just goes away. I know that this isn't racial trait it is more like technological thing, but so is also Centaur's more rigid ships.

But yes there could be trait for better spy which would give bonus for espionage missions.

Charming and repulsive I was planning to add give diplomatic bonus. Humans should have diplomatic or similar trait which would give +2, charming +1, repulsive -2. Population rush could give -1 diplomacy bonus so that would explain why it cost zero points. But anyway this can be tuned later.

If you are OK with that, I will open a PR for those traits.
Those diplomatic traits sounds fine, but not sure about removing that built-in cloaking device.

@tuomount tuomount added enhancement Feature request GUI Graphical User Interface issue Game mechanics New game feature to game mechanics Graphics Image or animation issue labels Dec 29, 2023
tuomount added a commit that referenced this issue Feb 1, 2024
There are now three different scenarios:
Random, Temperate, humid planet size 12 and Earth.
@tuomount tuomount added this to the 0.26.0 milestone Feb 1, 2024
tuomount added a commit that referenced this issue Feb 2, 2024
Fixes few JUnits.
Fixes one missing temperature from toString().
Adds maximum population amount in planet view.
tuomount added a commit that referenced this issue Feb 8, 2024
tuomount added a commit that referenced this issue Feb 24, 2024
@BottledByte
Copy link
Contributor Author

I did a review of the current implementation, both code-wise and from a player's point of view.
Here are some comments and findings:

  • New copy-pasted duplicate code was introduced, which may be even not working as intended.
    In file StarMapGenerator.java, roughly lines 886-927.
  • StartingScenario enum values are too granular while having similar effects. This introduces promotes duplicate code.
  • It is not possible to configure "parameters" of a scenario because of the enum (simulated by additional enum values)
  • Usage of text IDs instead of numeric IDs is recommended - ID of StartingScenario is neither accessed often (performance), nor stored in many objects (memory). Text ID offers more resilience in save migration, is human readable, etc.
  • Having starting scenarios implemented as enum is likely not long-term sustainable. Using either "bunch of data" (i.e. something Map<>-based) or "derived class per scenario type" + instanceof might end up more maintainable and/or extensible.
  • RANDOM StartingScenario enum value should probably not exist as "starting scenario". It is technically a GUI thing, a "pseudo starting scenario", which makes code once again more confusing (and needs special handling, like with "pseudo-races").
  • "Realm Setup" screen is stretched "out of window horizontally", even at window size greater than 1600. I believe it is caused by Swing framework trying to accommodate for JComboBoxes with overly long definitions of starting scenarios.
  • Better UI and player UX will likely have to be developed in order to pull this off. All the JComboBoxes and other fields under the image of a race feel more and more cluttered and/or confusing as new fields are added, while there are large "empty" parts of the screen.
  • Overhaul/Redesign of "Realm Setup" screen is good idea when adding this feature (as well as because of Design Proposal - Race Traits #673).
  • I like the addition of "Farming planet" scenario with bonus facilities and without ships. 👍 It can simulate things like "happy rural societies", where the realm/race is "uninterested" in space travel because they like how they live. I think there is potential in that scenario. Maybe add a penalty to "Hulls" tech, so one have to even research what "space ship" is?
    But IMHO could use a more "poetic" name , like "Utopia World" or something 🙂.

I consider current implementation as a prototype, to test how starting scenarios could look like. Therefore I recommend to refrain from adding too much "flavor" with this design now, as it seems rather crude, both code-wise and UX-wise. Another "dehardcoding the all-doing SpaceRace enum" is not what OROS needs 🙃


Current scenarios feel rather the same, that is, several scenarios are technically "configurations" of the "Normal" scenario, as I described here previously. Those "configurations" clutter current UI. While parameters of a homeworld can be huge deal-breaker in game (depending on race), from "narrative" and "features" points of view, they don't add much value.

The idea was that starting scenarios have parameters.
Exact details of a scenario would be parameters, while the "meta-scenario" (Normal, Homeless, Legacy, Disaster, etc) define the "features" and "feel" of a scenario. There are currently like 3 "meta-scenarios" implemented, as per the example list I compiled in previous comments:

  • Normal (normal ships, start some planet or in the Sol system, get compensated by extra tech for difficulties)
  • Homeless (start without homeworld, with or without extra tech)
  • Farming world (no ships, developed homeworld)

Those 3 give different feeling - first is "OROS as usual", second is "find a suitable planet quickly", and the last one is "reach space". TEMPERATE_MARINE_SIZE9 vs TEMPERATE_MARINE_SIZE14 feels the same, just with different planet size and gravity. Although, having the option to define such detail might also be appreciated by some players (when min-maxing or whatever)! "Scenario parameters" seem like a solution for this.
I should be seeing a short list of rather different scenarios, but I have the option to further tweak them.
I know that starting scenarios are WIP and subject of discussion, but this a general observation regarding "samey content".

And I think that supporting such "scenario parameters" system will just not go well with purely "enum based" implementation - because then one has to have those tons of cases, like with "high/low" planet gravity, etc., as is now.


The RANDOM "scenario", could be, for example, replaced by list of check-boxes, which would say which scenarios "player is willing to play". For example, player does not care whether to play a "Normal" or "Legacy", but does not want to play "Homeless". Such UI design would technically solve even a selection of a single scenario (by unchecking everything except one) or "totally random" (by un/checking everything).

The "Realm Setup" screen needs a redesign/overhaul anyway. I remember it was the basically the same back in 0.8.0Beta (first version of OROS I played 😄 ). But back then, there were only 8 realms max, no color selection, no elder realms, no race traits, no starting scenarios.
It worked from UX perspective back then, but it does not anymore - I will skip the bug that was in 0.8.0Beta, where buttons were not being draw within the window's viewport in "Realm Setup" 😄

But "Realm Setup" overhaul/redesign deserves it's own tracking issue, so I will stop elaborating more here.
I don't want to derail this issue... again 😄

@tuomount I hope this feedback will be useful 👍

@tuomount
Copy link
Owner

I did a review of the current implementation, both code-wise and from a player's point of view. Here are some comments and findings:

  • New copy-pasted duplicate code was introduced, which may be even not working as intended.
    In file StarMapGenerator.java, roughly lines 886-927.
    I'll take a look of this.
  • StartingScenario enum values are too granular while having similar effects. This introduces promotes duplicate code.

I'll choose going with enums, since I think creating different starting scenarios, might require new code a bit there and there, creating such with parameters is going to be bit challenge.

  • It is not possible to configure "parameters" of a scenario because of the enum (simulated by additional enum values)

Not sure if parameters are needed.

  • Usage of text IDs instead of numeric IDs is recommended - ID of StartingScenario is neither accessed often (performance), nor stored in many objects (memory). Text ID offers more resilience in save migration, is human readable, etc.

Currenly save files are not human readable, those are just binary files. Only good thing is that they are decent in size and are relatively fast to load. Even with long games, game files rarely take more than 2MBs, even they contain full history of the game.

  • Having starting scenarios implemented as enum is likely not long-term sustainable. Using either "bunch of data" (i.e. something Map<>-based) or "derived class per scenario type" + instanceof might end up more maintainable and/or extensible.
    This would good if starting scenarios would be in data files, but not sure how much of work that is going to be. Plus with that JSON data files, only parameters are customize able, like how many scouts are created, what techs are gained and so on, but not totally unique starting scenarios.
  • RANDOM StartingScenario enum value should probably not exist as "starting scenario". It is technically a GUI thing, a "pseudo starting scenario", which makes code once again more confusing (and needs special handling, like with "pseudo-races").
    Yes this is definitly GUI thing, but I quickly learned that this needs to be done since selecting starting scenario for each realm is quite a task.
  • "Realm Setup" screen is stretched "out of window horizontally", even at window size greater than 1600. I believe it is caused by Swing framework trying to accommodate for JComboBoxes with overly long definitions of starting scenarios.
  • Better UI and player UX will likely have to be developed in order to pull this off. All the JComboBoxes and other fields under the image of a race feel more and more cluttered and/or confusing as new fields are added, while there are large "empty" parts of the screen.

Yes, I agree realm setup has grown out of it's original purpose and needs to be redesign. Not sure how it should look like, separate view for each realm, but seeing all (currently 8) is also beneficial.

  • I like the addition of "Farming planet" scenario with bonus facilities and without ships. 👍 It can simulate things like "happy rural societies", where the realm/race is "uninterested" in space travel because they like how they live. I think there is potential in that scenario. Maybe add a penalty to "Hulls" tech, so one have to even research what "space ship" is?
    But IMHO could use a more "poetic" name , like "Utopia World" or something 🙂.

Names can be changing farming planet is now that good since robots got factories and lithovorians get mines so Utopia world sounds good. I have tried this starting scenario and this is actually quite a penalty, since realm totally misses early exploration.

I consider current implementation as a prototype, to test how starting scenarios could look like. Therefore I recommend to refrain from adding too much "flavor" with this design now, as it seems rather crude, both code-wise and UX-wise. Another "dehardcoding the all-doing SpaceRace enum" is not what OROS needs 🙃

Current scenarios feel rather the same, that is, several scenarios are technically "configurations" of the "Normal" scenario, as I described here previously. Those "configurations" clutter current UI. While parameters of a homeworld can be huge deal-breaker in game (depending on race), from "narrative" and "features" points of view, they don't add much value.

Reason why there are many "normal" scenarios is that I noticed that otherwise each realm would start on swamp planet which was getting boring. I was thinking maybe just categorize these under normal and silently pick one at background. Now there can desert planets, ice planets and marine planets.

The idea was that starting scenarios have parameters. Exact details of a scenario would be parameters, while the "meta-scenario" (Normal, Homeless, Legacy, Disaster, etc) define the "features" and "feel" of a scenario. There are currently like 3 "meta-scenarios" implemented, as per the example list I compiled in previous comments:

  • Normal (normal ships, start some planet or in the Sol system, get compensated by extra tech for difficulties)
  • Homeless (start without homeworld, with or without extra tech)
  • Farming world (no ships, developed homeworld)

Those 3 give different feeling - first is "OROS as usual", second is "find a suitable planet quickly", and the last one is "reach space". TEMPERATE_MARINE_SIZE9 vs TEMPERATE_MARINE_SIZE14 feels the same, just with different planet size and gravity. Although, having the option to define such detail might also be appreciated by some players (when min-maxing or whatever)! "Scenario parameters" seem like a solution for this. I should be seeing a short list of rather different scenarios, but I have the option to further tweak them. I know that starting scenarios are WIP and subject of discussion, but this a general observation regarding "samey content".

So, yes it would make sense to have parameters these parameters could be loaded from JSON and just change the overall starting scenarios, Normal, Homeless, Farming world

And I think that supporting such "scenario parameters" system will just not go well with purely "enum based" implementation - because then one has to have those tons of cases, like with "high/low" planet gravity, etc., as is now.

The RANDOM "scenario", could be, for example, replaced by list of check-boxes, which would say which scenarios "player is willing to play". For example, player does not care whether to play a "Normal" or "Legacy", but does not want to play "Homeless". Such UI design would technically solve even a selection of a single scenario (by unchecking everything except one) or "totally random" (by un/checking everything).

This sounds like good idea, but definitely needs own UI.

The "Realm Setup" screen needs a redesign/overhaul anyway. I remember it was the basically the same back in 0.8.0Beta (first version of OROS I played 😄 ). But back then, there were only 8 realms max, no color selection, no elder realms, no race traits, no starting scenarios. It worked from UX perspective back then, but it does not anymore - I will skip the bug that was in 0.8.0Beta, where buttons were not being draw within the window's viewport in "Realm Setup" 😄

But "Realm Setup" overhaul/redesign deserves it's own tracking issue, so I will stop elaborating more here. I don't want to derail this issue... again 😄

@tuomount I hope this feedback will be useful 👍

Yes this was useful, thanks. 👍

tuomount added a commit that referenced this issue Mar 4, 2024
tuomount added a commit that referenced this issue Mar 31, 2024
tuomount added a commit that referenced this issue Apr 7, 2024
tuomount added a commit that referenced this issue Apr 29, 2024
Add production planet with two factors and two mines.
Add metal planet with single factory where metal is already mined.
tuomount added a commit that referenced this issue May 2, 2024
Planet has 3 factories and 3 mines, but those are expensive.
Starting credits run out in 6 turns.
tuomount added a commit that referenced this issue May 3, 2024
Now it has 50 credits, so there are more choices how to use it before
credits run out. It can be used to purchase something, keep production
high and building something regularly. Combine these two or just save it
and get new ruler soon.
tuomount added a commit that referenced this issue May 4, 2024
Planet turns into volcanic world in 80-120 star years.
tuomount added a commit that referenced this issue May 10, 2024
Fixes doomed planet world type and amount of metal.
tuomount added a commit that referenced this issue May 11, 2024
Now same status is added only once.
Tectonic quake cannot kill zero gravity beings.
Fixed city in fire picture.
tuomount added a commit that referenced this issue May 11, 2024
Event happens now more close 120 star years.
There is image of new planet when event happens.
tuomount added a commit that referenced this issue May 14, 2024
This scenario is not allowed if only single technology advancement is
required since starting planet is already one.
tuomount added a commit that referenced this issue May 15, 2024
Started to plan/design global warming, but might be too complex to
implment into this version.
@tuomount tuomount added the Wait for verify Issue has been implemented but needs verification that it works. label May 17, 2024
@tuomount
Copy link
Owner

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request Game mechanics New game feature to game mechanics Graphics Image or animation issue GUI Graphical User Interface issue Wait for verify Issue has been implemented but needs verification that it works.
Projects
None yet
Development

No branches or pull requests

2 participants