GPiC++StF Chapter 1 Part 1: Game Technologies

---

In the game technologies chapter of the book it seeks to teach you about popular license agreements, useful technologies available to us, introduce us to the Concurrent Versioning System, talk about Doxygen, and go over some helpful components of the C++ Standard Template Library.

Alongside this I'll be talking about other technologies and other game engines that people recommend.

The first part of the chapter is about common license agreements. I suggest doing some research on these yourself but in the interest of making things a bit easy I'll supply links to and talk briefly about the common licenses that the book goes into.

Firstly is the Lesser GNU public license which, if software is released under it, allows you to use it in any application, commercial or public. However, if you modify the source code of the software under this license you much release those changes to the public. Just those changes, not anything else in your game.

Second is the GNU public licence. It comes with the stipulation that if you use the code under this license then anything you make must be released in full. This means that if you were to, say, build a game using the code from Quake 2, then you would have to release all of your game code to the public. You can still charge for your game though, so no worries really.

Third is the BSD license. This is pretty simple, you can pretty much do whatever you want with code under this license so long as you credit the original author of the code, which you should be doing regardless of what code you are using.

Finally the book talks about the Creative Commons license. It doesn't talk much about the license, but the link here is to the page directly where you can learn more about it. Essentially it's a way for creators to let others use their work while under some specific stipulations. Remember to read what license the art, code, music, etc. you want to use is under so as to avoid lawsuits in the future.

Now we'll get started on the actual useful technologies. The books lists 10 such technologies, from 3d modeling software and graphics APIs to game engines. In alphabetical order they are Blitz3D/Max, DirectX, FMOD, OGRE, OpenAL, the Popcap framework, RakNet, ReplicaNet, Quake 2 and 3, SDL, and Torque.

Blitz3D and BlitzMax are game engine kits that are fairly old. It's says here that BlitzMax can run cross platform. It seems to be a toolkit for making your own games, kind of like Game Maker. I'm not entirely sure, since I haven't used it. Further research finds that Blitz is fairly old, not updated since 2008 or so and the creator has moved on to another project called Monkey X, though even this seems to have gone stagnant sometime in 2016.

But that doesn't mean much so long as the code still plays nice with the current version of OpenGL and SDL. Using a game kit will hopefully greatly speed up your ability to create your first couple of games before you settle in, find your niche and get to work.

The next tech that is mentioned is DirectX. I'm sure most if not all of you have heard of it. It's the graphics and generally the game libraries that Microsoft use for their own personal systems. I personally won't use it since it's not cross platform but if you are developing for windows and xbox only it can be a good tool to use since there's so much documentation on it.

FMOD is an audio library. You'll need at least one if you're planning on making a game, unless you want your game to be silent, but that's usually a bad idea. OpenAL also falls into the category of sound management.

SDL does have some sound support, and it's what I've been using so far, however, online forums in 2017 seem to think that SFML may be a better choice, since it has better out-of-the-box support for sound and can do many of the things that SDL can do. However, many support SDL over SFML as it appears that SDL will continue to receive updates and handles input a bit better.

OGRE is next, a 3D rendering engine that is a wrapper for OpenGL. Forums seem to agree that you'll get things up and running faster if you use OGRE instead of heading straight into OpenGL but it's a bit harder to colour outside the lines using it. I personally like the control that working with lower level code gives me, so I'll be sticking to OpenGL. Likely you chose this, more harder path because you like that kind of control too.

If you aren't that kind of person, then you may have been tricked, because working with C++, SDL, and OpenGL is probably one of the hardest ways to learn game programming. You can make games far faster and easier with things like Game Maker Studio, Unity, and even the Unreal Engine. Don't take this harder road unless you are the kind of freak that wants to have full control over your game and are willing to put a lot of time and effort into learning incredibly basic stuff just to get a box to move across the screen.

The next bit is the Popcap framework. I don't have anything to say about this, it essentially no longer exists.

The next two techs are RakNet and ReplicaNet, which are networking libraries. I know literally nothing about networking except that it's fairly difficult, easy to get wrong, and pretty much essential if you want any king of multiplayer functionality to your game. Now, most indie games don't have network functionality, so it's not necessary for you to learn this kind of stuff, but I personally would like to make multiplayer games in the future and in that case I'll need to look at networking code, or write some myself.

Now, let's look at these techs real quick. RakNet is dead and ReplicaNet requires liscensing. SDL does have some networking functionality, but even doing a little research on it reveals that it's a very big topic that I'll have to look into when we get there. Might as well have a functioning backbone for the game before we dive into networking.

Quake 2 and 3 and old games that you can apparently build new games on top of. At this point though, they're so old that you'd be building legacy code that might not even run on most newer machines. If you want to do something like that just look for an open source game that you like that's written in C++.

SDL if of course what we're using. It's a framework that does things like open and OpenGL context, handle inputs, and essentially act as a buffer between the computers OS and our game so that we don't have to write code for every sing OS that we might want to run our game on. Apparently it also does things like sound and networking.

Finally we come to Torque, which is a full on game engine. Really, game engines are the way to go if you want fast, reliable game development. Right now we're building our engine from scratch, which is like free climbing the game creation mountain when you could just take the road that is game engines. Unreal, Cry, Frostbite. Find one that you like that makes games the way you want to make your game and learn it, it'll be easier. For me though, I want something completely different, because I'm literally insane.

That'll be it for this first post. We'll go over the second half of chapter 1 next time. It'll cover Concurrent Versioning Systems, what Doxygen is, whatever InnoSetup is, and some of the most helpful parts of the Standard Template Library. Hope to see you there.

---

▶️ DTube
▶️ IPFS