
Unreal Engine 4.19 Released - ksec
https://www.unrealengine.com/en-US/blog/unreal-engine-4-19-released
======
frenchie14
I've tried to learn UE4 multiple times before and I can never get into it.
I've been using Unity for several years and the workflow was much more
intuitive to me when I first picked it up. Visual scripting doesn't really
work for me and the UE4 C++ scripts feel very cumbersome next to Unity's C#
scripting (not just the language, but the amount of work needed to get the
desired behavior). It's a shame because the tooling, rendering pipeline, and
updates for UE4 are way ahead of Unity and I get envious every time I see
these releases.

Does anyone here use UE4 to develop small games? If so, what's your
development workflow like for game logic?

~~~
peterlk
I had also tried to get into UE4 a couple times, and failed until I used found
the following resources:

[https://www.udemy.com/unrealcourse/learn/v4/overview](https://www.udemy.com/unrealcourse/learn/v4/overview)
\- a bit slow, but there is tons of content

[https://www.udemy.com/unrealmultiplayer/learn/v4/overview](https://www.udemy.com/unrealmultiplayer/learn/v4/overview)
\- building an online game with Unreal turned out to be stupid hard for me,
and this has paved the way

[https://www.youtube.com/channel/UCRnPBe1tJpXA0lccx_U1mww](https://www.youtube.com/channel/UCRnPBe1tJpXA0lccx_U1mww)
\- UnrealGaimedev is amazing. I have so much thanks for his videos

With those, I have built some simple games. One of the things that I have
found interesting is that the visual programming of UE4 can accomplish way
more than I thought it was capable of. If you're getting started, I'd
recommend not even touching C++ because the visual programming stuff is
powerful enough for pretty much everything you would need in a hobby game.

~~~
isopede
I have been getting into Unreal the last few months and had the opposite
experience.

I found the visual programming language frustrating to use and reason about.
While I loved the discoverability of working with blueprints (it is easy to
find new nodes), I found that actually working on game logic quickly devolved
into an unmaintainable mess of literally, spaghetti code. It was great for
prototyping, but horrible at actually building something maintainable and
understandable. Reading other people's blueprint setup is even worse.

I found the workflow even more frustrating. Blueprints are stored as uasset
binaries, and as such make traditional version control impossible. Changing a
single default parameter in a blueprint rewrites the entire file, and can not
be diffed, merged, or reviewed, making git/p4 log nearly useless.

I know there is a builtin diff/merge in the editor, but it's pretty limited
and I would say it's quite a far cry from what "normal" developers are used to
in other parts of the software world.

I have since switched to using mostly C++, and only using blueprints for
derived Actors to set up art (meshes, materials, etc). It's definitely slower
to set up than using the blueprints. I'm not happy about being back in a place
where segfaults can happen; the compile-play-crash-restart cycle is much
longer than it should be. I'm not a huge fan of C++, warts and all. In return,
however, I can actually read the code, grep it, review it, etc. Do "all the
things" you're supposed to do as a good software engineer. I really don't know
how the AAA game studios are managing real games with blueprints, I kind of
doubt they are.

At least as an experienced software developer but amateur game programmer, I
found it much more comfortable to sit down with C++ and learn their API, than
it was to perform game logic by dragging around 'foreach' boxes and doing
arithmetic by crossing lines.

~~~
peterlk
I was also frustrated with the poor git support by blueprints. I ended up just
writing long commit messages so that I could read about what I (thought) I had
changed

~~~
pfranz
I've found the git support to be lacking. Every game studio I've known uses
Perforce mostly because it handles lots of binary data much better. Because of
the way games are developed, DCVS don't have as many benefits.

~~~
isopede
Perforce is great for binaries, but really kind of a substandard experience
for code, at least compared to hg/git.

I also tried Git LFS and it is a hot mess.

~~~
pfranz
I don't have much firsthand experience with Perforce. I've set it up, attached
it to UE4 and just appended commits. I have been on the miserable side of git
and binary data, LFS and other solutions seemed like awkward solutions.

Even ignoring the distributed aspect of git, the things I loved as a solo
developer was immediate branching, a sane way of merging, and things being
fast because there was no server to talk to (coming from SVN and CVS).

Now that I think more about it, I think some of the game studios I'm familiar
with were using Git for the engine and artists were using Perforce for their
assets.

------
bhouston
This is just brutal to Simplygon:

"The new system is used by HLOD and is a replacement for Simplygon....After
the prompted editor restart, the Plugin will replace the third party Simplygon
tool for static mesh merging LODs. This new Plugin is accessed in two ways:
The HLOD Outliner, and the Merge Actors dialog."

~~~
jensvdh
They got acquired by Microsoft, they'll live.

------
ksec
I cant think of a single pieces of software that has this consistent pace of
improvements, massive changes every release and shipping every few months, and
has been doing so for years.

~~~
vvanders
Many internal game engines go through similar levels of churn + updates, they
just usually don't see the light of day.

Gamedev is a somewhat unique space in that about 6 months from ship you fork
from upstream and almost never merge again. Heck most licensees I know hacked
UE3 to hell-and-back(which we did too) to add the features that we need to
actually ship.

------
minimaxir
It's funny how Fortnite became the ultimate pitch for UE4's versatility.

~~~
strgrd
I think it's funny that Fortnite will probably cause the inevitable unraveling
of UE4, as yet another game engine without baked-in anti-cheat.

Cheating in Fortnite is practically unheard of at this point. But it won't be
long until the player base is just as jaded as PUBG's:
[https://github.com/Griizz/Fortnite-Hack](https://github.com/Griizz/Fortnite-
Hack)

~~~
quacker
I have a few reactions here:

1\. Why should Epic go and reimplement anti-cheat that you can grab off the
shelf?

2\. A big part of limiting cheating comes down to the specific game design and
implementation. You need a server implementation that is as distrusting of
clients as possible, you need secure (networking) code, etc. Anti-cheat is not
a cure-all.

3\. Even without anti-cheat, Unreal Engine is still well-used by tons of
single-player video games. I don't see it "unraveling" regardless.

~~~
admax88q
> 2\. A big part of limiting cheating comes down to the specific game design
> and implementation. You need a server implementation that is as distrusting
> of clients as possible, you need secure (networking) code, etc. Anti-cheat
> is not a cure-all.

Unfortunately that's just not realistic for a large category of games. If you
can trust the clients to some degree then you can really really offload a lot
of server work. It's not feasible to process user's mouse input on the server
in an FPS for example. Not just from a server load standpoint but from a
latency standpoint.

~~~
monstrado
You don't need to do this in real time, instead you could log the data (e.g.
mouse clicks, key presses) to something like a database, Kafka, or Kenesis.
Now you've unloaded the anti cheat logic to other servers.

You don't necessarily need to ban a player immediately. If you can accurately
ban people within a day of using a cheat, then that's a pretty serious
deterrent from using them.

