Non-programmer idea for a game incorporating base assets/NPC's and AI mythologies/backstories/quests

RovingWanderer said:
A game with many pre-built assets for buildings, treasures, characters, etc… that doesn't change, and some magical connection to AI that generates stories, quests, attributes and so on for all of those graphical assets and NPCs for the game to reference and present to the player as a type of procedurally generated thing.

Hmm, that's just a single sentence describing something like a sandbox eventually, but not a game.
What should we do with it?

RovingWanderer said:
Non-musicians have suggested things to me that demonstrated their ignorance of stringed instruments

Do fast alternate picking on a single note and string, but accent each 3rd note.

That's just a single sentence too, but it should help you more than all the observations Troy Grady shared on his YT channel. ; )

Hi, JoeJ. Thanks for the response. I just had some mental diarrhea to expel. I knew it was based on absolutely no knowledge of anything technical, but my brain (I call him Fred, as in Fred Flinstone) formed this scenario of starting this game on my pc, selecting new game and seeing a unique experience pop up every time I click new game. I had to have a programmer tell Fred that there are things he doesn't grasp. Hopefully, your response will put Fred in his place again. That's not to say he won't come up with another thought and force me to post it here, though. 🙂

The area of adventure sandbox type games has not been explored much in theory, and not at all in practice, as far as I am aware.

RovingWanderer said:
I knew it was based on absolutely no knowledge of anything technical

Seems you use a lack of knowledge as an excuse to just letting Fred flowing, and then enjoying the vague emotional promise he makes up for you.
But that's a two fold mistake. Once because you refuse conscious realization that Fred isn't your private entertainer, but rather there is just yourself aiming to entertain others, and second because you refuse to tackle the lack of knowledge.

RovingWanderer said:
but my brain (I call him Fred, as in Fred Flinstone) formed this scenario of starting this game on my pc, selecting new game and seeing a unique experience pop up every time I click new game.

Don't stop here. You don't need to be a programmer to detect the lack of knowledge. To narrow it down, see what question your vague vision implies: ‘WHY do i want to have a unique experience each time i start a new game?’
Attempting to answer this, you likely get to new questions, e.g. ‘How could one play through differ form another by example?’, ‘How do my expectations differ from those of other players?’, ‘Which current games and genres tried to achieved my goals before, and what's their flaws and potential improvements?’ etc.
Just do the work to convert a desire but lack of knowledge into an actual game design, or let it be.

Btw, this is also why i don't see how ‘magic AI’ could just give us interesting dynamic stories in games.
AI can give you answers if you ask for something, by detecting patterns in millions of similar questions which have been asked before.
But it can not come up with the questions by itself, which is what it actually means to think.
So all you can do is tagging your assets with questions, and AI will generate stories to connect them, told by dynamic NPCs in real time.
But it will be just next level procedural boredom i'm sure.

I don't want a suno guitar player who sounds like everybody. I want Jimi Hendrix, or other human art.

RmbRT said:
The area of adventure sandbox type games has not been explored much in theory, and not at all in practice, as far as I am aware.

Well, we did quite a lot of theory i would say. But what's your plan to get started with it? After the racing game maybe? : )

Regarding myself, it's pointless to start a game before i have the ragdolls working, but i'm not as close as thought.
And that's still just a low priority hobby beside the work on GI, which i'll probably rewrite almost from scratch after current research on replacing ray tracing.
And i'm already 50. But i won't give up…

JoeJ said:
Well, we did quite a lot of theory i would say. But what's your plan to get started with it? After the racing game maybe? : )

Yes to both. We have done around 100 posts à 1 page per post or more, roughly, so around 100 pages of theory crafting and discussion, but it's not really gotten any public attention, so effectively, nothing is known about it to outsiders. And yeah, we probably will make the racing game first, that's the kind of game that is very cleanly scopeable compared to the other genres, and the minimal viable implementation of a racing game takes less effort than the minimal viable implementation of other genres, and then I can spend the rest of the budget on polishing and refining. Hopefully, that gains us around 5 years worth of budget in profits, so that we can make a proper adventure sandbox full time without a publisher. Our current budget is definitely not sufficient for making that straight out of the gate.

I already feel like 50… I don't want to know how bad it will be when I'm actually 50, lol.

Do you already have a method to give proper inputs to those ragdolls? Like, if the ragdolls are so complex an realistic, don't they also need complex input to get anything done? If you only get a directional thumbstick as the input method, or point and click, then I assume that won't really leverage much of the tech you're researching.

P.S.: somehow I did not get a notification in my feed about your reply. Only saw it by chance when looking through the main page's topics.

Here I've gone and jumped into a deep end of a pool that's way too big for me. I was merely hoping to see if there was something out there that was either waiting for me to experience or was a work-in-progress. Please don't borrow years from your future to put into your present, RmbRT. Keep yourself under 50 while you're under 50. I'm 62 going on 90, so I know where you could end up. At this point, it's difficult for me to retain enough knowledge to get from morning to bedtime, so my attempts to get into anything beyond simple perl and python scripting are futile. I certainly appreciate the information you've presented, though, and I'm sure your current project(s) will be quite interesting. I wish you and all the other braniacs here all the success in the world.

RmbRT said:
Do you already have a method to give proper inputs to those ragdolls? Like, if the ragdolls are so complex an realistic, don't they also need complex input to get anything done? If you only get a directional thumbstick as the input method, or point and click, then I assume that won't really leverage much of the tech you're researching.

Yeah, in fact idk and just hope to discover new gameplay options with experimentation and trial and error.

The primary problem is basic movement. I can not just set a velocity or acceleration to control the ragdoll precisely.
So my plan was to use a traditional but invisible character controller. The camera is mounted to that, so you can't see it but you can feel it. The ragdoll will try to follow, lagging behind a bit. But this should work good enough.
But currently i'm not sure if that's really needed. Direct control might work indeed well enough too, considering it should feel similar to the acceleration controls introduced with Super Mario and still used in any modern game.

Other actions like picking objects up / carrying them will not feel too different either. But it will be slower paced. Picking up some ammo ‘for real’ takes more time than just teleporting it to your inventory on proximity.
Likely the player has to wait, and if he moves too early the picking action will be interrupted and you don't get the ammo.
Not sure if this adds depth or if it just sucks, but i expect the former. With animation it would definitively suck, but with simulation i expect it's a joy to watch.

It's hard to imagine. But the way i think about it is: As a kid i loved RC cars. Controlling the toy from a distance felt like being an allmighty magican. And playing a racing video game is the exact same thing, just in a virtual reality.
But we did not have RC puppets or action figures. And video games are not there yet either. It's obviously fake.
So i hope the biggest advantage of the tech is not some unknown new gameplay mechanic, but just the way it feels to play itself.

JoeJ said:
The ragdoll will try to follow, lagging behind a bit.

This is a huge problem with game inputs, especially keyboard. You have the “activation” phase of the input already in the keystroke, but the game cannot feel it until it is fully pressed. Analog keyboards could maybe solve that, as you can also see the activation phase properly. Having movements that additionally lag behind the keystrokes sucks because it detaches the experience of issuing input from the experience of witnessing the consequences. Ideally, you could somehow make it snappy/responsive while also keeping realistic appearance (or at least something that feels real, even if it is technically wrong). You don't want a 100ms delay caused by the pressing of the key, and then another 100ms delay by the preparation of the ragdoll body until it properly winds up the motion.

JoeJ said:
Other actions like picking objects up / carrying them will not feel too different either. But it will be slower paced. Picking up some ammo ‘for real’ takes more time than just teleporting it to your inventory on proximity. Likely the player has to wait, and if he moves too early the picking action will be interrupted and you don't get the ammo.

Reminds me of what I came up with back in that “innovation on the FPS genre” thread years ago. Don't allow for instant 360° spins with infinite/instantaneous acceleration / deceleration, but rather cap the acceleration and deceleration rates, and also limit the maximum turn speed. And reduce accuracy while doing these major movements. It makes no sense to have higher accuracy while squatting than while standing up, and higher accuracy while still vs. when walking, but then have 0 accuracy impact when suddenly spinning around 720° out of nowhere. Also aiming with a drawn gun while walking is super hard, even if you aim down the sights (I tried it myself and you basically can't hit anyone reliably more than a few steps away, unless you put a lot of training into it). And spinning makes it even worse than just walking.

If you go for this kind of less snappy, but more grounded kind of control scheme, that is what I would recommend doing. It feels shitty because it causes lag / sluggishness in the controls, but it creates the experience of you controlling an actual body in the game world, instead of you as the player moving around using your keystrokes. Whereas current games focus on feeling as if it is you who moves around (even if it's third person view), and the shown character does not register as a separate person, but simply a visual representation of yourself. In the sluggish, more grounded controls and physics, the player does not feel like he himself is in that world, moving, but rather he is controlling a real person. Which while it breaks the initial type of immersion of you yourself being in that world, lets you create a new type of immersion: because the physicality of the body you control is so emphasized, you can also properly convey the state of the body without health and stamina bars etc., such as limping, or getting winded, etc..

So this new path could be aiming at having a very empathic experience with a real-feeling body in that world, but the player does not feel as though he himself is in that world, rather, he can strongly empathise with what a body he has control over is experiencing.

Also, there's a distinction between whether the camera is responsive, and whether the character is responsive. Decoupling the camera from the character's movement lag can already make the lag much more tolerable, while keeping the option to have mechanics of movement be sluggish. But either way, you can't use the current paradigm of game design with that kind of controls. You have to rediscover the first principles of the new situation you create when you have these kinds of controls, and then see the potential strengths and weaknesses of that situation. Old wisdom doesn't apply anymore when you change something so fundamental, and not only the method, but also the intended outcome must be re-assessed from scratch.

RovingWanderer said:
Here I've gone and jumped into a deep end of a pool that's way too big for me. I was merely hoping to see if there was something out there that was either waiting for me to experience or was a work-in-progress. Please don't borrow years from your future to put into your present, RmbRT. Keep yourself under 50 while you're under 50. I'm 62 going on 90, so I know where you could end up. At this point, it's difficult for me to retain enough knowledge to get from morning to bedtime, so my attempts to get into anything beyond simple perl and python scripting are futile. I certainly appreciate the information you've presented, though, and I'm sure your current project(s) will be quite interesting. I wish you and all the other braniacs here all the success in the world.

I've kind of made my peace with the fact that I don't really have full control over my health. I'm doing things here and there, and they are somewhat helpful, but ultimately, a full recovery is not something I can achieve through my own actions. So either God sees it fit to make me able like a normal person again, or I'll stay this way. Anyway, I'll keep that topic limited to this much, here.

RmbRT said:
This is a huge problem with game inputs, especially keyboard. You have the “activation” phase of the input already in the keystroke, but the game cannot feel it until it is fully pressed. Analog keyboards could maybe solve that, as you can also see the activation phase properly.

Yeah. Imo, it's the most ridiculous thing about PC gaming.
I mean, playing games is probably almost all that people do with PCs, beside browsing internet.
And still, while some genius HW companies managed to give WASD keys another color, nobody is willing to put a little anaklog stick on every keyboard, the fuck. : (

But well, it's still better than gamepads which lack mouse look.
Even more ridiculous.

Or, mobiles. Apple + Google making more money with games than Sony and Microslop combined, but… no fucking buttons at all???

Idk if those billion dollar gaming industries are dumb, coward, or just too stupid. But there still is no proper input device to play games.
Though, i should not really complain, because i know exactly what future those mentally ill tech billionaire accelerationists have prepared for us: First they take all HW away from us because they need it for themselves. And then they expect us to play cloud games by voice commands given to AI assistants, soon to be followed by neural interfaces, to put the AI brain prosthesis trend to the next level.

Can't wait for that, so i'm happy with WASD as long as i can have it. >:(

RmbRT said:
Having movements that additionally lag behind the keystrokes sucks

I have personally never experienced input lag when playing games. You did? What are examples?
I was thinking input lag is just a myth they come up with to sell us stuff now with awesome ‘NVidia Reflex’ features, in a time where the new GPU isn't any faster than the old GPU already was. ; )

The only input lag i have ever experienced was playing guitar with software amp simulation on PC. That's bad, but still ok after getting used to it. And those latencies are surely way higher than with gaming.

But probably i'm just not sensual for lag. I also don't complain about TAA smearing on the visual side for example. Other people hate it.

However, maybe more interesting is the fact that not every form of lag feels bad.
The Super Mario player controller is the best example. Compared to PacMan Mario is laggy, because it takes time until acceleration changes the velocity. But this is expected behavior, since the applies to everything we know from the real world too.
So it feels good to play, because it fulfills expectations, and also because it gives you some time to plan your trajectory.

Imo, the Mario acceleration controller is the greatest innovation on action games so far, even beating the 3D immersion Doom has added on top later. (though, i'm not sure if Mario was indeed the first game doing it this way)

RmbRT said:
Reminds me of what I came up with back in that “innovation on the FPS genre” thread years ago. Don't allow for instant 360° spins with infinite/instantaneous acceleration / deceleration, but rather cap the acceleration and deceleration rates, and also limit the maximum turn speed.

Ah, i share this idea.
For the ragdoll movements i mostly use controllers that drive to a given target as fast as possible, using given constant acceleration and deceleration. (There is no maximum velocity, which may feel counter intuitive but indeed mostly isn't needed.)
This is basically the most ‘natural’ motion you can have, because it again fulfills expectations learned from the real world, since gravity is just constant acceleration too.
I'm quite sure using this controller to smoothen mouse look would indeed feel good. And it's little work to try out, but i haven't yet…

RmbRT said:
(I tried it myself and you basically can't hit anyone reliably more than a few steps away, unless you put a lot of training into it).

I would claim the opposite: It's easier to hit distant targets while moving, simply because the enemy movement at large distance has a smaller effect on the distance to the cross hair.
This is important, because it gives this design principle:
Distant enemies: Player feels in control and applies strategic reasoning. Satisfying.
Close up enemies: Player is stressed and in panic. Chaos.

This is also why i personally love shooters but hate melee combat.

RmbRT said:
Whereas current games focus on feeling as if it is you who moves around (even if it's third person view)

Yeah, i was thinking along those lines. But recently i became more optimistic that i can do more ‘snappy’ or ‘twitchy’ stuff than initially expected.
Though, in general what i want is: Player feels like observing the protagonist by floating around him, but still feels like being in the game regarding camera controls.
This is always possible no matter what, so i do not worry.

RmbRT said:
So this new path could be aiming at having a very empathic experience with a real-feeling body in that world, but the player does not feel as though he himself is in that world, rather, he can strongly empathise with what a body he has control over is experiencing.

Yes. It will feel different then modern 3rd person games, but it will surely work from the psychological perspective.
However, there two fundamental technical problems, which were never perfectly solved.

1. Protagonist occlusion. Current solution is to show characters back on the side of the screen. And i really hate this. I can not even walk straight ahead with this setup.
The better solution is to show the character in the center, requiring to zoom out and showing him smaller. This was more popular in the 90s, e.g. in MDK. This is what i want, but it makes the second problem much worse:

2. Environment clipping camera. Current solution is to avoid camera environment collision by tracing a ray from character to desired camera position, shortening if needed. But this takes away camera control from the player and that's a no-go to me.
So i need a way to clip the environment instead, guaranteeing an empty cone from camera to character.
Unfortunately this is a hard rendering problem. I have some ideas, but it's very experimental stuff so far.
However, if it works, i can do the impossible: Enabling sidescroller platforming and tactical oversight, simply by running sideways instead forwards when desired. I could merge Doom and Mario into a single game, which has never been done. \:D/

RmbRT said:
But either way, you can't use the current paradigm of game design with that kind of controls. You have to rediscover the first principles of the new situation you create when you have these kinds of controls, and then see the potential strengths and weaknesses of that situation. Old wisdom doesn't apply anymore when you change something so fundamental, and not only the method, but also the intended outcome must be re-assessed from scratch.

Oh yes, my friend. And this is exactly why i'm so optimistic that new games are still possible.
We just need to change those fundamentals, and then we're basically forced to create new stuff, and it will just happen.
Which is exactly what's currently needed.

However, coming up with new things sadly is NOT a guarantee for success. But that's another story… : )

These kinds of keyboards would be a great standard going forward, and maybe also finally eliminate the legacy lockup of keys, depending on what other keys are already pressed: https://youtu.be/hEkLnJugFNQ?t=181 (somehow the forum fails to embed videos properly, eventhough it worked before…). These allow you to detect the keystroke with varying intensity instead of as a boolean. This would be really great if it was widely available. You could even detect the speed at which a key gets pressed (so you can differentiate key slams from normal presses and all that).

JoeJ said:
I have personally never experienced input lag when playing games. You did? What are examples?

No, I was saying, in case your ragdoll only starts moving after it registers they keypress, but that movement also still needs the realistic center of mass / posture shift, and muscle activations, etc., then you get the time it takes to press the key + the time it takes for the simulated body to get into motion properly. Whereas the current paradigm just instantly applies inputs to the character, or with only unrealistically little warmup. A real person cannot accelerate as quickly as any game character when you stand still and then press a key.

JoeJ said:
I would claim the opposite: It's easier to hit distant targets while moving, simply because the enemy movement at large distance has a smaller effect on the distance to the cross hair.

I was talking about me moving while holding the gun and trying to aim. Even just trying to keep it aimed ahead and the iron sights properly aligned is quite difficult. And then the arms must also be kept properly steady, and all that, and you must counteract the head bobbing etc. So even just walking straight forwards toward a stationary target while already having it in your sights is hard, when parallax doesn't even come into play yet.

JoeJ said:
However, if it works, i can do the impossible: Enabling sidescroller platforming and tactical oversight, simply by running sideways instead forwards when desired. I could merge Doom and Mario into a single game, which has never been done. \:D/

I was actually planning on making an engine that unifies first person view, third person view, and bird's eye view, and the associated control modes. Each camera mode has its own strengths and weaknesses and situations in which it really shines, so why force the same camera mode over the entire course of a game?

RmbRT said:
These allow you to detect the keystroke with varying intensity instead of as a boolean. This would be really great if it was widely available. You could even detect the speed at which a key gets pressed (so you can differentiate key slams from normal presses and all that).

Interesting. Although, consider the following toy problem:

Try to press A with a pressure of 50%.
Try to press D with a pressure of 50%.

You will pass this test only if you have visual feedback showing both percentage values on screen.
But under practical conditions you simply will not know how much pressure you apply, and you will fail even harder to have consistent precision across all fingers / keys.

A small analog sick would be better, because you can feel the angle mach better than pressure or depth.
Although those sticks have problems too, actually the difficulty to move only horizontally, but keep the vertical value at zero for example.
They currently solve this using a ‘push back to center force’, generated from two orthogonal springs.
But that's bad too, because now the push back makes it hard to keep a constant value without tensing up muscles, and it makes it harder to control both axis independently.
So driving a car with analog stick isn't a great experience either, imo.

Thinking of playing guitar again, this could inspire a solution for the kb method:
You can change the pitch of a note by bending the string up or down, and you can do this with great precision.
Ofc. that's because you get good feedback from listening to the pitch. I'm not sure if i could do precise bending without this feedback. But surely it would be much better than setting pressure or depth without doubt.

So i propose that WASD keys should be ‘bendable’, meaning you can pull them a bit down to tilt their angle.
Maybe that's nonsense, but would be worth to try out.

I really like to rant about game controllers, but it's not that i have a better idea regarding movement. ; )

RmbRT said:
A real person cannot accelerate as quickly as any game character when you stand still and then press a key.

That's not precisely true. The real person can not behave like PacMan, yes. But it can and does behave like Mario.
So this is not a problem i think, and thus may fake character controller probably isn't needed.

But ofc. a real person can not jump like Mario does. It can not change direction in air, and it can not alternate gravity with a button press.
This is a problem. So if i want precise jumping like Mario, i have to cheat, by applying external force when in air.

Not sure what i'll end up doing here, but cheating is always possible.
I could even cheat to reach maximum human walking speed finally, or getting faster than that.
But cheating is last resort and i'm not yet desperate enough to do it.
(However, i do assume cheating becomes needed later in practice to serve various game design goals.)

RmbRT said:
I was talking about me moving while holding the gun and trying to aim. Even just trying to keep it aimed ahead and the iron sights properly aligned is quite difficult. And then the arms must also be kept properly steady, and all that, and you must counteract the head bobbing etc. So even just walking straight forwards toward a stationary target while already having it in your sights is hard, when parallax doesn't even come into play yet.

I'm not sure if you mean the difficulty of aiming while playing Quake, or if you mean the the difficulty of positioning ragdoll bones precisely enough to aim at the cross hair with the virtual gun. But the later can be solved always and easily with cheating.
(I do not assume much cheating is needed here. The accuracy required to stay balanced is totally insane. So if i can do that already and robustly, i can assume that lack of accuracy is not a big problem in general. It's always just a latency problem, as it takes time to ‘hit the target’.)

Some games do accurate simulation of the virtual gun. Outcast for example. Your shot might be blocked from obstacles which did not occlude your cross hair, but otherwise it's enjoyable to observe. Anyway, we can always do what we prefer, no matter if animation or simulation.

RmbRT said:
I was actually planning on making an engine that unifies first person view, third person view, and bird's eye view

Outcast does this too, although its controls did not age as wall as the rest of the game. Iirc you can set camera distance with the mouse wheel, which is intuitive. But i almost never used this when playing.

Some Bethesda RPGs also do it, iirc.

I kind of want to do this too, but i assume it gives less benefit than we imagine. We'll see… : )

JoeJ said:
I'm not sure if you mean the difficulty of aiming while playing Quake, or if you mean the the difficulty of positioning ragdoll bones precisely enough to aim at the cross hair with the virtual gun. But the later can be solved always and easily with cheating.

I was talking about my IRL experience with guns. Aiming accurately without a bipod is extremely hard. Keeping a steady aim requires lots of control over your body and breathing. If you start walking or turning, it becomes way harder still. You go from hitting the center circle to almost missing the entire target. Yet in games, walking or turning while aiming down the sights will not give you a massive bullet spread. But when shooting from the hip, walking or crouching does affect your bullet spread.

Maybe that is just part of standard soldier training, and I just have no talent, but still I think games should factor that into their mechanics. They already did the same thing with snipers and holding your breath. I bet even a real super-soldier can't just walk around a corner, see something in the distance at the edge of his vision, instantly snap his aim to that thing and give a shot and give a headshot. Which is exactly what makes FPS games so damn annoying. 240Hz monitors are only required in online FPS because the character has unlimited turn speed and instant acceleration/deceleration, and loses no accuracy from just twitching your aim 60° to the side instantly.

JoeJ said:
I kind of want to do this too, but i assume it gives less benefit than we imagine. We'll see… : )

If you are in first person view, you get WASD + mouse aim, which makes platforming for example much easier, or aiming into the distance or whatever. FPS type stuff. In third person view, you lose control and precision compared to FPS view, but you get more contextual awareness of your surroundings. And you can even look around corners. Bird's eye view lets you look all around you and behind you, so if you are swarmed by enemies, that can help a lot, but you lose the vertical aspect of control entirely. Controls would then be directional movement and diablo-style point and click attacks. Also, bird's eye view can also allow you to control entire squads of units like in an RPG, while FPS only allows control of a single unit, but with higher control.

RmbRT said:
I was talking about my IRL experience with guns.

Ah ok. Well, i remember as a kid i tried shooting with Luftdruckgewehr with the local Schuetzenverein. But i could not hit anything even when standing still. I was the worst of all, like with any other sports i had tried. I can not catch a ball either.

RmbRT said:
but still I think games should factor that into their mechanics.

Would not be much fun i guess. The usual way to do it is giving the projectile direction a random offset, as done to model spread for shotgun projectiles.
But if you do this for my beloved Quake railgun, i certainly would not like that. ; )

RmbRT said:
They already did the same thing with snipers and holding your breath.

Ah yes. Often there was a random low frequency camera wiggle with snipers, so you had to shoot in the right moment when the crosshair was at the right place. Same concept as with meh ‘dart simulation’ on C64.
But no, please don't. Find another way to add a challenge, avoiding randomness. E.g. make the enemies moving more. Same kind of challenge, but feels fair to the player.

RmbRT said:
and give a headshot. Which is exactly what makes FPS games so damn annoying.

I well remember this happened to me when trying Battlefield 3. Spawn, headshot from somewhere, spawn, headshot, spawn, headshot… rage quit, stopped playing multiplayer FPS forever.

The problem here is simply: Shooters in open outdoor environment is no fun. Period.
The solution is simple too: Use indoor environments instead, adding an actual boundary to constrain movement and sight, to make it interesting and tactical. You don't get shot from ‘somewhere’, because somewhere does not exist within the boundary.
I would still play Quake Live if it were still free.

RmbRT said:
If you are in first person view, you get WASD + mouse aim, which makes platforming for example much easier

It's the opposite: In first person you can not do proper platforming, because you do not see the edge on the cliff below your feet, so you do not know haw far you can run until you must jump.

With third person that's better, but still bad, because the perspective projection destroys your sense of distance while running forwards.

So the only way to have proper Mario platforming is running sideways, where perspective projection becomes irrelevant.

But this does not work indoors, because the required large camera distance for enough oversight isn't possible, due to walls getting in the way and blocking view.

Super Mario 64 is a critically acclaimed video game, they say. But the truth is: It sucks, it's a disaster, and it's terrible camera controls has destroyed one or two generations of early console 3D video games. It took those japanese devs years to realize that Miyamoto had completely failed on 3D, and only Carmack got it right.
That's quite funny. But while Quake can do some decent platforming which isn't bad, it's nowhere near to what 2D Mario platforming gives.

Idk why i'm the only one expressing this so frankly, but imo this should be the first paragraph in the bible of action game design.
This is the key problem which we dodge since decades, but actually have to solve. To get back the greatness we have lost in favor of immersion, which we do not want to give up either.

RmbRT said:
And you can even look around corners. Bird's eye view lets you look all around you and behind you

Yes, but notice we get the camera clipping problem here too. In interiors, which remain essential to define the boundary, you can not do top down view easily.

Though, in this case we do have working solutions. Top down games just remove the ceiling and other objects blocking the view.
It works, but it's not the general solution needed to have a seamless transition to 3rd / 1st person camera.

A very simple workaround i use for prototyping is: Render back faces in black.
This way you can set the front clipping plane closely behind the character, but move the camera far behind into the empty void behind the clipping plane.
The clipping plane slices through the walls, showing a black cross section for the sliced, solid interior of walls.
It's glitchy and inefficient, but good enough for prototyping on low poly level geometry.

I have tried this using physics debug rendering:

You can see the black cross section of clipped walls, including glitches caused from intersecting, non manifold geometry.
Yes, looks bad.

Using Quake BSP levels, we could actually calculate the clipping cross section efficiently and robustly, solving the glitches and avoiding to render everything twice.
But that's limited to low poly levels which are no longer good enough in the modern general case.

Another option i see is using a transparent falloff instead hard clipping.
This way we eventually do not need the ugly cross sections.
I have tried this using my point splatting method borrowed from the GI project. Unfortunately the spherical projection is a bit confusing and detail is low. But here is how it looks without any clipping:

And here after moving the clipping plane forwards so it slices walls (and also clips the light and grey box on the ground):

You can see the soft clipping falloff on the red wall on the right.
Yes, it looks like shit too, but it would be perfectly playable. Flying through the scene gives me a good spatial impression and i get used to the strange clipping within seconds.

I'm not sure if any of those attempts would give acceptable visuals to players.
But it is indeed this very technical rendering problem which prevents us from making the perfect action game by merging Mario and Doom. So it's worth to share those results, even if still bad.

JoeJ said:
Would not be much fun i guess. The usual way to do it is giving the projectile direction a random offset, as done to model spread for shotgun projectiles. But if you do this for my beloved Quake railgun, i certainly would not like that. ; )

Well, either you get that kind of combat, but then people with 240Hz monitors and lower internet latency etc. will dominate, while this more grounded system I'm proposing would even the playing field much more. I hate coming across people who got their insane setups and way too much practice in those simulators that are just there to train your twitchy movements to aim at things that appear randomly on the screen, just to shave off milliseconds. Either you jump on that bandwagon or you'll be left behind and trampled over again and again.

JoeJ said:
Idk why i'm the only one expressing this so frankly, but imo this should be the first paragraph in the bible of action game design. This is the key problem which we dodge since decades, but actually have to solve. To get back the greatness we have lost in favor of immersion, which we do not want to give up either.

I guess you're right in that sideways camera is good for platforming jumps, but FPS view is best for walking over planks for example. And the effect of weapon barrel vs. camera, that is also much easier to control when you're in first person mode. For example if you need to throw a grenade over a wall or through a window, first person camera is much superior. You get better directional aim and can judge bullet/grenade trajectories much better in FPS view.

JoeJ said:
The problem here is simply: Shooters in open outdoor environment is no fun. Period. The solution is simple too: Use indoor environments instead, adding an actual boundary to constrain movement and sight, to make it interesting and tactical. You don't get shot from ‘somewhere’, because somewhere does not exist within the boundary.

Even shooters with indoors maps suffer from the same twitch shooting. Camper spots become popular because they are well protected or hidden but let you attack someone who just enters a new room easily. Multiplayer shooters in general suffer from a lot of factors that combine into something ugly as a whole. In a game where even remotely reliable aim requires that you don't turn much more don't walk quickly, the entire way you approach the game changes drastically. Positioning and cover becomes important, and timing, too. Running across an open area isn't instant death anymore, unless the enemy is willing to stay perfectly still to get a good shot in from his sniping spot. And once he exposes himself to shoot at you, he can't react well to others who attack him from other angles. The entire dynamic changes from twitchy competitions about who shoots first, into constant tactical tradeoffs of where you look, how good your cover is, how much effort you put into accuracy vs. whether to shoot quickly, and how fast you can move, etc..

Someone who sprints from cover to cover will then have a pretty good chance of surviving, because the enemies will not instantly be able to target him if they haven't already been aiming his way. And following him with their aim requires turning, which reduces accuracy. In current games, as soon as you even walk halfway around a corner, you're already dead. In a more realistic setting, you can dash from cover to cover and it gets you maybe a second of time where you're hard to hit if the enemy is taken by surprise. And if he starts spraying bullets, he'll hit even less.

———————————

Regarding the clipping for third person view: I guess the engine could trace a ray from the camera and see where it intersects like they do it already, and from then on, travel further backwards until the proper camera distance is reached. And then it knows all the geometry it crossed and that is in need of clipping. So it can then calculate the clipped planes and insert immediate-mode geometry that fills the hole properly, or something.

RmbRT said:
but then people with 240Hz monitors and lower internet latency etc. will dominate

Hmm, that's a point. Never looked at it that way, and i'm always just thinking about single player.
For Quake Live my handicap always was due to slow internet.
And observing other players which were really good at it, it showed they did no twitchy movements. They moved much less than i did, but maybe aimed more precisely, with more focus. They played slower, and i did not really understand how they did not get hit regardless.

But i missed out on later, more modern MP shooters. Did not play Counterstrike, CoD, or BF.
In Quake you keep moving all the time, and the movement is very fast. Camping or taking cover rarely happens.

RmbRT said:
So it can then calculate the clipped planes and insert immediate-mode geometry that fills the hole properly, or something.

Yeah, but while clipping geometry with a plane is fast, finding polygons to fill the cross section is not. It requires mesh data structures with adjacency information so you can traverse it, adding a high storage cost and high CPU cost at runtime. With modern levels of detail it's a real problem.
Also, most geometry currently used for visuals is not manifold, so calculating cross sections is not possible at all.

Though, if i really wanted to do this, i could use BSP trees and low poly levels. Retro Quake artstyle, but for a very cool game.
This would be practical. But i'm not yet desperate enough to give up on a more general solution also here… : )

JoeJ said:
Though, if i really wanted to do this, i could use BSP trees and low poly levels. Retro Quake artstyle, but for a very cool game. This would be practical. But i'm not yet desperate enough to give up on a more general solution also here… : )

Maybe something like nanite with chunked models and chunked LODs could actually be helpful for such a thing? Other than that, you could probably also do a second render pass that renders the clipped chunks of the model again, but with a different depth and maybe a stencil or something, and with a pixel shader that shades a flat plane instead of the actual geometry? I haven't really fully formed the thought so I can't explain it well, but I hope you get what I am trying to get at.

JoeJ said:
But i missed out on later, more modern MP shooters. Did not play Counterstrike, CoD, or BF. In Quake you keep moving all the time, and the movement is very fast. Camping or taking cover rarely happens.

Yeah it's mostly a thing in modern online shooters. It's the equivalent of what the Starcraft guys do with their hundreds of clicks per minute and what not, just for FPS instead. RTS games also should not be won through sweaty micromanagement, IMO, but through genuine strategic ability as a commander. In real wars, central command also doesn't micromanage every unit, and every process.

RmbRT said:
Maybe something like nanite with chunked models and chunked LODs could actually be helpful for such a thing?

Oh no. Nanite would make this just much, much harder i'm sure.

RmbRT said:
I haven't really fully formed the thought so I can't explain it well, but I hope you get what I am trying to get at.

It sounds you have vague ideas about a problem you never thought about before. But not sure.

Defining the problem is quite simple: We need a way to test if a point is inside or outside of a model, or to say it differently, if the point is in solid or in empty space.
If you have such test, you can do it for any pixel on the clipping plane, shading it black if solid.

The problem is, the data structures we use for rendering (e.g. mesh) only describe the surface, but no in/outside.

A simple solution is to trace a ray from the point along a random direction. If you hit a backface, you're inside.
But this only works for manifold models having a watertight surface. But for rendering we tend to remove surfaces which are not visible, or we use intersections of kitbashed instanced models, or we have some tiny holes, etc. all this breaks the manifold property.

A robust test which still works with such mess is to integrate the winding number of all surface to the point.
This mean iterating ALL triangles and summing up their solid angle / form factor.
It's neat and elegant. I have a very fast implementation of this for preprocessing GI paramterization, which avoids the brute force using hierarchical optimization. It can convert non manifold models to a density volume.
But no way to do this in real time.
However, i could store a DAG compressed voxelization of the static geometry, since i could easily get this data from the GI preprocessing tool. Lookup would be quite fast, at least faster than tracing a ray.
But no way to store such data for large and unique open worlds. This would be possible only if the scene is composed from instances, like Epic does for it's SDF volumes they use for GI.

So no matter how i turn it, it's probably only possible with some form of restrictions on content.
And considering the final visual result is unusual and probably rejected by many players, it's likely not worth all the trouble.

I currently favor the soft falloff method, not requiring to render the cross section.
But this may make sense only if i render the entire frame with splatting, abandoning HW triangles.
So that's a real revolution, which feels risky. But the splatting has some killer advantages:
Shading cache is trivial, reducing lighting cost by a factor of about 10 i guess.
True continuous lod is trivial as well due to blending discrete lods in image space. (The images above are actually the first time you have seen true continuous lod for both geometry and material.)
There is no aliasing. No need for related post processing and hacks. It generates a prefilterd image, and offline rendering image quality becomes possible.

But i also have some new problems, which do not exist with traditional triangle rasterization:
Needs high resolution point data for good quality, even for a large flat single colored surface.
The depth buffer is an approximation, causing undesired transparency for surfaces close to each other. (You see the column shining through the grey box.)
So there is no need for nude patches. All cloth would become transparent. :D

Maybe i could solve this by rendering cloth and such stuff in another pass.
And i don't know anything about performance yet. It's definitively not cheap. But unlike Spherical Gaussians it needs no sorting, and cost per splat is constant independent of its size on screen. (Thus DOF becomes trivial as well)

So yeah, it's very experimental stuff for now…

@rmbrt

Thanks for lending me an ear and the discussion! Turned out inspiring and fruitful again. I think i have a solution for the clipping:

Render a pass for the few triangles intersecting the clipping plane.
Render the intersection, generating an image of lines where the triangles are sliced by the plane. Adding normal information as well to define solid / empty half space per pixel.

Using this image, i can use the winding number method. It's only 2D now, so real time. Cost should be similar to computing a 2D SDF using the jump flood algorithm for example. That's no problem at all.

It would work with any kind of lod method as well. Neither Nanite nor discontinuities would add any problem, because winding number needs no watertight input.
I could even do it with splatting my imperfect GI surfels, which could also turn the black cap into a nice low frequency blur from the surface colors.
After that i can defocus the final scene render near the clipping plane using some more screenspace blur like DOF methods do.

I'm optimistic this would look acceptable. And performance is solved for sure. \:D/

Sounds like this will be expensive on tile-based GPUs without their own resident buffers in VRAM, right?