A user of Blender can absolutely point at an arbitrary part of a rock wall and say "move this over and make it bigger". Blender sacrifices rendering quality to make sure that interaction is reliably responsive. Cube/Sauerbraten forgoes some of the rendering optimizations provided by some other 3-D game engines to make sure you can always edit any part of the environment at any time, but it was already delivering interactive frame rates 20 years ago. And of course Minetest has very little trouble with arbitrary sets of nodes appearing and disappearing from one frame to the next, but Minetest isn't that great at performance, and its expressiveness is a bit limited compared to Cube and Blender, so maybe it's a less compelling example.

As long as it doesn't cause a glitch in playback, it's acceptable for your DAW to delay 10 milliseconds to figure out which note you clicked on. That's about 100 million instructions on one core of the obsolete laptop I'm typing this on. As you obviously know, that's plenty of time to literally iterate over your hundreds of thousands of little rectangles one by one, in a single thread, testing each one to see if it includes the click position.

But (again, as you obviously know) you don't have to do that; for example, you can divide the screen into 32×32 tiles, maybe 8192 of them, and store an array of click targets for each tile, maybe up to 2048 of them, but on average maybe 64 of them, sorted by z-index. If a click target overlaps more than one tile, you just store it in more than one tile. When you have a click, you bit-shift the mouse coordinates and combine them to index the tile array, then iterate over the click targets in the array until you find a hit. This is thousands of times faster than the stupid approach and we haven't even gotten to quadtrees.

A different stupid approach is to assign each clickable object a unique z-coordinate and just index into the z-buffer to instantly find out what the person clicked. This requires at least a 24-bit-deep z-buffer if you have potentially hundreds of thousands of MIDI notes. But that's fine these days, and it's been fine for 25 years if you were rendering the display in software.

Blender, as a design/creation tool, is something I would classify as closer to a DAW than most contemporary video games. The fact that you can use it to create games isn't central.

Its performance is very gamelike, I think, and your point seemed to be that design/creation tools like DAWs can't get gamelike performance, so I was offering it as a counterexample. I agree that the fact that you can use it to create games is irrelevant, and that wasn't a fact I was attempting to focus on.

With a modern data driven or ECS architecture, you actually can do that. There are demos out there with hundreds of interactive things on screen at one time. It's kind of amazing.

It's not like games don't have complex UIs either, where each button or field has a lot of logic to them. Many games have very simple UIs, but others get more complex than many complex web apps. Some are even multiplayer, and the server code... it's nuts how much work goes into this. The number of updates you send each second to keep players in a game in sync compared to what is needed to keep a chat app in sync is really impressive to me.

From a technical point of view, games are really cool!

I feel like the reason a lot of games are slow right now is because they are built out of these huge abstract "everything-doers". For example, each button can be configured in millions of different ways even though the game usually only has a few different types of buttons. It's not an optimal data structure by any means.

It's not like in the olden days where you would blit this stuff out to the screen using specialized routines that scream along as fast as the CPU will let you. Now, everything is dynamic and multipurpose and configured using properties on the object... engines like Unity get away with C# and way too much runtime reflection because it's convenient in the editor. Developers like it, it's less difficult than writing specialized routines.

> It is impressive that they can draw so much stuff so fast, but there are actually very few objects on the screen that the user can directly interact with.

> > With a modern data driven or ECS architecture, you actually can do that.

At some point people forgot that there are synonyms and different ways to phrase “actually”.

>All those complex surfaces you see in contemporary games? Very nice. But the user cannot point at an arbitrary part of a rock wall and say "move this over a bit and make it bigger".

The Red Faction series, building games like Minecraft and 7 Days to Die, and games like Factorio are some pretty obvious examples where you're completely and utterly wrong, so I'm not really sure why I should trust anything you said in the rest of your comment.

He's a pretty experienced and expert programmer, but I don't think he's much of a gamer.

You might be underestimating modern games a bit I feel, but as well game engines usually have editors just as complex as a DAW. Yet both games, game engine editors, DAWs and all the examples you mentioned all run vastly more performantly than many modern simple pieces of software. Which tells us that performance is possible regardless of domain if we build properly.

Yes, but the editors are (to the best of my understanding) not written using the same software techniques as the games themselves.

Don't know about the others, but I think Godot's editor is built using its own in-game UI system.

And Godot's editor is very snappy and responsive

UE5's editor is completely built in the engine's native UI toolkit, Slate.

No not all of them. The godot game engine editor is built in the godot game engine though so that is interesting.

What? What are you talking about? Games handle thousands of colliders and raycasts just fine. I thought you would mention that games get to use dedicated GPU hardware and apps might not be hardware accelerated but colliders? Very odd take.

Eh, the actual number of interactive items in a modern game is significantly less than thousands. Probably more like a few dozen when all is said and done.

You've missed my point entirely.

Games (generally speaking) do not involve allowing the user to interact in arbitrary user-defined ways with every object represented on the screen. The interactions that do happen are part of the physics engine not the "user clicked that and dragged it to the left" engine.

No I think klabb3 has the right of it. They're really not that different and it does just boil down to priority and what is fine to be outsourced to a huge stack of slow libraries and what is prioritized as a core competency.

Yeah, go check out some Factorio screenshots. Thousands of interactive objects animating on screen at once. Not only that, there is a complex sim running in the background. On my machine it runs well past 100fps.

Or 2d strategy games. Which had very decent number of animated units each with their own actions and which you could click and select...

It took the devs years to optimize it to that point though. And I'm quite sure that a screen full of trees or smoke emitting entities (thankfully you can turn smoke/steam off in settings) still makes it go below 60fps on my laptop.

Optimize, yes. But then... It's doing several (hundreds) of orders of magnitudes more than a typical app.

Several hundreds of orders of magnitude more? That doesn't sound possible.

That was an exaggeration but only slightly I guess :)

Considering how many objects and interactions Factorio tracks and at the same time lets you move around, inspect any of those things etc.

A typical app on the other hand does a CRUD operation every once in a blue moon.

This is nonsense. First, no one can interact in "arbitrary user-defined ways" with anything. Second, anything you can imagine on the web and more has already been done in games. Please don't tell people that running a 3d strategy game or a AAA multiplayer first-person shooter is somehow less complex than scrolling an effing window with a bunch of text and forms in it.

> Games (generally speaking) do not involve allowing the user to interact in arbitrary user-defined ways with every object represented on the screen.

Ah yes, and which apps actually allow you interaction in arbitrary user defined ways?

IIUC, in a game, let's suppose you pick up an object. We'll ignore the fact that you probably provide some sort of fairly broad movement to indicate that you want to pick it up - the game just notices this, and your on-screen avatar takes care of the rest. But now that you have it in your hand, you do not actually have control over in a direct sense. You may indicate that you want to lift your arm - all fine, but that information will be fed into a physics engine that will work on actual speed & trajectory, obstacles and collisions etc. What is shown on screen is not the result of you dragging a GUI object across the screen, but the indirect result of your indicating "lift my right arm" etc.

By contrast, most design/creation applications give you the ability to point with the mouse (or touchpad or whatever) at some object on the screen and then move it (sometimes along 3 axes). The speed of the motion, the axial extents and the destination come (at least initially) from you. This is true of drawing applications, design applications, DAWs and lots more.

There are lots of games with destructible environments and thousands or tens of thousands of interactive objects moving around, the static world you're describing hasn't been the Only Way for quite a while. Ignoring the obvious cases like Minecraft, Red Faction and Fortnite, even games where it isn't relevant to the gameplay still implement it sometimes - for example, The Division (2016) had fully destructible walls in many locations and if you fired enough rounds into a concrete wall you could punch a big hole in it that could be seen through and fired through to attack enemies or heal allies. This sort of thing doesn't have to come at the expense of visuals either, modern rendering tech along the lines of Unreal's Lumen & Nanite can adapt to changes in the environment and handle massive dynamic crowds of people or groups of cars.

You can quite literally point at an arbitrary part of a rock wall and move it over a bit then make it bigger depending on the engine you're using. It's why Unreal Engine has got a foothold in TV production.

> But the user cannot point at an arbitrary part of a rock wall and say "move this over a bit and make it bigger".

In some games, you can.

Could you give some examples of such games? I'm a gamer and I haven't seen anything like that, so I'd love to check it out.

As I mentioned in my other comment, two/three such games are Cube/Sauerbraten and Minetest.

Games have come a long way since Space Invaders and Pac Man.

They routinely do have hundreds, or thousands, of interactive things. Especially things like RTS games. But also, even if you look at turn-based strategy games, which have a much more application-like interface. Every hexagon, terrain feature, and unit is interactive, along with a full application-like menu, statusbar, and UI system.