Shots too random


#62

Yeah, I get that that’s how the game finds it’s random numbers. Exactly as that article says though, “It should be noted that even though good PRNG algorithms exist, they aren’t always used, and it’s easy to get nasty surprises.” So they are fallible and can be influenced by things on the user’s computer. (like the example with Linux and Windows.)
Even a ‘true’ random number generator isn’t truly random. it just takes a complex variable beyond our ability to understand the composition of and that we’re unable to predict, then uses that. Even if we can’t understand it doesn’t mean there aren’t patterns involved in it. For example the example given in the article is an atmospheric static detector. Well, if there’s a thunder storm then it’ll be sensing a constantly amount of atmospheric static, whereas the day after a thunder storm with clear skys would have far less.

“Statistics” is the word used to describe the overarching group. Predictions using previous knowledge, like coin tossing, are statistical predictions. A ratio is also a statistic, for example. Having 2:1 ratio on enemies to soldiers is a statistic, but it’s not retrospective. Similarly looking forward and predicting the chance of something to occur, especially within a finite simulation where all variables can be measured, is also a statistical prediction.

Your argument is that the pseudo-random number functions are designed to give a consistent variety of random numbers. Except, they don’t at smaller sample sizes. Mathematically what’s really the difference between getting 5/10, 50/100 or 1/2? If the pattern that appeared in the 5/10 continued through the next 90 runs went the same way then it would be 50/100. So by getting 5/10 and not the closest possible number (7 or 8 out of 10) it’s actually failing to keep up the chance it predicted.

Enough with the ‘toin coss’ it doesn’t represent the chance that should be prevalent in PP. If we were talking about casino games and games where the entire point is relying on pure chance then you’d have a point but phoenix point is not one of those games. It has strategy, diversity in weapons and soldiers, finite resources, etc. So luck should be far less of an issue. Rolling 50% instead of 75% in a game like PP means you lose more ammo while killing less enemies, the enemies have more opportunities to shoot you back, etc. A little change in chance like that can severely hamper your progress in the game. PP’s individual bullet system helps a lot to deal with this since every shot it rolls the chance to hit 3/6/15 times.

This is not may argument. Can you people not read? I don’t want 100% chance. The fact that soldiers and aliens can miss is good. It makes cover far more important and gives you choices where you have to be aware of the consequences should your soldier fail to hit the shot. I simply want the system to be artificially balanced, rather than using purely random numbers. With it being artificially balanced it won’t screw the player over consistently but it also won’t cause aliens to miss every single shot. It’ll simply make the game more balanced by giving each player the same likelihood of hitting regardless of their own personal luck, or lack thereof.
You say you want it “fair” but unlimited randomness is not fair. If it doesn’t treat players the same way then it’s not a fair game.

You’re right, you would have to miss some shots so that the 75% chance was accurate. However, the benefit of the system is that you would only ever miss up to 4 shots in a row (in a set. It would technically be possible to miss 8 in a row if they were at the end of one set and the start of another but it would be extremely unlikely, and even then you’d have 12 guaranteed shots after that.)
Additionally, it doesn’t have to be a set of 16. It could be a set of 4, for absolutely certain balance. Though I personally feel this would be too predictable and players could exploit it too easily.

Absolutely. I would agree that it might be difficult to work out such a system, but the developers of the game are already designing complex chance systems and they are professionals with relevant training, so i think they could do it and I think it would be worth it.


#63

If both players had the chance to get the same result, it’s fair. One of them may be unlucky and get a losing streak, but the game in itself was fair.

I don’t want an artificial “equalizer”, which will be gamed by min-maxers sooner or later.


#64

Tried another random now. Everything was under control, and the crates were good too, but then both of my assaults were deathed by a rifleman crabman 2 shots 2 deaths, 2 random, pure frustration.


#65

The definition of ‘fair’ - “treating people equally without favouritism or discrimination.”
If people are given different results due to RNG then one is shown favouritism over the other. One gets good results while another gets bad results, all at the whim of RNG. It doesn’t do it intentionally but it still does it and therefore the game is unfair if based entirely upon RNG.

Why do you care what other players will do to exploit the game? People cheat. Min-maxers can already save scum or use mods to ensure their soldiers get the best possible results.
The aim should be to create a fair game that can be played intuitively when players don’t know the mechanics.


#66

And I say that this is not true. RNG will be RNG, it’s not favoritism. I consider this closed for me, nothing we can discuss about this.


#67

Hi all,

For some reason I couldn’t find this post one hour ago and so I made a new topic: sorry about that.

Anyway, here’s the thing: I am researcher in AI and a PP backer, though I cannot play the pre-alpha yet as I am using a Mac.

While reading this post and hearing of bell curves and the likes, I got nerd-sniped :slight_smile:

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.

I probably ended up reinventing the wheel (the devs are likely doing something similar), but in the off-chance that I found something new I’ve set up a small git repository and a (long-ish) post in html and pdf format which explains the goal and the process.

Long story short:

  • High probability values should appear close to the center of the circle…
  • …But when you need to generate trajectories, it’s important to make use a roughly bell-shaped distribution

Plus: knowing the theory means that the process can be tightly controlled to reach exactly the desired results.

The full post can be displayed via gitpreview

You can also get the pdf from the repository (the links in the document won’t work unless you download the file though, due to limitations in github pdf viewer – they are not particularly important, though).

Cheers,

Michele


An introduction to the bell curve by Dr. Venstad
An introduction to the bell curve by Dr. Venstad
[BackerBuild1] We need percentages of possible damage
#68

Wow! Thumbs up for the crazy effort you put in there. It’s also very easy to understand, even for me, and I have very little advanced maths knowledge.

It seems as though the links in your pdf don’t work though. At least, I can’t click on them.

Anyway, this looks like a good set up and I’d like to see it in the game. :smiley:


#69

Didn’t make it to the end but already appreciate it :slightly_smiling_face:


#70

@lompabo
wow, that’s just a lot of work you put there. Wonder if anyone here could review it proficiently.


#71

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


#72

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


#73

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


#74

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 ))


#75

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!


#76

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:


#77

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:


Things we *don't* want Phoenix Point to have
#78

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:


#79

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.)


#80

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


#81

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?