Why C++ for Unreal 4?

Development Programming & Scripting C++
559

Easy there guys, I didn’t want to start the war :P.

Something that annoys me in Unity is how you can’t use a more ‘general’ architecture, I’ve discussed that in depth on the Unity forums and it seems there’s no good way indeed, for example, if you were doing a game from scratch, you could modify the ‘higher-level’ classes, in Unity you don’t have that liberty and you’re limited to the ‘scripting’ layer, that’s why people inevitably end up with lots of statics: for example, if you want a list to keep track of some types of gameobjects, you could use layers for that but they kinda suck. The fact is, in the end the architecture of a complex game system ends up somewhat ugly, does UE4 have some kind of limitation like that? I’m not talking about modifying the engine source, but what the engine provides you by default.

560

[=;409989]
Easy there guys, I didn’t want to start the war :P.

Something that annoys me in Unity is how you can’t use a more ‘general’ architecture, I’ve discussed that in depth on the Unity forums and it seems there’s no good way indeed, for example, if you were doing a game from scratch, you could modify the ‘higher-level’ classes, in Unity you don’t have that liberty and you’re limited to the ‘scripting’ layer, that’s why people inevitably end up with lots of statics: for example, if you want a list to keep track of some types of gameobjects, you could use layers for that but they kinda suck.

[/]

o_O

Unity’s architecture is as general and as high level as it gets. Everything is a GameObject, and every functionality is a Component on that object. Can’t get much simpler than that. People that that end up with lots of statics really should look into ScriptableObject class and the way unity serializes object references.

Also, for majority of games you don’t NEED to modify the architecture.

[=;409989]

The fact is, in the end the architecture of a complex game system ends up somewhat ugly, does UE4 have some kind of limitation like that? I’m not talking about modifying the engine source, but what the engine provides you by default.
[/]

Hah. XD Unity’s idea that “everything is an object” is actually significantly easier to get started with. UE4 has steeper learning curve.

You should really start using UE4 engine instead of discussing it and C++ on the forums. Get your hands dirty and see how it works yourself.

561

[=NegInfinity;410033]
Unity’s architecture is as general and as high level as it gets. Everything is a GameObject, and every functionality is a Component on that object. Can’t get much simpler than that. People that that end up with lots of statics really should look into ScriptableObject class and the way unity serializes object references.
[/]

I wasn’t talking about that kind of ‘high-level’, I didn’t have a better word… for example, the ‘main’ class would be the ‘highest level’ in a program, the scripts you create, at least in an engine like Unity, they are the ‘lowest level logic’, it’s like in class composition, people generally call the child classes ‘lower-level’, I suck terribly at programming terminology.

Yeah, I’m going to get my hands dirty.

562

I was under the impression from most discussions of Unity vs Unreal that Unity is easier to get something going but harder to actually finish a game in, especially in team context. My Unity experience is severely lacking though, so I can’t confirm or deny that.

563

No, I don’t think so… it’s always hard to finish a game, specially these days with all these ‘rad’ tools when you can easily start a new one… in the past we used to plan way more, nowadays it’s so easy that you just jump right in and left it unfinished after a while :P.

565

[=NegInfinity;410259]
Your impression is very likely to be correct. It is very easy to get started with the unity, but if you hit an issue, you’re screwed. Mostly because you’ll be at mercy of their patching team who also can break previously working features you were using. In UE4 you have source code and that can help greatly.

UE4 has very solid code base, although the way engine does some things can be awkward.

So, in the end, having source code access saves the day.
[/]

Obviously, in the case of an engine bug (not very likely though), then yeah, you’re screwed, but also it’s not who have the knowledge to fix bugs on the engine itself, so I wouldn’t consider that a ‘con’ for Unity.

566

[=;410261]
Obviously, in the case of an engine bug (not very likely though), then yeah, you’re screwed, but also it’s not who have the knowledge to fix bugs on the engine itself, so I wouldn’t consider that a ‘con’ for Unity.
[/]

In case of Unity you have 98% chance of hitting at least one game engine bug during game development and 80% chance of that bug not being fixed, and 30% chance of that bug being game breaking. Just check their general support forum.

We hit about dozen issues in our project, haven’t heard back from unity team on ANY submitted bug report, and that includes problems within primary engine systems like Mecanim and global illumination.

Having source code is the main reason for using unreal engine 4. Another reason is that that source code is very solid and is written by a team that knows what they’re doing.

It doesn’t matter if somebody doesn’t have the skill to use source code. Because with source code access you always have non-zero chance of resolving your issue, no matter what. Without source code access, half of the time your chance of dealing with problem you encountered is zero. Missing documentation, engine gltich, silence on the forum, nobody knows why something works this particular way, etc –> in any of those situations (which are commone) no source code means you’re screwed and won’t be able to deal with that.

567

I encountered bugs when I was using Unity, and all you can do when you find such a bug is find hacks to prevent it from occuring, my bug was that my terrains didn’t have textures when I generated them at runtime, the solution was to add a dummy terrain with all the textures loaded to force Unity to load them. As an engine programmer in real life I couldn’t take that. I moved to UE4 a year later, encountered a bug where BSP texture tools didn’t work at all, I downloaded UE’s sources found the bug in a couple of hours, patched it and created a pull request. That’s why I will never go back to Unity, because I reported a severe bug 3 years ago, a lot of people did as well and if I take a look at the ticket it’s still not resolved.

Reading comments such as “I always wonder how people with absolutely no affinity for visual stuff can even end up developing games.” is terribly sad, as if games were only visual.
Let me give you an answer : Blueprints are NOT as powerful as C++, I also don’t like having 15 boxes and 30 lines for something that would take me 2 lines in C++, I am sorry but blueprints become unreadable very fast and sometimes for very simple logic. Also an experienced Blueprint developer will never develop as quickly as an experienced C++ developer, I personally don’t see any benefit of using blueprints (with the exception of data blueprints).

568

Games are a visual medium, that’s all I meant by it. Can you tell me about a game that’s not visual? I mean you just said yourself you fixed a bug with terrain texture. Is a texture not visual by nature? This has nothing to do with blueprints being less powerful than C++, that was never the point. The point was that I have a hard time understanding that anyone working in games would not grasp blueprints because their too visual. You can dislike them and all, no problem, but to claim you wouldn’t understand them because they’re too visual while at the same time making objects fly around in a 3d space and generally dealing with a whole lot of visual/spatial stuff in games is just nonsensical.

It was never a blueprints vs C++ argument. I use both where applicable and that’s how it was meant anyway. The two work together very nicely. The fact I can create new nodes for example, even beyond just exposing C++ functions but making completely customized nodes with custom pins etc. for in the team is very empowering. Am I going to do simple game scripting like opening a door or starting up some particle system in C++? Of course not, but if you do then more power to you.

569

[=Gigantoad;410515]
Games are a visual medium, that’s all I meant by it. Can you tell me about a game that’s not visual?
[/]

Zork and the entire interactive fiction genre. There are also roguelikes which typically use ascii art, etc.

[=Gigantoad;410515]

I mean you just said yourself you fixed a bug with terrain texture. Is a texture not visual by nature?
[/]

That’s sophistry. The bug is algorithm-related/programming-related in nature and merely manifests itself in visual way.

[=Gigantoad;410515]

The point was that I have a hard time understanding that anyone working in games would not grasp blueprints because their too visual. You can dislike them and all, no problem, but to claim you wouldn’t understand them because they’re too visual while at the same time making objects fly around in a 3d space and generally dealing with a whole lot of visual/spatial stuff in games is just nonsensical.

[/]

Practical example: you’re required to describe a painting. You’ve never seen that painting before, it is 3x4 meters big, and you’re only allowed to examine the painting using a microscope which is permanently glued to your eye whlie your other eye is blindfolded and you’re wearing straightjacket. That’s what working with blueprints feels like. After 10 years of coding it feels incredibly inefficient, slow, big, clunky and gimimcky.

People that don’t like blueprints typically can do same thing faster and with less effort in text editor given any scripting language and they obviously start wondering why would anyone want inferior workflow. If blueprints work for you, great, but I already hate them after working with animation statemachines. It is a great way to get carpal tunnel syndrome (click-click-click-click-click), and while statemachines have their uses, I’d prefer to have “function” node in blueprints where I can type in the code.

Here’s example:

570

Ah yes, I knew text adventures would come up :smiley: Ok, can we agree that the vast majority of games are visual? Actually I could make an argument why even text adventures are kinda visual, your just painting images with words instead of graphics.

I understand all the arguments against blueprints and I acknowledged that they can get out of hand quickly (don’t have to, but they can). But again, the matter of contention wasn’t how good or bad they are, but just whether any game developer actually flat out doesn’t understand them, which I don’t believe can happen.

As for spaghetti blueprints: of course you can always use horrible examples to drive a point home, but I could do the same for code. As a developer I’m sure you’ve had your fair share of looking at bad, messy, horrible spaghetti code. So tell me, is that any easier to untangle than a mess of nodes?

I wouldn’t recommend completely avoiding blueprints even if you’re doing most stuff in C++, and Epic agrees with me by the way, that’s very much how they work internally. If you’re working with a team, most likely the question whether to use C++ only wouldn’t even come up because then no level designer or what have you could do any scripting at all. Your job as a developer will be to use the tools in a way that will enable and empower your team to work more productively, and if you don’t know the first thing about blueprints or flat out avoid them, you’re doing it wrong.

But you’re free to do whatever you want :slight_smile:

571

[=Gigantoad;410560]
Ah yes, I knew text adventures would come up :smiley: Ok, can we agree that the vast majority of games are visual? Actually I could make an argument why even text adventures are kinda visual, your just painting images with words instead of graphics.

[/]

The whole point of games being visual or non-visual medium is irrelevant. The discussion was about programming side of things.

[=Gigantoad;410560]

but just whether any game developer actually flat out doesn’t understand them, which I don’t believe can happen.

[/]

Ah, semantic argument.
It doesn’t matter. Most people are familiar with flowcharts, some are not and those won’t get blueprints.
What’s important is to have the most powerful tool, not the one “everybody will understand”.

[=Gigantoad;410560]

As for spaghetti blueprints: of course you can always use horrible examples to drive a point home, but I could do the same for code.
[/]

Great. Would be nice to have some decent blueprint designs for large scale systems. Or animation state machines with multiple movement modes and large number of attacks/actions.

[=Gigantoad;410560]

As a developer I’m sure you’ve had your fair share of looking at bad, messy, horrible spaghetti code. So tell me, is that any easier to untangle than a mess of nodes?

[/]

I’d say yes. I had nice experience of working on code that was first written for msdos, then ported to os/2, then ported to windows, then ported to have direct3d support (by me). Also it had 3 megabytes of mixed .c/.cpp code, included its own custom gui library, regualrly passed parameters to functions via global variables was multithreaded (15 threads, I think), but had almost no thread safety mechanisms because original cpu had single core and truly parallel execution couldn’t happen. Oh, and it was networked too.

There are standard practices for cleaning that kind of mess, isolating issues and keeping code working. Those won’t translate into blueprints, not to mention that software of this kind of size won’t be possible in blueprints to begin with.

[=Gigantoad;410560]

I wouldn’t recommend completely avoiding blueprints even if you’re doing most stuff in C++, and Epic agrees with me by the way, that’s very much how they work internally.

[/]

You can’t completely avoid blueprints even if you want to, because transition rules use them.
The reason why the even work is because most of the programming tasks in games are in “toy problem” category.
However, the tool is completely inferior to proper programming language, and arguing against that is silly.

572

I’d say you’ve never seen real spaghetti code. I once had to clean up some that featured hardcoded values in many places instead of using variables. It’s even better when some of those hardcoded values belong to otherwise unrelated functionality. Even just a simple thing like that can quickly become horribly annoying to clean up. Let’s not even talk about how much of a lesson in futility it is to refactor bad code that someone else wrote. Whole books have been written about the subject, and you want to claim in all honesty that it’s harder to clean up a mess of blueprints? Dragging nodes around, trying to separate them and trying to not have crossed wires? Of course that’s easier, wires will keep connected to the same thing no matter where you drag them. It’s literally just an annoying puzzle game vs. the serious engineering effort that cleaning up code is.

But arguing about any of this is sill so I’ll stop here. I don’t even know why I’m defending blueprints in a thread called “Why C++ for Unreal”. And just for the record, I advocate using both, not one or the other.

573

This weekend I’m gonna get my hands dirty.

Also, I again disagree on the ‘visual’ discussion, I still think that ‘visuals’ have nothing to do with ‘structure’; you can represent a structure visually, or in plain words, or by any other mean. That doesn’t change the fact that ‘visual’, imho, means something that is communicated through vision.

I strongly disagree that Unity has bugs that prevent people from finishing their stuff. Of course it has bugs, many of them, but there’s always a workaround or some alternative. I mean, that surely shouldn’t be taken into account when choosing Unity or not. Chances are you won’t hit a bad bug that will prevent you from finishing your game.

I’m not telling that Unity is good or something, but please let’s bash it for the real reason why it sucks, and game-breaking bugs aren’t one of the reasons for >99% of the cases.

574

[=NegInfinity;410444]
In case of Unity you have 98% chance of hitting at least one game engine bug during game development and 80% chance of that bug not being fixed, and 30% chance of that bug being game breaking.
[/]

That has always happened with all the engines or SDK I’ve worked (video game consoles, controllers, etc…).
In any project you always have to find workarounds. Having the UE source is nice, although you can also pay for it in Unity. Anyway that doesn’t mean you have the resources (time, knowledge) to fix it for yourself…

Both C++ and C# has their place and the one who chooses to ignore one is only hurting himself. This “war” against C# reminds me of when asm/c programmers were against C++ because it was slower to write code, more convoluted… in the end it was clear that when the code grows in complexity and size, we need better ways of dealing with it.

575

[=SaffronCR;414499]

Both C++ and C# has their place and the one who chooses to ignore one is only hurting himself.

[/]

I could ask the same kind of question regarding every single programming language in existence. Every language has their place and you WILL ignore most of them. By your logic you’ll be hurting yourself no matter what you do.

I’ve come to conclusion that choice of the language depends on programmer’s mindset. And C# is not very compatible with mine. That’s all there is to it.

[=SaffronCR;414499]

in the end it was clear that when the code grows in complexity and size, we need better ways of dealing with it.
[/]

And that is exactly why I prefer C++. It provides more tools for dealing with both size and complexity compared to C#.

576

[=NegInfinity;414516]
I could ask the same kind of question regarding every single programming language in existence. Every language has their place and you WILL ignore most of them. By your logic you’ll be hurting yourself no matter what you do.

I’ve come to conclusion that choice of the language depends on programmer’s mindset. And C# is not very compatible with mine. That’s all there is to it.

[/]

That’s your view, mine is that you can actually learn most languages and use it to your advantage. For example when I started with C/C++ programming I did everything with it, with a C mindset. Then I learned html, java, C#, SQL… and nowadays I select the most useful for each task. For example I programmed a multiplayer online game which uses SQL for handling matches and user data (a single SQL query beats anything you can do in C++, and there’s a reason LINQ was created and is widely used), C# is a lot faster of writing than C++ in most situations and that’s why it’s chosen for writing tools nowadays. And when you need to work close to the hardware and optimize, C/C++ or even asm is your only choice.

Obviously if you feel confident that C++ can handle all your needs, good for you. In my case I approach every new technology with an open mind and try to stay always updated, because until you don’t really know how to do things in a new way you can’t really tell if it that new thing is really useful, or **when **it’s useful. For example, approaching FPGA programming with a C++ programmers mind is going to make you hate it, when FPGA is a really powerful tool in electronics.

577

[=SaffronCR;414571]
you can actually learn most languages
[/]

You can only get “acquainted” with them so you can write stuff in them at very mediocre level. Not “learn”.

[=SaffronCR;414571]
Then I learned html, java, C#, SQL… and nowadays I select the most useful for each task.
[/]

You put html and sql in the same category as java and C#.
Also there’s no mention of lisp, prolog, haskell, and other languages.
I find that disappointing.

[=SaffronCR;414571]

In my case I approach every new technology with an open mind

[/]

Exactly what I tried with C#.

[=SaffronCR;414571]

feel confident that C++ can handle all your needs

[/]

I never said that. The “right tool for the job” principle applies. In my case C# fails to provide any significant advantage over C++ in the area I work with. That’s all there is to it.

578

[]
You can only get “acquainted” with them so you can write stuff in them at very mediocre level. Not “learn”.
[/]

That depends on the time and effort you put into it.

[]
I never said that. The “right tool for the job” principle applies.
[/]

Then there’s not much to add.

579

[=NegInfinity;414516]

I’ve come to conclusion that choice of the language depends on programmer’s mindset. And C# is not very compatible with mine. That’s all there is to it.

[/]

The choice of language has nothing to do with the programmers mindset. A proper choice of language is the one which fulfills all of your projects needs, which has nothing to do with the programmer at all.

Also, you claiming C# isn’t compatible with your brain is just a blatant excuse for laziness. Sorry, but it is. You have a human brain. It can understand far more than you think it can. Stop limiting yourself by be so negative…

[=NegInfinity;414516]

And that is exactly why I prefer C++. It provides more tools for dealing with both size and complexity compared to C#.

[/]

This is a subjective statement. Both languages have plenty of tools for dealing with both size and complexity. In fact in my experience, out of the box, C# has more tools for this. Also, C++ is a terrible language for implementing very very large projects.

Choosing one language for everything is just a terrible and stupid idea. Choose what works best, not for you, not for the language, but for your project’s needs.

Again, C# isn’t a language you all can just compare to C++ directly really… They are completely different beasts. C# is and was never meant to compete in who is better with C++. You guys are discussing which is better, Language A meant for tasks G, and language B meant for tasks J. If you honestly are choosing between C++ and C# with your project, I REALLY think you need to reassess what you’re trying to do with the project.