Creating a whole game without using Blueprint

Hi Unreal Community !

My name is and I am a game programmer who used Unity , CryENGINE and finally , Unreal Engine.

When I first started game development (or programming) I used Unity as I thought it was the easiest game engine of the 3 major engines. I started to learn C# and I reached a good level in it but the problem was with Unity itself , as it was not so powerful.

After Unity , I used a revolutionary engine in terms of graphics , CryENGINE 3. It was so powerful but the problem was (as I think) Crytek did not care about it. There were a few tutorials on the internet (most of them by 1Richmar) and the documentation was not so helpful. The FlowGraph was not so good and C++ was not used in most cases.

Finally , I came to Unreal Engine 4. The problems with the previous engines are not present here as it’s so powerful (I think not as good in graphics as CryENGINE 3 but it has also excellent graphics) and it has lots of tutorials provided by Epic and the documentation is good.

Now , I want to know if I can create a whole game in C++ without touching Blueprint as I am a programmer and I want to feel that I am really doing something :slight_smile: (Anyone can use Blueprint to create a game).

So Can I create a whole game in Unreal Engine 4 using C++ and without touching Blueprint ?

Thanks so so so much for reading
Bye

1 Like

You can, but it’s not recommended because it’s very inefficient. Usually you create base classes in C++ and do all your functionality there, but it makes sense to create Blueprinted sub-classes that might change some of the initial properties, such as the mesh used by a Character etc.

ShooterGame is a good example of this. All code is written in C++ and handled by that, but discrete objects sub-classed to Blueprints which just alter some of the default values. This allows the same players to have identical functionality, but with different meshes, inventories, health values etc. The engine is built and designed to be used like this.

Remember, you’re most valuable commodity as a developer is your time! Blueprint is so scary fast that it cuts a lot of that time out!

Blueprint itself IMO, is worth ten times the price of the engine on it’s own. For prototyping it’s second-to-none.

1 Like

Thanks very much for the response

But I’ve read a few hours ago on the forums that a developer from Epic Games said that C++ is 10X faster than Blueprint so , what about that ?

OK time is not so important to me as I am just a student at school (I am 14 years old) so , I can learn all what I want without considering time as a very important factor.

And as I said , I want to feel that I am really doing something as everyone can use blueprint but C++ is really something special for programmers

Thanks again

The 10x faster is true but not all is speed. You do want to code your complex systems in C++ and of course any expensive work but BP’s are deeply in the engine and should be used as the final entities in your game. Using only C++ will force you to reference many assets in code which is a very bad idea. Also using PAK files (the packaging system in Unreal using UnrealPak) will package .uasset files, so to create downloadable content you must have at-least one blueprint for stuff in your DLC. The workflow of gameplay code is also faster in BluePrint, you can just test in seconds, I usually do my prototypes in BluePrints and once they are working and I’m satisfied with it I move parts or the whole into C++ to optimize it.

1 Like

Thanks for response

But as I said above , the Blueprint eliminates the need for a programmer and I want to feel that I am doing something not just matching some nodes and booom ! I have a game !

Thanks again

You could say programming is just typing some letters and -booom- a game, too.

You wouldn’t be right if you said that, but you aren’t correct right now either, so I’m not sure what you want people to tell you. The engine wasn’t built to serve your desire to categorize people’s worth based on whether they program or not, deal with the fact that blueprints are an important and useful piece of the Unreal Engine. You are only hurting yourself by ignoring them. If you want to program and never touch blueprints, why are you using UE4? Go create your own engine to prove your manly programming might, I assure you that no one here will stop you.

If you’re making a game to feel uber 1337, then sure. You can use nothing but C++. Hell, use hand written assembler and you’ll be even more leet.

If you’re actually wanting to make a game, I wouldn’t recommend trying so hard to avoid Blueprints just so you look cooler. A working game is a lot cooler than an unfinished game written all in C++…

This…

Also, remember you are young and have much to learn about the world. In a few years when you enter the real world there will be many lessons learnt. In many cases in business the destination is far more important than the journey. Many employers don’t give squat about how you got the result, they are only interested that you have done it and done it efficiently (they have big bonuses for meeting those milestones you know and need to pay off that new porsche somehow). In the case of this topic, if that meant you were making a game to meet specific performance targets of a specific platform or higher and blueprints was able to deliver that, and do so in less time than pumping out lines of c++, guess what, it’s getting done in blueprints. Both blueprints and c++ are tools to achieve a result. Neither is better or worse than the other and it depends on the use case. Learn both and you have the best of both worlds.

Also, there is so much to learn. If you want to develop programs (either games, apps, whatever) then sure learn to code primarily. If you want to develop games then use some of the smart tools available to get your feet wet, just get in and make some games, this will teach you more than you know. You’ll learn about many of the different roles in game development (especially if you do them all yourself) and might find you rather something other than just coding all day long.

The main idea about blueprints as I see it, is hooking up the actual level logic and graphical stuff, all other logic seam to be easily done from source.
Essentially there is no problem using the editor as a level editor and settings tool, settings up hooks for boring stuff like the ui etc.

I would say that any great game would require insight into both. The dosage you decide to use can vary.
Specially c++ is a speed increase, you can get access change compare stuff on a few lines, that would take 30 nodes in blueprint.
And the best part is, all that can be exported as a blueprint node, giving you the speed of a proper source implementation, but the easy hook up of a gui.

Experience on this theme could “vary” from dev to dev, I can just say by what I felt until now.

I began the game making alike you, feeling that I could bypass “ALL” Blueprint stuff coding.

The nightmare began when you need to access content, you have the StaticLoad and FindObject methods, but they don’t suffice (IMO) to everything, as example when dealing with UI (way faster if you adopt UMG) unless you have time to expend experiencing and reading you’ll have some headaches.

On BPs you just need a reference variable, implement a set somewhere and since you are “already” making this pseudo-code on the editor you can simply click and say what will be loaded there.

Does this invalidate our C++/Coding skills? No way! You just need define where you’ll apply then and on this I’ll make choir with TheSpaceMan î (+1)

After get control over “BlueprintType”, “BlueprintNativeEvent”, “BlueprintCallable”, etc… You’ll “MAYBE” notice that while BPs “COULD” be mainly designed to allow non-coders to make games, when summed up with code knowledge you can go far away from what is offered. You can make your own classes with most funcionality implemented by code and after make a Blueprint “inherited” from this class and make use from all communication and customization stuff expanding it.

When I tell you about customization, I mean things that are made way faster when you “see” than when you “suppose” as example you can assemble a multi-part vehicle actor fast on a BP, (wheels goes there, body stays this distance from ground)… I think you got the idea.

Also consider that on expose your framework functionality to a non-coder environment you are investing to the future… Maybe your project grows, sells a lot… (I wish to you/your team a lot of success! :wink: ) so you’ll be allowed to hire people that will not need to know all the code stuff behind some framework element to use it on a level to your next DLC.

Best of Luck!

1 Like

Thaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanks very very very very very much to the best community

So What I learned from all this is that I can’t ignore Blueprint while making a game using Unreal Engine 4.
I just wanted to do something that is different from what a level designer , an artist , … etc can do.

Thanks very much again

We are pretty much exclusively C++ driven, but we still use Blueprint subclasses for data. It is senseless in this day and age to hardcode variables in C++ and suffer recompile times when iterating design values. So create C++ base classes with editable properties and create a blueprint just to customize these. The engine even tracks these as “data-only Blueprints”, which I assume allows some optimizations like not even running the script VM for those.

1 Like

Thanks very much for your answer

What they are saying is not “you can’t” but “you shouldn’t”. When i first started using UE4 i began with Blueprints only and never touched C++ but recently i started using both and trust me…its more fun. :slight_smile:

For example, i created a weapon master class that contains both rifle and shotgun mechanics so all i had to was create Blueprint sub-classes, change the meshes, adjust values and boom. I have two different weapons in no time! Plus i launch my projects via Visual Studio so in case if i have a bad code (like trying to access a null pointer) editor will crash and point me to the code in VS. I’ve also created Blueprint function libraries and simple plugins for my project which will speed up our workflow.

Blueprints are vast and very very powerful. Since i want to learn C++ more, I restrict myself from using Blueprints for my current project but still sometimes i cant resist using the beautiful UI of Blueprints. :wink:

Here is an example macro i made for our project. Using this macro i can run experimental features in my game. Am not saying that this is not possible in C++ but its way more easier to do this in Blueprints and it saves a lot of time.

Macro:

&stc=1

Example Usage:

&stc=1

Speaking for myself, using Blueprints to start with taught me how to work with the Engines C++ (and how to program in general, with or without C++). It’s bloody marvellous.

Doesn’t mean you can get away without using a dedicated programmer though, a project I’m working on right now calculates physically accurate orbit trajectories for space craft, based on a similar method to Kerbal. If you can get that kind of system working efficiently in Blueprint well… hats off to you. C++ still has a very firm place in development with Unreal, I often work out problems in BP first then program them in code afterwards, both for my own learning and for the sake of my OCD.

I think it can be helpful to think of the game creation process being split up between multiple people with different skills. If you create and organize your project with this in mind I think you will quickly see the value of blueprints and C++ and how they combine.

I know that many folks work alone, so it might help to think of yourself as a person with multiple roles. Self - The Level Designer, Self - The Engineer, Self - The Technical Artist etc. If your level designer wanted an N-Body Gravitational Attraction actor, you’d probably want to make this in C++ and expose only a specific set of Functions and Variables that would allow them to use the actor in the intended way - i.e. not trying to calculate 1000 actors with the classic formula :wink:

This is really no different than say, making a class in C++ and deciding what gets exposed to people that will be implementing your class. If you think of delivering small re-usable modules like this that can be consumed by various people in blueprints, I think you’ll begin seeing the synergy between C++ and blueprints.

A lot of people talk about the speed of blueprint prototyping, this can be nice especially when you’re starting out and may not have a good handle on all the classes and functions that you need. Remember you can right-click any blueprint node and “open code”. I think that once you are up to speed, the only reason blueprint might be faster to work in is because you have to completely restart the editor to add a new C++ class - this can really destroy your productivity if you’re in the middle of prototyping something. For me, doing vector math in blueprints takes more effort to read, write and diff, also I can’t do pointery stuff like


*tank = FMath::Max(*tank - LaserChargePerTick, 0.f);

so I naturally gravitate towards the C++ end of things.

Sometimes it makes sense to do a quick implementation via blueprint, sometimes it doesn’t. I often make the decision based on how complex the thing is and also whether or not I want people messing with something. If I think my level designer might accidentally break something by modifying a blueprint, I’ll encapsulate that critical functionality into a C++ class and expose only a few tuning variables that I know can’t break things.

As you use blueprints and code, you’ll probably find your own happy medium. I think most of us that are heavy C++ users still use blueprints for object composition. It seems easier to compose a complex set of objects in blueprints and then get references to those in C++ rather than compose a complex object in C++. In the first case you have a set of named sub-components that you look for, in the 2nd case you have hard-coded asset references. You can change the first without recompiling, although you can still run into issues if you change your object drastically.

Coming from pure C++ background, I found that blueprint confused as hell. As for me, I prefer toward doing almost everything by C++ and then exposed tweakable parameters via blueprint. For an example, I designed a very self-sufficient C++ vehicle class, and then exposed via Blueprint torque curve, skeletal mesh etc (User can create a blueprint class, derived from this class and produced truck, car - anything 4 wheelers).

And blueprint can quickly get messy (it looks literally like spaghetti) - in this regard, C++ is always shorter and easier to understand. BP has its own place, so does C++. YMMV - depending on the skill sets.

The gaming industry is moving this direction even Unity does it, Cry, and many in house… I been in the industry professionally, if you plan to be a programmer in the gaming industry, it is important to know, visual scripting… It is here to stay… I hated it at first since it felt messy and Kismet felt dirty …Now with Blue Print, its not as messy… Unity’s visual scripting is nearly the same… Cry as well. Many in houses, I have used …So again if your plan is to do just games, use it and love it. If you want to program more, vs visual then, use Unity, since you do not need any visual if you prefer to stay away from it. Plenty of others where you don’t even need it… So really it comes to what language and what engine do you want to use. I use many Engines, so But Unity and Unreal 4 are the main ones I use for my personal stuff…

Agreed 100% with this person!

I myself started with blueprints only and enjoyed it. Wanted to stab at the C++ side (C# programmer here) and am loving what I can do in both. Its really neat to make a function in C++ and then be able to use it in the blueprints. Kinda cool to see my code visually have a stance in the grid.

Side note, Final Fantasy VII remake is being done in UE4. I would LOVE to see the BPs on that project lol.