Game engines are basically eating the world
twitter.comIt makes a lot of sense. Why would you code something that complex to simulate stuff that game engines are already capable of?
> Why would you code something that complex to simulate stuff that game engines are already capable of?
Because game engines are for games. They fake a lot of stuff in their models.
The brilliance of humans is their ability to turn airports into Excel spreadsheets.
This bit of the thread is interesting - "The increasingly blurry boundary between games and life".
I'd say elections are going a bit this way, along with a lot of other stuff.
Right. Given that Vulkan and Direct3D12 have a very high barrier of entry, the way to get the most out of modern hardware is to leverage an existing high-quality engine.
A 'monoculture' would be bad, but I don't think that's a real risk. Also, Direct3D11 isn't going away.
Yup, we built a game engine in order to visualize your hikes, rides, flights, etc etc . https://ayvri.com
We've been surprised to see how many uses people have found for the tech, wildlife research, commercial drone operations, and more.
The default is currently cesium, but if you click the "view beta player", button, you'll see our hand-rolled game engine.
This does ring true. Esp if you consider the recent MS flight sim & how that's hooked into sat pictures.
It is very much constrained to geo type applications so the "eating the world" is a little dramatic. I like the hong kong airport example that...shows how broadly applicable geo type stuff can be and how much applicability it has if you take it to a granular level
At least in terms of movies, this seems like the obvious route:
It used to be that game engines had real-time processing requirements (60/30/15 frames per second) and were constrained by the hardware on which they ran, but movies looked more photo-realistic and could take hours or days to produce a single frame.
As silicon and algorithms get faster and closer at approximating reality, the difference between the output of the two softwares approach one another. Given the amount of effort required to build these softwares it makes sense to save the years of effort, cost involved and risk involved with what essentially amounts to building a bespoke, internal graphics / physics / particle simulation engine.
I really have A LOT of fun making https://nopaint.art in this browser based game engine called Construct 3 (https://construct.net) - there are times as a developer that I really hate the restrictions of the architecture / design but honestly, it's extremely productive for me to stay in the visual design mindset while making software.
I'd generalize to say that 'progressively higher level abstractions are eating the world'.. and always have been.
All of these firms use Game Engines? Or maybe everyone on Twitter used too much hyperbole.
I dunno, I recently started working with a car audio DSP platform that has companion apps for windows, iOS etc. These apps are basically glorified equalizers with a couple more advanced functions, so the interface is done with sliders, knobs, text boxes, etc. Basic GUI stuff. But the apps were built in Unity, presumably to minimize cross-platform GUI bugs and ease of portability.
For many developers its better to work in these auxiliary jobs, instead of game development, because Game Development is made fundamentally uneconomic due to the ~30% commissions charged just on platforms. Additionally B2C sales attract huge sales taxes around the world, whereas eg. a B2B contract with a Government airport is just pure revenue.