Unreal's Niagara has a visual editor. While it is packaged as an VFX/particle editor, it is in many ways an ECS. Each particle can have custom data structure and modules/systems that drive them. Under the hood the graphs are translated to SIMD-optimized VM bytecode when run on CPU. It can even support translation to HLSL/GPU-acceleration if all modules support it. Not sure if Unity has something similar.
Being raised knowing in your soul that your generation was chosen to be permanently infantilized by a decaying nanny state is an excellent recipe for a revolutionary cohort.
With the availability of game engines, gameplay programming is actually very high-level. Most of the logic is handling some input or some collision or updating some position or timer every frame. The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself, so the games programmer usually only need to interface with the high-level API of these systems.
Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.
There, I've said it. Most 'games' are in fact interactive movies, with very little game in them. That's what Game Engines enable.
I'm vote we stop calling them Game Engines and instead call them Interactive Movie Engines.
> The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself,
This is and always was a Bad Idea, let me bring up a very simple example for you, a racing simulator. What sets apart an arcade from a realistic car driving sim? It's not really the graphics, or "gameplay", its the physics engine.
You might argue "oh that's just knobs on the physics engine" - maybe. But the way you handle the graphics, the whole game, even, hinges on how well you have tuned that engine. I don't care how many artists or designers you have - adding doodads to a realsitic racing sim isn't going to make it more fun. And if your arcade gameplay isn't spot on, no amount of "gameplay tweaks" is going to fix your jank arcade racing game.
Game Engines don't really make for building racing sims. They make Ok FPS or world exploration templates, but you kinda want to not even care about assets in these types of games - and they are all geared at creating assets spitting, 10000 collectible doodad dumping, absolute messes.
> There, I've said it. Most 'games' are in fact interactive movies, with very little game in them. That's what Game Engines enable.
While I disagree with your argument about game engines being bad for games, you bring up an interesting point. Game engines are becoming cinematic movie engines.
Right now, they're a bit sub-standard. They shouldn't be built for consumer hardware at all, but rather live in the cloud where they have access to a lot of GPU compute for rendering.
The thing they get right is the reduction in film production complexity. Less going to set, less setting up lighting, cameras, etc. Easy tweaking in post, and an almost complete inversion of the production pipeline where directors, actors, and animators can work in lock-step with one another in fast iteration.
Unreal Engine is being stretched to do film things, but it's ultimately a local optimum. We're going to see a lot of new tools emerge in this space. (I'm building one!)
In the near future, films shot on cinema cameras and glass will be in the minority of visual media produced. It's just too time consuming. It'll become an artisanal pastime that directors like Wes Anderson remain attracted to.
The really interesting thing will be what happens to studios like Disney and Netflix that bank on in-house content and IP. Once media is no longer expensive and kids at home are making Star Wars of their own, the linear content moat is gone. Franchises and major IP will probably move to difficult-to-produce (for now) mediums, such as games, since films will turn into something more closely resembling novels - a huge basket of works, a wide distribution of quality, and a very long tail of interests that are catered to.
This seems backwards to me, since live action film is a lot more expensive than CGI animation. It's true that high-quality cameras and video editing software have become more of a cheap commodity, but this does almost nothing to impact the actual factors that push the cost of live action film up. Look at what people post on video sites, that's a far better representation of what's actually "cheap" in video.
This is a creative coding library, similar to OpenFrameworks, Processing, etc. The description is confusing. Seems to be an in-house tool some creative agency decided to open-source.
We (naivi.nl) indeed open-sourced NAP Framework about a year ago. Maybe it helps looking at it as a hybrid between a creative coding and game engine. But instead of making games you use it to interact the world around you, controlling many screens, lasers, speakers, servos etc. It is completely data-driven and ships with an editor, similar to a game-engine. But doesn't impose any sort of pipeline. It is not a creative-coding engine, we find that name to be limiting, as we use it for many other real-time, non-creative applications as well (medical for example):
I don't think it's that complicated, it's just a matter of having different values. The Chinese culture values prosperity, solidarity, and security over freedom. and those are things the current government has provided in spades over the last few decades. Freedom of speech is not that important as long as you and your family can live your life in peace and prosperity. For most Chinese, it makes no sense to go against the government.
Everyone is different. Nowadays, if I post something, it is either: a) I have something to share, a bit of knowledge/opinion/story. If this is the case, I already know I am correct, and as such do not really care about the response and it's very easy to walk away, or b) If I pose a question, in which case I will be open to any response because I'm genuinely curious. I think I used to care more about what other people thought when I was younger and more insecure. Sure I can still be proven wrong, but I usually do not care enough to respond. I just learn and move on.
I had one of the first revisions of the Ergodox EZ. There were some problems with the build quality, and a few of the legs arrived loose/broken. Customer service was great though, and I received replacement parts very quickly, but after a while the same parts came loose again. Likely a problem with the design or low quality component, which I hope the newer revisions have fixed. Otherwise a great keyboard, although it takes a while to get used to (around 3 months for me). I ended up building my own Ergodox using the open-source design - Now I have about 5-6 of them that I built myself, all with different keycap/switch configurations... Only negative is that I can no longer type on a regular keyboard ;)
It takes a while to get used to. I switched to Ergodox and Colemak at the same time, and it took me around 3 months to get up to my normal speed again. Unless you type a lot on other people's keyboards (IT-support or similar), I'd say it's definitely worth it!
I don't think OOP itself is bad. Bad abstractions are bad, no matter the language, and that is the main problem. Abstractions and domain models are created based on our understanding of a given problem as well as what is possible within a certain programming language/paradigm. Most of the time, we initially do not have a good understanding of the domain we are working in, and because we are conditioned to keep code "organized", we tend to fall back to established "patterns" (which OOP has an abundance of...), but these almost always end up being the wrong abstraction. By the time we figure this out though, it's already too late to change it.
A functional language such as Haskell tend to make us think a little bit more about what abstractions we use, because they are such an integral part of the language you can hardly do anything without them. We can "converse" with the compiler to come to a better understanding of how our code should be structured. You usually end up with a better domain model. However, this can also be very limiting. Lack of control of execution and no control of memory layout is a problem in my domain (video games). It's also slower to develop for because you can't take "shortcuts", which can be helpful to get something up and running without having to understand the problem domain.
I still use OOP daily (C++), but I never start out with abstractions when writing new code. I tend to create C-style structs and pure functions. Eventually, I will have a better understanding of how this new module should be organized, and will make an API that is RAII-compliant and whatnot. I think you can easily write clean code in OOP as long as the abstraction makes sense.
Out of all the comments here this one resonated with me by far the most.
You're totally correct: The goal is to find the right abstractions. Bad abstractions keep getting in your way either by leaking too much or by being based on invariants that turn out to be not actually be all that invariant, whereas good abstractions have no need to be touched again later.
For me, the additional layer of "how hard is it to change the abstraction if it turns out to be wrong" is also quite important. In my environment (algorithmic R&D) you never quite know which invariant your next idea will break. And this is where OOP can really bite you - untangling code from a class hierarchy or twisting interfaces to bend to your new ideas is anywhere between infeasible and a complete mess. Composition over inheritance can help save a lot of frustration here. But sometimes interface/abstract base class + a single implementation also provides a very clean abstraction to separate the core model/algorithm from the fiddly details. Just don't fall for deep hierarchies or large interfaces would be my takeaway so far.
Maybe we just need to get better at giving up on abstractions when they fail? I think that's very tough because they tend to still dictate how we think about problems (plus the usual cost of rewriting code). Your approach of delaying the abstraction choice sounds very interesting (somewhat akin to Extreme Programming?), I will try to keep that in mind for the future. In thinking about this I'm mostly afraid of code sort of remaining at this "makeshift"/provisional level and never actually settling into something more organized (due to lack of incentive/time to improve it). I think that can be kept under control, but do you have any suggestions on that front?
> Your approach of delaying the abstraction choice sounds very interesting (somewhat akin to Extreme Programming?), I will try to keep that in mind for the future. In thinking about this I'm mostly afraid of code sort of remaining at this "makeshift"/provisional level and never actually settling into something more organized (due to lack of incentive/time to improve it). I think that can be kept under control, but do you have any suggestions on that front?
Actually, I find that more often than not, code written in this manner is actually easier to maintain, because there are no layers and concepts to untangle - just the raw functionality and data transformations. You don't need to put yourself in the mindset of the person who wrote the code, who might not have had the right concepts in their head at the time. Instead, you just parse the code like a computer - This makes it easier to figure out what the code actually does rather than being distracted by the intent of the author.
The main purpose of abstraction is to intentionally hide implementation details so other people can use your code without requiring a full understanding of all the details. However, when maintaining code, obfuscation is the exact opposite of what you want - You want to fully understand what the code is actually doing. Internally, I forgo most abstractions. For public interfaces, I expose highly specific functions and datatypes rather than "generic" interfaces, and only the bare minimum. Variants should favor duplication over generalization when uncertain. It's up to the consumer of those APIs (which is often myself!) to choose whether or not to implement abstractions on top of those. In my experience, it's either super-obvious when it's needed or unnecessary if unsure - So you can usually push back abstraction up to that point.
Tech roles comes in many forms. For example, I have worked a fair bit with graphics programming and VFX, where extensive knowledge of photography would be very useful.
I can imagine tech jobs where most of the hobbies you've listed could be considered relevant. Dance? Biometric sensor tech. Guns? Video games. And so on...
