search

CleverRaven / Cataclysm-DDA

Cataclysm - Dark Days Ahead. A turn-based survival game set in a post-apocalyptic world.
http://cataclysmdda.org
Other
10.26k stars 4.11k forks source link

Nerfing Engines #20040

Closed Regularitee closed 7 years ago

Regularitee commented 7 years ago

I can't speak for the experiences of others, but I'm now getting 500 km/h+ max speeds on vehicles with the tonnage of an APC, but only using a single mid-range engine (4.0L V6). When you consider that you can now run multiple engines now on top of that... it strikes me engines need a bit of a nerf.

Anyone else care to give their experiences, or opinions on how engines should be nerfed (if at all)?

Coolthulhu commented 7 years ago

That engine rework PR that got reverted got the basic idea right, just not the exact implementation. The current model pretty much ignores weight, except for offroading (and even then it is very forgiving).

Regularitee commented 7 years ago

Sorry, I must have missed the discussion if/when/where it happened.

It was my impression that ignoring mass wasn't an issue before the engine overhaul. So why perform only a partial reversion if it causes the game to retain a major bug (massless vehicles)? Is there some under-the-hood, incomplete code he's trying to preserve, or something?

And is this mass issue already being worked on by someone, or is it still in a state of unresolved limbo?

keyspace commented 7 years ago

EDIT: tangent!

Mass was always taken into account, pre-overhaul, post-overhaul and post-revert.

The general speed drop during VPO, coupled with the changed application of thrust that probably caused a drop in acceleration, resulted in the now infamous "APC-vs-shrubbery collision" bug.

EDIT: That's not the mass effect you write about, but a bit related. Take a look at PR #19974 - my crusade to make the most documented PR in C:DDA history, in terms of PR description lines to changed lines ratio. :D

As for OP, haven't seen 500+ km/h yet. :/ Upload a savefile?..

keyspace commented 7 years ago

Also, there's PR #20007, third iteration of automated test to gauge vehicles. Got a feeling it's a prerequisite before any future overhauls.

Coolthulhu commented 7 years ago

So why perform only a partial reversion if it causes the game to retain a major bug (massless vehicles)?

Effect of mass was always very weak because it is divided by wheel area. Wheel area in turn has only a very weak effect on friction: you need 9000 cm^2 to have halved velocity from wheel area. The biggest wheel is armored at 640 cm^2, so you need 14 of those to halve velocity from wheel area. At the same time, for mass penalty, you need ~50 mass (in kg) / wheel_area (in cm^2) to halve velocity from mass, ~100 to get 33% velocity, ~150 to get 25% and so on. So a vehicle with total of 40 cm^2 wheel area (bicycle) would need to weigh half a metric ton to slow down to 50% of velocity.

A half-ton vehicle on two bicycle wheels should crush the wheels, not travel at half its optimal velocity.

That formula is inherently wrong and can't be fixed by changing constants in it and would require rebalancing all wheels in addition to the formula itself. A realistic formula could be used, but it would likely be too lenient or too restrictive depending on selected tile size.

What we actually want here is some penalty to acceleration from mass that can't be mitigated well. For example, calculating acceleration as (power - friction) / mass, with friction increasing when mass / wheel_area is too far from some optimum. Acceleration implicitly affects fuel consumption (currently too much).

keyspace commented 7 years ago

A realistic formula could be used, but it would likely be too lenient or too restrictive depending on selected tile size.

Clarify: too lenient/restrictive because tiles don't give real-world granularity. Correct?

(power - friction) / mass

I feel that re-inventing the wheel like this will invariably put vehicles back on square one - endlessly attempting to balance parts to "feel right".

The "doesn't feel right" comes from pre-existing RL experience (*). That simple formula above is not far from it, actually (a = F / m). So it could be a step in the "feels right" direction...

Sorry, veered off-topic again. :( Know this has been discussed already.

(*) No way around it - either suspend disbelief, or re-construct reality.

Coolthulhu commented 7 years ago

Clarify: too lenient/restrictive because tiles don't give real-world granularity. Correct?

No, it's more because tile size changes depending on context. Cities span barely hundreds of tiles, distance per cities is at most an order of magnitude greater. A realistic formula would need to assume one particular size of tile. Calculating tile size from running speed would be the most objective and straightforward, but also the most misleading and horribly lenient way of calculating it, while inter-city distance would probably feel too punishing.

I feel that re-inventing the wheel like this will invariably put vehicles back on square one - endlessly attempting to balance parts to "feel right".

It's not really reinventing the wheel. There is no formula that calculates acceleration from mass and engine power directly. There are multiple problems along the way, such as air resistance, aerodynamics that aren't just pure resistance, mass distribution etc. You can't just slap a V12 on a bicycle and break the sound barrier.

Partial realistic simulation is generally the worst choice possible. We can't use realistic formulas because they won't give realistic results without other realistic formulas. So we'd need to rip out the current system and replace it with a "realistic" one, which in turn would clash with other systems.

keyspace commented 7 years ago

Answered in my own repo.

kevingranade commented 7 years ago

On Jan 17, 2017 2:28 AM, "Keyspace-1" notifications@github.com wrote:

(power - friction) / mass

I feel that re-inventing the wheel like this will invariably put vehicles back on square one - endlessly attempting to balance parts to "feel right".

Which is why I reset things to the old behavior and started working on ways to measure performance objectively with unit tests. Then we can design some acceptance criteria for how we want things to behave, and balance toward that. The criteria will necessarily be a compromise between realism and "feels right" due to the fact that the underlying map isn't itself realistic.

Side issue, I would be curious to see what the map looks like if the scales were more consistent. Would it be more or less playable than what we have? Are there any things we can do to mitigate problems this would introduce? For example, intercity distance could be prohibitively large, but if we had road following fast travel, it might be ok.

Coolthulhu commented 7 years ago

Fast travel would be more abstract than non-euclidean distances are. For example, in Poschengband and Caves of Qud, getting "dropped" from fast travel at early level can mean instant kill, but lucking out on the "stay on overmap" rolls means being completely safe from all the high-level enemies in the area. And going autotravel instead of fast travel (having the player character actually walk all that way instead of teleporting) would only make sense if the distances were increased 2-3 times. Anything more than that at it would be unbearably long at current game speed, even with heavy frame skip.

kevingranade commented 7 years ago

On Jan 17, 2017 12:47 PM, "Coolthulhu" notifications@github.com wrote:

Fast travel would be more abstract than non-euclidean distances are. For example, in Poschengband and Caves of Qud, getting "dropped" from fast travel at early level can mean instant kill, but lucking out on the "stay on overmap" rolls means being completely safe from all the high-level enemies in the area.

Those are some of the reasons I'm totally against an abstract fast travel unless it's somehow supported by the story (teleporter, convoy, airplane). Having different systems for fast travel and regular travel is just asking for never ending balance problems.

And going autotravel instead of fast travel (having the player character actually walk all that way instead of teleporting) would only make sense if the distances were increased 2-3 times. Anything more than that at it would be unbearably long at current game speed, even with heavy frame skip.

I disagree, if necessary we can turn off a LOT of simulation overhead as long as certain constraints are met, such as no dangerous monsters in the reality bubble. Top offenders include active item processing, scent processing, monster actions, and possibly some aspects of fov calculation. For example, if we can assert that nothing is going to invalidate the transparency map, we don't have to keep recalculating it, we just have to add to it when shifting the map.

If we can strip it down to just drawing a conveyor belt of static content, it can be extremely fast. For the utmost speed though, we could have the player actually pathing through the map, but not draw it at all, just showing progress on the overmap.

Coolthulhu commented 7 years ago

Top offenders include active item processing, scent processing, monster actions, and possibly some aspects of fov calculation. For example, if we can assert that nothing is going to invalidate the transparency map, we don't have to keep recalculating it, we just have to add to it when shifting the map.

Skipping scent processing would work. It would hurt some tracking monsters, but it isn't a big deal. Alternatively, it could be optimized by only calculating it where the scent actually is (by calculating a bounding box every frame) which would boost performance by a factor of ~8. Fov calculation could be skipped with one exception: creatures (monsters and NPCs).

Active item processing should still happen - a lot of player-carried items can't "turn skip" properly. Or at least there should be separate caches for items which can't skip (use action governed) and those which can (rot). Turns-per-charge items with no uses could turn skip after being special cased.

Monster actions should be processed in some way. Maybe not perfectly, but totally skipping them would result in weirdness such as:

For example, if we can assert that nothing is going to invalidate the transparency map, we don't have to keep recalculating it, we just have to add to it when shifting the map.

Not sure what you mean here. The transparency cache is going to be invalidated often, especially if player travels by car. If transparency map was shifted in the same way as vehicle list is (map::copy_grid does something like that, I think), the performance gain would likely be minimal.

If there is performance to be gained from fov, I'd rather see it in:

For the utmost speed though, we could have the player actually pathing through the map, but not draw it at all, just showing progress on the overmap.

Drawing or simulating? Drawing is slow, but the biggest problem is that we can't skip all the simulations. Autotravel frameskip in options would be a good idea - those with good computers (or small viewports) would enjoy the view.

kevingranade commented 7 years ago

On Jan 17, 2017 2:16 PM, "Coolthulhu" notifications@github.com wrote:

Top offenders include active item processing, scent processing, monster actions, and possibly some aspects of fov calculation. For example, if we can assert that nothing is going to invalidate the transparency map, we don't have to keep recalculating it, we just have to add to it when shifting the map.

Skipping scent processing would work. It would hurt some tracking monsters, but it isn't a big deal. Fov calculation could be skipped with one exception: creatures (monsters and NPCs).

Monster actions should be processed in some way. Maybe not perfectly, but totally skipping them would result in weirdness

The assumption was, "no dangerous monsters in reality bubble", approaching a dangerous monster would disable the optimizations, sighting one (via raycasting) would cancel fast travel. Possibly monsters could be spotted on overmap scale (if in hordes).

Active item processing should still happen - a lot of player-carried items can't "turn skip" properly. Or at least there should be separate caches for items which can't skip (use action governed) and those which can (rot). Turns-per-charge items with no uses could turn skip after being special cased.

We could process active items in player inventory, but unless I'm missing something most of the items that can't to bear skipping turns are things like bombs, so that's not going to be an issue. If you mean battery-powered items, yea they could handle some special treatment.

For example, if we can assert that nothing is going to invalidate the transparency map, we don't have to keep recalculating it, we just have to add to it when shifting the map.

Not sure what you mean here.

The status quo is the entire transparency map is invalidated multiple times a turn, if no monsters are acting and we e.g. suppress field updates, we can get by with just shifting it, which is massively cheaper.

If there is performance to be gained from fov, I'd rather see it in:

Ray casting is better if we aren't drawing the map, if we are shadowcasting is better.

This sounds like more trouble than its worth.

As above, just turn off field/vision interaction during fast travel. In general though, if we sort the list by transparency and have aggregate field transparency be max instead of sum, we only need to check one field per tile.

For the utmost speed though, we could have the player actually pathing through the map, but not draw it at all, just showing progress on the overmap.

Drawing or simulating? Drawing is slow, but the biggest problem is that we can't skip all the simulations.

As above, disable a ton of simulation (profiler guided) if it's not necessary to determine the players safety.

Autotravel frameskip in options would be a good idea - those with good computers (or small viewports) would enjoy the view.

Sure, speed vs eye candy, though I'd say toggle on the fast travel menu/overmap rather than hoisting to options.

CoroNaut commented 7 years ago

Ok, so we make a revision that overhauls vehicle speed to be very consistent and working with precision and get rid of it only to complain about the vehicle speed again. lol

Also, I am very glad to see that you are beginning to care about measurement consistency even after it was deemed an unnecessary fix in the issue below.

19766 may also need to be talked about here and changed along with the very large quantity of issues everyone has with the engines now.

kevingranade commented 7 years ago

On Jan 17, 2017 8:10 PM, "CoroNaut" notifications@github.com wrote:

Ok, so we make a revision that overhauls vehicle speed to be very consistent and working with precision and get rid of it only to complain about the vehicle speed again.

The version I tested had vehicles that drove more efficiently on dirt than on pavement and burned less fuel if you brought them to a full stop every 5 turns, but please tell me more about the "consistency" and "precision" it had.

CoroNaut commented 7 years ago

The point is that everyone is talking about it as if it is worse now than when we did have the overhaul. If you want me to go into detail about how it was consistent and how it was precise, I direct you to #19275 where there is tons of information on the subject. The community wants a rewrite of the vehicles because of this debacle and I don't think this is gonna go away for a while. Its not fun to argue constantly, instead of arguing, we can sensibly work something out. Sadly, that doesn't seem to be possible. You want one thing, mugling wanted another, and now Regularitee submitted an issue on it. It was mugling who noticed and attempted to fix the issue first. Sadly, that wasn't good enough, and now we need a new idea that takes all the good things from what mugling had, put it into a new PR, and attempt that major experimental PR.

kevingranade commented 7 years ago

The point is that everyone is talking about it as if it is worse now than when we did have the overhaul.

No that's just you, the overhaul definitely made things worse, but in a different direction. As you don't seem to have anything further to add, please leave us to discuss solutions to the problem.

Coolthulhu commented 7 years ago

Overhaul did fix some issues. I wouldn't say it was better than what we have now, but it wasn't clearly worse, just worse from most perspectives. One of the good things it did that would be worth reintroducing (even if in a different form) was a relatively natural low cap on fuel consumption.

Current version has V12 consume the same amount of fuel per unit of power as any other gas engine, at any feasible velocity below safe velocity. The reverted one had gears (rather complex thing that I dislike, but that did the job) that made giant engines less efficient at low power outputs, without introducing artificial low caps.

Asmageddon commented 7 years ago

Yeah, issues aside, it was a good approach to the whole deal.