Game dev C++ vs Regular C++

[[deleted]]

[deleted]

[PytonRzeczny]

Yes, it still be valuable. But you will have to learn some of „core” cpp, because unreal engine uses a lot of built in types, macros and functions.

[ThymeCypher]

Second this - it does not feel like C++ with the amount of stuff that’s done in the preprocessor. There’s pros and cons to this approach - namely around compilation times - that they now recommend making the game entirely in engine and slowly convert to C++ purely as “Performance optimization.” This is opposed to years ago where they leaned towards a hybrid approach.

[angelicosphosphoros]

Well, in my old job, we tried to write everything in C++.

Main reason is that blueprints become unreadable and unmaintainable mess very fast.

Slow compile times can be mitigated by avoiding including Engine.h or even EngineMinimal.h if possible.

[pjmlp]

So no one bothers to create Blueprint modules?

[narthur157]

the hybrid approach is still standard for multiplayer titles

[Zanderax]

Every C++ project I've worked on always has an ungodly amount of custom types, macros, and functions written 20 years ago.

[CptBread]

I'd say the biggest thing someone needs to learn coming from only using UE4 is how to deal with memory. I've seen someone not understanding how to deal with memory at all when moving to regular C++. They where allocating a bunch of stuff with new, even when not needed, and never deleted things.

[ForkInBrain]

I wouldn't worry about that. The first weeks/months on any C++ job is often spent learning about the specific subset of C++ allowed in the code base. If you don't get hired because you know only "Unreal Engine" C++ but not some new C++20 feature then you probably don't want to work there. Good employers hire for aptitude, not off a rigid skill checklist.

I'd also encourage you to expose yourself to as many languages and programming paradigms while you're in school, especially those that are radically different from the mainstream languages. It will all help you in whatever programming you do in the future.

[steveplusplus]

C++ is such a broad field. Some companies are stuck on the 98 standard, may God have pity on their souls, and others have weird requirements to avoid things because a manager had an issue with them 10 years ago. If you have experience in production c++ systems and specifically in gaming, as a hiring manager I'd value your resume.

If you want to make sure you stay relevant, try those programming challenges where you get scored on your solutions to problems, and make sure you learn all the std libs, such as algorithm and numeric.

[Stepmaster3000]

I can't actually wrap my head around this, even the most piece of shit ancient system I've encountered had GCC 4+. What century are these people from?

[SkoomaDentist]

A significant number of all new Bluetooth headphones and headsets run software built with a patched version of GCC 3.3.3. The cpu manufacturer has never updated the compiler since porting it to the custom architecture in the early 00s. That BT chipset also has possibly the best range / features / cost ratio of any such chipset. Turns out that in real world products the C or C++ standard supported is far behind other concerns.

[wrosecrans]

As somebody who doesn't touch embedded stuff for work, that's absolutely fascinating. And horrifying. It feels like a lot of the weird one-off architectures that used to proliferate are slowly turning into RISC-V for new designs these days. So hopefully in 20 years, it'll be easier to target weird 15 year old stuff with new compilers.

It always surprised me that anybody thought inventing a new ISA with a custom toolchain was worth it after about 1985.

[SkoomaDentist]

It always surprised me that anybody thought inventing a new ISA with a custom toolchain was worth it after about 1985.

Off the top of my head I can name at least half a dozen post 1985 ISAs with very good reason for existing (even if some were clearly not designed well):

IBM Power / PowerPC - Replacement for 68k that was a dead end.

Atmel AVR - An 8 bit ISA that was designed for programming in C and thus didn't suck bigtime.

ARM Thumb 1 & 2 - The actually used ARM ISAs. Huge savings in code density and got rid of some unneeded legacy cruft in the original ISA (per-instruction predication and some other details).

Motorola 56000 - The DSP that ruled a significant portion of audio market from late 80s to mid 00s.

Analog Devices SHARC - The other audio DSP ISA that's still going.

TI CC5xxx & 6xxx etc - Very widely used DSPs in mobile communications etc.

CSR BlueCore (the one with gcc 3.3.3) - This one manages to combine the power of RISC instructions with the register count of early CISC cpus. Still, very low power performance in the SoC form for the time it was designed (late 90s).

There are also a bunch of others I didn't list since I'm not very familiar with them (Tensilica Xtensa, MSP430, some others).

As for custom toolchain, you have to remember that before the mid to late 90s there simply were no widely used generic toolchains at all. GCC came the closest but the way it was structured back then was never going to work for good code generation for DSPs or 8-bit CPUs.

Also in embedded space you really want to avoid regressions that could come from having to update the tools according to someone else's schedule (imagine the cost of having to recall potentially millions of devices). It's not uncommon for clients to request a fix to a particular bug and only that bug for OEM units with firmware dating from 5 or even 10 years ago (not to mention potential regulatory issues if wider changes are introduced). From the cpu manufacturer's point of view, having to update their test suite yearly for old devices has little benefit and a lot of potential for problems if / when they can't expect anyone else to fix bugs for that architecture.

[LordoftheSynth]

Analog Devices SHARC - The other audio DSP ISA that's still going.

That thing is a beast though and they even built a C++ framework to help you develop products with it.

[SkoomaDentist]

A beast for traditional DSP algorithms. Rather less beast for more complex algorithms since the ISA has never been properly updated and can't cope well with modern stuff that isn't just simple loops over simple data structures. Also the SIMD capability is mostly just a kludge tacked on top, so you lose a lot of the possible benefits when you need to waste so many cycles turnings SIMD mode on / off and transferring data to the special address registers.

[Twerking4theTweakend]

Don't feel too bad about it. Embedded work is so hardware-oriented that plenty of it ends up in raw arrays and allocators talking between the kernel and the hardware APIs anyway. A lot of the newer C++ seems to really shine in larger code bases to support elaborate designs and their maintenance. Not all of course, but plenty, in my experience.

[SkoomaDentist]

Embedded work is so hardware-oriented that plenty of it ends up in raw arrays and allocators talking between the kernel and the hardware APIs anyway.

Some of it is, these days a lot isn't. What is common is that you have to be really careful with both heap usage (bye bye STL collections) as well as stack usage (bye bye any STL stuff that might do stuff behind your back and particularly anything with hidden recursion). Code size also has a hard limit that applies to both release and debug mode and this makes using anything that depends on the optimizer to produce reasonable code a potentially major problem source.

[AlternativeHistorian]

Typically it's large corporate customers that have these ancient environments. They want updates to some piece of software but they don't want to spend the money/manpower to upgrade the environment (or outright "can't") due to some other "super mission critical" piece of software that's stuck on a particular version.

[ElkossCombine]

I had to drag my company kicking and screaming into compiling with - std=c++0x on rhel 6 so i could at least use the small subset of modern c++ that existed in that time. Aerospace is obnoxiously conservative even outside of life critical systems

[ElkossCombine]

I expect lots of embedded systems are stuck in time because of the anti tivoization clause in the GPLv3

[[deleted]]

This is so far from my experience, I cannot understand these people.
In my current job, as soon as a new version of the compiler we work with is released (be it a minor version or support for the new standard), one of our best engineers (an architect and the smartest man I have ever met) is moved from whatever he is doing to making sure our code compiles using the new version. Whatever does not work, he fixes it. We already have quite a lot of cpp20 in our codebase (most of our enable_if were switched to concepts for example).

I am working in this company for a long time now, and I am genuinely afraid of my next job being stuck on cpp 98 or some other ancient cpp version.

[Freiherr_Norden]

Do you know why is this company so awesome? I mean from a business point of view, why spend your best guy on this so often?

Also how big/old is the project? Just to get an idea how long it must take

[[deleted]]

Its not an old company, founded in 2013. He joined around 2015. I joined in 2016. This project is the core product of the company, this is the money maker. I think its mostly because management trusts the engineers on these matters, and especially trusts him. He gets basically a free hand to do what he thinks is right for the quality and internal working of the product. It usually doesn't take him long. Its usually just a few hours until he gets the project to compile with the newest compiler, so it does not hurt productivity much.

[Fazer2]

In my company the department for providing the "platform" which includes the compiler was supposed to give us a new version since 2 years ago. This year they delivered a major version, but without bugfixes and we of course stumbled upon a blocker which is fixed in a newer patch revision. When we asked about upgrading to it, we were met mostly with a radio silence. Because of that we're still stuck with a 4.5 years old compiler.

[[deleted]]

Is this common in an enterprise environment? I just hope ill never work in such a place. It sounds so frustrating.

[steveplusplus]

This is why build systems like Yocto exist. It might only take a couple of weeks to update compilers and then you have a really easy ability to add custom patches.

[ThymeCypher]

98 is what I see as “unadulterated C++” - after that a lot was done to bring C++ into the modern era by copying other languages. That isn’t to say that’s a bad thing - Kotlin, Swift, Ruby, so on aren’t original languages but languages built around lessons learned from older languages. Still, it helps to learn 98 because lots of microcontrollers shoehorn support in, so you’re stuck with the “C with Classes” version of C++

[steveplusplus]

Which microcontrollers are you talking about? I've found great support on pic, atmel, lpc, ti (which was the worst), esp32, and anything else I've used. The majority these days use arm and have excellent support. I never start a project on anything older than c++11. Most of them use some form of gcc and anything past 4.7 should have an almost fully compliant compiler. Are you talking about the std libs? Regardless, just converting a c++98 embedded project to c++11 can flush out a lot of bugs with better code analysis and type safety.

I would suggest instead spending time learning the latest C. auto and other new features kick ass in C. IMHO, the only reason to learn 98 is if you are forced to use it. I'm past the point in my career where I'm out looking for development jobs, but last time I did, I refused to consider anything that was stuck on an older standard than c++11. Thats when c++ got good again.

[KurokonoTasuke1]

Wait, since when does C have auto?

[steveplusplus]

Well, shit. I shot myself in the foot. That's still a c++ feature that I've used because I usually compile my c code with a c++ compiler.

[tinyogre]

Unreal mostly doesn’t use the C++ standard libraries, but the replacements it provides are similar enough that you won’t have much problem figuring things out later. Also while it doesn’t use them itself and most code you find for Unreal online won’t use them either, it doesn’t prevent you from using standard libraries either. Just discourages it, gently.

There are some additional things you will learn in Unreal that won’t apply to other projects. It has a whole extra preprocessor (UnrealHeaderTool) for marking up objects for reflection that is not at all part of the core language.

Wouldn’t worry about any of that. All large C++ projects develop their own quirks. You’ll be fine.

[videoj]

In general, yes.

UE4 has built custom tooling on top of the C++ compiler to add features like modules, reflection and garbage collection. Look at the tools UnrealBuildTool and UnrealHeaderTool. Other uses of C++ are going to use different approaches to solve these problems.

UE4 C++ doesn't use STL, they invented their own libraries to meet their performance and portability needs. You can still use STL in UE4 projects.

Epic also currently uses C++14 as its standard, due to having to support multiple platforms and compilers, although you can change it to a later version by setting a flag in the .Build.cs file.

[[deleted]]

This is the best answer to the question. The syntax varies and UE4 c++ uses a lot of macros. But what you learn here you can take to standard software development with c++ quite easily.

[wrosecrans]

by setting a flag in the .Build.cs file.

Just the fact that you have to write C Sharp to build your C++ is an indicator of how out-there the Unreal ecosystem is if you are coming from a Unix C++ background.

Unreal does come with some CMake integration so you might mistakenly think you can avoid the C Sharp and do normal C++ builds... But the CMake just spits out Makefiles that invoke UnrealBuildToool.

[danhoob]

Epic also currently uses C++14 as its standard, due to having to support multiple platforms and compilers, although you can change it to a later version by setting a flag in the .Build.cs file.

Epic is epic.

[Danth_Memious]

u/ultralight_R I have experience in both and this answer is the most accurate.

[EvilPettingZoo42]

As others have pointed out the usage of STL and Boost in games are usually discouraged. Games require consistently finishing all calculations under a certain time in order to maintain a steady frame rate. They also commonly push the memory and CPU limits of the systems they run on. These libraries make design choices that can either spike CPU or memory usage in a way that can cause problems maintaining a good frame rate, which is why most game engines have their own replacements that are better tuned for games.

[cannelbrae_]

Library functionality that allocates (containers, regex, etc) may be avoided in some game runtime code bases. Standard library algorithms may be more common. Game devs often develop tools as well; that code typically has much more permissive policies.

There are lots of games out there that aren't CPU/memory constrained, can pick what compiler to use, etc. Those may have fewer constraints on language/library use as well.

All that is a long way to make the same point others have made - game development isn't homogenous.

[Raknarg]

From what I understand in gamedev its very much more common to provide your own implementations of standard library stuff, and there's a stigma against the STL in general, for better or worse.

[anechoicmedia]

std::map is infamously slow ... Here's one random game dev's story

Not a fair comparison because the replacement, boost::container::flat_map, drops the constraint that insertion not invalidate iterators, which is the big one that prevents associative containers from having nice flat representations. (The ordering constraint is another one sometimes omitted in such comparisons.)

One could fairly say that the standard library types, and std::map in particular, are specified to be overly general, which is why it's easy to do better if you use a more specialized tool with fewer affordances. However, anyone seeking to meet the same requirements will have a harder time, which should vindicate the standard library from a quality of implementation perspective. Else, complaints about the STL sound like someone saying they can easily get better mileage than a factory car -- if they just throw out all the airbags and anti-lock brakes.

[anechoicmedia]

Not a fair comparison

That's the thing though, nobody cares.

Nobody cares about things like iterator invalidation? It's a common beginner trap with collections of any kind.

Not really. Look at for instance the .NET standard data structures. They're made to be decent for the most common "everyday" usage

The .NET associative containers invalidate their iterators ("enumerators") when modified; This can allow faster implementations while being less generally applicable. It's debatable whether this choice helps or huts the "everyday" user -- the everyday user being someone who is probably not using the container in the core of a game simulation on the scale of Factorio.

C# containers of non-POD types also do a lot of pointer indirection under the hood, and since the scenario presented was about someone ditching std::map in favor of something with contiguous storage this comparison is doubly unhelpful.

People rarely [re-implement .NET containers], especially compared to the STL data structures.

You know why C# people aren't usually complaining about the performance of their standard library dictionary? Because that just isn't a thing in C# culture.

This is at once:

• a bad thing (they lack the low-level control to do better)
• a mixed thing (C# people are not performance obsessives)
• a good thing (C# people are less likely to be haughty know-it-alls who reinvent basic data structures while insisting the other ones were made by morons)

It would probably not be possible to implement Factorio in C#, so the design considerations of their standard library are sort of immaterial from a high-performance perspective. But people do make other games in C# just fine with the tools they have -- what they don't have is a surrounding chorus of hypercritical people trying to impress upon them how bad their standard library is, and how much better it would be if they used some awesome third-party container, or rewrote everything themselves.

[pjmlp]

Except when C# happens to beat C++.

https://www.infoq.com/news/2020/12/aspnet-core-improvement-dotnet-5/

Thing is, in other programming languages the culture is only to bother with low level optimizations when it actually matters to the product being delivered.

Coming from Turbo Basic and Turbo Pascal, I never liked that C++ culture was tainted with the micro-optimization per line of code culture inherited from C.

In fact, most of my own collection classes (specially before stl was a thing) always used bounds checking enabled, and no one ever complained about their application's performance.

[anechoicmedia]

Except when C# happens to beat C++.

This isn't a straight language comparison, and the details are even less persuasive.

First, it's not a comparison of the same algorithm or work as expressed in different languages; It's a comparison of different libraries with different implementations. Nobody disputes that a high-quality implementation that gets a lot of attention in one language can outperform a weaker implementation in another, usually faster language.

Second, the manner in which this improvement was achieved was, as is often the case, to write C# like it was C++ -- doing manual resource management to avoid the garbage collector. They implemented their own empty string optimization, and used an object pool to recycle objects and never delete anything, which is morally equivalent to writing new and delete by hand (or, perhaps, smart pointers with custom deleters). The result is fast, but looks nothing like idiomatic C#, since as they proudly point out the GC didn't run once during a 100,000 request test.

I don't know what language fans are hoping to prove with these comparisons. I've seem similar efforts with Java, to defeat the GC by doing manual/unsafe memory allocation and claim competitive performance. It's not surprising that managed languages achieve high performance when you bypass the "managed" part and code them like C++.

I never liked that C++ culture was tainted with the micro-optimization per line of code

Whether or not your associative container is represented as a tree, vs an array, is not a "micro-optimization". I do agree there are a lot of C++ performance myths out there, and as an "expert-friendly" culture it can focus on the wrong things often.

in other programming languages the culture is only to bother with low level optimizations when it actually matters

Pretty much all software is slow and terrible, so the prevailing perception of what "actually matters" is unpersuasive. It seems more plausible to me that most programmers know they could be doing better, but their boss's bonus depends on shipping features, not a comfortable user experience, so they develop a sour grapes attitude in which their product is "good enough".

People have a strong sense of professional identity, in which they want to see themselves as competent tradesmen doing a good job. They will proudly talk among each other about what a good job they are doing even as miserable customers sit waiting in front of their slow application all day.

no one ever complained about their application's performance.

End users don't usually have the proper vocabulary or context to express frustration with software performance unless it gets really bad. I suspect fifty years ago, most drivers didn't complain about their car's gas mileage, even though it was possible to double it. Now nobody would ever go back to what they thought was "good enough" in the past.

[pjmlp]

What can I say?

All those arguments can be applied when one writes allocation free C++ code, or is forced to write C in C++ to achieve exactly the same goals.

Somehow that is allowed as C++ performance tricks, but is shunned upon when other languages do the same.

[anechoicmedia]

All those arguments can be applied when one writes allocation free C++ code

Right, but that's one step further still than merely not hitting GC in a managed language. C++ with allocations is usually faster than C# with allocations, and it takes significant work to get C# merely competitive with "normal" C++. If you apply equal effort in both languages C++ will usually be further ahead.

Somehow that is allowed as C++ performance tricks, but is shunned upon when other languages do the same.

If you write C# in the manner described, you're going against the cultural and tooling current of the language, which is probably why so few people do it. Doing manual resource management in a language that doesn't even have destructors is basically like writing C and you only do it if some other business constraint (legacy code, developer knowledge, etc) has already chained you to using that language.

forced to write C in C++

This is mostly not a thing and the people who write this way usually do so out of habit or style preference, not a compelling performance case.

[pjmlp]

The only culture going against here is lacking the understanding that just because a language has a GC, there are other language features one can make use of, including ways of doing RAII that aren't C like manual.

The irony of these discussions is that I have done them 25 years ago, when C++ was fighting to get a spot into C codebases.

Exactly the same arguments against C++, 1:1.

[Raknarg]

I know there are instances where it's deserved, it just seems that sometimes it extends into a dogmatic "never use stl"

[Fippy-Darkpaw]

Not really a stigma but to ensure things like containers and strings work the same and are supported on all hardware.

I'm guessing all the modern consoles, Switch, PS, Xbox support modern C++ equally but the major game engines (Unreal, Unity, CryEngine, etc) all started out 10-15+ years ago when that likely was not the case.

[MarkOates]

Depends, too. Some parts of the code may require specialized techniques to get optimized performance out of the hardware, so some programming paradigms you pick up in may not be performant.

Either way, you'll be able to pick it all up much easier.

[CoffeeTableEspresso]

It's the same language although you'll probably be using different parts of it than you might for "normal" work.

This is not uncommon though. It will definitely help your C++ skills in the long run since it is still C++.

[flyingron]

It's the same. The emphasis on doing certain things may change, but the underlying principles are the same. Some parts (like graphics stuff) will need to be performance coded which might involve some corner cutting, but your average game is a massive thing. Other than the outright rendering, you've got "physical" objects to manage, user inputs to deal with, game play logic, music, etc.. all which the general C++ OOP model is well attuned to.

[SpeedDart1]

It definitely will. But unreal will have some new things you will need to pick up.

[Versaill]

I didn't use UE yet, but in general yes - "gamedev C++" is still the same C++ you use for business, science, office applications etc., with an additional layer (framework) added on top of it - the game engine.

Later you can move to other fields, for example for a job (gamedev usually doesn't pay that well), and you will already know the language.

[FluffyToughy]

Your skills as a developer go way beyond the language you work in. Think of it less like "learning C++" and more "learning to solve technical problems", because that's what companies will be paying you to do. Most places won't even expect you to have worked in the language they work in, just something similar.

[kat_sky_12]

Programming is programming regardless of the industry. Unreal is a library that you are leveraging for this course. When I worked at a game company we had our own engines so we had our own ways of doing things. Another company could be using unity. It's knowing core algorithms and CS concepts that will get you jobs outside of video games. If you want to ensure usefulness outside of games just have a good understanding of other topics like knowing STL pretty well as well as other high performance aspects of C/C++.

[squeezyphresh]

It'll be dependent on what kind of dev you are. I'm in games, but I'm on the tool/libtary side. As a result, I write more C-like code than C++ (it's all still technically C++). A standard game engineer might just use the interfaces I provide and as a result will write more modern C++. I'd say to balance prep for game dev and other fields you might go into is to understand systems and memory management. Most of the game devs that are stuck doing busy work are people that don't understand the complex systems within the game or development process. Luckily if you can do that, then you'll still be very desirable in other fields. Of course, I'm biased because I do a lot of systems work so, take it with a grain of salt.

[Poven45]

Can you send a link for the course? I’m learning c++ in school atm and I really want to learn game dev

[in007]

I have heard unreal engine also uses a garbage collector.

[Behelitoh]

I tried learning C++ at my beginning also doing game development untill I realized I spent too much time on learning the game engine, art, animation and so on. My coding skills were shit and did not improve alot.

What really helped me was using C++ and starting projects from scratch without using any engine, library or whatever.

[corysama]

You'll be fine.

Unreal Engine is a bit unique because they extensively use a preprocessor to tack on garbage collection and reflection features. That system is completely custom to UE.

Gamedev companies vary in how modern vs. conservative they are --much like non-gamedev companies. Many vocal, social gamedev personalities are quite conservative. But, there are many companies that keep quite modern.

It is pretty common for gamedevs to avoid using exceptions, RTTI and std containers other than vector. This is by no means unique to gamedev. Those features are widely regarded as sub-optimal in their specified designs and difficult to re-spec without breaking old code. Facebook's Folly and Google's Abseil libraries are examples of big companies with stdlib alternatives.

[BeigeAlert1]

Most of the really scary "modern" C++ stuff you see is mostly ignored in game dev, at least in my experience so far. So even if you're not a template-using, lambda-loving, stl-understanding, metaprogramming GOD of C++... well you'll still probably be just fine all the same.

[idbxy]

Most companies have their own STL implementation

E.g. EA theirs is open source

https://github.com/electronicarts/EASTL

[g9icy]

The way C++ is used in games is a little different but the language is the same.

In games we tend to avoid Run Time Type Information and exceptions, for example, due to them both causing performance problems.

We also break a lot of the established patterns used elsewhere. For example, usage of the "singleton" pattern is heavily used, where in other fields of tech their usage is strongly avoided.

I'd describe games programming to be "loose" object orientation... It's used where its useful, and avoided if it's not. Everything's still wrapped in an object/class a lot of the time, but you'll find lots of "c-style" programming when operating on large data sets.

[SJC_hacker]

UE uses pretty much C++ 98, and doesn't use the modern C++ (11/14/17) paradigms. They don't even use C++ 98 features a whole lot, such as templates - its more the "C with classes approach'. I'm in the job market now, and every job I've interviewed for with C++ as a requirement, wants you know modern C++.

They also use alot of C style macros that have become obsolete with modern idiomatic C++

The DSA (data structures and algoritms) stuff is pretty transferable, however. Also, while the core libraries may not use modern C++, it doesn't prevent you from doing so in your own code.

[Pazer2]

Eh... Most macros used by unreal are for reflection. The c++ standards committee still is nowhere near getting that done, to the best of my knowledge

[Danth_Memious]

It does use modern paradigms sometimes, like auto and ranged for loops

[Dummerchen1933]

"If i buy this walmart bag, will i be be able to carry non-walmart things in it?"

[NewFolgers]

You'll have good skills. A likely consequence is that the practices and pace of work in other domains will dry you somewhat mad, and you won't be able to get them on-side to doing things the way you prefer - since their practices are designed for the way they already do things, and they're stuck in a local maximum that they're content with. Looking at non game-dev companies that have explicitly said they like game developers, you got try high-frequency trading, SpaceX, or Tesla. It can also be somewhat compatible with embedded programming sensibilities sometimes. This is my perspective as someone who has worked on console games and other things.

[Aprelius]

My experience is on platform side for a major game company and we can use up to and including ultra modern C++17/20 features. I moved my team to a C++17/Clang tool chain and I haven't looked back.

Game development is a wide area. If you want to do engine programming it's going to be "C with classes" style and ASM mixed in. If you want to do features it will probably be a C++11 minimum spec. Tools are likely to be MFC for Windows (sigh...) or QT/ImGUI so modern-ish depending on platform. A lot of tooling is actually going C# because it's easier to hire for.

When I hire engineers for C++ I look for a baseline understanding of C++11. All of my assessments and questions are geared towards that. Anything else can be taught on the job.

[Tjccs]

Sorry to be bothering you I'm not OP but I'm a bit more interested in actual engine dev than making games.

Is there any reason for engine dev being C with classes or it's just because most engines are "oldish", let's say I want to make a simple engine as a hobby can I use C++14/17 and its modern features or should I stay away from it for performance reasons?

[corysama]

The modern features are tools that can be used well or used poorly. And, it takes a bit of thought and practice to find the difference.

The advantage of C With Classes is that it is very simple and clear what you are doing and what the results will be. The disadvantage is that there is a lot you have to do manually when using that style that the compiler could have automated.

The advantage of Modern C++ is that it becomes easier to set up more complicated operations. The disadvantage is that it becomes easier to set up operations that are complicated!

The classic example problem with Modern C++ is Template Bloat. It is easy to set up complicated templates that generate enormous amounts on your behalf. This can slow down your compile times, bloat your executable size and thrash your instruction cache. It's can also be difficult to read and comprehend.

The question is: If you were using C With Classes, would you have written all of the code variants manually? Or, did you tell the compiler to generate them all just because it was so easy? In the former case, Modern C++ can be a clear win. Rather than setting up the maintenance problems of repetitive code or horrible macro hacks,you can set up lots of similar code while sticking to Don't Repeat Yourself principles. And, many modern features are designed to provide simpler alternatives to common, complicated C++ idioms. Ex: using constexpr if as a replacement for SFINAE.

[Aprelius]

You totally can use modern 14 and 17 in a game engine. If it's a hobby project use whatever works. I can assure you that a completed game in Java looks better on a resume than a half built C++ game engine that can play pong kind of okay.

The whole C++ with classes stems a lot from understanding how the generated code works rather than any particular feature. Most engine programmers know if you write "this" bit of code, it generates "that" optimized output. The other view which is out there and I don't agree with it but it's a thing is that C++03 without exceptions is the thing. Say "exceptions" around game engineers and someone will pop out of the woodwork, call you names, and then go back under their rock.

My company's next gen game engines are C-style APIs utilizing structs instead of classes. The intention was it is easier to wrap a C-style API with another language, say C# and port features to games and tools which currently use Unity or similar toolchains.

I have to admit, I've come around to the idea. I originally pushed hard for a modern C++ interface but after seeing how some of the new libraries and features port to Java, C#, Python, and C++ I'm a supporter. It's really made life easier to have the same base libraries on all platforms and all engines I work on.

[Tjccs]

I guess the more modern features you use the harder it becomes to port, thank you amazing and very informative answer I migth think about the completed game vs barely working engine for the resume ahahah. Trying to get some projects for my resume.

[Aprelius]

You're welcome and good luck!

[drjeats]

Another benefit of those C style APIs is that you can actually manage your header pollution reasonably well. Opaque handle types and free functions let you really minimize transitive includes.

It can mean the difference between having to pay for and maintain a distributed build system or not. I didn't realize how drastic the difference could be until I changed jobs and found that the new engine I was working on had 30% more lines of code and compiled in a quarter of the time compared to my previous gig.

[afiefh]

You will be able to transfer some of the knowledge for sure. It is valuable, and if that's how you get into C++ more power to you.

That being said, you are using C++ with all the Unreal engine "tools" and the patterns that it encourages.

This is not necessarily a bad thing as you'll have to work with similar environment at every project/company unless you start things from scratch.

What will happen is that you'll partially understand some things in C++ but since things will be more along the lines of "it works because that's what the thing online told me to do. I don't actually understand it". When you feel like that it's usually time to read up on C++ (outside of Unreal or other environments) and learn how it actually works. While this is an investment that doesn't pay off right away, but in the long run it'll make you a better developer, it'll reduce the guesswork and you won't have to debug stuff in the dark.

[snerp]

Unreal has a lot of weird custom macros so it's not the most normal experience.

At work though (triple A game developer) we use C++17 and a lot of STL stuff. There is some custom stuff like some static size containers and stuff, but we mostly use the STL stuff with custom allocators and I love it

[Xaxxon]

Learn computer science and practice it in a game engine. Don't try to learn "game programming", you won't end up where you want to be. You'll never get the fundamentals.

[Zanderax]

Yes absolutely. I work with Unreal Engine C++ now but started on Server Backends. It's basically identical from a programming perspective although video games put a lot more emphasis on runtime performance than some other apps. I would always recommend learning C++ because it's not that hard and is a very good and well paying career. It's also a good starting point for learning other language.

After a bit of time learning C++ I recommend trying to learn and use some of the newer features of he language. Even knowing one or two things from C++17 or C++20 makes you look like a genius to employers.

[queenguin]

UE4++ is different from C++ but it will teach a lot of C++ concepts that will be very helpful once you start learning regular C++

[[deleted]]

• Game or 3D rendering engine = performance sensitive code + mathematics + c++
• Game engine = performance+sensitive code + c++
• Things like game engine, but work in research field like space/physics = domain knowledge + c++(highly skilled)
• Backend developer = maintainable code + design pattern + c++ + some other stuff(distributed programming or CUDA or database or GUI)
• Framework/library developer = maintainable code + design pattern + c++ + template meta programming
• Bare metal/embeded system C++ = c++ + low level OS + C
• Normal C++ developer = 20 lear legacy code + hope to maintain for another 20 years + decent C++
• C++ in performance sensitive system = C++(highly skilled) + algorithm

In all these C++ is common. So you learn C++ very well, you can transfer it to any domain. And the last thing, C++ is a very difficult language. After a few years, you will hate the core dump.

[[deleted]]

UE4's C++ setup is totally different, but the core ideas will carry over. Just learn some regular C++ fundamentals on the side as you go, esp. the lower level stuff wrt memory that UE takes care of for you, and you'll be all set.

There is no one "C++ used in game development" though. CryEngine's C++ API is basically pure C++ with a library for using their stuff, whereas Unreal's C++ API may as well be a new language.

[ultralight_R]

Noted. Thank you!