A few brainless clicks now and then, you say? A couple years ago I was sick and I played the game The Longing and I remember thinking it was the perfect stuck at home sick game.
Recently I completed Crossing Souls. It’s a game overloaded with 80s nostalgia. The soundtrack is from two composers. The first has 80s synth tracks while the other providers John Williams / Amblin like scores as the story of a group of young friends and feels like a movie from that time.
The 7th Guest and The 11th Hour remain top-tier for me. The music was half the experience, turn it up and just enjoy that creepy vibe while solving puzzles. And they’re all on The Fat Man’s Bandcamp now!
My dad and I used to play 7th Guest together. What a classic! It’s been a long time since I played that one. Had it on CD-ROM. Now I need to go find the soundtrack.
The full soundtracks to both games are on the Fat Man’s Bandcamp, which I linked up above. Also, the “greatest hits” collection album 7/11 is on Spotify. It’s surprisingly easy to listen to these days!
Would a game that is essentially a micro Linux distro count? I feel that should be pretty doable as a bootable USB stick or CD.
If you did it that way you’d have to bundle the Linux kernel plus graphics drivers at a minimum. But I wonder how much of the OS you could avoid having. Certainly you wouldn’t need a Desktop Environment. I wonder if you would need something like X or Wayland or if you could get away without that (to run games built in a normal-ish userspace way). I guess finding the minimal environment for SDL would be a good starting point. That sounds like an interesting exercise for sure.
Although something like that probably isn’t as pure as you’re looking for, it would be pretty cool to do anyway. Maybe we should start a club.
“Extrinsically motivated” games I like: I’ll play it once, beat it, play a bit of post game, drop it.
“Intrinsically motivated” games I like: make my own stupid-ass goal, spend dozens and dozens of hours on it, finally do the stupid thing, progressed 1% further through the game, get bored, drop it, but then I pick it up again thinking about doing another stupid-ass thing.
It mostly just contains graphical changes, and adds optional ray tracing which I wouldn’t suggest unless you have a very powerful computer.
It had some issues when it first came out, but it seems to work fine now from my experience. Don’t expect anything groundbreaking but it’s a nice update. Textures especially look better overall.
Not a game dev but I’ve done some programming and I love games so I’ll take a stab. There’s a few reasons I can think of:
That’s how the engine they’re using works. Game engines take a long time to develop, and so if you’re using one off the shelf or from a previous project, it may be from a time when tying behavior to the frame rate was a low overhead tool for timing that would cause few if any issues. Given that Wolfenstein is a Bethesda title and they’ve made many games with similar engine level limitations, this seems most likely to me for this particular case.
They never intended to release it that way, and just set it up that way early in development to start getting to the real gameplay work. Then the deadline came around and it wasn’t a high priority in terms of getting the game out the door.
Probably doesn’t apply to Wolfenstein, but for indie games that have one or only a few developers, none of those people may have done much programming before, instead being more focused on other aspects of game design. So if you’re learning as you go, there’s a good chance some hacky things will make it in to the final product.
Wolfenstein New Order was made by Machine games and used ID Tech 5, same as Doom 2016. Nothing to do with Bethesda or their Creation Engine. Bethesda only published it.
Because it’s easier to programm a single thread that executes a sequence of commands like [ update-gamelogic, update-graphics, etc. ] instead of at least 2 threads (for gamelogic and graphics) that you have to synchronize somehow. Synchronization can be pretty difficult!
Tying game logic to the framerate doesn’t really have anything to do with single- vs multi-threading. You can properly calculate the time since the last update in a single-threaded engine.
If the game loop doesn’t run at the same speed as the render loop you’ll get ‘tearing’ - some game objects are at the latest state, some are not. That can cause some funky bugs.
From my understanding, tearing can occur even if the game logic and render command submission happen on a single thread, since it’s a consequence of the OS compositor sending buffers to the monitor in the middle of rendering.
correct, but now you’ve just identified two separate types of tearing, both happening at different times. put them together and the perceived frequency will be significantly worse than it was prior.
being able to zero one of those out and only worry about the other means you can hopefully optimize a better solution - as much as one can when you can’t realistically atomically update the entire display from top to bottom.
A big problem with an unlocked framerate is the physics system, which you can generally solve in two ways:
You tie the physics to the framerate. Problem is that this introduces all sorts of weird behavior, caused by rounding errors and frequency of collision checks. For example, objects could start glitching through thin walls if their framerate is low because collisions are checked less often.
You run the physics at a fixed internal interval. This solves a lot of problem with the first approach, but also means that you have to put in effort to mask the fixed framerate through interpolation/extrapolation if you still want to keep the actual framerate unlocked.
So Wolfenstein New Order probably went with the first approach, made sure their physics system stays stable within a certain FPS range (30-60), and then locked the FPS beyond that.
Let’s say you don’t tie game mechanics to frame rate. How often should you update the state of the game? 50 times / second? 100 times / second? You need to pick a fixed rate if you want to keep the physics engine consistent. If you make the rate too high the game will not run on low-end machines, so you need to find the right balance.
But let’s say you make it 100 times / second. Now between those updates, nothing changes. You can render at 500 FPS, but you’ll be rendering the same thing five times before anything changes, so the extra frames are useless. There are ways around this. You could perform interpolation of object positions between the previous state and the new state (but this introduces input lag). You can keep things that don’t affect gameplay (e.g. eye-candy animations) running at the full FPS. But none of these things are trivially obvious. So it becomes a question of ambition, competence, and the will to put time (i.e. investor’s money) into it. Hence many projects simply prioritize other things.
I’m not sure what interests you most (or if you’ve already done this), but one thing I’ve always enjoyed is trying to tackle all of the shrines. Each of them has their own puzzles that’s different enough to keep me entertained, and the access to skip travel points is great for whatever else you might be doing.
You can also try to get korok seeds but those are sometimes even more annoying than the regular side quests
Edit: Sorry for the double comment, my app was glitching
bin.pol.social
Najstarsze