Programmer, graduate student, and gamer. I’m also learning French and love any opportunity to practice :)

  • 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle


  • I find there’s a lot less variety in my monster train runs. Most classes have a distinctly best strategy and the artifacts generally also funnel you towards that strategy. For example, I can’t remember the last time I played an Umbra run that didn’t set up a morsel engine behind a warden or alloyed construct - as far as I’m concerned, those are the same strategy, it doesn’t feel different. The only other build I think is viable is just “play Shadowsiege,” which rarely happens early enough to build for it.

    Every class in STS has at least three viable archetypes and almost every run within those archetypes still feels different to me.


  • I almost exclusively play for A20 heart kills. I play all 4 classes but in a “whichever I feel like today” way. I tried rotating between the characters for a while and really didn’t enjoy playing silent or watcher while in the wrong mood for those classes.

    My favorite deck in recent memory was probably a silent discard combo with Grand Finale as the only damage-dealing card in the deck. My favorite archetype in general is probably ice defect. A good all-you-can-eat ironclad run is great too.

    I don’t think I agree that STS is especially well balanced - some regular hallway combats do irrationally more damage on average even to players much better than me (for example, floor one jaw worms or any act 3 darklings). In general, the game could be quite a bit harder on A20 and still be fun for players who want a challenge. It’s also weird to me that A1 makes the game easier compared to A0. Between the classes, there is a class which is clearly stronger than the others. However I also don’t think this is a bad thing. Imbalances create more opportunities for new experiences, and for different kinds of players to have different kinds of fun. And that certainly agrees with “infinite replayability.” I’m sure in 5 years’ time I will still be seeing interactions I’ve never seen before.




  • I’m a computer scientist mainly but with a heavy focus/interest in computer architecture. My plan is to teach at a university at this point - but it seems to me like that would be a good place to create completely open standards technology from.^1Specifically because if the point isn’t to make money, there’s no reason to create walled gardens.

    There’s certainly enough interest from people who want to be able to build their own systems. What would actually worry me isn’t the ability to make a new open standard or any of that. It’s that AMD64 is very hard to compete with in this space, because the processors are just faster, and there is so much x86 software that people who build PCs usually want access to.

    AMD64’s performance is the result of years and years of optimizations and patenting new hardware techniques, followed by aggressively litigating people trying to compete. ARM performance is catching up but ARM prefers licensing their core IP over making their own systems, making it harder for them to break into the PC space even if they want to.

    A new player would be in for a long, long time of unprofitable work just to compete with AMD64 - which most people are still happy with anyway.

    ^1 some others and I are actually working on some new ISA / open soft processors for it. However it is focused at an educational setting and unlikely to ever be used outside of embedded devices at most.


  • Only the number of shuffles is linear. Shuffling an array and marking/deleting correctly-placed elements still take linear time even with a “placement oracle.” It’s at best O(n^2) so the algorithm still wouldn’t be a good sorting algorithm.

    It’s like doing selection sort, except we’re selecting a random set of elements (from that poisson distribution) instead of the smallest one.


  • I’m not sure the median is what you want. The worst case behavior is unbounded. There is no guarantee that such an algorithm ever actually terminates, and in fact (with very low probability) it may not! But that means there is no well-defined median; we can’t enumerate the space.

    So let’s instead ask about the average, which is meaningful, as the increasingly high iteration-count datapoints are also decreasingly likely, in a way that we can compute without trying to enumerate all possible sequences of shuffles.

    Consider the problem like this: at every iteration, remove the elements that are in the correct positions and continue sorting a shorter list. As long as we keep getting shuffles where nothing is in the correct position, we can go forever. Such shuffles are called derangements, and the probability of getting one is 1/e. That is, the number of derangements of n items is the nearest integer to n!/e, so the probability of a derangement would be 1/n! * [n!/e]. This number converges to 1/e incredibly quickly as n grows - unsurprisingly, the number of correct digits is on the order of the factorial of n.

    We’re now interested in partial derangements D_{n,k}; the number of permutations of n elements which have k fixed points. D_{n,0} is the number of derangements, as established that is [n!/e]. Suppose k isn’t 0. Then we can pick k points to be correctly sorted, and multiply by the number of derangements of the others, for a total of nCk * [(n-k)!/e]. Note that [1/e] is 0, indeed, it’s not possible for exactly one element to be out of place.

    So what’s the probability of a particular partial derangement? Well now we’re asking for D_{n,k}/n!. That would be nCk/n! * [(n-k)!/e]. Let’s drop the nearest integer bit and call it an approximation, then (nCk * (n-k)!)/(n! * e) = 1/(k!*e). Look familiar? That’s a Poisson distribution with λ = 1!

    But if we have a Poisson distribution with λ = 1, then that means that on average we expect one new sorted element per shuffle, and hence we expect to take n shuffles. I’ll admit, I was not expecting that when I started working this out. I wrote a quick program to average some trials as a sanity check and it seems to hold.



  • I’ve used it to fix regressions, most recently in a register allocator for a compiler. There’s pretty much no chance I would’ve found that particular bug otherwise; it was caused by an innocuous change (one of those “this shouldn’t matter” things) clashing badly with an incorrect assumption baked into a completely different part of the allocator.

    I had seen the same effect from an unrelated bug on a different program. When I added a new test and saw the same effect, I had a “didn’t I fix this already?” moment. When I saw that the previous fix was still there, I checked if an older version of the allocator exhibited the same bug on the new test, and it did not. Bisecting found the offending change relatively quickly and further conventional testing exposed the incorrect assumption.


  • Learning how to program in any language will make it easier to pick up any other language, because the main burden for a beginner is how to think programmatically. However once you’re enough past that wall, being an expert on one language will mostly only help pick up languages that are similar. So if you knew C++, you could pick up the syntax and probably most of the semantics of the others very quickly, because they are similar in that regard. But you’d still probably struggle to actually program in C, because C is lower level (has way fewer features) than C++.

    Technically speaking, C is a subset of C++. But that doesn’t mean being a good C++ programmer automatically makes you a good C programmer.

    C# is similar to the other two in syntax as well, but it’s much more like Java than either of them.


  • If you want to make simpler games, you could start with scratch or stencyl. These tools aren’t really programming languages per se but they let you build programs out of blocks that are much easier to visualize and play around with. There’s some research that suggests they are good entry languages and some research that suggests they aren’t, so ymmv. I’ve used both, but I knew how to program already.

    For the record you shouldn’t let “usually made with” drive your decisions. Java is still popular for some games. Slay the spire, a very popular deck building game, was written in Java, which is a decently popular choice if you want to support modding. But C++ and C# are more popular simply because that’s what you use if you’re using engines like unity or unreal.

    side note: C, C++, and C# are all different languages.






  • Casually, I enjoyed it a lot. It felt like better BOTW, with much more new stuff to explore than I expected. My only gripes where the delay on quick menus (botw did not have that, and it feels awful) and I generally think the sage mechanic leads to bad play patterns. But overall, it’s amazing.

    I’ve been involved in speedrunning both games. Versioning issues in TOTK are way worse. Movement tech in botw was a lot more interesting and varied, until windbombs were found anyway. The menu lag feels even worse while speedrunning. The stuff we’ve got for inside shrines is pretty cool, and there’s some very cool out-of-bounds stuff found already. So it’ll probably stay fresh for a while. I’m not sure if it’ll hold me for as long as botw did though.