Unreal Engine 5 = Game Changer

No we do a final post-processing pass in Premiere. So instead of Blender -> Unity it's Blender -> Premiere -> baked video.
We used to do Blender or 3ds Max to Unity (back and fort), bake into a video then Premiere but it was very tedious.
We now go straight from Blender to Premiere without passing by Unity, otherwise we have to set everything again in Unity which is kinda pointless as we don't do real-time cuts in our game.

 

Exactly. I'm trying to make it so that the 3d elements in my scene look the same in Blender as they would in Unity, which means I'm also having to recreate my edge detection outline shader and my specific LUT setup. If I do this in Blender, things that function in Unity fast enough that they run at 30 fps on an Intel HD 5000 take 2-8 seconds to render. These are not geometrically complex props either. I'm rendering my output at 960x540 and rarely does the polycount exceed 1500.

Blender's realtime capabilities only exist for a very specific definition of realtime as they have yet to fully accelerate the compositor, something people have been asking for since the compositor was introduced.

Worse yet is that the compositor can't even be used in the scene view. You have to render it out. This is also a hotly requested feature.

 

Some body created this and Epic gave them a mega grant to go ahead.
honestly I have NO clue how the hell they did it, but it works

 

This looks interesting.
After using Unity for a while, i am now testing out unreal, and this looks like a very practical addition.
Do you maybe have a source for that?

 

I completely understand your point, though also want to add that bps changed alot since 4.0 and have been improved over time and way more functionalities are now exposed to it. Like I said, blueprints have a relatively low skill curve but despite of that allow you to pretty much create 95% of games you want to create. Heck ive just recently seen a solo developer with no coding experience release a full open world survival game done entirely in blueprints, and its not looking bad at all considering its 1 guy. The ms paint analogy is kinda what i mean by being disregarded or played down. Some guys trash blueprints though dont realise that some people, even solos are having a blast releasing and developing their own game with it. If it gets the job done, its gets it done. Simple

 

Can't we just enjoy the best of both worlds? I love mom and dad equaly.

 

http://www.spoon-tamago.com/2013/05/28/tatsuo-horiuchi-excel-spreadsheet-artist/
proof
Bad artist blame the tools

 

https://forums.unrealengine.com/com...t-tools-and-tutorials/1573386-mgc-magic-nodes

 

I am not trying to disregard Blueprint with that MS Paint comment. I am trying to make an analogy that you can understand as an artist. As a programmer, I feel massively empowered when I have C#, C++, or C available to use. It is similar to how an artist feels about Photoshop. When I messed around with Blueprint in UE4.0, I definitely did not feel empowered. I felt like I could probably do some simple stuff with Blueprint, but that it would quickly become a mess if I tried to build anything custom outside of a typical Unreal game clone. You would feel the same way if somebody asked you to create serious artwork using MS Paint instead of the Adobe suit products.

Having said that, I definitely do realize that both Blueprint and C++ support have improved a lot since UE4.0. For example, I had to compile my C++ code and then restart the UE4.0 editor each time I made changes and wanted to test the changes. With UE4.0, I could not simply hit Play to test code changes like I can with every version of Unity. That issue was eventually addressed in UE4.x, but I don't remember which minor version number it was.

In addition to that, I immediately realized how amazing Blueprint could be for level designers. In a large product, a level designer can use Blueprint to open and close doors instead of requesting help from programmers. That is very empowering for artists doing level design.

 

I really like having options that are smart, convenient, practical, and supported for a long time. I personally prefer using c#, it's my favorite language. But sometimes visual scripting simply does things faster and smarter than c# does. UI, Behavior Trees, State Machines (like Mechanim), setting up player input, hooking up visual data seemlessly (like data sheets or databases) all benefit from visual scripting tools. No one wants to write a large behavior tree or state machine all in c#, likewise certain code looks cleaner and runs much faster in c# than any vs tool right now.

This whole debate of whether Unity or Unreal is better than another is silly. I'd rather focus on the weak points of one game engine, and suggest options that would objectively make the engine much better. An official scripting language for Unreal Engine that works seemlessly with Blueprints would be amazing. Likewise, having all Unity features baked in (no separate packages for essential features), and Unity releasing the engine source for everyone would make the engine a lot more feasible for large projects.

I've been playing around with both Unity and Unreal for a while because it's hard to say one engine is definitely better than the other for my use case.

 

Just because it's able to do the job though doesn't mean it's ideal for the job. An amateur woodworker can buy a lathe and tools to make use of it for a few hundred dollars, but the professionals buy lathes costing thousands with features such as automation because the amateur way while it works it isn't very efficient.

It's very telling in my opinion that (a) Epic Games is/was looking for a middleground scripting language as this shows that they too acknowledge that while Blueprint has its uses it's clearly not an alternative for actual code, and (b) one of the best nodes available is one that adds small sections of code to your visual scripts.

Getting back to the quote I choose to comment on, 95% of the games that I want to create would be extremely inefficient as (a) it's difficult to create large scale graphs, (b) it's difficult to maintain large scale graphs, and (c) while they can be turned into C++ and compiled handwritten C++ by a skilled programmer will always be superior in performance.

Blueprint is fantastic for people who have limited programming skill but everyone else would be better off with actual code.

 

If you actually want to make games, to be honest none of that should come in between you. Work clean and it’s manageable. Of course, if you know how to program, by all means use programming. And when did I ever convey the notion that blueprints are superior? All I am saying is that some folks just disregard them unfairly and label them weak when they really aren’t. Blueprints are just an alternative way to script. Code can be just as messy and unreadable and inefficient if you re not experienced. Point still being 95% of games can be done in bps alone and bps have been battle tested. I feel like going in circles. If People can create games in bp, by all means let them do it. Its not as bad as people think. Again, complex games can be done in BP, its harder sure, but possible. And like mentioned bunch of times the ceiling to learn them is low compared to scripting languages and this is why you see so many solo devs whip out great games in ue4 with bps. I genuinely think the hostile attitude comes from coders is because they feel threatened by it that now artist are able to do pretty much alot of the scripting on their own without being reliant on a programmer. But in the end its a tool like any other, no tool is bad. It all depends on the individual, how determined he or she is.

I could also name countless of c# pitfalls in unity on larger projects but would I ever go as far to say its a bad language? No.

 

About F***ing time. We've been working in this archaic, purely text based system gate kept by neck beards for forever. We need to push this further. The faster we make coding accessible the faster we can solve the world's problems (and make better games)

Making coding more ergonomic and advancements able to propagate backwards is HUGE. The fact no one has been attacking this is crazy.

We need to make the practice of coding malleable and organic, we need a system that can expand without invalidating prior progress. Something that can change and improve over time. Making code a visual thing is only natural. We are visual beings, we absorb things visualy faster than any other method. Visual scripting gives code an understandable form, and having each nodes code isolated per node is a HUGE deal in helping us digest things in bite sized chunks.

The very nature of visual scripting cuts down on user error and greatly simplifies the system into something that can be understood.

Text has no restriction, you can type anything, there are no indicators of inputs, or structure so recognizing mentally what else there is to master in invisible and requires extensive outside resources.

Having lists of functions, variables, etc. gives a form to the art of coding, it gives you a tangible element to see and learn.

I'm so sick of the neckbeards circle jerking how inneficient visual coding is. They have no vision, they are obsessed with their dominance in a medium that pushes everyone else out.

 

It is not a problem what other people use. If there's a someone who wants to code GTA 5 in whitespace, they're free to do so. The problem happens when said someone starts proselytizing that whitespace is the true way and it is the way of the future, because using only 3 symbols for your program is obviously far easier than using 95 symbols of ASCII and because anyone can learn to use 3 keys only. The next problem happens when a company in charge of framework I use decides to drop C++ in favor of whitespace to ride the whitespace hype train. Because, as a result, I'm left with S*** tools that do not let me utilize my skills to the fullest..

Now, try to make an Unreal game without ever opening blueprint editor, and you'll see what the problem is.

Also, one more thing:

"it is possible" does not mean much, as in order for it to be "possible", you only need turing completeness.
If it is harder, what is the point? The tools are supposed to be empowering and not add extra hardships to the table.

--------

Anyway, I think I'm done here. The beginning was informative, now we're moving into the insult flinging territory. Probably the time to lock this up.

 

Please stop recycling the rumor about "hard to code" bank software, it just needs to die. Writing single number to database (and several buggy frontends for it) is abysmal compared to the vastness and complexity of game mechanics and math behind them. Also, FYI, HFT guys use jittted Java and C#.

 

They are 2 seperate organisms. High end data software needs to check certain boxes and be excellent in different areas. One is cold, important data that has a very specific use case and requires the highest securities. The other is a less tangible expression of "fun" that relies on exploration and expression.

Neither is "easy", they are inherently opposites of each other and rely on competencies in different areas.

Wisdom vs intelligence stat.

 

It is just driving me nuts that juniors usually don't understand and never appreciate the challenges presented in the gamedev field. We do have cold and hot data. We do have to optimize to the every bit of the available hardware (which is usually mobile with power of ps2 or ps3 content for no more than 5 minutes). We do write complex server and database systems with hundred of millions of users and amount of diversity in interactions far exceeding simple number write in the account table. We do have to support hundred thousands CCUs. We absolutely do have to care about user money balance that erroneously can be corrupted. And we absolutely investigate these cases just as a bank would. People loose money due to bank errors all the time and spend months trying to get them back. We usually solve these problems within 2 hours.

The thing is, the number of topics used in the gamedev nowadays is far more complex and exciting as writing buggy bank software using SOLID, agile and other bullshit they made up out of boredom.

 

Shader Graph has nodes in which u can drop code. Very similar to this.

On the topic, any news on how the UE5 tech works? i have not found any myself.

 

They are not opposites, they have huge overlap, because both rely on the same disipline - programming.

Games are cold hard data beneath the layer of media. Online games can have database backend which will be not very differetn from the one used by the bank. The moment you touch multiplayer you'll be want security. Because otherwise a brainless script kiddie will ruin the experience for your customers by injecting data into network session, which will harm your gain and draw people away from multiplayer. When you don't deal with multiplayer, your want stability so you won't lose players due to the game being a broken mess that glitches and crashes all the time.

Speaking of which, with avaialbility of visual scripting tools, number of broken games or cheaters in games skyrocketed. It is not uncommon for popular online titles to have thousands of complaints about teachers and the situation never improving for years.

There's no neckbeard conspiracy to keep people away from industry. When people criticise visual scripting software, it is because they're appalled by its inefficiency, lack of power, and lack of ease of use. If something good appears, then it will be embraced. The problem is, what we have now is not good.

This earlier screen at least looks like someone managed start moving in the right direction instead of being bedazzled by ability to move noodles about. Although a lot of problems still apply (like blueprints still being undiffable binary blobs which will make them immune to branch merges), the node working outside of IDE and so on.

 

There is overlap, but banking software is purely functional, whereas games have the potential to have expresion.

There is absolutely a throng of unhelpful coders who get off on having unique knowledge of the discipline.

There should be no difference between visual code and code. It should simply be a container that works in exactly the same way.

 

Or they don't simply understand intended workflows. Visual scripting isn't about replacing programming or traditional programmers or providing a similar "level of power". It's like saying "what we have now in Photoshop or Houdini UI isn't good because its inefficiency and lack of power from programmer point of view"

It's about unlocking scripting to people who wouldn't be able to implement their ideas/art otherwise. To provide easy and fast scripting for people whose primary job isn't programming. If the user is unable to perform basic actions without a programmer, his contribution is limited by the programmer's time. And the entire game functionality/quality is limited by the programmer's time.

In this case, visual scripting delivers power and ease of use to the end-user. Comparing it to traditional coding is pointless since non-programmers wouldn't ever touch it. These are different solutions for different people and problems.
There are tons of great node-based solution, not only blueprints. Also shader, particle, animation, behavior, audio graphs.

It's common to prototype mechanics and entire games in blueprints. It's much faster than any traditional programming language. And doesn't require a programmer to do this. It provides a totally different workflow where designer/artist doesn't need to write down a perfect design for mechanics or shader - which is often impossible, they don't know what exactly is needed until they do few iterations. Instead of spending days on the paper design which would be thrown away after seeing a prototype for the first time, designers iterate idea together with implementation.

After prototype #5 is working well (from a design standpoint) and we want to build a game on it, now it's time to design system and ask a programmer to provides systems, tools and even custom editors.

The effect is that non-programmers don't wait all the time for programmers to provide every single script or shader. Programmers don't spend live on coding dirty prototypes in C#/C++ or trying to read designer's mind. Programmer can focus on developing systems and tools most of the time. And then expose needed functionality to other team members any way he thinks is the best.

After that, still implementing details for given things, like scripting cosmetic events on NPC is best with visual scripting - where you got data and simple logic together. A programmer shouldn't ever be involved in implementing such high-level cosmetics. It's a waste of his time and skills.

Any data backing up this statement?
Cheating online game is possible if gameplay logic isn't validated by authorative server. It doesn't matter if you would do that in visual scripting or assembler

 

This sounds a lot like a variation of "The person disagreeing with me must be an idiot" argument.

It's been repeatedly mentioned when visual scripting is useful, and in which scenarios.
It has been also mentioned more than once that the problem is not existence of such tools, but forcing it onto programmers.

Simple actions like npcs is actually suitable for normal scripting and not visual scripting tools. A bunch of helpers for builtin editor will quickly bring this to the visual scripting levels for a non-coder and it won't take 5 years to develop and polish.

Kinda makes me wonder why people suddenly want to program game logic via virtual discrete logic chips.
Because previously typical wish was telling computer what to do in english.
---

Speaking of Photoshop, an image editor is actually a type of software that could use a node-based alternative to layers. Yet for some reason the feature is not there. Makes one wonder why.

 

Well, I never witnessed a programmer being forced to use visual scripting.* I guess that's why I partially misunderstood you.

*I tried to integrate PlayMaker into designer workflows a few years ago. They kinda like it, I hated it. PlayMaker was crap for me, from the perspective of supporting it in code. Although it's just poor implementation of visual scripting and I decided to use it, so I can blame only me.
After that, I came back to UE4 and blueprints and never looked back.

I'm not sure about Photoshop (although it has scripts). Maybe that's what people retouching photos need. Just some ML-based fixing images is that what Photoshop user needs? Dunno, I just speculate. Or simply Adobe is afraid to make any big changes. They even don't update Photoshop to make utilizing more CPU threads

Although... Substance and Houdini go into this direction. Allows artist to build their own procedures and non-destructive workflows. Instead of just "clicking through stuff" all the time. Houdini also allows to "go deeper" with VEX and C++

 

The problem is here the reality. I agree with you but i have often seen some other ideas. Visual Scripting is often sold as solution for coding, You do not need more any nerds who are typing code. You can have the same solution with VS using not so qualified and high paid people. VS saves costs. This is a "huge advantage" for deciders (who often not nerds). And when such a solution short terms works …

 

Unfortunately many peoples fall for hypes but they have to spend much more later to fix the mess created by the node-based systems.
their performance is not comparable to handwritten ones especially on bigger projects.

 

The problem of visual scripting is mostly it has been designed by people who see it as baby's first language, and therefore have those limit backed into them, they aren't considered serious, sometimes you get some sugar visual to help a bit, like making primitive type data flow colored, but they don't solve the prime problem they introduce. Worse is that data flow and command flow are not distinctly visually separated, and stuff like small expression probably need a new takes. I haven't see loop being handled properly visually yet.

What's good is that it self documented, so it remove opacity, it prevent syntax error so we can focus on logic first, it make apparent the flow of the program (graph type of visual coding), instead of hiding it through teleporting variables, allowing to isolate problematic problem easily, it's malleable. It's already the parse tree, so compiling it could be actually faster, no need for an intermediate representation, therefore we can actually use that to reduce and simplified visually like the parser use the tree to optimize code (not used in current visual coding).

IMHO we need a new paradigm of visual scripting that is thought out, probably a mix of the best of all worlds. Text need also an evolution, we have been piling tools on top of the old notepad interface to give birth to the bloated modern ide, and that lead to war of stupid like tab vs whitespace which makes the need to have those ugly indent visualizer, the less said about all those highlight putting the unnecessary information on the forefront. If expression where itemized, as they are done by the ide anyway since it recognize syntax error, why not bypass the ";" that trip everyone by making it automatique (it's a tag for the compiler, it mean nothing for human), it's time to redo that from the ground up.


on roughly the topic:

More here https://garry.tv/unity-2020


edit:
choice quote

 

This is so misinformed on so many levels. I think its kind of getting in circles now. Its really amusing that have barely used the system judge it. I am not the best at coding because i like doing more art and blueprint allow me to prototype my game to a very far stage so far I could ve never done with coding in c# lets say. I cant think of anything i couldnt do with BPs. The workflow is different but not necessarily worse. Yes its not everyones cup of tea but its not simple by all means. I see more people releasing games as solos with visual scripting than hardcore coder bros here who have been coding for years but never actually released anything, while on the other hand i see artists releasing fully playable game with great performance (blueprint nativization makes it just ~10% worse than c++ code). Its also funny to think that you think you have put more thought into these systems than epic games engineers who carefully designed it with alot of factors in Mind but hey „iT BaBySTep and LiMiTeD“

 

BRO learn to read

 

It doesn't matter about the reality. What matters is that C++ is a high-end enterprise-grade programming language for which you will be competing against high-end enterprises (billion-dollar corporations) for talent.

Say you spend $800 for two Unity Plus seats, vs $0 for Unreal, but $10,000 more for a C++ dev vs a C# dev. Which engine is cheaper? In many cities around the world, it is not even a matter of cost - Unreal Developers simply don't exist.

I'd love for this to change, and for programming in Unreal to be as popular as Unity, but that is not currently the situation.

 

I might be currently enclined towards UE due to the following:
I ended up here while dealing with another preview product. (And yes I try to avoid them as much as possible).
So take everything with a grain of salt.

In the first place, these days business decision often drives the choice of engine,
unless special features are required. And UE's new licensing is a great improvement.
Don`t pay anything till you get a million is great, for those who release free products and those who start out with less than 100bucks in their pocket. Or any who is sure he will not collect a million from the game. And all those free extras. Though the Unity deal is not bad either it has its own benefits. Unity has advantages business-wise in finding devs easier.

On UE5 related, there is a rumor that Epic is trying to improve demo to run 60fps on a consoles 2k screen instead of 30fps (one limiter was actually V-Sync).
And it runs currently on 970Evo Plus and RTX 2080 around 40fps.
Source: https://www.pcgamer.com/unreal-engine-5-tech-demo-pc-performance/

UE BP is targeted more for Artists and Designers. There is a reason why the first step in Visual Programming is started with usually graphics shaders simplification. That's why Shader Graph is the first step in Unity.

I agree 2+ years in preview mode is too much (though it is still better than buggy prod.). I prefer UE common 1-year cycle going from beta -> release.

DOTS is a neat idea, I hope it matures well. But as also Game Development lecturer for also Artists, Designers, and some Programmers, should I start teaching with DOTS or stick to MonoBehaviour and ScriptableObjects?
Will, it split community?

I dream of the time when Unity becomes stable enough. Where I don`t have to explain my students` workarounds due using 1-2 preview packages.

UE is not perfect either.
a) It needs power when you are teaching UE4 on integrated graphics PCs, teaching optimizations too early becomes a requirement. Luckily we are getting classroom upgrade to a similar level of power of new consoles.
b) It's C++ requires modernization and cleanup. I can`t teach easily the current version of C++. But I can dream. This area is highly dependent on the platforms it needs to support but maybe with UE5 at least C++17 macros would be replaced with attributes similar to Unity.
Or if I really dream hard:
In addition, ISO C++ also works on gaming focus in SG14 group: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2057r0.pdf
So many juicy parts could be upgraded there (all these will benefit Unity also but Unreal gets the double benefit as not only engine developers will have access to it):

 

A person calling himself "programmer" would learn every language. C++ isn't any high-end esoteric enterprise-grade language. I learned it after custom scripting languages, blueprints, C#. I still don't consider myself an amazing low-level programmer. My math sucks, I'm unable of grasping low-level abstractions needed to program operating systems or work on the core of renderer.
However, I handle all gameplay logic and writing editor tools just fine

Payrolls depend on the country and local competition. In my country, Java junior programmer with no experience working for a bank earns more than half of the game developers and junior gamedev programmers.

Any kind of programmer coming to gamedev here accepts a lower salary in exchange for a more interesting job.

 

No "no true scotsman"

 

Care to elaborate, please? I'm not sure why you would apply this logical fallacy here?
(fallacy I didn't know yet by name, so thanks for that)

 

Modules in C++ 20 should (finally) remove one of the biggest annoyances and archaic features of C++: headers. IMO that's the biggest culture shock for programmers coming from C# (and many other languages). Should increase compilation speeds too, as parsing headers and PCHs is often the biggest time hog.

Also, I don't get the "high-end language" thing. Nowadays the gaming industry is probably one of the major enclaves of C++, and it's the reason why decades-long pushes to modernize the language are finally gaining speed. If you know C# and Java you can easily find more and higher paying positions outside the gaming industry.

 

How good are you at rust? How about golang? How's your COBOL? Think your Objective-J is up to snuff? I hope you know XBase++

Your statement is on its face ridiculous. There are thousands of programming languages and the vast majority of programmers are proficient in maybe two because the skills are transferable but they still won't know every language. They won't even know more than a few of the biggest ones.

 

A programmer wouldn't learn every language, as there are too many of them.

In addition to those mentioned by Murgilod, there's, for example, Prolog, Common Lisp, Haskell, OCaml, Erlang, D, Ruby, Perl, Clojure and many others. not to mention oldies like Ada, Fortran, Pascal, Basic, which often had dialects.

As a programmer you wouldn't learn everything, but pick those you deem useful, and look out for new concepts. You'll be able to get up to speed faster with new languages, for example, one imperative language will have semblance of the other, but as they say the devil is in the details.

 

Wow, guys, let's not go absurd with every statement.
Where did I suggest that a programmer needs to learn every single language on the planet Earth?

Or is it my English just that bad? Does the phrase "would learn every language" don't clearly mean "would be able to learn every other language if needed"?
If "C# programmer" needs to learn C++ because he's switching engines or whatever reason, he would be able to learn basics by using language in a matter of weeks or months, right? Not every single detail of the language, just learning new things over the years, sure.
Especially while we're comparing Unity's C# and Unreal C++ (which provides things like reflection and garbage collection already) and both engines embraces OOP for gameplay, not some hipster programming paradigm.

Artists learn and use multiple tools usually. Obviously starting from the single one, and jumping between tools and workflows if needed. Why this is so weird to suggest that the programmer would learn a new language from time to time?

 

https://garry.tv/unity-2020

Creator of RUST has joined the discussion with his own blog and I have to agree with him. For the last few years Unity is trying all the time to create from their engine something more profesionall. Meanwhile what they should have done is to make developers life easier.

What Unity has actually implemented into their engine to make ours life easier? To allow to create games faster?

 

Right here:

 

Haha, OK, so it's just my lingual mistake. Sorry for confusion

 

"Every language" means exactly that. Every language in existence.

 

After seeing people trying to outdo the ue5 demo in dreams, I'm starting to wonder if they are skipping the GIM for SDF baking altogether, as it would simplified thing a lot, those dreams attempts are getting really intricate visually ...

 

Yeah, cause people working in a industry where they are perpetually forced to throw away stacks of knowledge and experience every couple years and learn new sht (often in their own spare time) are totally in the position to gate keep? lol

Don't go blaming us because visual scripting thus far is a worse solution than just programming in an IDE....
We'd love for our jobs to become easier.
Programming is hard. We know that more than you do.

 

Also the obvious point is that you need a "gate keeping neckbeard" to make a visual scripting anyway before you can use it.

 

What's even worse:
https://twitter.com/BooijJelle/status/1263765745206349825

 

I should point out BP is text-based behind the scenes:
For example, simplified BeginPlay() event in class for BP looks like:

Begin Object Class=/Script/BlueprintGraph.K2Node_Event Name="K2Node_Event_0"

EventReference=(MemberParent=Class'"/Script/Engine.Actor"',MemberName="ReceiveBeginPlay")
NodePosX=-576
NodePosY=-752​

End Object

 

I'm convinced they gave up GIM in fact, also the engine is confirmed to run on switch.

https://www.researchgate.net/public...Distance_Field_Calculation_for_Adaptive_Grids

 

Also in 2018 in unity:
https://twitter.com/robertcupisz/status/1058079006644412418

 

IMHO unity gooble up a bunch of hi skill nerd who too deep in what they like with the promise they could do more of what they like without concern about anything else.

I'm actually trying to parse the source of the heretic demo so called tools, and it's just that, nerdgasm exclusively without regard of any sorts of usability, which mean it's basically useless unless you have such a domesticated nerd in your team. Which the tragedy of the shader graph too, and then urp and hdrp. That is they make decision for you because that's the best, why would you want it any other way? Clueless nerdiness is a personal traits I have, so I understand.

Unreal have domistacted their nerd with the reality of having to make and maintain game for profit and have to deal with messy gamer and customer.

 

Yes, programming is hard but people have this tendency to mistakenly believe it's because of the code that most programmers write but nothing could be further from the truth. Programming is hard because you need to thoroughly understand the problem you need to solve and be able to break it down into very small steps for the computer.

Once that's been accomplished the easy phase takes over where you start writing code or drawing graphs.