Slightly different question from the ones that have been asked already - I have looked at those. I have Bjarne Stroustrup’s C++ book (the 4th edition).
I was trying to do some basic things in UE4 and realized I’ve gone too far ahead of myself. I’ve been using Unity and C# up until now but I’m immensely determined to switch over. I’ve done a little C++ in the past making a couple of applications. Some background info: I’m a first year computer science student who has spent a long time dabbling, and was also a professional 3D artist before returning to study. My goal is to make some simple games on my own.
I have some questions. And even though they are specific questions I’m after both specific and non-specific answers. Any information in the direction of these is very welcome.
What concepts in C++ do I have to be familiar with before I can start programming in UE4? If you really want to answer this effectively, what chapters from the above mentioned book should I read over?
Should I spend time doing things outside of UE4 before going into UE4, what things, how much time? I want to get started in it ASAP. With Unity and C#, C# was like speaking english for me, so I went straight into Unity and rarely used it outside of it, but I’m not sure I can do the same with C++
If I should spend time writing other applications, what frameworks should I use, what applications would push me in the right direction for enhancing my ability to use UE4?
I absolutely love making games, and can’t wait to tame UE4
I’d just start in UE4 on one of the templates like the top down or side scroller in C++. Don’t try to make a whole game off the bat, but add your own features.
You’ll need to study pointers and understand the concept of them. C# has a very similar syntax to C++, but some things like looping through containers using iterators will probably look like black magick at first, it’s not. Because they shared the UE4 source you can look in the .cpp files and see how they did everything.
Knowing C++ is just the tip of the ice-burg, there’s much more to it than that. The main difference between “procedural applications” and the UE4 is the fact that you are programming within the UE4 framework. UE4 is an “Object Oriented Event Driven” system. The UE4 engine/framework uses the “don’t call us we’ll call you” design model. I’ve never written for Unity, but I used to write some plugins for the CryEngine, there are many parallels. I don’t know which book would be ideal, but a good abstract programming book on Object Oriented / Event Driven frameworks would be what you want. The biggest hurdle from those fresh out of school is that sure, they know the languages but they don’t have any experience with object oriented / general systems programming. There really is no standard except the system/framework in which you’re programming, but generally a few idioms/patterns/designs are often reused.
The most used features of Object Oriented / Event Driven systems are inheritance, polymorphism, and generic programming (templates). They use a “Don’t call us we’ll call you” approach to design. At a bare minimum you’ll have to inherit from a base class and then register this class with the system (UE4 does some of this for you), how else would it know your class exists? Be sure you define whatever data structures and interfaces are required by the system, and then add functionality and/or change the behavior of the class so it behaves how you want (aka polymorphism). How this is done is dependent on the system, in some cases it might be done through a GUI (see my Slate tutorial), in other systems/frameworks registering a class might involve adding some code someplace in another source file, or one of your classes might create/register an object of another class during runtime. This is a huge topic but this is generally how it works.
Think of the UE4 engine as a game of Magic the Gathering, all of your “game classes” are the cards. The game will at times “call” the cards to perform operations defined by the cards. Some cards don’t do anything on their own, they have to be attached to other cards, some cards alter the behavior of some cards, some cards change the rules of the game etc… The main difference between UE4 and Magic in this analogy is that any human element must be defined in in code. The way you define “cards” for use within a UE4 game vary, one class/card might be added to the game by dragging and dropping it into the game world via the editor, others might be “registered” in a source file some-where, or added during run-time by other “cards”, others might be set as the default class to use in the Project Settings of your game (like the HUD in my Slate tutorial). This is what is known as “object oriented programming” and unfortunately the “don’t call us we’ll call you” (this is an important concept) model of programming is only barely touched upon in college (i have a CS degree myself).
The only limitation is that you have to inherit from the “card types” included in the system, although it isn’t much of a limitation because you can extend them to do almost anything you’d want. Some examples would be an Actor “card”. If you were making a Magic game in UE4, you might define a monster as a “card” that inherits the Actor “card’s” functionality, and then define whatever specific behavior about that monster in it’s class. If you wanted to change the game-rules, you could inherit from GameType, and from there change the way the game selects and messages the various Actor “cards” in the system.
PS: Like said, it’s very important to know the difference between a class and an object, a value and a pointer, a reference and the actual information, not just in terms of grammar and syntax, but the actual theoretical difference. It’s just as important to fully comprehend that concept today as it was 40 years ago. Just keep at it, the Compiler Design books I mentioned are a great way for fully understanding computer languages beyond just grammar and syntax (you also need to fully appreciate the difference between the stack and the heap to avoid memory leaks and working with the UE4 garbage collector). I don’t know anyone who understood all these things in a day.
If that’s all I need to know to get started then that’s great! Yep had a look at the Wiki, can’t wait to see how it grows.
The templates use blueprints rather than code, no? Blueprints, while being something I want to get into, aren’t something that I want to learn before I know C++ fluently. Will have a look into pointers and all that.
That’s a really good analogy - makes sense. I’ll look into the things you’ve mentioned and see how I get on.
A good approach is to make a transition from blueprints to C++. Blueprints are easy to learn and there are thousands of tutorials available. Then use the blueprints as a guide to write your C++ code. I wrote a tutorial based on this idea. It’s cut into chapters and in every chapter you will learn a different aspect of programming. It’s very advantageous because you stay in Unreal Engine, you write a code that will be useful for later, and you learn at the same time.
You could spend time outside of UE4, or you could apply yourself to small projects in UE4 to learn C++. Or even better to write individual components that are reusable for your future projects.
You’re very welcome, and yes I assumed my answer would not be of direct interest to you after 4 years.
I was leaving my message to anyone would be passing by with the same question, and the quotes was to make the message clearer :). Yep this thread is still on google.
