dogles

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#.

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.

OTOH, he was too busy to take the follow up call.. ;)

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).