[HN Gopher] So You've Decided to Move from Unity to Unreal Engine
___________________________________________________________________
So You've Decided to Move from Unity to Unreal Engine
Author : Kye
Score : 235 points
Date : 2023-09-14 14:30 UTC (8 hours ago)
(HTM) web link (impromptugames.com)
(TXT) w3m dump (impromptugames.com)
| WhiteOwlEd wrote:
| Data scientist here who spent a couple of years working with
| Unreal (to produce high end data visualizations). Here are my
| thoughts
|
| > Blueprints suck! Not really. Think of Blueprints like python.
| Its good for routing and keeping track of things at a high level.
| Think of C++ as handling things at a lower level.
|
| > I heard you need to start with blueprints. Not really. After
| going through the basic tutorial that Unreal Sensei has on
| YouTube (https://youtu.be/gQmiqmxJMtA?si=TqBiiIe12M5hiCda) , it
| is better to do a mix of blueprints and C++ if you have any
| programming background.
|
| > I don't know what to use for the IDE. I used Rider for Unreal
| Engine and it has good integration into Unreal Engine.
|
| > So when do you use C++? When I was doing data vis of census
| data, I needed a way to load in 10,000 data points into memory.
| The "out of the box" tools for Unreal didn't support this, so
| custom C++ was the way to go.
|
| > But really, if I just want to get started with Unreal and want
| official tutorials, where do I go?
|
| After going through Unreal Sensei, I looked at at
| https://dev.epicgames.com/community/unreal-engine/getting-st...,
| there are a ton of tutorials there for game developers.
|
| Also, a year ago I put together an online course that looked at
| how to ramp up on Unreal Engine. The course ("Data Visualization
| in the Metaverse") is ideal if you already have a programming
| background. I put the course out on YouTube for free
| (https://www.youtube.com/playlist?list=PLKH3Xg62luIgPaB4fiFuT...)
| and happy to answer any questions about it.
| azan_ wrote:
| >Data scientist here who spent a couple of years working with
| Unreal (to produce high end data visualizations) That sounds
| amazing, could you share some of your visualizations?
| vintagedave wrote:
| > I don't know what to use for the IDE. I used Rider for Unreal
| Engine and it has good integration into Unreal Engine.
|
| Don't forget Visual Assist! It's more flexible, is faster, uses
| less memory, works on uncompilable code, etc. (I work on it.)
| xkcd-sucks wrote:
| Is anyone aware of unofficial (and maybe illegal in some
| jurisdictions) releases of Unreal toolchain that strips off the
| Epic Launcher and can be downloaded without making an account?
| [deleted]
| MikusR wrote:
| https://godotengine.org/
| spywaregorilla wrote:
| You can just grab the repo off of github to use it without the
| epic launcher but you do at the minimum need an epic account to
| get access. I'm not sure why you would want it to be unofficial
| or be so stubborn against making an account of any sort.
| caniszczyk wrote:
| Also check out https://o3d.foundation and Godot as options...
| open source gaming engines should be at the heart of modern game
| development imho, just like Linux is the heart of many
| infrastructure things we do
| jimmaswell wrote:
| > Read the documentation on the Gameplay Framework. All of it!
|
| Is it just me or is this an unviable learning strategy? My
| approach for learning anything has always been to follow small
| tutorials, build an intuition, and only consult docs when I need
| some specifics.
| johnnyanmac wrote:
| depends. IME I tend to go through at least 3 passes of
|
| - read high level architecture docs, - try to do some small
| coding - get confused and google until I get my goal done - go
| back to reading high level architecture docs
|
| You're (or at least, I will) never absorb and become productive
| in all that material in a first pass. But at the same time
| reading the intro for the mentality of how the big picture
| works helps a lot to scope into what to focus on.
| freedomben wrote:
| Everybody is different. It's certainly unviable for some
| people.
|
| For me, the ideal thing is a book, and great docs can feel like
| this. Something well thought out, comprehensive, deep, and
| importantly error checked/reviewed. The downside is books are
| increasingly rare and get outdated really quickly.
| janosdebugs wrote:
| As someone who recently learned UE: yes, this is completely
| unviable. The UE API docs are almost useless. Use Rider and its
| code navigation instead, you'll get much better results.
|
| The docs about the concepts are better, those are worth
| reading.
| adamkittelson wrote:
| I think it's just different learning styles. My preference for
| learning e.g. a new programming language has always been to
| read a book cover to cover as the first step (if it's a
| language established enough to have a book anyway). Note that
| it's not important that I actually _understand_ everything on
| this first pass. The cover to cover is mostly about getting the
| lay of the land so I know what exists, then, even years later
| when I have a problem that could be solved by using some bit of
| the language that I read about but didn 't really understand
| but vaguely recall is a thing it springs to mind and I can do
| my deep dive on that aspect then.
| pxc wrote:
| I'm currently doing this with a few programming language
| books, and the strategy for me is basically to read the book
| in two passes. On the first pass, the goal is just to get
| through the whole thing and get a feel for everything it
| covers. If I don't understand it, that's okay-- I just let it
| wash over me.
|
| It's only on the _second_ pass that I am trying to go through
| each section carefully and make sure I really understand
| before moving on, including seeking outside help or resources
| if I feel confused or stuck.
|
| This feels fun for me, and the casual first pass makes it
| easy to figure out if a book or language truly appeals to me.
|
| I also feel, strange as it sounds, like for me it save time
| compared to learning in small increments through tutorials.
| It lets me more quickly absorb the basics for things that are
| already more or less familiar, and then I can focus on
| exercises and examples only for the tricky stuff.
|
| When I first started studying computer science, in high
| school, the biggest productivity gap was between the students
| who tried to work only with what they were directly taught in
| class by the teacher and the students who decided to go
| explore the language/stdlib API docs on their own. There was
| a lot of 'wow, how did you do that!?' from the former group
| and a lot of 'it's built in, check out this part of the
| manual' in response from the latter. But somehow no amount of
| exchanges like that could convince the former group to take
| some time to RTFM in a comprehensive or unguided way, so it
| stayed that way.
| david422 wrote:
| > follow small tutorials, build an intuition, and only consult
| docs when I need some specifics
|
| While I basically tend to learn like this - (solve my current
| problem and move on, since I have limited time to spend on
| things) - I find that this type of learning can miss some
| things. Like when the documentation says this is important etc
| and you never know about it/find out about it the hard way when
| your stuff doesn't work properly.
| atomicnumber3 wrote:
| Yeah I agree. For me personally the best combination seems to
| be a quick start guide to get me bootstrapped and let me get
| the gun poinTed at my feet, and then solid normal documentation
| for me to mend my feet each time after I shoot myself.
|
| Some of it is a matter of it being hard to even have the
| language to know how to ask the questions you have, so a
| bootstrap or quick start to let you just get in there and start
| looking around helps a ton and makes the full documentation a
| lot more accessible.
| andersa wrote:
| It sounds more like an intermediate strategy, if you're eager
| to discover some tricks you missed. First do some small
| projects to familiarize yourself with the basics. Reading the
| API before really knowing the context of anything you're
| looking at seems fairly pointless to me.
| blt wrote:
| Your style will get you through a project, but you'll miss out
| on useful but nonessential features.
|
| For example, a lot of C++ programmers miss the full spectrum of
| std::algorithm. A lot of Python+NumPy programmers miss out on
| some useful indexing tricks.
|
| I'm still suffering from not taking a rigorous approach to unix
| shell.
| Maschinesky wrote:
| I read the kubernetes API and I did not regret it.
|
| Nonetheless for just getting to your goal and not becoming
| really good in something this is not necessary or can be done
| later
| TacoRabbit wrote:
| It's also worth noting that if you're concerned about Epic
| Changing the Deal and doing a rugpull like Unity, they've said
| you can simply not accept the changes and continue operating
| under your existing terms you agreed to:
|
| "If we make changes to this Agreement, you are not required to
| accept the amended Agreement, and this Agreement will continue to
| govern your use of any Licensed Technology you already have
| access to."
|
| You potentially lose access to epic services of various sorts,
| but it's a far cry from the Unity situation.
|
| https://www.unrealengine.com/en-US/eula/unreal (Section 7)
| interestica wrote:
| I think Unity had that same provision? Until they changed it:
|
| "Unity silently removed their Github repo to track license
| changes, then updated their license to remove the clause that
| lets you use the TOS from the version you shipped with, then
| insists games already shipped need to pay the new fees."
|
| https://old.reddit.com/r/gamedev/comments/16hnibp/unity_sile...
| blinding-streak wrote:
| Unity offices are closing due to death threats. Things going
| smoothly after their pricing change.
|
| https://www.bloomberg.com/news/articles/2023-09-14/video-gam...
| mrtksn wrote:
| What up with the gaming community? I get the the players being
| carried away or be from a special demographics but aren't the
| game professionals aware that they are doing business?
| Underpaid developers, death treats after some pricing changes.
| Wow.
| skeaker wrote:
| "The gaming community" consists of an insanely large number
| of people. Some percentage of people on Earth are
| willing/crazy enough to use death threats to get their way.
| The gaming community is large enough that that percentage
| manifests itself in the form of death threats being used. The
| question isn't so much "what's up with the gaming community"
| as it is "what's up with this small percentage of humanity."
| saurik wrote:
| There is something interesting though that while the
| audience of superhero movies is super large and while there
| are a lot of overly toxic complaints and clearly a number
| of people who are super angry about various things, I
| haven't seen news reports of any offices at Warner Brothers
| or Disney being closed due to credible threats of violence.
| skeaker wrote:
| I suppose you haven't looked hard enough, then: A 5
| second google search for "marvel movies death threats"
| turns up multiple articles about threats against
| directors for killing off Marvel characters. To your
| point I'm not sure that they closed their offices over
| it, but how they react isn't really up to the people
| making death threats.
| mardifoufs wrote:
| This is not necessarily the gaming community. If anything,
| the devs who are currently revolting are usually pretty
| critical of said community
| musicale wrote:
| The developers are revolting.
| pixl97 wrote:
| Rent goes up 200%: [we sleep]
|
| Unity changes pricing: [ we riot ]
| johnnyanmac wrote:
| let's be real: there's good odds that the people doing
| this hail from countries where they feel they can be safe
| from legal avenues of (the US-headquarter) Unity.
|
| Also, these are children or the privileged who are
| complaining about video games on thee internet. They have
| no issues with rent.
| spywaregorilla wrote:
| > I heard Blueprint sucks!
|
| > Blueprint actually rules. Look, I get it - why would a visual
| scripting thing be good? They're all shit! I agree.
|
| > Blueprint is the only one that's any good. It's amazing. It
| will also help you learn the engine. Everything you do there will
| be applicable to C++. No matter who you are, you should start in
| Blueprint. It's 100% true that you can build an entire game in
| Blueprint. Yeah, with multiplayer. Yeah, performantly. Yeah,
| maintainably. It's not just for rapid prototyping.
|
| > Be a snob about Blueprint at your peril. I've helped a lot of
| people get good at Unreal and get hired for it, and Blueprint-
| related recalcitrance is the number one way people screw
| themselves - without realising, they sentence themselves to
| months of wasted time and frustration only to mould themselves
| into the type of Unreal user who sabotages any team they're on.
| Swallow your pride and look at some nodes.
|
| Best advice in this page. Blueprints are excellent. They make the
| engine API extremely discoverable. You naturally gain a deep
| understanding of the classes and components and how they
| interact. They are performant. They can do 95% of what you want.
|
| The C++ engine API is fine but it doesn't lend itself to learning
| the engine. I don't recommend using it unless you identify a
| specific need.
| LanceH wrote:
| I had this same scepticism but kept seeing tutorials doing real
| with with it until I was convinced.
| aschearer wrote:
| How do people using Blueprints deal with:
|
| - Find and replace a variable
|
| - Change a variables type
|
| - Merging changes from multiple commits
|
| - Refactoring
|
| - Finding all references
|
| I'm a fan of visual coding and use it extensively in YWDHT but
| have found the above challenging. I'm curious how Blueprints
| solves these issues, especially for larger teams.
| russdpale wrote:
| A colleague and myself were just discussing similar issues
| with SSIS packages compared to just running the queries in a
| stored procedure on the server.
| Pxtl wrote:
| Yes but the difference is that Blueprint is actually a good
| language while SSIS is a dumpster-fire.
| timeagain wrote:
| I think you missed the point. Yeah it isn't code and it has
| downsides, but it is a GUI for discovering and learning to
| intuit the API. To not use it would be tantamount to refusing
| to read the documentation.
|
| When entire teams are using visual programming tools through
| the entire dev lifecycle (incl. refactoring and maintenance),
| wake me from my cryogenic freezer!
| andybak wrote:
| But the original article and the post we're all replying to
| isn't arguing for using it for "discovering and learning to
| intuit the API" - they are arguing for using it for the
| bulk of coding tasks.
| spywaregorilla wrote:
| No I don't think so. You can. I do about 80/20 bp,
| gradually shifting some content to cpp as I need more
| specific network replication capabilities.
|
| But they're definitely referring to learning by doing
| stuff in blueprints. I would agree with this. Figuring
| out how something ought to be done with the engine in
| blueprint and then re-implementing it in cpp is the more
| pleasant experience imo.
| spywaregorilla wrote:
| Not sure why this is downvoted.
|
| > - Find and replace a variable > - Finding all references
|
| I think the basic search tools are pretty good. I can't say I
| expect find and replace to be super common. I would prefer to
| do such things one at a time.
|
| > - Change a variables type
|
| I would say you really shouldn't be doing this too often.
| It's compiling to statically typed code under the hood so
| this will frequently cause a lot of breaks. You can do it,
| and it will highlight all the areas where this breaks things
| (maybe more easily than c++ might tbh). And if the types are
| compatible, that might mean you have to do the annoying step
| of redrawing lines to the same var with a new "node"
| representing the proper type.
|
| > - Merging changes from multiple commits
|
| This is hard and not good. The most difficult part about
| blueprints.
|
| > - Refactoring
|
| I tend to think this is pretty easy. Maybe easier than in
| code. I'm a big fan of collapsing all nodes into subnodes. So
| every individual step becomes one high level node. You can
| also "collapse nodes" into a function itself. You want to
| minimize the number of nodes you're looking at any given time
| so it kind of encourages good practices on itself if you're
| competent.
| exogen wrote:
| Would you be down to chat a little about your Blueprint
| experience and take a look at a tool I've been working on?
| Check my homepage (on my profile) for contact info if so,
| I'd be very thankful :)
| spywaregorilla wrote:
| I'd prefer to just reply to comments but I'd take a look.
| You might find better perspectives asking the folks who
| sound like they've finished shipping a complete game
| though.
| andybak wrote:
| > I can't say I expect find and replace to be super common.
| I would prefer to do such things one at a time.
|
| This seems like a very strange thing to say. I presume you
| do text-based coding as well? Multiple cursors,
| search/replace, bulk refactors and other semi-global
| operations are a huge part of my normal workflow and I
| can't quite fathom how visual coding would change the need
| for that.
|
| Regarding refactoring - I'm not sure what you describe
| really is "refactoring".
| spywaregorilla wrote:
| I'm a data scientist day to day, which is a very
| different feel from coding up game systems. The latter is
| a lot more intricate and intertwined. The text coding I
| do in c++ for unreal is probably more involved.
|
| I can't say what you're saying resonates with me as
| familiar. I've always been confused at why people ever
| feel multiple cursors is useful if not just begging for
| disaster. You can, for example, rename a property in a
| blueprint class, and that will flow through to all
| references to that property in other blueprints, if
| that's closer to what you mean.
|
| When I think about refactoring I think about taking some
| logic and making it into a more reusable function; or
| abstracting it into a shared component. I would say the
| former is what I was saying, and the latter is more of a
| capability offered by the engine than the tooling.
| Reparenting classes to compatible alternative parents and
| moving properties and logic to component classes is
| relatively comfortable in my opinion.
| andybak wrote:
| This is an extremely good list of the potential issues with
| most current node-based tools and Is be very keen to see a
| detailed reply.
| [deleted]
| crustaceansoup wrote:
| I've only been on medium-small teams, but I'll give it a
| shot:
|
| Merging is essentially as banned as we can make it; we use
| Perforce, and set all .uasset files (Blueprints and other UE
| assets) as Exclusive Checkout so only one person can edit
| them at a time. This is recommended by Epic. When we do need
| to merge things, it's mostly a manual process of opening the
| Editor on two branches and duplicating all of the changes.
|
| All of the refactoring-related questions, again, mostly
| manual effort. There are some constructs that can help keep
| things DRY which reduces the problem, like BP function and
| macro libraries. You also get inheritance and interfaces. UE
| also lets you redirect property, class, and function names to
| new names using "Core Redirects"; you can do that and then
| resave all packages to effect a bulk change.
|
| Finding all references: Search All in UE will find a string
| _anywhere_ ; that means in property details, BP function
| calls, variable names, comments, anything. There's not
| exactly a "find references" as you might expect from a normal
| IDE though.
|
| Really, the ultimate solution to dealing with these and the
| general "visual scripting spaghetti" problem if they're on
| the verge of becoming acute is to stop using Blueprint. We
| try not to use Blueprint for any complicated systems. It's
| nice for simple presentation-related things (e.g. "play x
| sound when y happens"), or places where we want designers to
| have some control for tuning or prototyping, but even for
| something that seems "straight-forward" like GUI code it can
| very easily end up spiraling out of control.
|
| Blueprint also has a performance cost and it's hard to
| profile. UE5 dropped UE4's main attempt to fix this with
| "nativized" Blueprints, i.e. Blueprints that got compiled
| into C++. There are ways to improve Blueprint performance,
| but you really shouldn't even get yourself into a place where
| you're leaning on it so heavily that you can even worry about
| that.
| yAak wrote:
| Sounds very similar to the problems of using
| XIBs/Storyboards in iOS dev. (aside from the perf. cost you
| mention)
| dbrueck wrote:
| Earlier this year we completed a huge refactor that involved,
| among other things, getting us almost 100% off blueprints
| (now we use them just for little bits of presentation logic
| in UIs).
|
| BPs are amazing for discovering how to use the engine - they
| provide a sort of guided exploration of things, especially
| when you don't know what you don't know.
|
| For us they really, really, really broke down when it came to
| version control, multiple people working on the same BP, code
| reuse, and refactoring. Arguably, at least some of this was
| our fault - I think you're "supposed" to do the major coding
| not in BP and then use BP mostly for really high level stuff,
| and we didn't always do that.
|
| Anyway, it's been wonderful not having those issues anymore.
| Gone are the days of changing one thing and then git saying
| that 100 files have uncommitted changes!
| doctorpangloss wrote:
| It's nice to hear from someone with real experience.
|
| Blueprints clearly delivered negative ROI. In general they
| probably do. This is the worst time to be advocating for
| visual programming, considering the first truly
| groundbreaking application of AI is going to be in writing
| code.
|
| The real question is, did C++ give you any real ROI either?
| Probably not, it probably only got in the way compared to
| the way Unity is architected.
|
| > Gone are the days of changing one thing and then git
| saying that 100 files have uncommitted changes!
|
| You're using Unreal, but not with Perforce? Get back into
| the time machine buddy!
|
| People's expectations about this extremely clunky engine
| are way too high.
| bradleyishungry wrote:
| Blueprints are extremely useful in prototyping at the
| very least, not just in the initial stages of development
| but for adding new systems. There is nothing wrong with
| them and the idea that LLM's are going to replace
| blueprints is ridiculous. Sure, you will be able to have
| them write a block of collision code, but gamedev is one
| of the most complicated fields in terms of having an
| understanding of what your state is and what references
| what.
|
| LLM's can spit out code without understanding the
| problem, but understanding the problem is 99% of gamedev
| dbrueck wrote:
| > The real question is, did C++ give you any real ROI
| either?
|
| We actually moved most of everything that was in BP (and
| a good bit of what was in C++) to Python, so it addressed
| all of our issues while also speeding up development and,
| somewhat surprisingly, giving us a decent performance
| boost too.
|
| > You're using Unreal, but not with Perforce?
|
| Yeah, definitely not going to use Perforce, haha - might
| as well be using SourceSafe!
|
| > People's expectations about this extremely clunky
| engine are way too high.
|
| Unreal absolutely does have its warts, an almost
| overwhelming amount of complexity, and we've run into our
| share of issues. Sometimes you're amazed at how quickly a
| feature can be implemented, and then other times you
| spend days on something you thought was going to be
| trivial. We replaced the replication system with
| something better suited to our needs, for example. That
| said, on the whole we're pretty happy with Unreal (both
| the renderer and the materials system are very
| impressive).
| exogen wrote:
| Hey, I've been working on something I think is pretty cool
| to address some of the shortcomings mentioned here. If
| you're up for chatting about your experience and offering
| some feedback, mind hitting my profile and shooting me an
| email (on my homepage)?
| johnnyanmac wrote:
| >They make the engine API extremely discoverable.
|
| yeah, because the UE documentation is absolutely horrid (and
| it's not like Unity is better at this). I have lots of gripes,
| but I think the meta issues involve how BPs cause so much
| community knowledge about the c++ API to be buried. Absolutely
| fatal if your game cares about performance.
|
| >They are performant
|
| They are performant... IF you know how to weave between them
| and c++. Shame that courses don't really seem to emphasize that
| and you simply hit that wall once you're working on a project.
| pfisch wrote:
| Blueprints have terrible performance. They just do. Even trying
| to compile them into c++ doesn't work well.
|
| Blueprints run at least 100x-1000x slower than equivalent c++.
|
| This isn't even discussing working with multiple coders and
| version control, which is also a disaster.
|
| If you are making a simple game then they can work. If you
| aren't then they are not great.
| johnnyanmac wrote:
| >Blueprints run at least 100x-1000x slower than equivalent
| c++.
|
| they are slower but unless you are doing literal math in the
| blueprints this is a huge exaggeration... which is exactly
| what one AAA game I worked on did. _sigh_. And they wondered
| why we couldn 't hit 60fps (tho, that wasn't even the biggest
| detractor to performance).
|
| Now, BP's in general usage when you're not doing literally
| everything in them is about 10x slower. But when you properly
| use blueprints, you can mitigate this a lot. BP's in a large
| project work best when you expose existing c++ code to BP and
| make sure any designer code is piped through c++ first. The
| main exception tends to be UI code, but UI is rarely a
| performance bottleneck in large 3D games to begin with.
|
| >This isn't even discussing working with multiple coders and
| version control, which is also a disaster.
|
| yup, that's my 2nd biggest gripe. Nothing worse than trying
| to submit code and the BP you changed one node in is locked,
| with the owner of the lock being out for the day.
| brundolf wrote:
| My hangup with blueprints has always just literally been: I'd
| like to type them out with my keyboard instead of using a mouse
|
| I wish they offered like a "Bluescript" language or something,
| that just maps 1:1 with blueprints but lets you write them out
| as code
| andybak wrote:
| I think lossless roundtripping with a textual representation
| is essential if node-based tools want to escape the local
| minima they all seem to get trapped in.
|
| Either that or the ability to use 3rd party editors so
| competion and innovation can happen in the same way it has
| for textual code editors.
| andersa wrote:
| Blueprints are not performant, they are potentially the slowest
| scripting language to ever be used in a significant way, worse
| than python even. If you don't believe this, try implementing
| some basic number crunching routines in pure blueprints and see
| how long they take to execute. Though if you're just using them
| to configure and glue together C++ classes, like most gameplay
| code is doing, then it's usually fine.
|
| Reading other people's blueprints and understanding them is
| much harder than doing this with the equivalent code - having
| to follow the wires everywhere is a nightmare with all visual
| noise. I often jokingly call it a write-only language. Not to
| mention the part where you must have compiled the project and
| be running Unreal Editor with all the assets loaded to do this
| in the first place.
|
| And then you can't even properly diff or merge them without
| using some special tool that doesn't properly integrate with
| your version control and only works reliably half the time.
|
| Blueprints are fantastic for familiarizing yourself with the
| engine, since you can quickly discover all the things to do
| from the context sensitive search. They're also great for
| people to get started with their projects and prototyping.
| They're not at all suited for production work in a large team.
|
| I really wish Unreal Engine supported a proper scripting
| language so the choice isn't between noisy node graphs hidden
| in binary asset files and raw C++ code. People keep shooting
| themselves in the foot with both of these.
| johnnyanmac wrote:
| >I really wish Unreal Engine supported a proper scripting
| language so the choice isn't between noisy node graphs hidden
| in binary asset files and raw C++ code. People keep shooting
| themselves in the foot with both of these.
|
| That's apparently what UE's new Scheme based language,
| Verse[0], is aiming to do. But this is very new tech and
| currently used in the Fortnite editor part of UE. It's not
| quite something to use in the main engine yet.
|
| [0]: https://dev.epicgames.com/documentation/en-
| us/uefn/verse-lan...
| brundolf wrote:
| Oh I didn't know about this, this sounds great
|
| Have they said explicitly that it has ambitions beyond
| fortnite?
| jarsin wrote:
| Don't forget to use base classes in c++ though. It's massive
| performance hit to cast to bp only classes. The base class will
| help you move nasty bp stuff like complex calculations once you
| run into them.
| boppo1 wrote:
| For any Unreal experts:
|
| I'm an aspiring graphics/engine programmer. I don't really care
| about making games, I'm more excited about improving the tools
| available. My feet are wet enough with C++ that I think it would
| be good to start digging around in/ modifying/ contributing
| (likely merely attempting 'small' stuff like bugfixes) to the
| Unreal codebase. I've been doing so lately with Blender's
| codebase lately with some success, so large software isn't
| _totally_ new to me. Blender is mostly C though, hence my
| interest in seeing how things are done in Unreal.
|
| Any tips/ resources/ advice/ quirks I should know that you can
| share would be greatly appreciated!
| johnnyanmac wrote:
| If you were working in Blender, Godot may hit up your alley a
| bit more as an open source community driven engine.
|
| But wrt UE, it depends on if by "contributing" you mean "making
| plugins" or "contributing to the codebase at large". From the
| sound of things you want to do the latter. Unreal is "viewable
| source" but you first need to sign up with an Epic Games
| account: https://www.unrealengine.com/en-US/ue-on-github
|
| From there, there are instructions on how to contribute (the
| contribution documentation is actually on a public page:
| https://docs.unrealengine.com/5.3/en-US/contributing-to-
| the-...)
|
| There is probably some official Unreal Engine community as well
| (probably on the UE forums), so that can be a place to ask for
| any specific pieces where devs need help. Best of luck.
| gigatexal wrote:
| But Unreal is doing the same nickel-and-diming though no?
| starburst wrote:
| They didn't retroactively changed the TOS of their engine so
| that a game you made years ago means you now potentially
| receive monthly invoices from Unity (and what about ridiculous
| new fees they will think in the coming years).
|
| If Unity would've said that now any games built using whatever
| the most recent version of their engine is subject to a new TOS
| that means a fees per installs it wouldn't have nearly
| generated the amount of backlash it has received (no one is
| going to use Unity for a future project regardless of the fact
| that the fees per install is for the most majority a much
| better deal than 5% revenue).
| gigatexal wrote:
| Yeah that too. My initial take is clearly wrong to link the
| two of them. Shame Apple is partnering with Unity when Unreal
| seems to be the more popular/better looking engine.
| starburst wrote:
| Yeah I wonder if that will impact their partnership they
| have with their VisionOS...
| dave_sullivan wrote:
| 5% after your first million in game sales and only in quarters
| when you sell at least $50k of product?
| samspenc wrote:
| Also, as other comments have pointed out, Epic makes most of
| its money from Fortnite, their revenue from UE licensing fees
| are tiny in comparison.
| gigatexal wrote:
| Yeah that seems far more reasonable never mind.
| ffhhttt wrote:
| Because it's predictable and and you can trust Epic to not
| start pulling the rug from under you.
|
| Even with the new pricing model Unity should still stay way
| cheaper for anyone who make more than $2-3 per user.
| zengid wrote:
| wow, great resource even if you just like to know more about
| both.
| jarsin wrote:
| That is until round 2 of Epic vs Apple. Where Apple officially
| kicks the Unreal Runtime off it's store this time. [1]
|
| Amazes me the short memory of the dev community. So many studios
| and publishers could not take the risk of Unreal being kicked off
| and had to switch to Unity.
|
| Unity is still cheaper for vast majority of cases too.
|
| [1] https://www.macrumors.com/2020/08/17/apple-terminate-epic-
| de...
| Pxtl wrote:
| I can't help but be reminded of the people who jumped from
| Twitter to Threads.
|
| Ultimately, the recent wave of enshittifications of major
| products - Unity, Twitter and Reddit off the top of my head -
| It's a hard reminder that lock-in and governance matters.
| Software is a long investment, so it's time to start thinking
| very hard about how the software you use is run, and how much
| control you have if it all goes sideways.
|
| I realize that OSS options like Godot aren't really comparable,
| but since Unreal's main competitor is Unity, it feels likely that
| Unreal could do something similar since they don't have a
| competitor keeping the pressure on about price anymore.
| ainiriand wrote:
| Do not fool yourself here, Unreal's main competitor was never
| Unity, it was the different myriad of proprietary engines that
| exist in powerful studios, there is were the millions are.
|
| Unity could never get into that piece of business and Unreal
| Engine is barely scratching it.
| Pxtl wrote:
| Yes, but Unity targeted the Indie market with "free for small
| unsuccessful projects and we take a small cut of sales if it
| takes off" first and then Unreal jumped into that market.
|
| While Unreal entered that market from the opposite direction
| (offering a proper, supported high-end gaming engine to
| replace in-house engines of AAA gaming companies) they both
| converged into the same market when it came to selling to
| small players.
| karim79 wrote:
| That was always the impression I had, engines such as id tech
| X, Frostbite, Fox Engine, etc, in my view are some examples
| of more "direct" competition.
| Ekaros wrote:
| Also the models these companies pull are so weird, tone-deaf
| and impenetrable that it boggles mind. But maybe that is point.
|
| Like Unity pricing model. And then Hashicorp and what ever does
| competing product or offering mean...
| stuckinhell wrote:
| Game development is a very different space due to the extreme
| amount of middleware used and the fact porting between engines
| has been done since the 90's.
| babypuncher wrote:
| Twitter usage is down 30% and probably still declining, so I
| wouldn't say their enshittification saw no consequences.
|
| When something has momentum it takes a lot to slow it down, but
| that does not mean doing so is impossible.
|
| Unity is a different case though. Unity is retroactively
| applying these new terms to existing licensees, even if their
| game already shipped years ago. Unlike Twitter, they are
| directly hitting their customers wallets in a very nasty way.
| And unlike Twitter, Unity isn't the only well established
| player in its market. Already in-development projects might not
| switch, but this is sure to give studios pause when evaluating
| potential stacks for future games.
| hypeatei wrote:
| Unity never seemed like a good engine. It's CPU bound which is
| extremely aggravating for a _GAME_ engine.
|
| A popular game made with Unity, called Rust, always gets a lot of
| shit from players because GPUs don't do anything except give a
| couple FPS. I'd be glad to see Unity die with these pricing
| changes.
| kibwen wrote:
| Quoting a post from the lead dev of Rust-the-game entitled
| "Unity can get fucked": https://garry.net/posts/unity-can-get-
| fucked
|
| _" Let me be clear.. the cost isn't a big issue to us. If
| everything worked out, the tracking was flawless and it was 10p
| per sale, no biggy really. If that's what it costs, then that's
| what it costs. But that's not why we're furious. It hurts
| because we didn't agree to this. We used the engine because you
| pay up front and then ship your product. We weren't told this
| was going to happen. We weren't warned. We weren't consulted.
| We have spent 10 years making Rust on Unity's engine. We've
| paid them every year. And now they changed the rules. [...]
| Let's not make the same mistake again, Rust 2 definitely won't
| be a Unity game."_
| andersa wrote:
| Unreal is similar. All of the gameplay code runs on a single
| thread. The game framework tricks you into building slow OOP
| stuff by default with far too much pointer chasing. You can
| easily make an Unreal project that performs worse than the
| equivalent Unity project. In fact, many do!
|
| It takes effort to release a well performing game using either
| engine if you have a non-trivial amount of "stuff" going on.
| Luckily Unreal comes with fairly advanced profiling tools so
| you can find where the problems are.
| bluescrn wrote:
| C# support is/was its killer feature. Game dev without the pain
| of C++, and without being limited to non-standard scripting
| languages (or worse, visual scripting spaghetti)
|
| With Unity, you can use C# for everything, from the simplest
| 'spin this object around' script to customised rendering
| pipelines and complex in-editor tools.
|
| Performance was clearly good enough for the engine to become
| wildly successful, particularly amongst indie/mobile developers
| making smaller games, and experienced users learn to avoid the
| main performance pitfalls.
| pjmlp wrote:
| Get ready to throw away everything that was written in C# to
| start with.
| zerr wrote:
| Or move to Godot/C#.
| pjmlp wrote:
| Doesn't do game consoles.
| madacol wrote:
| GODOT developers are trying to do it via
| https://w4games.com/. But not sure if it's ready
| pjmlp wrote:
| C++ part, not AOT compilation for .NET.
| starburst wrote:
| Technically there is UnrealCLR, so if you made a game with
| mostly Unity-agnostics code it's possible to keep a bunch of
| it.
|
| One of my game is multiplayer, the whole gameplay code is
| completely Unity-agnostics to run server-side without any Unity
| code.
| pjmlp wrote:
| Which is a proof of concept and doesn't do mobiles, game
| consoles and VR/AR headsets, mostly useless.
| starburst wrote:
| Very true, for now, but the amount of tools / libraries /
| projects that will spawn / funded / contributions to move
| projects out of Unity is gonna make that more realistic
| eventually.
| pjmlp wrote:
| I seriously doubt it, as it requires embracing the game
| development culture that most FOSS folks are against to,
| and most commercial engines rather stay with compiled
| languages instead of having a R&D department in
| compilers.
| jaimehrubiks wrote:
| > It's free until you make a million bucks USD, and only after
| that is it 5% gross, and only in quarters where you made more
| than $10,000 USD. So most folks never end up paying anything.
| There are no subscription fees or anything. To clarify, if you
| make a million bucks, and then one dollar, you only owe them five
| cents.
|
| It sounds very fair to me, what are the general thoughts here?
| r053bud wrote:
| It's fair until they change it without warning. It's not a
| matter of if, it's a matter of when. I love Unreal, but I know
| it's coming.
| throw16180339 wrote:
| Epic is a highly profitable private company controlled by the
| founder. They have no incentive to mess with a business model
| that works; their margins are higher than Unity.
|
| Unity has over 3x as many employees as Epic, much lower
| margins, is publicly traded, and they've been losing money
| hand over fist. Everything is subject to change until they
| make money, shut down, or are acquired.
| beanaroo wrote:
| What happens when your business has a portfolio of
| products/services over multiple departments, spanning various
| platforms, and only one consumer mobile app uses Unity for an
| augmented reality component that's not a core offering (premium
| feature)?
|
| Should Unity still be entitled to the same cut?
| ricardobeat wrote:
| Those are the Unreal fees, not Unity.
|
| But to answer your question, they are royalties on top of
| that one mobile app, not your entire revenue. If you
| distribute it for free, you might pay no royalties; if it
| somehow is tightly related to your main revenue-generating
| product then you'd sign a custom licensing agreement with
| them.
| owenpalmer wrote:
| I'm surprised they can sustain such low pricing
| csdreamer7 wrote:
| Take a quick look at how much fortnite is making per day in
| 2018.
|
| https://www.cinemablend.com/games/2454545/the-insane-
| amount-...
| danudey wrote:
| The arrival of Fortnite Money has meant that Epic can afford
| to spend a lot more and charge a lot less for everything they
| do. They opened a studio in Vancouver and started hiring
| whoever they wanted from other companies, e.g. The Coalition,
| with starting salaries that made jumping ship a no-brainer
| for the engineers they were picking up.
|
| For Unreal, I think it fundamentally comes down to:
|
| 1. We want to be the biggest and best game engine out there
|
| 2. We want everyone to use our technology if at all possible
|
| 3. The vast majority of our money is going to come from the
| top 1% of the huge players in game dev (CD Projekt Red, The
| Coalition) and not from anyone else
|
| 4. The more people who use Unreal to make games, the more
| Unreal devs there are in the world, and the more Unreal devs
| there, the more likely those huge companies (or potentially
| blockbuster indies) are to choose Unreal for their projects
| because talent is readily available (see point #3)
|
| _Edit_ : Per their court case with Apple:
|
| https://www.theverge.com/2021/5/3/22417447/fortnite-
| revenue-...
|
| They made over $5bn in _profit_ from 2018 to 2019 from
| Fortnite, and $5.1bn in revenue in 2020.
| NetOpWibby wrote:
| I spend money on Fortnite roughly every month. Extrapolate
| that to an insane amount of players and it's not hard to
| see that they're in an excellent position.
|
| Creator payouts from building games and experiences within
| Fortnite builds loyalty and encourages further development
| from kids going, "Ooh, I have an idea for something."
|
| It's incredible.
| PeterisP wrote:
| Just as in game microtransactions, it doesn't matter how much
| or little the median person is paying, because all the profit
| is in the minority of very big payers / 'whales', so you
| optimize the payment structure of the small payments to
| ensure that they don't prevent you from capturing the whales.
|
| If your game doesn't earn a million dollars, it doesn't
| matter to Epic, because all those (many!) tiny games in total
| don't earn enough that even a much higher pricing would move
| the needle.
|
| However, if the low-end pricing structure means that one more
| (or one less) blockbuster chooses this engine, that makes all
| the difference, because they are going to pay the full rate
| out of the billion dollars they earn.
| ffhhttt wrote:
| Technically if your game is not F2P Unity will still be much
| if your revenue i a couple if millions (even with their
| bizarre and convoluted per install pricing).
|
| Also I don't think they have that many people working on the
| engine (they have less than half the employee count of Unity)
| and it's probably subsidized by Fortnite revenue to some
| extent.
| corysama wrote:
| Games that expect a large revenue are expected to negotiate
| a custom contract with Epic. That has been their practice
| going back to Unreal Engine 1.
| johnnyanmac wrote:
| in that regard I'm sure they will do the same with Unity.
| But Unity for the little guys that just a _little bit too
| big_ suffer the most in this deal. At least Epic handles
| that edge case by letting those edge case devs keep the
| first million.
| readyplayernull wrote:
| That's mostly a contribution fee, game engines don't make a
| lot of money from their software, in their case the real
| revenue comes from Fortnite.
| nottorp wrote:
| They're financed by blood diamonds. I.e. tencent making their
| initial funds from gacha on the Asian market and now trying
| to buy legitmity with it.
| johnnyanmac wrote:
| Tencent purchased a stake in Epic in 2012, years before the
| f2p mobile market took off.
|
| Tencent isn't just a mobile game company, they are
| basiaclly Chinese Microsoft for how many parts of the
| industry they are entwined in in their home country.
| brucethemoose2 wrote:
| The side benefits are enormous. Its not like Unity where
| Unity fees are _the_ bread and butter for the company.
| WeylandYutani wrote:
| And with respect for indie games the vast majority of them
| barely make money.
|
| Unity was trying to squeeze water from a rock.
| brucethemoose2 wrote:
| Unity makes its money from mobile gaming, and that is a
| juicy rock to squeeze.
| [deleted]
| Ekaros wrote:
| Just remember how many AAA or big name titles use Unreal as
| engine. Those can sell millions of copies at 60 per copy. And
| even if they have much better rate it is still probably half
| a million to millions a game.
| danudey wrote:
| Epic made more than $5bn in _profit_ from 2018 to 2019,
| according to documentation from Epic 's court case with
| Apple, and $5.1bn in revenue in 2020.
|
| https://www.theverge.com/2021/5/3/22417447/fortnite-
| revenue-...
|
| With numbers like that, collecting a half-million dollars
| from even ten blockbuster games per year is probably not
| even worth the time and energy it would take; that would be
| 0.1% of their revenue, which, relatively speaking, is
| basically nothing. That whole business wouldn't even show
| up on the balance sheet.
| ffhhttt wrote:
| Isn't most of that from Fortnite and not the engine
| business?
| enragedcacti wrote:
| > collecting a half-million dollars from even ten
| blockbuster games per year
|
| I don't think that's in the right ballpark. PUBG has
| generated about $15 billion in revenue over 6 years or
| $125 million per year in revenue for Epic.
|
| Jedi: Fallen Order sold 10 million copies at full price
| in its first four months, netting Epic ~$20 million.
|
| Even an indie game like Stray netted Epic ~$2 million in
| one month of Steam sales.
|
| https://vgsales.fandom.com/wiki/PUBG
|
| https://en.wikipedia.org/wiki/Star_Wars_Jedi:_Fallen_Orde
| r#S...
|
| https://www.gamesensor.info/news/stray
|
| * assuming all these devs have the standard 5% deal and
| chopping 30% off for marketplace fees where only
| sales*price data was available
| akhosravian wrote:
| FWIW basically no established game developer is using the
| standard terms epic provides. If you're in a situation
| where you have a high degree of confidence you will owe
| Epic money it is worth reaching out in advance.
| johnnyanmac wrote:
| True, but I also imagine that Epic isn't bargaining down
| the rev share too low. Or, companies are fine paying 8 or
| even 9 figures upfront in anticipation of such success in
| a custom contract.
|
| I can't imagine it being chump change.
| amiga386 wrote:
| This may well be marketing, but it's good marketing. It leads
| with being open and honest that not everything is great with
| Unreal or Epic either. That's much more convincing than something
| which claims to be sunshine and rainbows.
| koromak wrote:
| for really small teams, does godot make more sense? I've always
| heard Unreal is too much to chew on
| johnnyanmac wrote:
| for 2D or simple 3D games, sure. Godot should be able to do
| enough to enable a small team to launch a game. You just have
| to keep in mind that console support won't be as robust and
| smooth as UE.
| crustaceansoup wrote:
| Some disagreements based on my experience working with UE for the
| past 11 odd years. Mind if this all sounds negative that I really
| like working in the engine and would recommend it for most game
| projects. I just think you should be aware of what you're getting
| into.
|
| > Unreal and Unity are not game engines in the same sense.
|
| This is mostly a true description, but
|
| > It's the same way with Unreal, except you're not getting
| "whatever Epic ended up with when making Gears of War"
|
| No, a lot of what you're getting _is_ "whatever Epic ended up
| with when making UT, Gears of War, Paragon, and Fortnite". You
| can very much feel their previous games in it. This is good and
| bad; good in that the tools you need to ship a real game are all
| there and the engine is actually battle-tested; bad in that the
| tools you need to ship a game that doesn't fit that mold might
| not be and there could be a lot of _stuff_ that will get in your
| way if you decide the Epic Way doesn 't suit your project.
| UE4/5's adoption does help a lot, things were rougher earlier in
| UE4 and in the UE3 days.
|
| > Porting to consoles isn't an outsource job here.
|
| Nah, we needed help to ship Chivalry 2 on console and WinGDK.
| Many smaller teams do outsource or contract for assistance. It
| was months of multiple programmers and tech artists, it really
| wasn't one person x one week.
|
| > Upgrading to the latest version is not a big deal.
|
| If you're a tiny, Blueprint-only indie / side project I guess
| this is probably true. It takes us weeks though.
|
| > Unreal introduces new systems carefully.
|
| We and other teams I've talked to had a policy of waiting for the
| first hotfix revision of a major UE4 update before attempting an
| upgrade, though.
|
| > I heard Blueprint sucks!
|
| See my comment https://news.ycombinator.com/item?id=37512356
|
| > I heard Unreal is geared towards first person shooters and it's
| a struggle to make something in my genre!
|
| As above I don't totally buy the rebuttal. If you're doing
| something way out of left field you _can_ do it in UE, you might
| have to bypass a lot of Epic 's way of doing things though.
|
| > What if I don't want fancy graphical bells and whistles? What
| if I'm not making something in a realistic style?
|
| I've not worked on VR or mobile but I've _heard_ that Unity
| scales down better. Some of UE5 's nice stuff (nanite, lumen)
| also doesn't scale down well.
| hnthrowaway0315 wrote:
| I'm curiously to see whether a big player switches side. Likely
| not as all big players were probably consulted.
| mediaman wrote:
| I get the impression that Unity did not do a lot of homework
| before rolling this out. Several aspects of the policy they've
| waffled on, and when asked about who would pay the fee for
| GamePass games, they said the distributor would, but it appears
| the distributors were not consulted on this.
|
| Not to say they didn't consult with the major Unity players,
| but it seems plausible that they didn't based on the
| carelessness of the rest of the rollout.
| Ekaros wrote:
| Big big players probably don't care the Pro and Enterprise tier
| isn't too horrid. Or they have negotiate their own deals. For
| them 0.01 per install is probably magnitudes less than they pay
| on advertising per player.
| ffhhttt wrote:
| > re the Pro and Enterprise tier isn't too horrid.
|
| Technically you couldn't even use Personal or Plus if you
| made over 200k a year. It doesn't really make much sense to
| stay on the personal tier now anyway, as long as you manage
| to make at least over $10k per developer in a year.
| somenameforme wrote:
| A course that finally made Unreal "click" for me, after years of
| toying with it, was Tom Looman's 'Professional Game Development
| in C++ and Unreal Engine' course. The source for what you build
| (with the chapters available in the git history) is here. [1] It
| was based on a class he taught and so also includes homework,
| which I found infinitely more valuable than just following along
| in a 'Here's how to [x].' type lesson.
|
| [1] - https://github.com/tomlooman/ActionRoguelike
| compacct27 wrote:
| I agree, that course was fantastic. Unreal C++ was way less
| intimidating after.
| [deleted]
| bastardoperator wrote:
| Or you can wait for Source 2 which is rumored to be dropping on
| September 23rd with CS:2
| tapoxi wrote:
| Source 2 has been out since 2015, with tooling, but so far I
| think the only third-party licensee is S&ndbox. It's not so
| much a modern game creation platform as it is a collection of
| Valve's internal tools.
|
| Also from a technology standpoint it is miles behind Unreal
| Engine.
| sosodev wrote:
| It seems a goal of S&box is to allow more developers to ship
| games that are built using Source 2. I'm curious if we'll see
| much of that in the future.
| babypuncher wrote:
| I'm not convinced Valve is all that interested in pushing
| Source 2 as an alternative to Unreal or Unity, and their
| organizational structure would probably make them a pain to
| work with.
| ThatPlayer wrote:
| I think they did when they first announced it, and that it
| was going to be free (like Unreal/Unity). But that was also
| in 2015 and we've seen no public release of that since.
| ryanwaggoner wrote:
| I have no personal interest in this topic, but I like this site
| and the way the FAQs are organized. I'd love to have this for
| more topics.
| Nexxxeh wrote:
| Did Unity have the same reputation for shader cache compilation
| stutter on PC as UE4 games do?
| sovietmudkipz wrote:
| Tell me more. I've recently (past two weeks) gotten more into
| shaders and I'd like to hear more about this story. What was
| the shader cache compilation stutter?
___________________________________________________________________
(page generated 2023-09-14 23:02 UTC)