Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wi Flag (2002)

asheron.fandom.com

Post reply on HN
Print view View original

31–40 of 217 posts

Re: Wi Flag (2002)

#31

Post by ryani »

EarthLaunch wrote: post #10

Why does weighted randomness seem so difficult for games? Are there any libraries that simplify this? I couldn't find any for JS. So I created my own "algorithms" for things like randomly choosing which type of plants spawn in the world. It weighs them by the local frequency of each land-type. Eg if there's more swamp nearby, it's more likely to spawn cattails. It's awful. Not intuitive. Weights have to be passed in…

Here's the standard algorithm for this problem

    function weightedRandom(weight, outcomes){
      var total = sum( weight );
      var roll = Math.random()*total; // value in the range [0,total)
      var seen = 0;
      for(let i=0; i

Re: Wi Flag (2002)

#32

Post by jerf »

SamBam wrote: post #11
TheRealPomax wrote: post #2

tl;dr: players get attacked based on monster targeting RNG that's supposed to take an interval [0,num_players], assign players to subintervals that are shorter or longer based on a bunch of factors, and then roll a random number somewhere in that full interval. Whoever's subinterval the number ends in, they get targetted. Instead, the code assigned subintervals and then rolled a number between 0 and 1, instead of 0 a…

> A unit test could have caught this I've always wondered the best way to write tests for "This event should happen x% of the time." Obviously we could re-run the test 100 times and see if it happened close to x%, but not only is that inefficient, how close is "close"? You'll get a bell curve (or similar), and most of the time you'll be close to x but sometimes you'll be legitimately far away from x and your test wil…

In the similar situations I've run, what I've often done is:

1. Start with a known seed. 2. Run a single test run like what you say, and verify this run by hand. 3. Freeze the test in this state, that is, assert you get that exact result every time on the given seed.

What this creates is not what I would strictly speaking call a "unit test", but it does sort of pin the algorithm to your examined and verified output. In this case, a human would quite likely have caught this problem on a decent test set. Obviously, there are other pathologies that would slip right by a human; the human being careful only raises the bar for such pathologies, it doesn't completely eliminate them.

But at least freezing it solves the problem where a change you did not realize would be a change slips by unnoticed and this function suddenly has a completely different outcome.

This has worked for me, in the sense it has caught a couple of bugs that would have had non-trivial customer implications. But I've never worked on an MMORPG or anything else where randomness was intrinsic to my problem; it has always been incidental, like, is my password generation algorithm correct and does this sample of my data look like what I expect, not the core of my system.

Re: Wi Flag (2002)

#33

Post by groestl »

tmoertel wrote: post #14
dylanpyle wrote: post #3

I've seen a similar mistake in a rushed "feature flagging"/phased rollout system. User IDs were random UUIDs. Let's say we want to release a feature to ~33% of users; we take the first 2 characters of the UUID, giving us 256 possible buckets, then say that everyone in the first 1/3 of that range gets the feature. So, 00XXX...-55XXX... IDs get it, and 56-FF do not. This works fine. However, if we then release another…

One easy way to avoid this problem is to give each feature its own independent space of “dice rolls” by hashing the user ids with feature-specific constants before interpreting them as dice rolls: feature1_enabled = hash(user_id + "-feature1") / HASH_MAX

For reference: https://en.wikipedia.org/wiki/Consistent_hashing

Re: Wi Flag (2002)

#34

Post by shadowgovt »

veilrap wrote: post #5

I love the "lore" that this sort of bug creates, especially in these sorts of large scale multiplayer environments. Players claiming to be cursed, and the curse was real! A very different sort of event that it reminds me of is the old World of Warcraft plague: https://en.wikipedia.org/wiki/Corrupted_Blood_incident

One of my favorite things in gaming is when lore develops from bugs.

When they added the ability for Kerbals to be killed in Kerbal Space Program, they tripped over a bug where the first Kerbal in the game's engine, Jebediah (the one who dated back to the original introduction of astronauts at all, where only one existed), could not be killed. Because of some of the game logic having gone unmodified from the earlier versions, some operations would cause him to be loaded into the pilot seat and those operations didn't check if he was deceased. As a result, you could lose him on a mission only for him to spontaneously appear at the controls of another mission.

The community responded with fan-art of "Jebediah Kerman, thrillmaster."

Re: Wi Flag (2002)

#35

Post by Goronmon »

Aeolun wrote: post #23

Hmm, when they told me they were assigning people to a list I kind of knew what the answer was going to be. What is curious is that it took them a long time to find. I’d think that -as long as you believe there is a bug- this should be fairly straightforward to spot.

I could be remembering incorrectly, but back when this was occurring no one knew that issue was specifically limited to "mob spawns attacked certain people". The more honest description is the line about "From the beginning of AC, some players have complained about unbelievably bad luck."

People blamed this behavior for everything from loot drops, to combat outcomes, and to aggro mechanics.

And also remember that AC was before MMOs became massively popular, and outside of specific events and locations, there wasn't always more than a handful of players in a certain area for a given server where aggro mechanics like this would matter.

Re: Wi Flag (2002)

#36

Post by shadowgovt »

EarthLaunch wrote: post #10

Why does weighted randomness seem so difficult for games? Are there any libraries that simplify this? I couldn't find any for JS. So I created my own "algorithms" for things like randomly choosing which type of plants spawn in the world. It weighs them by the local frequency of each land-type. Eg if there's more swamp nearby, it's more likely to spawn cattails. It's awful. Not intuitive. Weights have to be passed in…

Statistics is actually pretty hard to get right, and it is the nature of the problem space that errors aren't immediately apparent unless one actually runs analytical regression on the algorithm to confirm it has the right "shape," which (a) can be time-consuming given the complexity of the algorithm and (b) doesn't tend to be part of unit tests because unit test doctrine is pathologically opposed to nondeterminism.

(This last pert is not an unsolvable problem, and in fact random algorithms should be unit tested. But it requires the right kind of unit testing).

Re: Wi Flag (2002)

#37

Post by hesdeadjim »

Some of my fondest gaming memories are from this game. There was nothing ever quite like it, and the allegiance system created a special type of community bond that I haven’t seen repeated.

At one point I had 10 “vassals” sworn to me, and in our allegiance that came with the expectation that you assist and mentor those under you. Stakes were higher when our allegiance committed to being red dot PKs on a white server with a few other stronger groups in play.

The server emulation scene has come a long way since retail shut down, but even the most populous servers are a pale shade of this game in its hey day.

Re: Wi Flag (2002)

#38

Post by phreeza »

tmoertel wrote: post #14
dylanpyle wrote: post #3

I've seen a similar mistake in a rushed "feature flagging"/phased rollout system. User IDs were random UUIDs. Let's say we want to release a feature to ~33% of users; we take the first 2 characters of the UUID, giving us 256 possible buckets, then say that everyone in the first 1/3 of that range gets the feature. So, 00XXX...-55XXX... IDs get it, and 56-FF do not. This works fine. However, if we then release another…

One easy way to avoid this problem is to give each feature its own independent space of “dice rolls” by hashing the user ids with feature-specific constants before interpreting them as dice rolls: feature1_enabled = hash(user_id + "-feature1") / HASH_MAX

If you suspect some flag effects interact with each other (e.g. one flag increases button size by 10%, and the other decreases it by 10%) you can go one step further and define feature groups and hash by user-id + group-id and then assign non overlapping ranges to the flags.

Re: Wi Flag (2002)

#39

Post by NKosmatos »

I enjoy reading such stories, where the software fault (or glitch) is something very simple and easily overlooked. Mind you, this story is from 2002 :-)

Re: Wi Flag (2002)

#40

Post by [deleted] »

EarthLaunch wrote: post #10

Why does weighted randomness seem so difficult for games? Are there any libraries that simplify this? I couldn't find any for JS. So I created my own "algorithms" for things like randomly choosing which type of plants spawn in the world. It weighs them by the local frequency of each land-type. Eg if there's more swamp nearby, it's more likely to spawn cattails. It's awful. Not intuitive. Weights have to be passed in…

[deleted]
Post reply on HN