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
I would think I'd rather avoid the whole issue via nerfing hitscan and high-velocity-projectile weapons, and buffing lower-velocity-projectile and melee weapons.
There have been successful FPS games with that formula (Tribes comes to mind). There are cheats/hacked clients, but they're on a much less problematic level (mostly around visibility).
Given that Epic makes Fortnite and Unreal, is it that implausible to assume that "lots of people wanting to cheat in Fortnite" might instead lead to "Epic builds anti-cheat stuff for Unreal, puts it in the next release"?
(FWIW, a little searching reveals that Fortnite seems to use the exact same anti-cheat company as PUBG: https://www.battleye.com)
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.
> 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.
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.
They're hardly the only ones. Injustice 1&2,Guilty Gear Xrd -Sign- & Revelator, Marvel vs Capcom: Infinite, Dragon Ball FighterZ - these days, it's actually less common for AAA fighters to not use the Unreal Engine.
Infinity Blade back in the day was essentially a UE3-on-iOS tech demo that had unexpectedly good gameplay. (there was a game mechanic that enticed you to examine and pan around the highly-detailed environment!)
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?
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.
Agreed on the visual programming system. I went into UE4 dev thinking I'd work mostly in C++, but now I'm basically only doing enough in C++ to get something exposed to blueprints so I can prototype faster.
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.
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
I think they could go a long way to fixing this by building a textual representation of blueprints. I can see art assets being unmergeable, but as far as I can tell there's no good reason why nodes, the netlist of connections, and their parameters couldn't be stored in text.
At least this would allow diff, merge, and code review with standard tools.
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.
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.
Learn blueprint scripting. It takes a little getting used to but it's essential to being productive in UE4. Once you get the hang of it it's basically another scripting language. You can get a long way without writing any C++, and because it's faster, less error-prone, and has great auto-complete it makes it a lot easier to learn UE4's APIs while working in BP than in C++.
Besides that, read the docs and learn UE's concepts of actors, components, blueprints (prefabs), actor inheritance, pawns, and controllers. Then when you want to add some C++, make C++ base classes for your blueprint classes so you put some functionality in each.
I've been making an arpg as a solo project for ages (https://streamable.com/b9hae) and using the GameplayAbilities plugin that comes with the engine. I do the abilities (which tend to be heavy on delegates, so visual scripting is perfect for it), the UI, and the animation blueprints in BP, while everything else is cpp. I follow the model of creating all base classes in cpp, then having the final implementation as a data-only blueprint. This lets me rapidly change the values of things in BP in the editor when I'm fine tuning things, without having to deal with BP otherwise. So if I have a fireball spell for example, the fireball actor will have all its logic in cpp but the visuals, sounds, base damage, explosion radius etc. are all set in the editor in the bp, but the ability that lets me cast the fireball will be in pure bp.
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.
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.
"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."
42 comments
[ 4.9 ms ] story [ 60.7 ms ] threadCheating 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
There have been successful FPS games with that formula (Tribes comes to mind). There are cheats/hacked clients, but they're on a much less problematic level (mostly around visibility).
(FWIW, a little searching reveals that Fortnite seems to use the exact same anti-cheat company as PUBG: https://www.battleye.com)
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.
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.
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.
[1] https://www.reddit.com/r/FortNiteBR/comments/82xyhb/launch_e...
AAA fighters are a long way from it's FPS roots.
I wouldn't be shocked at all if they got made into a TV show at some point.
Does anyone here use UE4 to develop small games? If so, what's your development workflow like for game logic?
though you can't use unreal-JS for iOS apps (uses v8)
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 - 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 - 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.
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.
At least this would allow diff, merge, and code review with standard tools.
I also tried Git LFS and it is a hot mess.
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.
Besides that, read the docs and learn UE's concepts of actors, components, blueprints (prefabs), actor inheritance, pawns, and controllers. Then when you want to add some C++, make C++ base classes for your blueprint classes so you put some functionality in each.
Epic has great docs, this one might be a good place to start if you have Unity experience: https://docs.unrealengine.com/en-us/GettingStarted/FromUnity
I made a lot of getting started resources and cheatsheets to help newcomers such as a C++ Cheat Sheet[2] and a Blueprint Cheat Sheet[3].
[1] https://www.uecasts.com
[2] https://uecasts.com/resources/unreal-engine-c-plus-plus-chea...
[3] https://uecasts.com/resources/unreal-engine-blueprint-cheat-...
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.
"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."