Why C++ for Unreal 4?

No argument is better, wrong, or right RichG. is sort of stuck in their ways. You just have to find a good fit for yourself. I am so excited for you! I got my first start (modding) in Unreal Tournament with UnrealScript & C++ (we could use DLLs and Epic gave some limited source for us to link against).

Hm, not too sure where to start. Try Blueprints first Rich. Slowly work your way into C++ land as needed.

Start with Ivor Horton’s Beginning C++ perhaps? I really liked that book when I get started. You know, C++ can be quite forgiving. I wasn’t very good when I started out. I had a lot of memory leaks. But when I crashed it was easy to track down. Of course, I was working in my own codebase working on tools (not a full blown AAA game Engine)

[=RichGelles;18824]
These kind of threads are always interesting as they grow along. To me it seems we have the c++ folks who are probably all pretty happy they can get in there and tinker with their fav language. Then there is all the folks who use and know C#, javascript , python ,lua etc and are not so happy with having to learn or relearn c++ and many may even have come over from Unity where they were happy coders and now have to start a new. So that group is a little disappointed and maybe a little frustrated having to learn something new. Then there are the rest of the folks —basically a blank slate who do not know know much of anything …and are off to learn c++ or at least that is their plan for now.

                               Now I am certainly more in the last group so I have no real zeal for c++ or any other language. Since I have really been blown away by the possibilities of UE4 and the entire package --I plan along with learning blueprints plan on starting on learing c++ .  Since its all new anyhow ---- to me its not such a bad thing what Epic did here. 

                               Its seems to me alot of this conversation is really just where folks find themselves as to how they care or don't about c++ and UE4. And maybe if I was not such a noob I would know which arguements were better --but for now I am on the c++ side. Smiles. 

                                And if anyone wants to chime in with resources ie books, tutorials etc worth checking out to learning c++ ---- please share them. 

Rich
[/]

[=RichGelles;18824]
These kind of threads are always interesting as they grow along. To me it seems we have the c++ folks who are probably all pretty happy they can get in there and tinker with their fav language. Then there is all the folks who use and know C#, javascript , python ,lua etc and are not so happy with having to learn or relearn c++ and many may even have come over from Unity where they were happy coders and now have to start a new. So that group is a little disappointed and maybe a little frustrated having to learn something new. Then there are the rest of the folks —basically a blank slate who do not know know much of anything …and are off to learn c++ or at least that is their plan for now.

                               Now I am certainly more in the last group so I have no real zeal for c++ or any other language. Since I have really been blown away by the possibilities of UE4 and the entire package --I plan along with learning blueprints plan on starting on learing c++ .  Since its all new anyhow ---- to me its not such a bad thing what Epic did here. 

                               Its seems to me alot of this conversation is really just where folks find themselves as to how they care or don't about c++ and UE4. And maybe if I was not such a noob I would know which arguements were better --but for now I am on the c++ side. Smiles. 

                                And if anyone wants to chime in with resources ie books, tutorials etc worth checking out to learning c++ ---- please share them. 

Rich
[/]

I think your plan to learn Blueprints and C++ as you go is a great idea. In particular Blueprints are something you should focus on given your background. There’s a good reason for that actually:

Getting into blueprints will give you a good foundation is some of the fundamental components of the engine: actors, player controllers, materials etc. Blueprint is actually a visual programming language. It is probably one of the best ways to learn some of the fundamentals of programming and it will give you a good sense of the kinds of library functions that you will have access to in C++ as you get more confident with that.

Once you’ve got enough Blueprint in your head to have an idea of some of the types of Blueprint nodes that exist and how you build some simple graphs I’d start with a beginning C++ book. I learned C++ so long ago that I can’t remember what sources I used but I’d recommend you probably get a couple different books OR even just use the internet, there may be quite a few resources to draw on without cracking open a book.

Using UE4 to learn C++ is actually really cool. I should start a thread about this. Starting a C++ project in Unreal will take care of all the setup and building configuration you need to do. It’s a major source of headache that you can avoid entirely and it will just allow you to focus on writing code.

You should try to replicate some simple of the simpler Blueprint graphs in C++ as a first goal. There are some good C++ tutorials on the wiki. A good project actually would be for someone to show a Blueprint example and then a C++ example that does the equivalent thing.

I’m also learning the engine like else on here, but I’ll keep this in mind and I might be able to produce some tutorials like that.

In the meantime feel free to PM me or post here if you have any problems or questions I’d be glad to help.

[=Serapth;18644]
There is no one ring, er… language to rule them all.
[/]

I think I have to advocate myself a little. For the record.

First, what I mention the ultimate tool is limited to product code. As I clarified in another reply, I don’t care whatever used in non-product code. It’s OK if they produce result.

And I have clear reasons of preference to C++. I won’t repeat it because I believe here knows pros and cons of C++. I have investigated most major languages, and the pros and cons of C++ are the best deal to me even in productivity perspective.

For the using of DSL in product code, I apology. I haven’t worked in AAA , so I don’t know what they need and how they’re running. So my claim on large scale team would hardly be correct. But in general, I wouldn’t prefer using extra DSL if the problem is easily solvable with primary language.

Anyway I am getting think it could make sense if it is incredible hard to hire properly skilled C++ programmers. (well, I haven’t tried to hire some C++ programmers, so far) Maybe you would like to use even less-skilled programmers by providing proper sandbox…

[=RichGelles;18824]
These kind of threads are always interesting as they grow along. To me it seems we have the c++ folks who are probably all pretty happy they can get in there and tinker with their fav language. Then there is all the folks who use and know C#, javascript , python ,lua etc and are not so happy with having to learn or relearn c++ and many may even have come over from Unity where they were happy coders and now have to start a new.
[/]

There is an entire demographic you are missing out here.

Many of the people that oppose C++ as a gameplay language know C++ already, they just find it ill suited for the task. It’s not about not wanting to learn a new language, it’s about programmer productivity. Many people in this thread act like scripting languages were only used by “those too stupid to know C++”. This is very far from the truth. There is no sense spending the extra effort C++ requires if you don’t need the extra benefits it provides. For a lot, perhaps the vast majority, of a game’s code, performance really isnt all that important. We all wait at the same speed, regardless to the language you choose. To say nothing of the fact that many of the games people will be creating wont even come close to taxing the machine unless they make a pretty serious mistake.

[=drawtree;19036]

Anyway I am getting think it could make sense if it is incredible hard to hire properly skilled C++ programmers. (well, I haven’t tried to hire some C++ programmers, so far) Maybe you would like to use even less-skilled programmers by providing proper sandbox…
[/]

… this is a perfect example. People use scripting languages for many reasons that have nothing to do with the programmer’s talent level. Hell, many single developer C++ based games still expose a scripting language. Just a few reasons:

Programmer productivity
Security/sandboxing
Modding/extensibility by end user
Data storage (Especially LUA/)
Easy Tooling
Optimize link/build cycle
(Logical) Separation of responsibility

and yes
Ease of Use.

I’ll be glad once Epic Games improves the workflow a little more. Right now, when we add variables to a Class we have to close down the editor and restart. This is lost productivity. My guess over there they are usuing SSD drives which has become pretty standard in the industry. I guess I will get an SSD at home.

For now though I am trying to stick to only defining core stubs in C++ and extend the gameplay in blueprints.

Blueprints really are quite wonderful. I suspect I will slowly become much more active over there (in the Blueprint forum)

It’s just so easy and intuitive.

[=;19126]
I’ll be glad once Epic Games improves the workflow a little more. Right now, when we add variables to a Class we have to close down the editor and restart. This is lost productivity. My guess over there they are usuing SSD drives which has become pretty standard in the industry. I guess I will get an SSD at home.

For now though I am trying to stick to only defining core stubs in C++ and extend the gameplay in blueprints.

Blueprints really are quite wonderful. I suspect I will slowly become much more active over there (in the Blueprint forum)

It’s just so easy and intuitive.
[/]

You don’t have to close the editor in order to compile your C++ game code. Just use the “Compile”-button in the editor’s toolbar to compile your code. That’ll work just fine and you don’t have to close the editor at all.

[=;19126]
I’ll be glad once Epic Games improves the workflow a little more. Right now, when we add variables to a Class we have to close down the editor and restart. This is lost productivity. My guess over there they are usuing SSD drives which has become pretty standard in the industry. I guess I will get an SSD at home.

For now though I am trying to stick to only defining core stubs in C++ and extend the gameplay in blueprints.

Blueprints really are quite wonderful. I suspect I will slowly become much more active over there (in the Blueprint forum)

It’s just so easy and intuitive.
[/]

Out of curiosity, what kind of load times are you talking about here? With a SSD and 8GB of RAM ( probably the two most determining factors for load time ) on Win8.1, it takes about 9 seconds to load the Strategy demo, then another 3 or so seconds to perform in editor actions. It’s annoying, but certainly no major loss of productivity. What time frame are you seeing to load a level without a SSD?

What’s actually killing my Unreal usage is CPU usage. The Unreal Editor is seemingly designed to max out one core. On a desktop this is no big deal, but I do the majority of my work while out and about. If I am not near a plug, that simply means no Unreal work for me. On my primary laptop, I am lucky to get an hour and a half on battery. On my Macbook Air, I get a whopping 31 minutes from full battery to dead! For comparison, I could run Unity on that machine for about 5 hours on battery, and about 4 on my PC machine.

Fortunately Unreal have acknowledged the issue and are hopefully working to fix it.

[=ShawnBaxe;19148]
You don’t have to close the editor in order to compile your C++ game code. Just use the “Compile”-button in the editor’s toolbar to compile your code. That’ll work just fine and you don’t have to close the editor at all.
[/]

Depends, if you add a class or change it’s signature, you have to restart the editor. If you simply change code, you do not.

[=ShawnBaxe;19148]
You don’t have to close the editor in order to compile your C++ game code. Just use the “Compile”-button in the editor’s toolbar to compile your code. That’ll work just fine and you don’t have to close the editor at all.
[/]

There are cases where you have to close the editor for sure. Like adding a new Class

[=Serapth;19149]
Out of curiosity, what kind of load times are you talking about here? With a SSD and 8GB of RAM ( probably the two most determining factors for load time ) on Win8.1, it takes about 9 seconds to load the Strategy demo, then another 3 or so seconds to perform in editor actions. It’s annoying, but certainly no major loss of productivity. What time frame are you seeing to load a level without a SSD?

What’s actually killing my Unreal usage is CPU usage. The Unreal Editor is seemingly designed to max out one core. On a desktop this is no big deal, but I do the majority of my work while out and about. If I am not near a plug, that simply means no Unreal work for me. On my primary laptop, I am lucky to get an hour and a half on battery. On my Macbook Air, I get a whopping 31 minutes from full battery to dead! For comparison, I could run Unity on that machine for about 5 hours on battery, and about 4 on my PC machine.

Fortunately Unreal have acknowledged the issue and are hopefully working to fix it.
[/]

Yeah UnrealEd sends my fan into overdrive. I noticed a friend of mine doesn’t have this problem because he’s water cooled :slight_smile:

Let’s see, sometimes it appears to take quite awhile for this Editor to startup if I don’t give it a default project. I’m not home right now so I don’t have the numbers. Sometimes it can take 2 mins or so. But if I’m on a roll then it might only take 20-30 secs.

I’m pretty thrilled at how nice Blueprint is though. Will probably only do the bare minimum in C++ and do everything possible in Blueprint.

[=Serapth;19109]
… this is a perfect example. People use scripting languages for many reasons that have nothing to do with the programmer’s talent level. Hell, many single developer C++ based games still expose a scripting language. Just a few reasons:

Programmer productivity
Security/sandboxing
Modding/extensibility by end user
Data storage (Especially LUA/)
Easy Tooling
Optimize link/build cycle
(Logical) Separation of responsibility

and yes
Ease of Use.
[/]

I agree 100% with this. I dropped out of the industry to go indie and wrote an engine in C++ and use Lua as a scripting language. You almost couldn’t find two languages that are more opposite. Lua is duck typed and that leads to a lot of potential issues but for a small developer with only 1 or 2 people actually writing Lua code that’s ok.

Where I think the benefits of a dedicated scripting language start to get more grey is on much larger teams with lots of people of varying skill sets banging away on the script code. I think to choice of language to use for scripting in that case is heavily influenced how big and how much script gets written. Duck typing certainly has issues and statically typed languages, while arguably less flexible, do remove a large set of common errors.

Definitely a trade off. In the case of UE4 I think C++ and Blueprints are a good balance.

Another point I’d add is that writing Actor classes and gameplay in Unreal C++ does not force you into the esoteric and complex parts of the language. The frameworks they provide do the heavily lifting. Most of the code you need to write for gameplay in UE4 will be very straightforward C++, and all of the “hard to do things” are managed for you by the engine. It’s actually a great environment to learn the C++ language.

The only thing that really bothers me is the size of the generated code. The size of the intermediate folder for my small project is already ~2.5GB.

[=;19185]
The only thing that really bothers me is the size of the generated code. The size of the intermediate folder for my small project is already ~2.5GB.
[/]

Intermediate code is never part of the shipping process and its size should be disregarded, it is temporary!

I send my team updated C++ binaries sometimes several times a day, and only sending the binaries and the source is under 100mb

:slight_smile:

[=;19164]
Let’s see, sometimes it appears to take quite awhile for this Editor to startup if I don’t give it a default project. I’m not home right now so I don’t have the numbers. Sometimes it can take 2 mins or so. But if I’m on a roll then it might only take 20-30 secs.
[/]

This tends to happen when files are spread out across a hard drive, and take much longer to load initially than subsequently when the files are cached. For optimal performance, compile and run from an SSD such as this awesome one: Are you a human?

[=ShawnBaxe;19148]
You don’t have to close the editor in order to compile your C++ game code. Just use the “Compile”-button in the editor’s toolbar to compile your code. That’ll work just fine and you don’t have to close the editor at all.
[/]

You have to, when you change the memory layout. so you can’t create new classes/functions/variables but you can modify existing ones.

Ah okay…yeah…guess my brain was on vacation on this one :wink: Thanks for clarifying :slight_smile:

[=;19205]
and take much longer to load initially than subsequently when the files are cached.
[/]

Actually and Epic,

This is something I’ve been meaning to congratulate you on!

I love how fast UE4 loads, after that first initial load! I open and close the editor frequently due to my workflow of testing from commandline, coding in c++, and loading editor for asset changes.

And UE4 loads so fast!

After the initial load, which does take longer, subsequent loads of UE4 are actually about 3-5 seconds on my computer, which is sooo nice, even faster than the UE3 UDK, by far :slight_smile:

So congratulations on your cached Editor loading system, it is something I’ve always wanted to mention enjoying.

:slight_smile:

[=;19168]

Another point I’d add is that writing Actor classes and gameplay in Unreal C++ does not force you into the esoteric and complex parts of the language. The frameworks they provide do the heavily lifting. Most of the code you need to write for gameplay in UE4 will be very straightforward C++, and all of the “hard to do things” are managed for you by the engine. It’s actually a great environment to learn the C++ language.
[/]

As someone who teaches people how to program, specifically games, I have struggled with this for a while. I have been asked dozens of times if Unity was a good way to learn to program. Should I learn to program then learn Unity, or should I learn to program while learning Unity? The same applies to Unreal Engine, and after all this time I dont have a good answer.

I can see merits both ways. One of the things that make learning easier is being hands on. If I could go back in time and learn 12th year math knowing it was directly applicable to game programming, I would have groked Matrix math, translations, etc… a heck of a lot easier. Learning something as a completely abstract concept is never easy.

On the other hand, without a foundation you are basically just putting magic numbers into a text file. How much of this is actually learning? I remember wayyyyy back, I used to enter page after page of basically binary code printed in a magazine to create a game. Did I learn anything in this exercise? Other than how to type, not really.

Learning with UE first would present some fairly interesting learning problems. First C++ syntax is a bit unwieldy to start with… without learning from scratch, its going to be pretty daunting. Templating syntax for example, isn’t going to make any ****** sense until you know what a template is and what problem they solve. Then there are macros… a powerful feature of C++, and something UE relies on heavily, but also something that should be avoided like the plague while a learner.

I think in the end, my recommendation for people starting with C++ and UE4 is the same as people starting with Unity + C#. Start with the language basics, run through a beginner book and make the obligatory console apps, then try picking up UE4.

[=Serapth;19250]
As someone who teaches people how to program, specifically games, I have struggled with this for a while. I have been asked dozens of times if Unity was a good way to learn to program. Should I learn to program then learn Unity, or should I learn to program while learning Unity? The same applies to Unreal Engine, and after all this time I dont have a good answer.

I can see merits both ways. One of the things that make learning easier is being hands on. If I could go back in time and learn 12th year math knowing it was directly applicable to game programming, I would have groked Matrix math, translations, etc… a heck of a lot easier. Learning something as a completely abstract concept is never easy.

On the other hand, without a foundation you are basically just putting magic numbers into a text file. How much of this is actually learning? I remember wayyyyy back, I used to enter page after page of basically binary code printed in a magazine to create a game. Did I learn anything in this exercise? Other than how to type, not really.

Learning with UE first would present some fairly interesting learning problems. First C++ syntax is a bit unwieldy to start with… without learning from scratch, its going to be pretty daunting. Templating syntax for example, isn’t going to make any ****** sense until you know what a template is and what problem they solve. Then there are macros… a powerful feature of C++, and something UE relies on heavily, but also something that should be avoided like the plague while a learner.

I think in the end, my recommendation for people starting with C++ and UE4 is the same as people starting with Unity + C#. Start with the language basics, run through a beginner book and make the obligatory console apps, then try picking up UE4.
[/]

I agree, I should have been a little more clear: I think UE4 is a great environment to learn C++. I’d definitely recommend having a beginning C++ programming book with some examples under your belt.

UE4 eliminates is having to deal with setting up your programming environment, dealing with user input, and some of the peripheral things that can get in the way of pure programming.