I am once again asking for the quote of the month to be changed as it is now a new month - Mjmd

Create an account  

 
Reversing to Orion - project 1oom

Thank you and good luck!

(January 8th, 2019, 05:36)Tapani Wrote: * Perhaps enable most bugfixes by default, but provide a "-classic" command line switch for the hard-core gamer who prefers the bug-by-bug similarity. Changing the philosophy to making 1oom the way the Master of Orion 1 was INTENDED to be, and not only recreate the way the last version IS.

Sounds good to me. I understand wanting to preserve the original behavior, but I didn't understand why we needed those pbx files to enable bugfixes. On the other hand, if the original author shows up again, it'll probably make it harder to merge your changes back into it. I don't know, his last commit message looks pretty final, but I think he was talking about wanting to keep working on it after 1.0.

Capturing the intent is not always easy. The stated purpose of the research interest mechanic is to reward you for slow and steady spending. I'm pretty sure that the tech slider micromanagement that we regularly do here is not at all intended. So should kyrub's "Science Lights" be enabled by default? On the one hand, it supports an unintended play style, on the other hand, the player could do the same calculation in another program, it's just more tedious.
Reply

Cool - I'm glad to hear you're taking this up, Tapani!

One thing I noticed trying out 1oom 1.0 (Classic sdl2) that I hadn't seen in any previous release I tried: Quitting the game and continuing from the auto-save no longer seemed to restore all low ("WASTE") ECO sliders to the minimum clean. I can understand why this might actually be done on purpose, but I prefer the original functionality for >99% of actual game situations.

Oh ... and since this came up for Ianus: Is there a good/easy way to compile 1oom for the Mac?
Reply

(January 8th, 2019, 09:29)RFS-81 Wrote:
(January 8th, 2019, 05:36)Tapani Wrote: * Perhaps enable most bugfixes by default, but provide a "-classic" command line switch for the hard-core gamer who prefers the bug-by-bug similarity. Changing the philosophy to making 1oom the way the Master of Orion 1 was INTENDED to be, and not only recreate the way the last version IS.

Sounds good to me. I understand wanting to preserve the original behavior, but I didn't understand why we needed those pbx files to enable bugfixes. On the other hand, if the original author shows up again, it'll probably make it harder to merge your changes back into it. I don't know, his last commit message looks pretty final, but I think he was talking about wanting to keep working on it after 1.0.

Capturing the intent is not always easy. The stated purpose of the research interest mechanic is to reward you for slow and steady spending. I'm pretty sure that the tech slider micromanagement that we regularly do here is not at all intended. So should kyrub's "Science Lights" be enabled by default? On the one hand, it supports an unintended play style, on the other hand, the player could do the same calculation in another program, it's just more tedious.

I wholeheartedly agree about PBX files. My first impression was that bugs weren't fixed, because I was not aware of the PBX mechanism at all.
Also you are right about interpreting intent .. yes it can be tricky and a slippery slope. But as I see it we already have three "flavours" of 1oom:

(a) The "Vanilla" version - reenacted MOO1, bug by bug
(b) The fixed version - with bugs fixed, behaviour documented in OSG implemented, Classic+ AI etc
© The extended version - with uiextras, governors, research lights, fractional pop increases, new AI ...

The default in 1oom v1.0 is (a), while (b) can be enabled with PBX and command line switches, and © with additional command line switches. I would expect most (read: virtually all) players to prefer (b), or even ©.

My idea was to make (b) the default, and let (a) and © require a command line switch to enable, and custom flavours PBX files. Or let users somehow chose flavour after launching.


(January 8th, 2019, 18:49)RefSteel Wrote: Cool - I'm glad to hear you're taking this up, Tapani!

One thing I noticed trying out 1oom 1.0 (Classic sdl2) that I hadn't seen in any previous release I tried:  Quitting the game and continuing from the auto-save no longer seemed to restore all low ("WASTE") ECO sliders to the minimum clean.  I can understand why this might actually be done on purpose, but I prefer the original functionality for >99% of actual game situations.

Oh ... and since this came up for Ianus:  Is there a good/easy way to compile 1oom for the Mac?


While I have not seen what you describe about ECO sliders, I certainly feel there is something funny with them. Sometimes I find developing planets running a lot of research, in a way that did not happen in the original game. Abou t ECO, a thought I had was to interpret a locked ECO slider as "minimum without waste" - and let the game enforce it. This would break original game functionality so I did not do it yet. Maybe there is some other way to accomplish the same effect. (Apparently there are "Governors" enabled with -uiextra, but I never got them to work as I wished).
Is there an easy way to reproduce and debug the ECO slider problem you describe?

About Mac:
Just tried compiling it on MacOS 10.8, and got it to compile with gcc-4.2. Since I only have SSH access to Apple machines, I could only test that the binary runs. In case anyone is interested in testing it, I put my executable at:

http://tapani.homeftp.org/1oom/1oom_classic_x11-MacOS-20190109

You will need the original game LBX files, and a local X Server (such as XQuartz) to run it. Sorry for no SDL binaries yet, I need to talk to the owner of the machine if SDL can be installed.
Reply

Sad to hear original developer has left.

Does it have everything from kyrub's patch? I see there is a big difference in difficulty between them. 1oom on impossible is easier than kyrub's on hard.

What is the reason why kyrub's patch produces 3 scouts in 1 turn and 2 scouts in 1oom? Which one is correct?
Reply

(January 12th, 2019, 03:37)eMeM Wrote: Sad to hear original developer has left.

Does it have everything from kyrub's patch? I see there is a big difference in difficulty between them. 1oom on impossible is easier than kyrub's on hard.

What is the reason why kyrub's patch produces 3 scouts in 1 turn and 2 scouts in 1oom? Which one is correct?

Define "correct". The original game (v1.3) has a bug with the initial design costs. A default scout costs 11 BC, but designing an identical scout will result in an 8 BC design. My guess is that kyrubs patch fixes this (but I have never used his patch, in fact found out about it very recently).
The original 1oom developer had this idea that 1oom should mimic the original game behaviour, pretty much bug-by-bug, so scouts cost 11BC. For those who wanted bugfixes and kyrub's improvements, the original developer provided a way to use PBX files detailing what changes to include.

Personally I find the idea of forcing every 1oom player to compile their own PBX file to enable even basic fixes very un-user friendly. I'm strongly leaning toward changing 1oom default to include all fixes + kyrub improvements enabled, but also provide an easy way to downgrade to original (v1.3) behaviour. (This default behaviour change is already present in my own internal development version, but I have not dared to push them until I hear more what you, the users, think).
Reply

(January 9th, 2019, 06:36)Tapani Wrote: Sometimes I find developing planets running a lot of research, in a way that did not happen in the original game.

That does sound strange; I wonder what would cause it....

Quote:Abou t ECO, a thought I had was to interpret a locked ECO slider as "minimum without waste" - and let the game enforce it. This would break original game functionality so I did not do it yet. Maybe there is some other way to accomplish the same effect. (Apparently there are "Governors" enabled with -uiextra, but I never got them to work as I wished).

Would it be possible to do this by clicking on the message to the right of the ECO bar that says "CLEAN" or "WASTE" or "+1 POP" or whatever? And/or by hitting the "=" key on the keyboard?

Quote:Is there an easy way to reproduce and debug the ECO slider problem you describe?

Yes (sorry it took me so long to reply to this...) - load the save from the zipped folder attached to this post. Or just start a new game as [anything except Silicoids] and reduce the ECO slider at your world to "WASTE" and then quit. When you continue the game (or load the attached save) the slider will still show "WASTE" (in the case of the attached save, still with zero slider in ECO). In the original game, the ECO sliders for any planet below the minimum "CLEAN" would be adusted upward to minimum "CLEAN" whenever the game was loaded from a save.

In case the bugged behavior is somehow unique to my setup, or in case it otherwise helps, the zipped folder also includes the 1oom_log.txt for the session in which I created the save.

Quote:About Mac:
Just tried compiling it on MacOS 10.8, and got it to compile with gcc-4.2. Since I only have SSH access to Apple machines, I could only test that the binary runs. In case anyone is interested in testing it, I put my executable at:

http://tapani.homeftp.org/1oom/1oom_classic_x11-MacOS-20190109

You will need the original game LBX files, and a local X Server (such as XQuartz) to run it. Sorry for no SDL binaries yet, I need to talk to the owner of the machine if SDL can be installed.

Cool - I'll ask Ianus if he's tried it.

(January 12th, 2019, 10:31)Tapani Wrote: Personally I find the idea of forcing every 1oom player to compile their own PBX file to enable even basic fixes very un-user friendly. I'm strongly leaning toward changing 1oom default to include all fixes + kyrub improvements enabled, but also provide an easy way to downgrade to original (v1.3) behaviour. (This default behaviour change is already present in my own internal development version, but I have not dared to push them until I hear more what you, the users, think).

For what it's worth, I like your idea a lot!


Attached Files
.zip   Wastesave.zip (Size: 3.21 KB / Downloads: 1)
Reply

(January 8th, 2019, 05:36)Tapani Wrote: * Perhaps enable most bugfixes by default, but provide a "-classic" command line switch for the hard-core gamer who prefers the bug-by-bug similarity. Changing the philosophy to making 1oom the way the Master of Orion 1 was INTENDED to be, and not only recreate the way the last version IS.

(January 8th, 2019, 09:29)RFS-81 Wrote: Capturing the intent is not always easy. The stated purpose of the research interest mechanic is to reward you for slow and steady spending. I'm pretty sure that the tech slider micromanagement that we regularly do here is not at all intended.


That's the rub. Sometimes the way things are transcends the way things were meant to be. A physics bug might change a game from what the developers intend to something players actually prefer. Regarding research slider micro then, the first question is does the way things incidentally turned out transcend the original intention? The players who actually might care about such a thing, who almost certainly are rather authoritatively represented by the people on this forum, are probably not a fan of mindless slider micro, so I'd say no.

So should a project like 1ooM adopt a solution similar to Ray's or my own?

I don't think so. At least if it wants to stay authentic, and at least not as the default behaviour. The issue here isn't that research slider behaviour is unintended. It's working as designed. Rather, it's the meta-result of the system that's unintended, where non-strategic noise is amplified where it was hoped to be reduced. Aligning the meta-result with the original intention requires reworking the system itself, which is a fundamental change. And who knows what the designers might have come up with if they had figured out the issues in their original design.



(January 8th, 2019, 09:29)RFS-81 Wrote: So should kyrub's "Science Lights" be enabled by default? On the one hand, it supports an unintended play style, on the other hand, the player could do the same calculation in another program, it's just more tedious.

The way I look at it is that the lights don't change the fundamental nature of the system, which rewards micro. But they do make that micro easier to achieve and less time consuming, which effectively reduces the non-strategic noise. In terms of better aligning with the intended playstyle, one could argue that everything else being equal straightforward non-strategic micro is better, and more in tune with both the original design intention as well as the intentions of present community, than complex non-strategic micro.

The rebuttal to this is that 99% of players won't ever figure out how research slider micro works, while those lights do provide some hints.

All in all, I'd argue that the lights help bring things closer to the original design intention for those who already understand how the system works, but not otherwise. I guess that doesn't make things any easier :P
Reply

(January 13th, 2019, 03:34)RefSteel Wrote:
(January 9th, 2019, 06:36)Tapani Wrote: Is there an easy way to reproduce and debug the ECO slider problem you describe?

Yes (sorry it took me so long to reply to this...) - load the save from the zipped folder attached to this post.  Or just start a new game as [anything except Silicoids] and reduce the ECO slider at your world to "WASTE" and then quit.  When you continue the game (or load the attached save) the slider will still show "WASTE" (in the case of the attached save, still with zero slider in ECO).  In the original game, the ECO sliders for any planet below the minimum "CLEAN" would be adusted upward to minimum "CLEAN" whenever the game was loaded from a save.

In case the bugged behavior is somehow unique to my setup, or in case it otherwise helps, the zipped folder also includes the 1oom_log.txt for the session in which I created the save.

Guess I misunderstood what you ment. Your example is quite trivial. In fact the original game does adjust the ECO and seems to be buggy with this! For example in v1.3 you can initially build 2.2 factories on turn 1, but setting it to waste, saving and then reloading allows 2.4 on turn 1! This little extra 0.2 is present until you (or an effect) touches the sliders.

For completeness this functionality (but not the bug?) should probably be implemented. Will add it to my TODO, but not at very high priority.

Quote:RefSteel
(January 9th, 2019, 06:36)Tapani Wrote: About ECO, a thought I had was to interpret a locked ECO slider as "minimum without waste" - and let the game enforce it. This would break original game functionality so I did not do it yet. Maybe there is some other way to accomplish the same effect. (Apparently there are "Governors" enabled with -uiextra, but I never got them to work as I wished).

Would it be possible to do this by clicking on the message to the right of the ECO bar that says "CLEAN" or "WASTE" or "+1 POP" or whatever?  And/or by hitting the "=" key on the keyboard?

Possible, yes. Desirable, debatable. Also I have had some other ideas about clicking on the CLEAN/WASTE part of planets. Often I find it annoying that I have to terraform before I can build pop (esp on planets in war zones), to build a shield before I can build bases ... an idea I had to let the right hand side toggle what is being built. Like:
  Bases <--> SHIELD
  Fact <--> RESERVE
  POP <--> TFORM / SOIL
etc

So for that reason I'd prefer to keep the right hand side unused for now.

Using the '=' key is not hard to implement, but I don't want to do it manually on all colonies. Perhaps introducing a second type of slider lock, that locks to the effect and not the amount of BC or percentage spent. Using the second lock type, locking the defense slider at 2 bases / Y, would spend the minimum to build 2 / year. Same with eco, set to CLEAN, +1 POP etc. Toggling this might be done by clicking on the slider lock multiple times. Like:
unlocked <---> slider locked <---> effect locked <---> unlocked

All of these are somehow extending the game in ways I am not really comfortable doing. Would prefer to stay close to the original.

Quote:RefSteel
(January 12th, 2019, 10:31)Tapani Wrote: Personally I find the idea of forcing every 1oom player to compile their own PBX file to enable even basic fixes very un-user friendly. I'm strongly leaning toward changing 1oom default to include all fixes + kyrub improvements enabled, but also provide an easy way to downgrade to original (v1.3) behaviour. (This default behaviour change is already present in my own internal development version, but I have not dared to push them until I hear more what you, the users, think).

For what it's worth, I like your idea a lot!

Good to hear! Any others?

(January 13th, 2019, 23:47)Jeff Graw Wrote:
(January 8th, 2019, 05:36)Tapani Wrote: * Perhaps enable most bugfixes by default, but provide a "-classic" command line switch for the hard-core gamer who prefers the bug-by-bug similarity. Changing the philosophy to making 1oom the way the Master of Orion 1 was INTENDED to be, and not only recreate the way the last version IS.

(January 8th, 2019, 09:29)RFS-81 Wrote: Capturing the intent is not always easy. The stated purpose of the research interest mechanic is to reward you for slow and steady spending. I'm pretty sure that the tech slider micromanagement that we regularly do here is not at all intended.

That's the rub. Sometimes the way things are transcends the way things were meant to be. A physics bug might change a game from what the developers intend to something players actually prefer. Regarding research slider micro then, the first question is does the way things incidentally turned out transcend the original intention? The players who actually might care about such a thing, who almost certainly are rather authoritatively represented by the people on this forum, are probably not a fan of mindless slider micro, so I'd say no.

So should a project like 1ooM adopt a solution similar to Ray's or my own?

I don't think so. At least if it wants to stay authentic, and at least not as the default behaviour. The issue here isn't that research slider behaviour is unintended. It's working as designed. Rather, it's the meta-result of the system that's unintended, where non-strategic noise is amplified where it was hoped to be reduced. Aligning the meta-result with the original intention requires reworking the system itself, which is a fundamental change. And who knows what the designers might have come up with if they had figured out the issues in their original design.

(January 8th, 2019, 09:29)RFS-81 Wrote: So should kyrub's "Science Lights" be enabled by default? On the one hand, it supports an unintended play style, on the other hand, the player could do the same calculation in another program, it's just more tedious.

The way I look at it is that the lights don't change the fundamental nature of the system, which rewards micro. But they do make that micro easier to achieve and less time consuming, which effectively reduces the non-strategic noise. In terms of better aligning with the intended playstyle, one could argue that everything else being equal straightforward non-strategic micro is better, and more in tune with both the original design intention as well as the intentions of present community, than complex non-strategic micro.

The rebuttal to this is that 99% of players won't ever figure out how research slider micro works, while those lights do provide some hints.

All in all, I'd argue that the lights help bring things closer to the original design intention for those who already understand how the system works, but not otherwise. I guess that doesn't make things any easier :P

There are several quirks that people might consider 'part of the game'. For example the AI always backing off in scout vs scout battles, allowing the human player to squat on planets with only scouts. Should another AI change this?
Also the feature to redirect fleeing ships (even back to the contested system) is probably a bug, but almost an essential part of gameplay in some cases. There are probably others.
Reply

(January 12th, 2019, 10:31)Tapani Wrote: Personally I find the idea of forcing every 1oom player to compile their own PBX file to enable even basic fixes very un-user friendly. I'm strongly leaning toward changing 1oom default to include all fixes + kyrub improvements enabled, but also provide an easy way to downgrade to original (v1.3) behaviour. (This default behaviour change is already present in my own internal development version, but I have not dared to push them until I hear more what you, the users, think).

That would make sense. I found it hard to push myself to test 1oom version because original MOO is too easy for experienced player.

Do you have some sort of plans for your fork of 1oom? I think 1oom_aaron's original plans to add multiplayer were great but overambitious.

My own random ideas:
  • In next research window - show top tier techs in slightly different color.
  • In new spaceship window - show obsolete weapons in slightly different color e.g. nuclear bombs when we have fusion bombs available.
  • Change random events so all of them can happen to human and AI players.
  • Give AI ability to attack and capture Orion.
  • Make revolt on a human player system non-random but from spying. I've lost few games in Kyrub's version to this without meeting any other race!
  • I wonder how would it look like if human player wasn't protected with 1 guaranteed colonizable system in 3 parsecs and no other races in 7 parsecs. There is a danger current AI would struggle from early attack.
Reply

(January 14th, 2019, 06:46)Tapani Wrote:  There are several quirks that people might consider 'part of the game'. For example the AI always backing off in scout vs scout battles, allowing the human player to squat on planets with only scouts. Should another AI change this?
Also the feature to redirect fleeing ships (even back to the contested system) is probably a bug, but almost an essential part of gameplay in some cases. There are probably others.

Absolutely. I have no doubt that the people on this forum would welcome such changes, but perhaps the wider audience wouldn't. If those features are added, it would probably make more sense to keep them optional. Of course, for the scout v. scout example I don't think the AI would change, but rather no combat event would be generated for the scenario where neither fleet is armed (eg. both fleets orbit the system peacefully).
Reply



Forum Jump: