That reminds me of the music in the film "Inception", in which the extremely low-register bass-heavy music in the background of scenes from lower levels of dream-in-dream is actually the main score, played back dramatically (and semantically / thematically) slower and lower.
Availability.
There must be many other reasons, but IMHO that has to be the biggest factor. Being able to just start a session, in the moment, when you feel like it, is a fundamental difference.
Counter-intuitively, I think the fact that it's not a human seems to have a non-negligible effect too. It's a computer program you can share whatever with, and it'll never judge you, because it cannot. It reads exactly what you write and assumes you're faithfully answering, then provides a reply based on that.
I haven't been so unlucky myself, but I know many who've had terrible first experiences with therapists and psychologists, where I'm wondering why those people even are in the job they are, but some of them got so turned off they stopped trying to find anyone else to help them, because they think most mental health professionals would be the same as the first person they sought help from.
Unity can't really be said to have less or more features than Unreal IMO. Each has features lacked by the other, and neither lacks anything really major. But if I had to pick one for being the most featureful, I'd pick Unreal. Unreal has a built-in visual programming language* and some very advanced rendering tech you might have heard about. Unity has tons of features for 2D games lacking in Unreal and supports WebGL as a build target.
(Though imo unity is the better engine. Unreal has so many bugs and so much jank that to make a real game with it you basically need a large enough team that you can have a dedicated unreal-bug-fixer employee.)
*Technically Unity has a visual scripting language too but IIUC it's tacked on and I've never heard of anyone actually using it.
Speaking of bugs, I remember the last time I thought maybe I'd try making a simple game in Unity I gave up when I couldn't stop clipping through walls.
The collision was clearly working, just some n% of the time you'd end up on the wrong side of the clean flat rectangle you were walking into.
For performance/practicality, it's Unity > Godot > Unreal. Building something in Unreal that simply runs with ultra low frame latency is possible, but the way the ecosystem is structured you will be permanently burdened by things like temporal anti-aliasing way before you find your bearings. Unreal and Unity are at odds on MSAA support (Unity has it, Unreal doesn't). MSAA can be king if you have an art team with game dev knowledge from 10+ years ago. Unreal is basically TAA or bust.
One minor tangent (aiming for helpfulness, not pedantry), "I have few" reads as "I don't have many" (emphasizes the low number), whereas "I have a few" emphasizes the fact there's more than one -- which from context was clearly your intent. HTH!
- Maintaining stateful secrets at rest gives me the heebie-jeebies.
- The tools shouldn't let me shoot myself in the foot.
- The tools should ideally not have such a high learning curve that I won't actually use them.
You can put your secrets in a separate repository and not think of them as the same kind of repository you'd publish.
Like... I wouldn't put a git-crypt'ed / sops-nix'ed repository online, simply because I don't like the idea that now anyone needs is brute-force; I know quantum computers aren't there yet wrt. brute-forcing stuff made by random people like me, but even hypothetically having this attack vector open, I don't like it.
So there's only two good solutions:
- You put secrets in a (hashicorp-style) vault that only decrypts temporarily in memory.
- You put secrets in an encrypted database with only safe tool integration.
The things I don't like about git-based secrets management:
1. You might mix your secrets into projects and then later someone else might release that (against your current interest)
2. The solutions I've seen (sops-nix, agenix, secrix, etc.) are hard to set up and even harder to onboard people on
When something's hard to set up, you might make a mistake or skip some concept.
Well-done secrets management that isn't based on a service like AWS Secrets og GitHub Secrets should be much, much easier.
I like the idea of how easy this is. Now, if it would just be best practice in every possible way at the same time.
The (admittedly well-known) problem with lockenv is that you can't revoke access once a password is known.
reply