Hmm, okay. That doesn't sound like an implementation of RT then...just more like what we had up until now. No?
this is sort of what I mean earlier, lol. this is an implementation of ray tracing, it just doesn't have anything to do with rendering. casting rays has been done for a long-ass time in gaming. all this talk about ray tracing these days are about casting rays to have better rendering results
I'm going to reply just to this, because the rest is a strawman argument you have fabricated and which no one in this thread is defending.
It would feel worse because you'll be removing all the systems and design layers that the developers put in place to make the puzzles more fun and easier to play and replacing them with a system that has not been designed with a focus on gameplay. Like @RedSpring says, try doing it in real life and you'll see how many things you have to accomodate for to make the puzzle work as intended. Then you'll need to start adding passes of game design to make the solution obtainable, to fight back against false positives, to give hints to the player...
That's what I said earlier, that in order to use raytracing you have to hack the system just to end up doing what you were doing with the original "non-RT" solution, so there's no point in going that route. BTW, I think you're mixing Raytracing and Raycasting: "Raytracing" is used for lighting, while "raycasting" is just emitting a ray to check for collisions,. The latter is a pretty standard system in games since forever. I think Sonic 1 already used 2 raycasts downwards to detect slope inclination and the Zelda light puzzles probably already used it.
more envoled light/Sun puzzles, expect the light/Sun puzzles of Ocarina of Time/Majora Mask, in a much larger scale
that's not hacking the systems. you're not "changing" anything when you're creating the definitions in the first place. "ray tracing", "ray casting", "ray marching", "ray stepping", etc are all derived from the same basic principle of shooting a ray from a point and doing something with the collision. for rendering, you're determining how to color pixel upon hit based on the properties of the thing you hit. IMO, using "ray tracing" just to refer to lighting is too limited of a definition. especially when there are non-lighting examples out there including physics and audio
IMHO that's hacking the system because you're disabling a lot of its features and changing how it fundamentally works, like you said: "(...) you're only shooting one ray from the light source, and telling it to ignore any other object. the light source is also told not to have energy falloff with distance. the mirror is told to ignore any other light source aside from the one needed for the puzzle, and not to absorb energy of the light"
Yes, but "raytracing" in the context of this thread, has been used in regards to lighting since the very first post. Now, if you're saying that instead of "raytracing" we should be using "raycasting", well that's pretty much what everyone in this thread has been saying from the start, so I don't know what you're arguing at this point.
it's not disabling features if you never put them in in the first place
I wasn't arguing anything. I was describing a method of casting a ray to hit a mirrror in the typical "Zelda mirror puzzle". which is the kind of shit I was also talking about since post 5
I've seen RT being used for spatiotemporal distortions. that would be crazy for a dungeon
Probably this. Still nice tho
Sure, if you want to make a wacky game where people have to fight the controls like Getting Over It you can use physics. But the fact remains that after 40 years the golden standard reached by developers all over the world is that realism is not the goal when trying to achieve good gameplay. Even the example games you provide move away from physics and implement all the usual platforming hacks.
You're making a big assumption that more realistic systems will provide better gameplay, when in fact, the game designers objective often moves them in the complete opposite direction: You define what you want to achieve and then you take the steps in the direction to achieve it. Usually these include simplifying the physics (thus moving away from realism), trying and defining new hacks (again, moving away from realism) that get you closer to your goal. In Zelda's case, the goal has never been realism so the driving force behind the game has never been to achieve it. This idea of having to adequate the games design so it can incorporate raytracing for gameplay purposes is the absolute opposite of how Nintendo designs games.
Have you ever designed a puzzle? The first lesson you'll learn is that what seems evident to you will go completely unnoticed by most players. You really aren't aware of the layers and layers of "invisible" design that you can find in any good puzzle.
Again, no one is denying that. We're challenging the point that raytracing is going to be used for more than visual flair, because there's absolutely no gain in doing so and there are a lot of inconveniences. It's a lot of work just to introduce problems in something that's already been solved for decades and hopefully arrive to the same place where you are today.
