This is the first article in a series that will discuss how to get started doing game engine development using OpenGL (also referred to as GL). This will be a very practical series where the emphasis will be placed on getting things done and references will be provided for more in-depth coverage of complex topics. This will also be a very personal series that will be an opinionated take on what I’ve learned while writing my libraries. Do not expect a reference documentation on game development.
The Go Programming Language
The programming language of choice will be Go and the primary reference libraries will be my own fizzle graphics library as well as netpeddler for networking, glider for basic collision testing and cubez for basic physics solving. There almost certainly are better libraries around, but they may not be written in the same programming language used in the rest of the series and since I’m the author, I’m already intimately familiar with them. None of these libraries are ground-breaking so the concepts covered should easily transfer to other libraries if you would like to use something else.
Besides the practicality of using my own libraries there are a a few other good reasons to use Go. It has a very simple and clear syntax that stays out of the way and is very easy to read; the toolchain also can enforce a common coding standard for uniformity between projects. Even readers that are not familiar with Go should be able to follow along with minimal difficulty. Due to very fast compile times it also is a great language to experiment with for OpenGL because turn around times on builds from code tweaks to graphics functions will be minimized. Lastly, the standard library will be able to take care of many tasks that, if we were using C, would have to be coded from scratch.
What Will Be Covered
This list is subject to change, but the planned coverage is as follows (roughly in order):
- general GL concepts (using OpenGL 3.3)
- creation of windows / GL context
- basic “modern” GL
- getting mesh data to GL and art pipeline
- ambient, specular, diffuse lighting model
- shadow maps
- skinned animation
- object collision
- physics integration
- virtual reality integration
For maximum enjoyment, readers should be familiar with general programming constructs already, such as: how to build a projects, what conditional statements are, how to call functions, why defining data types is useful, etc… A familiarity with C will be handy, particularly in sections covering GLSL. If you want a quick booster shot of Go an interactive tour can be found here. A still relatively short (for most programming languages) but thorough look into the language can be found at Effective Go. The standard library source code is also very approachable, especially in comparison to some standard libraries, and can be referenced while searching for a canonical implementation of a concept.
For software, a UNIX environment will be used for this series. If you’re on Linux, you’ll be set. If you’re on Mac OS, things may work out well, but I cannot vouch for the code because I don’t have access to the hardware to test on (pull requests for any required fixes will be appreciated). If you’re on Windows I can suggest the following, which I use very heavily in my own setup:
- Cmder for a terminal emulator that is more reliable than mintty.
- Msys2 for a 64-bit toolchain and
pacmanas a package manager (make sure to pair it with a 64-bit install of Go)
Third-party libraries, besides OpenGL, that will likely be referenced at some point in this series:
Why Bother Writing Your Own Engine?
This is a very important question to consider at the very start. Writing a game engine from scratch will require competency in a diverse set of areas. Acquiring the breadth of knowledge to be successful will take a lot of time and motivation. It would appear that you can cut the time down drastically if you use an existing engine like Unreal Engine 4 or Unity which performs a lot of the heavy lifting for the user. You can deploy to multiple platforms with the same code base with minimal adjustments. You can leverage tens if not hundreds of man-years of research and development into graphics in an already proven solution. So why go about writing your own engine from scratch?
The answer to this will vary. Maybe you like a particular programming language (and I really like Go) and you wish to use that to write games. Maybe you don’t like the ‘kitchen sink’ approach of major engines where your resulting deployable executable package is larger than you think is necessary.
I think one of the best reasons to roll your own engine is to get a working understanding of all of the moving parts that are needed for a game. It’s easy to cause all kinds of problems and performance issues with a 3D engine when the user has little understanding of the impacts of the choices they make. After spending some time learning how OpenGL works I was able to make better sense of design choices made by UE4 and Unity that previously made almost no sense.
A powerful motivation for me was to have an open sourced engine for which to build games on and then to document the process for people to learn from. With a simple engine like fizzle, things are easier to reason about.
So Lets Get On With It
Enough of a preface! Part 1 will cover basic OpenGL concepts in light detail.