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

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.

[1] https://liveplusplus.tech/

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.

(Not affiliated with Rider, just a big fan)

[1] https://www.jetbrains.com/lp/rider-unreal/

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

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

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.

Well I would argue that I'm rubber, and you're glue.

I agree, there is a lot more unexplored territory! Lemmings was definitely one of our inspirations for World Zombination. Specifically, the zombie drones that you mutate into special units with different abilities. http://worldzombination.com/

Can we please stop calling Unity/Unreal "free"? Unity still sells a Pro version, and Unreal takes a cut of revenue after a certain amount of $ earned. I'm not arguing against either model, and it's GREAT for hobbyists, but these engines still cost professional studios money.

BOSTON - SENIOR ENGINEER - PROLETARIAT, INC.

Proletariat is a Boston-based startup built by game-industry veterans from Harmonix, Turbine, Media Molecule, and Insomniac. We lovingly handcraft engaging tablet-first experiences, focusing on creating great team multiplayer games. Like the original revolution, Proletariat rises up to wrest game development from big industry and return it to the people.

We're currently looking for Senior Engineers who want to build great games for tablet and mobile devices. We are a small team, so you will have the opportunity to work in many different areas: gameplay, user interface, server systems, and internal tools. You will work with our artists, designers, and product managers to create new features that are launched regularly to our playerbase.

You can find more information about our team at http://proletariat.com/team and our current game in development at http://worldzombination.com.

Qualifications:

- 3+ years engineering experience.

- Some game development experience.

- Demonstrable ability to learn and work in multiple programming languages.

- Continues to improve development skills and learn new technologies.

- Self-directed and can work autonomously, but can also ask for help when needed.

- Able to communicate well with other disciplines, including artists, designers, and product management.

- Enjoy playing a wide variety of games.

Bonus:

- Experience with Unity engine.

- Experience with Haxe programming language.

- Mobile development experience.

- Node.js experience.

Proletariat is a well-funded, venture-backed startup that offers attractive salary, benefits, and equity for qualified candidates. Contact [email protected] if you are interested in joining the revolution!

Our game (currently in development) is written in Haxe. http://worldzombination.com/

I wrote a blog post that talks about why we chose Haxe here: http://blog.proletariat.com/post/63004824563/choosing-a-deve...

I disagree with this argument. Modern programming is done with groups of people; you are not only communicating your intent to the machine, you are communicating your intent with fellow engineers. It is in this case that nuance is important. For example, C++ references and pointers are exactly the same as far as the machine cares. But the difference is important for communicating intent to other engineers.

This isn't to say that C++ lacks significant flaws, but I don't think nuance and variety of expression is one of them.

I am a big fan of languages trying to solve callback hell. I use a library in Haxe that allows for similar syntax: https://github.com/proletariatgames/haxe-continuation. Haxe compiles to Javascript and is great for node programming...but it has the added benefit of also compiling to c++, php, java, c#, etc., etc. ;)