Cost Effectiveness: Ship comparisons

[Geoff the Medio]

Part of the reason to have a relatively high increase in ship costs with number of ships is to keep the number of ships produced smaller. The game tends to slow down to unplayable turn times in longer games, and number of ships is a major contributor to those times. Strategic balance doesn't matter if the game is unplayable.

[Bigjoe5]

Part of the reason to have a relatively high increase in ship costs with number of ships is to keep the number of ships produced smaller. The game tends to slow down to unplayable turn times in longer games, and number of ships is a major contributor to those times. Strategic balance doesn't matter if the game is unplayable.

There are a lot of ways to make the game playable that don't involve messing with actual game design, and which we should look into before committing to other methods (where by "committing", I mean actually start designing other game features based at least partially on the decision to use those methods, which hasn't happened yet, but might).

[Geoff the Medio]

There are a lot of ways to make the game playable that don't involve messing with actual game design...

Aside from attempts to optimize the relevant code, which is ongoing, there's not much that can be done if the number of objects in the universe grows unbounded; the game is going to slow to a crawl eventually. Some sort of limit on objects are going to be needed in the design

[Bigjoe5]

There are a lot of ways to make the game playable that don't involve messing with actual game design...

Aside from attempts to optimize the relevant code, which is ongoing, there's not much that can be done if the number of objects in the universe grows unbounded; the game is going to slow to a crawl eventually. Some sort of limit on objects are going to be needed in the design

Some sort of limit on objects will be needed from a design perspective to keep the game from getting ridiculous to manage for the player. My personal favourite method of doing this is to have the game actually end ( ) under certain conditions, such as sole-survivor.

Regardless though, I think we can increase limit on the number of objects in the universe such that the game is still playable way higher than it is now.

[Geoff the Medio]

I think we can increase limit on the number of objects in the universe such that the game is still playable way higher than it is now.

If you have specific modifications to turn processing that would make that happen, do please post suggestions or discussion in the programming forum, or implement them.

[Dilvish]

I think we can increase limit on the number of objects in the universe such that the game is still playable way higher than it is now.

If you have specific modifications to turn processing that would make that happen, do please post suggestions or discussion in the programming forum, or implement them.

Oh! Oh! I do! I do!

... The Tommyknockers! (Stephen King reference) When there are too many objects in the universe, the Tommyknockers come and start destroying random ships (maybe oldest ships first) to keep the total below limit

I'm actually a little serious about that suggestion, but in a more serious vein, I want to emphasize Geoff's point -- we've come a long long way on performance in the past six months, and we're continuing to work on it (or, at least Geoff is, and I think about working on it now and then ). Monster on monster predation is one possibility Geoff has mentioned that might help a lot for at least some situations -- it seems like in these big galaxies the monsters proliferate like crazy. That's something someone can experiment with purely through scripting.

I myself tend to think that at some point here we should do a full review of the EffectsGroup processing structure. Geoff has made terrific headway with certain pieces, but I'm still a little uncertain about the overall structure that seems to require a surprising degree of reiteration. If we could better analyze and constrain just how much reiteration we need/do I think we could make very significant gains. I'm not sure if anyone besides Geoff would be able to draw up that process map currently (and I probably have not convinced him of the need), but if he stays tied up with other things I may eventually try to tackle it.

[Bigjoe5]

I myself tend to think that at some point here we should do a full review of the EffectsGroup processing structure. Geoff has made terrific headway with certain pieces, but I'm still a little uncertain about the overall structure that seems to require a surprising degree of reiteration. If we could better analyze and constrain just how much reiteration we need/do I think we could make very significant gains. I'm not sure if anyone besides Geoff would be able to draw up that process map currently (and I probably have not convinced him of the need), but if he stays tied up with other things I may eventually try to tackle it.

I totally agree, although I'm just beginning to look into FO's code seriously. The process of actually finding objects that meet an effects condition could probably also be sped up using some kind of indexing.

[Geoff the Medio]

The process of actually finding objects that meet an effects condition could probably also be sped up using some kind of indexing.

Can you explain what you mean by "indexing", possibly in a new programming thread?

[Bigjoe5]

The process of actually finding objects that meet an effects condition could probably also be sped up using some kind of indexing.

Can you explain what you mean by "indexing"?

Store trees or hashtables of references to universe objects sorted by or hashed on a particular attribute that we commonly use for conditions. For instance, if an effect acted on all objects with target population within a certain range, we could use a tree index on target population to get the affected objects without having to test the condition on every object. There might be some in-memory database library somewhere that we could use for that, actually.

edit: A quick search came up with this, which seems suited to our purposes, but it's license is compatible only with GPL version 3, not GPL version 2...

[Geoff the Medio]

Caching condition results can be done; there's a special case for scope = Source already in Universe::StoreTargetsAndCausesOfEffectsGroups. Just that one was done first because it's a very common case so was most likely to benefit from the speedup.

This could be expanded / modified to cache the results of any condition evaluated by the loop over effectsgroups in that function, so that if multiple effectsgroups repeat the same scope or activation conditions, the results can be reused.

A more general method would modify the function to have a parameter which is a mutable reference to a map from conditions to results sets in which to cache the results of evaluating those conditions. You'd have to check conditions to make sure they're source object invariant before caching / using those cached results, though; if they're source variant, then they'd have to be re-evaluated for each source object. I suppose you could also index by std::pair<Condition*, int> where the latter is the source object ID or INVALD_OBJECT_ID when the condition is source invariant, though I doubt there'd be a huge benefit to that beyond just indexing by Condition*. There currently isn't a SourceObjectInvariant method for Conditions / ValueRefs, but one could be added similar to the existing RootCandidateInvariant, LocalCandidateInvariant, and TargetInvariant functions.

I'd avoid trying to pull in general use databases for this... As proposed, you would be essentially re-implementing one condition in a very limited but complicated way, which would break down in many cases such as when not all objects are potential matches.

[Vezzra]

Making players select colony locations rather than indiscriminately colonizing everywhere was part of the intent.

I basically agree with that, with one reservation: Colonizing everywhere (as in: not necessarily "every nook and cranny" but most of the planets in my territory) should still be a viable option - it just shouldn't be something you have to do to play an optimal game. What I don't agree with is the means to achieve that goal. Because IMO this cost increase for colony pods (even if set as high as 10%) doesn't make colonizing everywhere non-optimal (it takes way longer for the investment to pay off, but it still will pay off!), it just makes it tedious and un-fun. And discouraging the player to choose an option that would otherwise be an optimal one by making it un-fun to play is not a good idea.

As I stated already in an earlier post: As it stands it forces the player to decide between a less optimal and a less fun game.

There are other, far better mechanisms to achieve that, as you pointed out yourself:

This wasn't expected to be a complete solution to limit empire size (in number of marginal planets, not breadth), and elsewhere-discussed happiness-type factors are likely still needed. If players need other encouragement to spend resources on interacting with other empires instead of trying to back-fill at any cost, then that can probably be arranged.

The influence/happiness mechanic e.g. looks very appealing to me, and will achieve the goal of preventing colonizing everywhere to be a must effectively and interestingly, I believe. And if it shouldn't prove to be enough, we can think of further "other encouragements", as you mentioned.

I also wonder about how easy it is to capture native planets... My guess is that it's presently too easy for the cost.

Yep, I agree. Capturing native planets should be more expensive than colonizing a planet, because not only you get an already developed colony, you also have the chance of getting an additional species to colonize with. Currently it's far cheaper to acquire a native planet.

Notably, troop ship costs don't increase with number of colonies, so invading might become more and more cost-effective with time compared with producing colony ships. This is particularly so if native planets' defenses aren't scaling to empire strength as turns progress...

And here is another major problem I see with all these cost-increase-mechanics: They mess up balance. It's not done with just making hulls, certain ship parts or certain buildings more expensive the more you have of something (ships, colonies, a specific building etc.). These elements for which you increase the cost are part of a "bigger picture", in most cases their cost is balanced against the costs of other game elements. So, in order to retain that balance, you'll have to increase the costs of these other elements too, which in turn might cause balance problems with even more game elements, and so on.

Happiness could become a big factor in making such planets useful as well, so that players would often want not to invade them, but instead gain control diplomatically, or perhaps leave them independent or remove the natives if it wouldn't be advantageous to control them.

These are options I would very much like to see E.g. the possibility to take over a native planet by spending influence?

[Vezzra]

If the goal is to make colonizing planets more of a decision (as opposed to always being the right choice to colonize everywhere), there are other ways besides cost to accomplish this. The main one that comes to mind is to spread out the habitability growth tech and increase their RP costs.

That's definitely something that should be done. Habitability growth techs should be very expensive, because the benefits you gain by them are quite formidable.

[Zireael]

The influence/happiness mechanic e.g. looks very appealing to me, and will achieve the goal of preventing colonizing everywhere to be a must effectively and interestingly, I believe. And if it shouldn't prove to be enough, we can think of further "other encouragements", as you mentioned.

I agree completely.

Yep, I agree. Capturing native planets should be more expensive than colonizing a planet, because not only you get an already developed colony, you also have the chance of getting an additional species to colonize with. Currently it's far cheaper to acquire a native planet.

Seconded, too.

[Vezzra]

Though you appear to be comparing apples to apples, you're really comparing 10 apples to 5 Ultra-Oranges.

Um, I certainly simplified things to make my point, but why do you think I'm comparing apples to ultra-oranges? I wonder if we're talking about different things here.

I'll try to explain what I meant in FO terms:

For simplicities sake let's assume I try to play a game where I forgo ship's and weapons techs, but focus solely on techs boosting industry and research (to maximize production output). Somewhere in the early stages of the game I design some kind of ship that initially costs 10 PP (I'm just making up numbers that are easy to work with). Let's assume a production capacity of 50, so I'm able to "buy" 5 of these ships per turn.

Let's assume further that I successfully expand my empire, and after some time my production capacity will be 500 - ten times the amount I had when I initially designed my ship. However, I also have been producing a lot of ships in the meantime. Now, instead of being able to build 50 of these ships per turn, I can only build 20, because the cost for this ship, although it's absolutely the same ship (so we are still talking about apples), has risen significantly. That looks like comparing apples to apples to me...

The reasoning behind this mechanism: The increase in production capacity is so high, that you can produce way too much of certain things if nothing is implemented to counter that. Solution: progressively raising the cost. Which boils down to a "devaluation" of PP. So in essence we counter excessive increase in production capacity by decreasing what you can get per PP.

That of course is one way to deal with it. But wouldn't it be far simpler, straightforward and comprehensible for the player (in short, more KISS) to just rebalance the boni you can get to boost production? I mean we can give the player 100 PP, but make certain things more expensive so that you have to pay twice as much for them, resulting in giving the player effectively only 50 PP. Or we can just give the player 50 PP...

I don't really think anyone has much of a problem with higher productivity tending to be accompanied by higher costs

Well, I do, kind of. However, it's not so bad that I couldn't deal with it should I turn out to be the only one.

inflation as economies grow is pretty much a universal thing (maybe some of the cost increases could be due to an inflationary effect based on the entire galaxy's total economy to fit better with our natural expectations).

Well, we're not trying to make some kind of economic sim game, but a 4X space game with an emphasis on KISS. I don't see how introducing mechanics that reflect the concept of inflation makes the game more interesting. IMO it only makes things more complicated and awkward.

I think mostly we're just struggling with the difficulty of balancing various aspects.

Don't get me wrong: I fully acknowledge what should be achieved by these mechanics, I just think there are other, better ways to accomplish that.

That balancing might be a bit easier if productivity & cost growth was slower, but not hugely so.

That's where I disagree. I think these cost increasing mechanics seriously mess up balance. Take the increasing hull costs for example: These raise tremendously over the course of a game, changing (better: completely overthrowing) the balance between hull costs and ship part costs dramatically, to the point where ship part costs become irrelevant.

I do think a bit slower growth might be good to help somewhat mitigate the large race pressure here, but I dunno, it might be unavoidable, and I think a decent rate of growth is a fairly large part of what tickles the imagination when playing these games...

Maybe that's just me, but if you're going to take away much of that apparent growth by increased costs, as a player I'd prefer giving me slower growth. Less confusing and annoying

[eleazar]

I'd been under the impression that the make-it-cost-more-for-each-one-the-empire-owns approach is a stop-gap, until it was possible to implement more suitable growth-retardants. That approach is fine for what we can do now, but i don't consider it an ideal solution. It is not especially transparent, and probably doesn't scale with the needs of such a system.