Closed BottledByte closed 5 months ago
Example of story/plot resulting from starting scenarios follows:
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:
Obviously, even combinations those 6 base Starting Scenarios could result in "unique stories" or interpretations, like:
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.
And this starting scenario should be visible where races, governments and elder realm is being selected, not in possible space race creation.
I would not remove Alonians, just remove their starting scenario.
I already did locally :slightly_smiling_face: . 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 :smile: It took me less time than fixing Unit tests :upside_down_face:
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 :slightly_smiling_face:. 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 :unamused: ).
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 :slightly_smiling_face: .
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 RaceTrait
s. 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 RaceTrait
s 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! :smile: ). 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.
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
RaceTrait
s. While it is better than doing it withSpaceRace
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
RaceTrait
s 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.
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! :smile: And as you say, even in such edge case, the game is technically completely playable, practically adding a new "nomad mode" :smile: .
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).
:+1: I see nothing wrong when StarMap will get some cleanup WHILE new planetary mechanics are implemented. The tests will likely have different opinion. :slightly_smiling_face:
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 RaceTrait
s 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" :smile: . 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.
I have derailed the issue a little, this should be in GH-673. :smile:
π 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.
:+1:
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. :smile:
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
RaceTrait
s 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.
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:
StarMapGenerator.java
, roughly lines 886-927.StartingScenario
enum
values are too granular while having similar effects. This introduces promotes duplicate code.enum
(simulated by additional enum values)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").JComboBox
es with overly long definitions of starting scenarios.JComboBox
es 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.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 :upside_down_face:
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:
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 :smile: ). 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" :smile:
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 :smile:
@tuomount I hope this feedback will be useful :+1:
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. somethingMap<>
-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
JComboBox
es 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
JComboBox
es 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.
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 π.
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
vsTEMPERATE_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 in0.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. :+1:
Closing.
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:
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. :slightly_smiling_face:
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
RaceTrait
s 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.