Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: 1 ... 4 5 [6]

Author Topic: Building Better Worlds  (Read 43514 times)

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: Building Better Worlds
« Reply #75 on: February 25, 2017, 10:46:29 AM »

Quote
feedback welcome! I did document how they work, but it does seem like it didn't exactly take off as far as being used by mods. I don't think it'd be practical to change anything major about it at this point, but, still.
Personally, I found it a bit difficult to get the rules to do much, and found myself re-writing the code used to generate those UIs rather than mess with them further. 

I think that you're in danger of creating a meta-language here that just makes things more obscure, rather than less; I'd honestly recommend that the code governing the operation of the Rules gets pretty explicitly documented at some point.  But not right now; it's too much of a waste of time, I'd imagine, with things getting refactored fairly often.  If I ever feel like diving back into a major mod for this game again, I'll give more feedback at that time :)
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23988
    • View Profile
Re: Building Better Worlds
« Reply #76 on: February 25, 2017, 11:17:17 AM »

I opened the thing once trying to localize Starsector into Korean. Then it got updated... made me quit the project.

I think that's more to do with the inherent issues in localizing something that's a work in progress than rules.csv specifically, though.


Heck I postponed Seeker for two years despite having a dozen of extremely scripted artifacts, fully implemented, completely weird, with interesting stories and quests attached to them sitting on my hard-drive because it is beyond my competences to implement the dialogues properly.

Hmm - what's the biggest hurdle? If we're talking about "talking to NPCs specifically" (and even if we're not) I should probably add an easy way to divert that from rules into an "interaction dialog"-style plugin.


Well, here's my abbreviated list of problems with current rules.csv implementation:

Thank you, I appreciate it and want to get this conversation going. And hopefully get to a point where it's much more usable.

First, let me say a few things about how it works/my experience with it, just so we're maybe more on the same page. The rules system, btw, is not something I came up with from scratch but is rather an adaptation of a system used by Valve for Left 4 Dead. They're using it for something simpler, but it's a flexible and powerful system - and that's a large part of the issue. There are many ways to do the same thing, and many ways to do things that maybe you don't want to do using it. It took me some time working with it to figure out some basic patterns that work well. Definitely took a shift in thinking compared to writing regular code. (Why add this system in the first place? Well, the game needed *something* to handle the rapidly-multiplying number of interactions.)

The other point is that the system is more or less optional, and standard interaction dialogs (i.e. like the FleetInteractionDialogPluginImpl) can be used instead. More or less, the rules system is best for a larger number of simpler things. If you get into any kind of conversation tree more than a few levels deep, it's not going to work out.

For example, the new salvage system - the core interaction is implemented using rules.csv, but there are also a bunch of "special" things that can happen - you find something, and there's an option or two to select - and those each have a custom fully-Java plugin that handles it before returning back to the core interaction.


- The documentation is really incomplete

What specifically is missing? Aside from documenting all the commands; that's not really viable - there's a ton of them and you can also add new ones.

- It lacks a bunch of basic programming flow stuff, like OR in conditions

Looking at it as a programming language is probably not the right way to go. That said, two possible approaches:

1) A custom command that computes whatever condition you want to check for, or
2) Multiple rules for each set of conditions, that FireBest <trigger for rule with the actual work>

- There are a number of little things that can trip a new modder up, like the text column's contents being displayed before the script column code is run (so you can't get variables in the same row that as the text that uses them)

It runs in that order so you can set text highlights from the script. If one wants to print the text after running some commands, there's an AddText command.


- Programming in a spreadsheet editor is generally clunky to begin with – a couple of people in the modding chat mentioned than an editor would be nice
 
As an aside: a really hardcore implementation would be to dispense with the custom scripting language entirely and make the conditions and scripts use raw Java code with Janino script evaluation.

Yeah, I thought about that - but as you say, programming in a spreadsheet editor is no fun, and Janino script evaluation isn't particularly fast, either - which can be an issue if it's checking conditions, which has to be fast.

The "right" way to do it is to add custom commands for code with any amount of complexity. In vanilla, to minimize the number of custom commands, I tend to have a single command for a specific interaction, with parameters. For example, there's a "SalvageEntity" command, and then the various rule-scripts run things like:

SalvageEntity showCost
SalvageEntity performSalvage
SalvageEntity demolish

That way all of the heavy code is in the same Java file that you edit using an IDE, and the interaction-related stuff in the spreadsheet is kept as simple as possible. If the flow of the interaction is set up right, it's also easy to add different descriptive text based on the specific entity being interacted with and its properties, without affecting the rest of the flow.

The way to do that is setting up a trigger that prints the description text, and then having every rule using that trigger continue the interaction in the same way

E.G:

description1, EntityDescription, $entityType == <entity type 1>, FireBest RestOfInteraction, <description of entity 1>
description2, EntityDescription, $entityType == <entity type 2>, FireBest RestOfInteraction, <description of entity 2>
restOfInteractionStart, RestOfInteraction, , <whatever code etc>

The nice thing here is a mod could add some custom text for a mod-specific entity into the interaction process without altering the interaction flow, and in a way that's compatible with multiple other mods doing the same thing.


Thoughts?


Personally, I found it a bit difficult to get the rules to do much, and found myself re-writing the code used to generate those UIs rather than mess with them further.  

Fair enough, pretty much why that's an option.

I think that you're in danger of creating a meta-language here that just makes things more obscure, rather than less;

Yeah, that's a good point and something I'm aware of/concerned about. I *think* part of the issue is a lot of the earlier rules I put together, I was still trying to figure out how to use this best, and so it's very much not a good example to follow or try to figure out.

I'd honestly recommend that the code governing the operation of the Rules gets pretty explicitly documented at some point.  But not right now; it's too much of a waste of time, I'd imagine, with things getting refactored fairly often.  If I ever feel like diving back into a major mod for this game again, I'll give more feedback at that time :)

The nice thing is that the rule-operation code is very stable - I think over the course 0.8a, I've only had to fix a few minor bugs in it. It kind of just does what it needs to do; the core of it is pretty simple - the last thing I'd want to do is add more features to it. Anything complicated gets farmed out to Java code via custom commands.

« Last Edit: February 25, 2017, 11:23:22 AM by Alex »
Logged

Tarkets

  • Ensign
  • *
  • Posts: 45
    • View Profile
Re: Building Better Worlds
« Reply #77 on: February 25, 2017, 12:13:29 PM »

In-game story missions are something I'd absolutely love, but sadly don't see happening. You need quite a bit of variety and depth, otherwise it just doesn't work.

I think it can be done, but with certain things being up in the air it's hard to say what implementation is going to be used until stuff gets nailed down. Sunless Sea has a lot of story content and missions in a (superficially!) similar game to SS but it uses a boatload of special stats and one-off variables, and had the locations of things randomized but not actually randomly generated. Space Rangers also had a ton of story content but outside the endgame goals the story content was largely in planet-only text adventures

And then there's the question of how the story content interacts with the procedural or emergent content. A randomly generated bounty mission getting scrubbed because the target fleet is in a system already swarming with pirates, or because the target gets blown away by other hunters/defense fleet/something else is probably fine for most people. But you'd probably get upset if in the penultimate mission of the 'Rescue the admiral's daughter' quest chain the admirals personal shuttle got waxed by random Luddics or the planet got taken by Tri Tachyon before you could do anything and now the whole things failed.

That was a lot of incoherent words to say "We'll have to wait and see" but anyway
Logged

nomadic_leader

  • Admiral
  • *****
  • Posts: 725
    • View Profile
Re: Building Better Worlds
« Reply #78 on: February 25, 2017, 12:28:30 PM »

That "That's all" doesn't begin to describe the inordinate amount of work it represent to create in Starsector
...
I invite you to open that file and see for yourself. After all, modding is open to everyone, if you don't like the lack of quest mods you can fix that!

Sorry, you're correct. Keeping track of all the branching quests and avoiding bugs and conflicts and making the story interesting is a lot of work, and it doesn't have an immediate visual payoff the way a sprite does.  I've never had time to get much into SS modding and it'd mean a lot of questions in the "stupid modding questions" thread, but maybe when .8 comes out I'll try again.

That said, if a sort of library or framework or metalanguage could be created by more advanced modders for less advanced modders (and creating one is complex), there's nothing so programmatically complex about the logical operators required to make simple or branching quests themselves, though it is labour intensive. Other games like Endless Sky, you can just enter this stuff into a text file, and as a result there are a lot more quests.  SS has all this robust modding supposedly, but it's so complicated that after 5 years we have almost no quests. That is a problem for this game.

I mean something that turns it into a paint-by-numbers kit by limiting creator options to a number of fields that could each be filled with one of a few choices or by hex flags, and then the mod would read those files to create the quests.

So example fields could be:

MissionRequirements
MissionOfferLocation
ProbabilityOfOffer
OfferedByFaction
RequiredRepution
MissionType
MissionDeliveryLocation
CargoType
PaymentType
PaymentAmount

MissionRequirements could be reputation, another certain quest already completed, your fleet size, etc.

Then for example the MissionOfferLocation field could take one of a few inputs:
1. Any market owned by OfferedByFaction
2. A Specific Market
3. Any market owned by an enemy of OfferedByFaction
etc.

Or for example PaymentType could-
1. Cash
2. Cargo
3. Ship
4. Reputation

and so on...

Story missions would be the same thing basically but offered by NPCs in the comms dialogue, and they'd have branching dialogue options with logical operators like AND/OR/NOT/IF. There would be a set of persisent variables stored in the player save file (think of the Escape Velocity/Endless Sky "Mission bits" system that would keep track of which other quests had been completed, and with what result.
Logged

Histidine

  • Admiral
  • *****
  • Posts: 4661
    • View Profile
    • GitHub profile
Re: Building Better Worlds
« Reply #79 on: February 25, 2017, 08:02:10 PM »

Aside from documenting all the commands; that's not really viable - there's a ton of them and you can also add new ones.
Well the doc PDF to me reads like it set out to do just that (documenting the vanilla commands at least) but stopped midway through.
After 0.8 comes out, if just those commands that are already there but with no text (SetTooltip, SetShortcut, SetTextHighlightColors, etc.) have their entries completed, that should cover most/all of the commonly used commands at least.

Another thing that annoyed me when I had to implement it: dialog options where each option involves a different value for the same variable.
Spoiler
In Nexerelin I have options for things like: listing all markets for one faction in a list of factions, or setting the number of procedurally generated systems. I have a rule with the following options:
Code: csv
option1:One
option2:Two
option3:Three
In something done in Java, clicking any of those options would call a single method doThing(<1-3>). But in rules.csv, I have to add one row for each option:

Code: csv
Option1Selected, DialogOptionSelected, $option == option1, DoThing 1
Option2Selected, DialogOptionSelected, $option == option2, DoThing 2
Option3Selected, DialogOptionSelected, $option == option3, DoThing 3
which can quickly lead to dozens of lines that do the same thing.

Hypothetical solution: each dialog option can set one or more variables after the text, e.g. option1:One:$myVar = 1
In the absence of that, should I do something like this instead?
Code: csv
OptionSelected, DialogOptionSelected, ParseOptionAndGetArg $option, DoThing $arg
[close]
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23988
    • View Profile
Re: Building Better Worlds
« Reply #80 on: February 25, 2017, 08:09:02 PM »

Well the doc PDF to me reads like it set out to do just that (documenting the vanilla commands at least) but stopped midway through.
After 0.8 comes out, if just those commands that are already there but with no text (SetTooltip, SetShortcut, SetTextHighlightColors, etc.) have their entries completed, that should cover most/all of the commonly used commands at least.

It did, but then I ended up putting most of the documentation in the javadoc for the commands. It's more likely to be up-to-date etc and seems like a better place for it. But a lot of the commands are so specific to a particular vanilla use case that they're not generally useful.


Another thing that annoyed me when I had to implement it: dialog options where each option involves a different value for the same variable.
Spoiler
In Nexerelin I have options for things like: listing all markets for one faction in a list of factions, or setting the number of procedurally generated systems. I have a rule with the following options:
Code: csv
option1:One
option2:Two
option3:Three
In something done in Java, clicking any of those options would call a single method doThing(<1-3>). But in rules.csv, I have to add one row for each option:

Code: csv
Option1Selected, DialogOptionSelected, $option == option1, DoThing 1
Option2Selected, DialogOptionSelected, $option == option2, DoThing 2
Option3Selected, DialogOptionSelected, $option == option3, DoThing 3
which can quickly lead to dozens of lines that do the same thing.

Hypothetical solution: each dialog option can set one or more variables after the text, e.g. option1:One:$myVar = 1
In the absence of that, should I do something like this instead?
Code: csv
OptionSelected, DialogOptionSelected, ParseOptionAndGetArg $option, DoThing $arg
[close]


How about:
$menuType = myMenu

In whatever rule adds the options, and then:

MyMenuOptionSelected, DialogOptionSelected, $menuType == myMenu, DoThing

With DoThing reading the value of $option and doing whatever is appropriate?

Logged

Clockwork Owl

  • Admiral
  • *****
  • Posts: 790
    • View Profile
    • Starsector South Korean Community
Re: Building Better Worlds
« Reply #81 on: February 25, 2017, 08:15:26 PM »

I think that's more to do with the inherent issues in localizing something that's a work in progress than rules.csv specifically, though.

But how else am I supposed to lure my friends into buying it? :D
Logged

Lakis

  • Lieutenant
  • **
  • Posts: 79
  • I shall offend all of them!
    • View Profile
Re: Building Better Worlds
« Reply #82 on: February 26, 2017, 01:05:03 AM »

Why not have the worlds or stations that are 'dilapitated' or uninhabitable places where once can scavenge for goods and parts.  Nothing organic, but I mean... Things like household goods, fuel, supplies, weapons, High Value technology... There's bound to be something of value to scavenge from there, but there should be a risk as well...

Say... Getting a boutny placed on your head for not paying a scavengers fee and the like.


Otherwise, great insight into the game and your thought processes!
Logged
http://fractalsoftworks.com/forum/index.php?topic=8100.0 - Metelsons Faction Mod - Occasional contributor - mostly a cold dead planet.

Schwartz

  • Admiral
  • *****
  • Posts: 1452
    • View Profile
Re: Building Better Worlds
« Reply #83 on: February 27, 2017, 01:04:41 PM »

That thing with the frying pan is pretty clever.

Also - don't worry too much about flooding the game with systems. I think modders will do that either way, so you might as well spearhead Alex's suffering. ;D
Logged

kazi

  • Admiral
  • *****
  • Posts: 714
    • View Profile
Re: Building Better Worlds
« Reply #84 on: February 28, 2017, 02:40:27 PM »

Quote
"Laicaille” was also my attempt to reference Lascaille’s Shroud from the Alastair Reynolds books

Inhibitor trap confirmed.
Logged

jn_xyp

  • Ensign
  • *
  • Posts: 28
  • Ordinary Player, Fossic.org customer support
    • View Profile
    • Jn_xyp's Blog (In Chinese)
Re: Building Better Worlds
« Reply #85 on: March 05, 2017, 08:14:45 AM »

Okay, this game is still alive......
People in Chinese forum were talking about the new version, and they said it would perhaps released before February.......
But I will still waiting, maybe I can let my grandson send me the new game to me.....
Logged
Ordinary Player, maintainer and customer support of fossic.org.
Pages: 1 ... 4 5 [6]