One thing that wasn't mentioned: (realtime) multiplayer. What's the story here for Unity these days?
There's still a lot required in Unreal to implement things like bullet or projectile latency-correction unfortunately, but the base infrastructure they provide here is huge. Last I used Unity, there was essentially nothing. There were some third-party things but nothing you'd ever want to use in a shipping multiplayer game that isn't turn-based.
Has anyone actually shipped a multiplayer (not turn-based) game with Unity that doesn't regret the decision?
short answer: yes. If you stay within their uclass/uproperty framework, you have garbage collection, guaranteed initialization of class members, type reflection, etc.
Rare issues come up like:
```
int* Element = &Array[0];
Array.Add(0);
*Element = 3; // could be access violation or memory-stomp if array was resized
```
Which can be addressed somewhat by code style policies.
Their garbage collector is also slightly weird in that it most things are deleted when there are no more references to it (as expected) but Actors can be deleted explicitly, in which case all references to them are set to null. This makes a lot of sense for a game engine actually, just perhaps unexpected from a language like C#.
C# remains a plus for a lot of game code, but not as much as you might imagine. C++ usage in Unreal is really a small restricted subset of C++. For typical gameplay code, you play within their rules for uclasses/ustructs/etc and it feels pretty much like any other managed GC language. Meanwhile, for places where it matters, "raw" C++ is of course always available.
Re: iteration time, Live++ [1] integration has matured a lot in UE5. That means compiling most code changes without having to restart the editor (or even in-editor game session). Again, not much different than Unity here, though both can break and require editor restarts for certain types of changes.
To double-down on OP, by far the biggest advantage Unreal has for professional development (aka anything you want to ship) is full source code. I've worked in both but can't imagine going back to a black-box engine. Unity/Unreal are both MASSIVE codebases ported across every modern platform imaginable and guess what: there a plenty of bugs in both. I can't imagine going back to an engine where I can't A) see what it is doing and B) fix issues without waiting weeks/months for a patch.
Just want to +1 that Rider for Unreal [1] is GREAT. It's also totally useable for non-Unreal C++ projects. Things like code inspection (e.g. goto definition/find usage/etc) and refactoring are actually fast, unlike Visual Studio. I've got a few quibbles about low-level (think asm) debugging, but I've pretty much moved exclusively to Rider at this point.
The Unreal-specific stuff is nice as well: being able to see what blueprints override a uproperty or implement an event is a huge time saver for AAA-scale codebases.
I think the bigger problem (which the example conveniently sidesteps) is that smart contracts don’t involve people. They involve _wallets_. I can have as many wallets as I want. Unless there is some external (centralized, trusted) unique identity mechanism, there’s no way to ensure the vote isn’t rigged. It also means that I could make a smart contract where I’m on all sides of the contract (e.g. say I’m trying to pump the market value of park-improvement projects…).
Outside of “a few neighbors who all know/trust each other and the public key for each other’s wallets” example, this all falls apart.
The two most popular engines (Unity and Unreal) both have a GC for “front end” gameplay code. The trade-offs are real: manual resource management would be incredibly complex for large modern games (think open world, multiplayer), but GC spikes are a common issue in both engines.
The places where you generally don’t want a GC are with low level engine code, like the renderer - code that might execute hundreds or thousands of times a frame, where things like data locality become paramount. GC does you zero favors there.
You believe so...with what evidence? You’re pointing at a system that has well-documented, overwhelming evidence of systematic corruption, lawlessness, and oppression, both in recent history and modern day. A “few bad apples” sort of defense is infuriating at this point, because it seems so willfully ignorant. We have the highest incarceration rate in the world - doesn’t that give you pause?
I find it odd that you’re responding (multiple times, copied and pasted) about an article documenting a _pattern_ of injustice and corruption, bemoaning anti-government bias. How is this relevant at all? If you’re arguing the pattern doesn’t actually exist, citations are needed. Otherwise I think this is pretty clear reporting that the courts are not “working well”.
I’d go as far as say that for the lower class, the difference the modern court system makes is negligible. Whether you want justice or mercy, you better bring cash.
This is not necessarily related to the medication. ADD often represents as hyperfocus, to the detriment of the things you should be focusing on. https://en.m.wikipedia.org/wiki/Hyperfocus
It’s support’s job to focus on one thing at a time, meanwhile it’s a coder’s job to try and keep dozens of things in mind at a time. Context switching IS hard regardless, but like you said, one of the roles has it baked into the job description.
The crux here is that Programmer committed to X work done by the end of the week, and Support is effectively subtracting their time to accomplish X. This is a managerial problem, and not an easy one, because it’s not predictable.
My estimate, if you’re a programmer working 40h/wk on a live product, 8h of coding is a good week. Expect the majority of your time to be spent planning, reviewing, and supporting. If you’re sacrificing one of those to get more concentrated coding time, make sure that is communicated. YMMV.
In any case, if you don’t have managerial support to get engineer resources to fix problems, then it’s not support - it’s therapy. Sometimes that’s the best you can do.
This was very well written. Effective communication with people is far more challenging (and rewarding) than the communication with devices that we developers do on a day to day basis. It’s easy to get lost in that cloud, and lose touch with the people we’re building for.
In startups, this aspect can too quickly get shunted off to a QA or CS personnel, and problems get abstracted into incident tickets (that are often ignored in favor of the Next Big Feature). That seems to me to be giving up one of the classic fundamental advantages of a small business: the personal touch.
Probably the biggest tells of a UE4 game are in screen space reflections for reflective surfaces, and the use of temporal antialiasing (which can cause minor ghosting artifacts, particularly in reflections). These can be found in other game engines too, but the artifacts of UE4's particular implementation are pretty distinctive (to me).
I strongly agree, and add that if you don't get along with your therapist, shop around. Like most professions, practitioners range from awful to amazing.
There's still a lot required in Unreal to implement things like bullet or projectile latency-correction unfortunately, but the base infrastructure they provide here is huge. Last I used Unity, there was essentially nothing. There were some third-party things but nothing you'd ever want to use in a shipping multiplayer game that isn't turn-based.
Has anyone actually shipped a multiplayer (not turn-based) game with Unity that doesn't regret the decision?