Fun to see you here - I discovered this game through your videos! I think despite the lack of raw "content", I got a LOT of playtime out of this game by trying to push higher on the leaderboards.
I've considered trying to do some hyper optimisation, taking into account the number of cycles each instruction takes - it seems that a lot of people are interested in that.
That's not my natural style though. I've had plenty of criticism for not being performance sensitive, but that's not really how I unwind (although I do plenty of optimisation at work!).
Everyone is underestimating how hard it is to willingly kill a person. Shooting a paper target or apple at a range is nothing like sighting on a person, letting out your breath and pulling a trigger.
I think it's more appropriate to say TOTP /is (nearly)/ phishing-proof if you use a password manager integrated with the browser (not that it /doesn't need to be/ phishing-proof)
"Repeats" may be the term you're looking for. That would be interesting, however in some pieces it could make the overall document MUCH longer. It would be similar to loop unrolling.
It can be hard during live performances, because it can incur large jumps in the sheet music which can be annoying to follow. Not a problem if you learned the pieces by heart or have a pageturner, but this is not always feasible or the case.
The project has data about every location (doors, chests, etc.) and the conditions that must be met to allow access to those locations - for example [1]. From there the randomizer shuffles various entrances/exits and item locations around using rules that are mostly guaranteed to keep the game beatable.
Question for you and commenter above, do you play games with controls similar to Outer Wilds often? Do you play many games in general? I've seen this comment a few times and I'm curious why this is such a common talking point. I thought the controls were very intuitive, so I'm curious if it's a familiarity issue or something else.
The thing about Outer Wilds for me is that it's a game about exploration, but most attempts at exploration are punished (limited time frame, sands suffocating you, "ghost matter" kills...). They stuck with a "hard scifi" control scheme where you control your character in 6dof with inertia, which makes some things unnecessarily hard and did not (IMO) add anything to the game itself. The things you interact with in the world are also annoying to use, like the machines where you need to slide a ball around by locking it with your sight... Just let me press a button already!
I think there were two separate puzzles where I had identified the correct solution, but the mechanics were so clunky that my attempt failed. Making me waste time exploring elsewhere. Had to consult a guide just to see that I had unknowingly botched the physics. Which is an awful experience for a puzzle game. Especially when the clock is working against you and some of the set pieces require very specific timing to interact with them (where doors are only open for a certain few minutes in a run).
The game is definitely a unique experience, but some of the design elements hamper the experience.
I did not play with a controller, which made Dark Bramble effectively impossible to finish because the keyboard is all-or-nothing thrust. Had to cheat to get past it. They should have said that using a controller was mandatory, not recommended.
It's not mandatory, there's 1 part in Dark Bramble where you can go a little faster if you use a very small amount of thrust. You can just use the momentum you came in on though, there's still plenty of time
Totally achievable by using interfaces instead of structs
type Foo interface {
Foo() int
}
type Bar interface {
Bar() string
}
type FooBar interface {
Foo
Bar
}
Then functions that accept a Foo will also happily take a FooBar. Does not solve the problem of passing a FooBar[] to a function that expects Foo[] but that can be solved with generics or a simple function to convert FooBar[] to Foo[].
The motivation for the seemingly strange rounding is that a set of numbers can be rounded before summing without biasing the sum. It has good use cases but so do all rounding modes.
In general, if some recommendation from IEEE 754 (the floating-point standard) seems strange, its because someone like William Kahan thought about it in great detail and you'd be wise to follow it.
reply