Shots too random

Thanks! I’ll check the links: it may be a limitation of the GitHub online pdf viewer, though

2 Likes

Yeah, it would be a shame if this went unseen. @JulianG @UnstableVoltage

2 Likes

Ok, I’ve added the same content in html, and in that format the links are working (they were not particularly important in any case). The link can be found in my original post in this thread.

Thanks again for the support and best wishes to all!

Michele

3 Likes

It took some time, but I think I may have worked our most of the theory behind bullet trajectory generation, and as a plus I found a way to control the sampling so that the resulting probabilities follow a highly customizable and (hopefully) widely acceptable pattern.

Holy … true fan detected, give him 50% discount on everything ))

2 Likes

Hooray, a fellow academic and nerd :slight_smile:

… who alsos uses a Mac, and is involved in AI? Who isn’t, these days? :wink:

Hmm… do you mean: is it correct? Yes, of course it is :slight_smile:
Is it well written? I guess that depends on the target audience, but judging by the responses here, I’d say very much so :wink:
Is it a scientific article which will be published in a famous journal!? (This is what I’d mean by “review”.) Hehe, no. Those papers require a bit more work, as Dr. Lombardi can surely confirm.

Anyway, thanks for a great post, @lompabo!

2 Likes

Nice to know I am not alone, @JMPicard !

About the quality of the online “post”: let’s say I’d not want that anywhere close to my CV, for fear it may corrupt it :wink:

At leat it should be correct, however, and it helped me make sense of the devs comment about their strange probability distribution with a peak on the yellow circle.

Here I am partially replying to this post by @Duskmare (BTW: no offense taken). Basically, I suspect that:

  • The devs are first sampling the distance from the center of the circle (or something equivalent) and then a “rotation” angle on the circle
  • Their comment about “very accurate and very inaccurate shots are equally likely” refers to how they sample just the distance.

It turns out that, if you sample in that way:

  • If you want to obtain higher probabilities in the center of the circle, that gracefully decrease towards the border (I think many of us would expect this)…
  • …You need to sample the distance from a strange probability distribution where both low and high values are very unlikely.

It sounds a bit crazy, I know, but unless one does this the probability to hit the center becomes abnormally high.

Of course, as @Duskmare says, at this point this is all speculation: I don’t know if the devs were actually referring to how they sample just the distance, and since I don’t have access to the pre-alpha I cannot even confirm my predictions empirically.

I guess a confirmation from the devs is the only way to settle it.

Nice discussion, anyway :slight_smile:

3 Likes

Haha, don’t be so harsh on yourself! It’s cute, and you know it. Besides, a little enthusiasm is hardly a flaw :nerd_face:

As for how to actually implement stuff, I guess that’s quite dependent on what Unity offers. I’m not at all familiar with it, but at a brief glance it looks like mathematical stuff is, to a large extent, absent. So, let’s amuse ourselves with how to do it :nerd_face:

For taking an actual shot, I guess any way of drawing from a suitable probability distribution is fine. However, I suspect most shots aren’t actual shots: every time you move your cross-hairs around, in free-aim mode, the game needs to recalculate the expected outcome (damage) of taking precisely that shot, and I would expect these “fake” shots to vastly outnumber the real ones.
Perhaps there are even many enough of them to warrant some performance considerations :scream: Let’s assume that, because that’s where the fun is :yum: Otherwise, it would just be draw a large sample from the distribution and compute the average of the outcomes.

What you want, then, is a sample which is highly representative of its underlying probability distribution – a good stencil. You’d use it in just the same way as if drawing a large sample, but you wouldn’t have to perform the draw every time :money_mouth_face: This isn’t the main benefit though – rather, the benefit is that you could choose a nice stencil :face_with_monocle: After all, you’d need a rather dense scatter plot for it be satisfactorily uniform, and you’d really want that, if it was fixed.
What I’d do is to use the golden ratio to draw a sunflower. Really, check out that page; it’s awesome :star_struck: But I’d choose my radial increments to match the desired distribution of accuracy, i.e., I’d let the radius increase as the derivative of the inverse of the cumulative probability distribution over radius / accuracy :exploding_head:

Not only would this stencil be most pleasing to the :eye:, highly symmetrical and without large gaps (probably what makes it so beautiful :star_struck:), but it would also be a very nicely distributed sample of the PDF. This would help avoid flickering in expected outcome as the cursor moves around; intuition is its the actually the best possible sampe, of a given size, for this purpose :sunglasses: It would also be trivial to compute an expected outcome: simply take the average outcome of all the points of the sunflower. Taking variable accuracy into account would be simple as well – just scale the stencil with the inaccuracy of the shooter :straight_ruler:

If your stencil was fine enough, you could even reasonably well simulate shots by drawing, with uniform probability, from the :sunflower:. However, for actual shots, there’s just no way drawing a few points is the performance bottleneck. And then again, perhaps Unity offers fast evaluation of Gaussian beams, and you could just shine a “flashlight of probability” from your muzzle towards your target, and see how “illuminated” each surface was? Oh well, I had fun writing this, anyway :crazy_face:

2 Likes

If Unity provides a view of what you see (view, as in API) with hooks to the different components, I guess it could also be as simple as integrating the PDF over each of the visible components, although this is just boring to talk about :sob:

Hmm … using the stencil (or any other samle) it should be relatively straightforward to account for cover blowing up while shooting, though; simply keep track of the expected damage to cover, etc., as you go about evaluating each point in the stencil, and when an object’s health is saturated, remove it from the rest of the evaluation? It seems this isn’t done in the current build. I guess there may also be a perfectly good reason it isn’t, apart from this also being a detail :stuck_out_tongue_winking_eye:

2 Likes

Damn you beat me hear!
Wehen I read the post I thought basicly the same. :joy:
Well good job!
(But realy who uses a Mac and why? I tell you openSuse is the way to go.)

@UnstableVoltage
Any way I hope one of the snapshot guys did the Math?

If not Read @lompabo s excellent post here:
https://htmlpreview.github.io/?https://github.com/lompabo/pptrajectories/blob/master/README.html

(Actually I just signed up to tell you don’t use a simple bellcuurve it won’t work.)

2 Likes

I like the stencil idea, and the bit about the sunflower is very cool! :wink:

If I get it right, it would be a way to estimate expected damage and take into account the effect of cover. Since we have access to the probability distribution, it’s enough to compute the probability-weighted sum of the shot effects on the stencil.

Overall, you could get rather accurate damage estimates, even if also the idea of having no estimate at all has some merit – and thrill :smile: .

The probability density function itself could be computed once and for all for each soldier/weapon pair (it can then be scaled with the distance from the target), so that should have almost 0 impact on the performance.

The weighted sum over the stencil points should instead be updated as the user aims: so making that part efficient may be the key.

Nice post!

Michele

2 Likes

Ah, the point of choosing radial increments in that particular way was that each shot would have the same weight, so you could forget about the PDF after computing the stencil :slight_smile:

Oh yeah, baby :sunglasses:

Perhaps this could be made optional?

2 Likes

Quite interesting discussion, but you know what guys? When I pressed ‘fire’ for the first time in Backers Build One I was in shock how good it is comparing fo FXOMs. And I saw gloryfication of ballistic system in many comments… And now this topic shows up. [What the hell] - was my first thought. If devs will try this out it would be nice, but damn, I’m really fine with the current functionality.

2 Likes

That…is actually really cool. I’d like to have that 'cause I always wondered what kind of odds they were taking against me.

2 Likes

Both Firaxcom had mods to show enemy chances to hit, but I understand Firaxis’ choice not to display them natively. You just have to look at the post you quoted. People can’t stand losing soldiers at full health and in full cover and equate low odds of it happening with no chance of it happening at all.

If you don’t want you soldier to get shot, you break line of sight. This is an actual 0% chance to get hit :slight_smile:
If your base soldiers have 65% aim, you don’t take a shot unless you’re in elevated position or have close range bonus, or you use guaranteed damage consumables (grenades)

similarly, I’m quite happy with the reticule targeting of PP (minus potential alpha bugs) but I expect it to turn too much into "I put the small circle on a body part therefore I HAVE to hit said body part)

2 Likes

If a player of XCOM, or Phoenix point, never wants their soldiers to get shot and gets really angry when it happens, they are playing the wrong franchises. Word to the devs - you will never please these players no matter what you implement.

5 Likes

I don’t get annoyed if my soldiers just get shot. It happens, that’s fine. What I do get annoyed at is when a soldier has full health, is behind full cover and far away from the enemy, but he gets insta-killed by a sectoid (or equivalent rubbish enemy) who scores a crit as well as hitting with such a minuscule chance. Especially if it’s right after a soldier of mine misses a 90% chance to hit shot.

I’m not saying enemies shouldn’t be able to land these shots, there should just be measures in place to prevent these fluke moments that can destroy your best character despite perfect tactical game-play. Simply because when bad luck screws you over the game just isn’t fun, it feels like it’s cheating and it’s not a fair game instead.

2 Likes

That’s war for you. Expect casualties. You can never entirely mitigate risk … only manage it. Wen you score an unlikely shot, critical and kill the enemy, you don’t go on forums complaining the game was cheating. It’s fair because it can happen to either side. And we need the risk of death to be present to feel the tension.

3 Likes

It looks like the “dealing with the raw RNG” vs “tweaking the results to please the player” (or realistic vs fun) problem.

I hope to see Phoenix Point work - and advertise - as “true RNG” game, including ballistics, hit chances, game events, mutations etc. However that doesn’t mean we can’t have some safety nets to avoid the most extreme cases that may be received as unfair and cheating, like the dreaded one-hit deaths.

The FiraXCOM has the “stabilize critically wounded soldier” option instead of instakill. The Darkest Dungeon has “At Death’s Door” status that allows to heal the character with 0 HP. Some shooters like Borderlands have “Fight for your life” and “Second wind” sequence which gives the player last chance to rescue before dying.

Perhaps PP could borrow some of it - I imagine that one-shot-kill of a soldier with full health behind a cover (as in the given example) should result in 1 HP with Bleed and Unconscious. You have one turn to stabilize the unfortunate guy and then you have to guard him or carry him to the extraction zone, as the enemies could still abduct or target him.

This way:

  • you can prevent the unavoidable low chance insta-kill and give the player some control how to deal with the situation;
  • I would not call this cheating in favor of player as the unconscious soldier cannot be insta-healed, still can die and now requires squad’s help until end of the mission;
  • and this is very much realistic “exhausting the enemy” scenario, because the wounded soldiers need to be first-aided, carried out of the fight, evacuated to the hospital, get the medical treatment, which uses much more resources and manpower that just a body bags for the dead.
3 Likes

Its so funny how people don’t understand randomness, especially randomness in computers and I’m not talking about OP but rather about those saying 50% chance can mean 0% and 100% hits too… well, its not true. also, saying that chances are not showing on small samples is not true… c’mon, instead of writing this, you could just try it at home, get a freaking dice and tell me if you can random roll 6 10 times in a row… you cant. computers on the other hand do this all the time. If you don’t have a dice try the coin. you will only get 10 heads in a row extremely rarely, normally, even on small sample size it will be around 50%. and again, before you answer, try it… the problem is that choosing randomly between 1 and 2 and choosing a number below or above 50 randomly from 100 is not the same. while the first case will give you roughly 50% 1 or 2, the second will give you total random bull. the higher the pool the bigger the spread will be. to get a close to random you need to use the minimum possible pool. like for 75% use random(4) etc but its better if you dont even use random this way. bell curve and random(100) is the worse way on a computer to make up random. instead you should have base values and random multipliers that give deviations as its more logical and gives a far more fun experience (also, can easily account for multiple deviation lie weapon accuracy, soldier skill, aiming aids, useful range and so on and so on and so on). Im programming similar things and made up a little graph of how to do it: https://i.imgur.com/muUdGBW.jpg its far more sophisticated and easy to program. Still not realistic but at least logical.

1 Like

If you want to disprove basic mathematics and statistics, would you care to explain us where is the flaw? Empirical evidence isn’t really helping.

For the record, rolling a 6 ten times in a row is a one in 60 million, so telling someone “sit at home and try it … you can’t” isn’t exactly a valid argument. For the record, my biggest stroke of bad luck was missing 4 shots at 96% (roughly one in 400000 IIRC), that’s a different order of magnitude.

As far as improbable rolls, I once rolled an absurd sequence in Necromunda. Consider that almost every roll was a 1 in 6 chances and you’ll be close enough (shot → weapon jam → weapon explodes → wounds user → user falls from platform on top of other gang member → other gang member is wounded → user dies in AAR, bystander dies in AAR). Yup, those are crazy odds, and there is a reason why I still remember it almost 20 years later.

Since it’s impossible to roll 10*6 on a dice, with a mere 1 in 60M odds, you just proved that it is impossible to win the lottery too btw (looks like odds of winning the american lottery are in the 1 in 175M range). Of course, if there was evidence that some people won the powerball, it would be a bit of a contradiction wouldn’t it?

As far as computer generated RNG, rolling from a smaller sample and weight the result is a simple waste of code. Bear in mind that games like FiraXcom had their RNG dissected in great details, by mathematicians and programmers alike (sorry I CBA to dig out the studies atm) and the conclusions were “yes XCOM’s RNG is fair and, although there are imperfections that would not pass in stricter environments like casinos, these imperfections cannot be perceived by the human mind outside of a technical analysis of the generator”

4 Likes