1
\$\begingroup\$

I'm curious about the impacts of applying the C++ Core Guidelines to game development.

When I try to discuss about this, and point out that we should check return values, or validate user data, or just have good naming, I get objections like 'once shipped, no one will have to deal with this code', so why not just make it work, without wasting time with all this care about raw pointers, and raw loops etc. I believe it's mental laziness, but I'm not sure if there's really a major downside to following these guidelines.

What are the pros and cons of applying these guidelines in the context of game development?

New contributor
phydthekid is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
\$\endgroup\$
7
  • 1
    \$\begingroup\$ It depends which guidelines you are talking about. Game development can be similar to other software development, and guidelines are there to guide people. If you know what you are doing you can go off on your own and do what's best for you project :) \$\endgroup\$
    – TomTsagk
    2 days ago
  • \$\begingroup\$ You still want your project to be maintainable, so after you ship it, you can apply updates to it, or add new content. If you plan to abandon a project once you ship it, nothing matters really, code whatever you like. \$\endgroup\$
    – TomTsagk
    2 days ago
  • \$\begingroup\$ The argument that you can disregard coding guidelines, if you don't intend to ever make changes/updates to the product after shipping it, isn't valid. One thing all plans have in common is that they change, and so will your code long before you even think about shipping it. (Game) development is a lenghty process and good coding practices not only help after-release maintenance and extension, but will also help you immensely when you need to return to modules after mere weeks. \$\endgroup\$
    – LukeG
    2 days ago
  • \$\begingroup\$ I'm not a C++ expert myself, but as I understand it even "usually-good ideas" like unique pointers are not always as zero-cost as expected (see about 17 minutes in), and sometimes in the very hot loops on tight time budgets like we have in games, that can matter. \$\endgroup\$
    – DMGregory
    2 days ago
  • \$\begingroup\$ I watched the video, that's interesting. Sometimes that could matter, especially on engine side, in fact there you tend to avoid pointers at all. At higher level, in plain gameplay logic, it surely does not. \$\endgroup\$
    – phydthekid
    yesterday

2 Answers 2

2
\$\begingroup\$

Not a professional game developer, but do write high performance C++ code for a living.

In any non-tiny project, following some good guidelines (like the ones posted) will:

  • result in faster development (debugging is a significant part of development time),
  • result in a more robust product for a better user experience.

For example, not checking return values can result in either a miserable debugging session if it causes a problem that cascades to somewhere else (learned that the hard way), or a silent crash when the user runs your game in a way that causes some failure that didn't occur in testing.

A difference between game code and other code is that game code has a shorter expected lifetime, but I seriously doubt that is enough of a difference to make those guidelines any more or less useful.

For code that only I see that I plan to throw away after a week or so (say a one-off conversion), sure I'll not worry so much about guidelines.

Having said that, guidelines are a useful set of handrails, not a straightjacket, and you are sometimes doing yourself a disservice by following them slavishly - I routinely break many of them, and which ones are important will depend on your project.

For instance (as @DMGregory points out) in hot loops with a tight time budget (this happens in non-games too!), you don't want to follow guidelines at the expense of performance - for a hot enough loop you do whatever (safely) needs to be done to meet your time requirements. Even in those cases it is sometimes better to start with a guideline conforming version as a base, and an optimized loop should be very well commented so you can see what you did (and why) when you come back to it.

I have been involved in projects in which every guideline must be followed without fail, and projects where guidelines are ignored, and they are both awful.

Having spent more time in those guidelines, they seem pretty good and not over-prescriptive (but looks like they haven't been finished yet), and they give reasons. For instance, rather than the common "thou shalt never use goto" I've seen so often, in "ES.76: Avoid goto" they say why to avoid goto, and when goto is ok. Some of it is stylistic: "Enum.5: Don’t use ALL_CAPS for enumerator". Overall, they are good enough that I'd want to be able to give a good reason for any part of them that I'm not following.

\$\endgroup\$
1
  • \$\begingroup\$ I totally agree with you. I believe that these guidelines have been written by very experienced people, so it's correct to be aware of them and when needed decide not to attend to them, but in general I think it's pointless to question them for " that's my style" kind of things. When I do reviews and ask to attend to these guidelines I hear back "well that's my style, I don't usually do that because I don't like it, or in the past I had many bugs due to this approach so I don't do it anymore" . \$\endgroup\$
    – phydthekid
    yesterday
-3
\$\begingroup\$

Short version:
There are no pros and only one con. Modern C++ is inefficient for game development.

Long version:
C++ is by no means inefficient, however real time application require maximum efficiency. Therefore using modern C++ is guaranteed to be at least in one place more slow than using simple C++98 or C-style. So there is the con in following this.
Guidelines like the one you linked are usually created after years of failure and development decisions that have set the project back a considerable amount of time.

I have to mention that a game is not a program on which the linked guideline is based upon. Commercial products like Excel, Blender3D, Unity, generate data, while games generate entertainment. This implies that the development process of games is unique from game to game. Therefore code guidelines in general provide absolutely nothing beneficial to the development of a game. This is also the reason people have said that as long as you ship it, it's OK to do whatever, because it's true.
There is however a youtube series that shows how a game is made step by step, from scratch, made by a professional programmer with 20+ years of experience in game development, if you're interested.

I also have to mention that Bjarne Stroustrup has, from my knowledge, NEVER shipped a commercial program OF ANY KIND and neither did Herb Sutter (but I could be very wrong about him), so you should definitely take that into consideration.

\$\endgroup\$
4
  • \$\begingroup\$ "Therefore using modern C++ is guaranteed to be at least in one place more slow than using simple C++98 or C-style." Could you expand on this? I'm missing the logic there. \$\endgroup\$
    – MadMan
    2 days ago
  • 1
    \$\begingroup\$ There are good and bad bits in this answer. E.g. "code guidelines in general provide absolutely nothing beneficial" is way too off. \$\endgroup\$
    – Kromster
    yesterday
  • \$\begingroup\$ Can you prove what you declare? \$\endgroup\$
    – phydthekid
    yesterday
  • \$\begingroup\$ You can do that yourself, benchmark any modern c++ program and then a c style that generates the same result, compare the times. Obviously compile with /O3 \$\endgroup\$ 20 hours ago

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .