I made a game using Kismet and another using Playmaker, so naturally my next one will be made using Blueprints.
However during the development of those two games I was sometimes forced to use programming since the visual scripting couldn’t do something (properly).
So as a safety measure I would like to start my next game with a C++ Project instead of a content only Blueprint project to have C++ as a backup option.
I never tried a C++ project, but still want to be able to make an informed decision about this, so what disadvantages will I have switching to the C++ project type?
What I found so far is that the setup is more complicated since it needs visual studio, but that’s ok since there is a free express version.
Another one I found is that it’s not possible to compile C++ projects for iOS without a Mac.
So basicaly I want to know if there are more C++ project type disadvantages, so that I don’t choose the wrong type.
PS: This is not supposed to be a discussion of whether working with C++ or Blueprints is better, there are plenty of those aready. ^^
You might be a lot less productive since you’re sitting there in visual studio constantly trying to compile code. Finding compiler errors is a bit harder than regular C++ since Unreal has it’s own crazyness on top of C++.
I myself am an avid C++ coder and am doing a lot of things in C++ so I have no regrets. I typically code up all the base stuff in C++ and only tweak a few things in Blueprint, like make a base weapon class. Then create blueprint weapons and tweak meshes, damage, etc.
dont bother with vs express its terribly slow
there is now a free community edition
cant thing of any disadvantages, blueprint as you know is limited but can be expanded using c++.
the engine source is available written in c++ so you can even change things at their core.
the only thing that might throw you is
There’s really no disadvantage to a C++ project type if you know C++ and have a compiler/IDE installed already. One of the really nice things about the C++ templates is that they include a blueprint subclass of the C++ classes created from the template, so you have the flexibility to use C++ or Blueprint, whichever is more appropriate to the situation and/or your tastes. If you work in blueprints in a C++ template, you’ll basically compile your project code once and then it’ll be just like a blueprint project.
You don’t actually have to launch from Xcode or VS with a C++ project, either. You can launch them directly from the UE4 launcher if you’re not planning on making C++ code changes.
You will need to update your C++ as the API changes with updates. That’s the only reason I can see why it would be better if your not planning on writing C++ to use a BP only project, you’ll save yourself that step.
My main project in UE4, the cat game in my sig was a BP Project, which I then added C++ to.
I like to work in a double project environment. Where you have a c++ plugin containing all the games base class functionality and then have a blueprints only project that uses said plugin. This way you have the best of both worlds. you could have a blueprint only project that uses c++
Another thing to be wary of with C++ stuff though is code changes through engine upgrades. Usually stuff is deprecated rather than outright removed/changed, but sometimes you end up with build errors after an engine update. This isn’t really a concern with content-only projects. Of course, you can go back into the source and fix those issues and it will build fine. It’s just something to be aware of if you have a ton of code.
My workflow is mostly in blueprints. I create C++ nodes when I need them for things the current nodes can’t do. At the end of the project when it’s ready to wrap, I tend to convert everything over to C++ just because I want to get as much speed as possible (and code is kind of like porn for me). I don’t write in code first because compile times aren’t good enough yet to allow for that kind of alchemy. BP for prototyping and getting your ducks in a row, C++ for what blueprints can’t do and for shipping.
Aside from from the fact that you have to compile from time to time, it’s hard to me to think of, of any particular disadvantages.
I personally work mainly in C++ (when making actual game ;p). Sometimes I tend to quickly sketch some ideas in blueprint (especially for UI stuff with UMG) or some quick tests with traces.
But usually I tend to setup underlaying logic in C++, and then expose it in reasonable manner to editor. Just note on this. If you expect to expose more complicated functionality than property editing (and even then), you will NEED to extend editor, with various things, like custom BP nodes (nodes, not functions), details customizations, property customization, maybe even roll out custom editor for something particularly complex.
But it’s worth time ten fold. Once you have nice tools, you can quickly iterate over game mechanics without touching code and recompiling anything.
Does this only apply to my own C++ code additions? Or is it also a problem if I never end up changing C++ code and stick with blueprints all the way? (I’ll start from an empty C++ project, no templates!)
It applies to all code projects, but the likelihood of something low-level enough breaking so that it borks empty code projects is very slim. You should never experience any deprecation problems if you don’t add any more code to an empty code project but it’s possible. And even then, why would you start with a code project if you don’t add any code?
On this topic, as a beginner, the thing that is confusing me is: What is the actual difference between a C++ project and a blueprint project?
If I start with a blueprint project, I am taken directly to the editor and can create blueprints. But I can also use “Add code to project” to write C++ code.
If I start with a C++ project, I get a Visual Studio project. As soon as I build it, I am right back in the editor and can create blueprints, etc.
The only meaningful difference I’ve encountered, so far, is that the C++ project has the extra step of having to actually build the editor before running it. My guess is that I really only need a C++ project if I plan to be modifying the engine/editor code?
C++ projects let you program character classes, items, everything. You can then create blueprints which extend Actor c++ classes very easily in the editor. Running the VS project opens the project in the editor and loads the c++ code.
Blueprint-only projects are opened in the editor without any custom code, and you use Blueprints to access all of the functions. (To me, coding game logic is much easier, more flexible/maintenance free, and less cluttered in c++)
From my own experience I’ve been able to just copy .uasset files (models, blueprints) over to different projects (c++ code would not be “active”), and in future I’ll create a new c++ project and copy things over. But the limitation is that this doesn’t seem to work for things like vehicles, so I might have to recreate these things manually.
In earlier versions with c++ projects the editor had sometimes broken my .uproject file and I couldn’t generate the code again, so now I make backups as much as possible.
Nothing, in my experience. I mean, it will actually add code and you can write C++, but that code won’t impact your game.
I’m not sure if this is intended, but adding code to a content-only project does not make it a code project. Code placed in its source folder does not add or change game functionality and hot compile is not available. The only way I’ve found to change this is to start a new code-based project and copy over the content folder from the content-only project, then set your preferences up again.
One reason I think this may be intentional is because code-based projects won’t build for iOS from Windows, so it may be a way of just locking out code-creep so that those projects will cook. Why I think it might NOT be intentional is that it didn’t used to be this way - I’ve added code to content projects before and added functionality, but that was versions ago. Now it doesn’t work like that. Also, no developer has explicitly stated that this is the intention as far as I know.
Ah, thanks, Jared. That makes a lot more sense now. Is it common to build code “outside” the project? For example, maybe to make a DLL? I’m asking just because the whole build process is pretty painfully long when building the whole project/engine/editor/whatever. This might be because I’m using Visual Studio Express and not “Community,” which I’ve seen recommended here in the forum.
The reason why you can’t use the classes etc. that you create through the menu, is because they are not in a folder that is accessible. If you want to access code, the source needs to be in the either the ‘’ or the ‘Classes’ folder inside the game module. These days I think that the ‘Private’ folder is also included, and that the ‘Classes’ folder is all but deprecated, actually.
To add code to a BP-project, do the following:
Create the folders ‘Private’ and ‘’ inside your '[ProjectFolder]\Source[MainGameModule]' (Create whats needed/missing in path)
Choose ‘File’->‘Add code to project’ in the editor to add code. On the first ‘Add code to project’, the ‘Resource’ folder; as well as it’s content, will also be created.
The module class files ([ModuleName.cpp and ModuleName.h) will be placed directly inside the module source folder, while subsequent classes will, as mentioned, be placed in the expected folders. Move these to the appropriate folders (‘Private’ and ‘’) and refresh VS project.
I prefer input etc. on blueprints, so I usually choose BP project even though I prefer C++ to BP. I have not encountered any differences between code and bp-project, when these steps have been followed…
You should definetly upgrade to community, and If you have a few dollars to spare, buy yourself the Visual Assist plugin.
When installing this, you can disable IntelliSense and let this plugin do predictions and completions. Before I did this, completion was nigh useless because of the insane search delays.
Thank you for that rundown, oasf. I create all of my new projects as code projects these days even if I tend to use blueprints first, but this is good stuff. I appreciate your expertise on this!
A lot of people tend toward adding code outside the editor, but I personally prefer using the Add Code to Project wizard just to get the templates for my header and source taken care of, even when making plugins. I usually write plugins as project code first anyway then move it over to the appropriate file structure when it’s ready to package.
So does implementing Steam still require C++ projects, despite the new Blueprint nodes for hosting/joining servers?
Or were the Build.cs and Target.cs changes only required for because he is using C++?
PS: I know this is about a potential disadvantage of content only projects, not C++ ones… but I still haven’t decided which project type to use and this is an important factor.
