<\/div>At the center is the language, its syntax, functionality, and the basic types it supports. Then we have the standard library. It is, essentially, a bunch of code written in that language. The standard library is specifically designed to prevent the “everyone needs to make their own” problem I described last week.<\/p>\n
For example, the C language doesn’t have a built-in way to print strings of text to the screen. It does<\/b> provide a way to output a single character at a time. You could<\/b> write a bunch of code to take a string and shove it out to the console one character at a time, but since outputting strings to the console was so common in the early days, this idea was implemented in the standard library. You can see it in the classic Hello World example code:<\/p>\n That first line tells the compiler to bring in “stdio.h”. That’s short for “Standard Input-Output”Fun fact: For my first year or so in C, I thought it was called “studio.h”. I was slightly confused when I finally typed it in manually rather than copy-pasting it from my previous project, and discovered that it was in fact NOT “studio”. If I had a time machine, I’d use it to send 1990 Shamus a proper book on the language so he didn’t have to muddle through so much of the language in the dark.<\/span>. We then use that on line 5 when we call “printf” to output a string.<\/p>\n I should point out that for a developer, the line between “core language” and “standard library” is more academic than practical. The language ships with the standard library, basically everyone uses it, and so rank and file programmers just think of it as “part of the language”.<\/p>\n From here the line gets blurry. Out beyond the standard library we have “common libraries”. In the C++ world this would be something like the Boost library<\/a>. This stuff is a little more sophisticated and not quite as universal as the standard library, but it still covers a lot of common things, with the aim of giving the language ecosystem one good implementation of a feature rather than having a thousand half-baked incompatible ones competing for mindshare as with my VectorBox vs. DasVektor example from last time.<\/p>\n As you move outward into the realm of “everything else”, libraries get more specific to particular domains, and less common in their usage.<\/p>\n I should stress that all of this is how a common programmer would view things. From the standpoint of someone developing and maintaining the language, the world probably looks more like this:<\/p>\n They don’t care what libraries are common and they don’t want their beautiful language getting blamed for the shortcomings of all those terrible libraries floating around in the wild.<\/p>\n All of this is to agree with people in the comments who said that Vectors, matrices, and other game-specific types ought to go in the standard library and not in the core language. I agree, I just didn’t think it was worth making that distinction. And now that recklessness on my part has led to this over-explanation.<\/p>\n I ended the last entry with a promise that we’d talk about the drawbacks of using a game engine to turn C++ into a language for game development. So let’s do that now…<\/p>\n I should note that the term “engine” doesn’t have a formal definition. There’s no structural difference between the external libraries we talked about last week and a proper game engine. If a library is really large and is focused on a particular problem, then at some point people will start calling it an engine rather than a library.<\/p>\n Last week I proposed starting with raw C++ and then trying to construct a game using libraries. One for window management, another for networking, then sound, image manipulation, rendering, physics, and so on. Essentially we’re trying to build a game engine piecemeal. This is a huge pain in the ass because all those disparate libraries were made in isolation and weren’t designed to inter-operate. They’ll have redundant code and lots of annoying little incompatibilities.<\/p>\n Finding good libraries is hard, integrating them with your project is harder, and getting them to work together is a long and thankless task. This is how I operated on my projects over the years<\/a>. I got away with it because my projects were always small in scope and not intended for commercial release. Even at that limited scale, getting all the parts working together was often a headache. You end up with this frankenstein project that feels like it’s held together with duct tape and positive thinking.<\/p>\n Rather than building an engine out of spare parts like an episode of Scrapheap Challenge<\/a>, why don’t we just use a game engine?<\/p>\n#include \r\n\r\nint main()\r\n{\r\n printf(\"Hello, World!\");\r\n return 0;\r\n}\r\n<\/pre>\n
<\/div>Start () Your Engines<\/h3>\n
<\/div>Yeah, Why DON’T We Just Use a Game Engine?<\/h3>\n