Overview
Prior to writing this blog post, I had a friend of mine asked me what he should learn to increase his skills in using Unreal Engine, so I told him what I know of it in a sequential and progressive learning steps, I also directed him to some good online tutorials and reading materials, after that we talked quite a bit and I soon learned that his long-term goal is to become a AAA game programmer, he did not know what specialization he wanted to pursue in the future but his career goal was clear, he already had a dream of becoming a game programmer in a certain multinational AAA game studio; Since we are talking about the future, we broaden our scope and looked past the limitation of tools such as Unreal Engine, and we came to the very core of being a game programmer, the essence of programming a game, the long-lasting knowledge of it, in summary: The Game Programming Principles. And this blog post is basically the result of our discussion.
Principles vs Techniques
Principles are completely different from Techniques. Principles will never change, they are laws, they are commanding and you can not escape from them because they are always there. Techniques, on the other hand, may come and go, they may get iterated, refined, and factored, some techniques can last for a decade or more but it is inevitable that they too will get replaced with a better one.
Knowing the techniques of doing something is important, because without them you will not be able to produce results, in the simplest sense, if you don’t know how to do something you can not do it. Principles, on the other hand, are not practical, you can not act upon them. but they help you to understand a technique or even create a new one.
Let’s say you are now using Unreal Engine and you need to create a path for the AI to follow. So you search through the web and found a tutorial on how to do it by using Spline, the initial 7 steps to create a spline are:
- Create an actor blueprint, BP_PawnMovementPath, and edit the blueprint by double clicking it in the content browser.
- Add a SplineComponent to the blueprint by clicking the Add Component button on the upper left corner of the blueprint editor.
- Rename the SplineComponent to “MovementSpline”.
- Drag and drop BP_PawnMovementPath from content browser to the Viewport to spawn it.in the world.
- Open the details panel of the actor and select “MovementSpline”, the spline is now ready to be edited.
- In the Viewport, hold alt and drag the end point of the spline to extends it.
- Repeat 6 and create the path that you need, you can fine tune it by moving the control handlers of each spline points.
Now you know how to create a path that a pawn can follow in Unreal Engine, this is a technique that enables you to produce results, you can make an interesting path, you can also alter the spline points to make the character gradually rotates while following the path, etc.
Is this a worthy knowledge to learn? Yes, definitely! you can now make a game (or a part of it) by using this technique. But, let’s say that you are now moving from Unreal Engine to SnowDrop Engine, does knowing this technique helps you when you are faced with the same path following problem? I would say no, the technique can only be used in Unreal Engine. Some of you may say otherwise, because you think it’s kind of similar, there’s also a Spline in SnowDrop and that we can use it to move a scene graph entity, if you have this kind of thinking then you have not differentiate between techniques and principles.
The principle behind this technique is a Spline, it is a polynomial function that produces a smooth curve at the place where the polynomial pieces connects, this function takes a real number as parameter, and the output is also a real number that lies on the curve; The parameter usually limited in a certain span and it is usually referred to as time, especially when the spline is used for kinetics (movement) purposes. There are many kind of splines: quadratic spline (spline that has 1 control point), cubic spline (has 2 control points), Bezier spline ( a series of curve components that has p-degree), Nurbs ( a mesh of splines ), etc.
The similarity that you noticed after moving from Unreal Engine to Snow Drop, is actually the principle, the spline! If you know the principle, moving from one engine to another will not be daunting, because you already know the principles, you already know the underlying law behind the techniques, you can focus on learning the techniques itself and you will be able learn it much much faster. And what if you are moving to an engine or game framework/library that has no spline implementation? You create one!
Those that has a deep understanding of the principles will be flexible to changes, they are very quick to adapt to new changes (and I can assure you that game programming changes a lot in a matter of months or even weeks), they will not be dependent on the tools they are given, they can create tools to solve a problem, they can create a solution instead of searching for tutorials that may not even exist for the problem they currently face.
Those that are relying only on techniques will be productive for a certain time, at least until the tools they are using becomes obsolete. You may know or hear about someone whose skills becomes obsolete because they are too dependent on the tools, some of them just can not move on, they are still using Macromedia Director or even 8086 Assembly embedded in Pascal code that can only be compiled in Turbo Pascal to make games, they can make them amazingly fast, they are very productive because they have mastered the techniques, but their games are not marketable, it’s fine if it’s just a hobby, but if you want to make a career in Game programming (or programming in general) then it is the worst move I can think of in this industry.
I hope at this point I’ve made my point clear about the difference between principles and techniques.
The Principles of Game Programming
We know that principles hardly ever change, some may never change at all till the end of time, it’s a law, they are huge and heavy objects that you can not move. So, what are the principles of game programming? I think that you yourself should think about it, think hard to find the root of the techniques you are using and only then you will find the principles.
For me, there is only one game programming principles: Math.
Math is very broad, two game programming specializations may emphasize on two different realm of Math, but they are all math none-the-less. Let’s take, for example, a Gameplay programmer, she needs to create a skill tree for her RPG game, a tree is a graph in mathematics, if she tries to find a solution to her task by thinking in term of graph she will understand the problem better and will surely find a good solution in implementing her skill tree regardless of what engine and what programming language she’s using; Another example is an Engine Programmer, he needs to create a system that manages huge assets in a platform that has a lot of limitations, if on top of knowing the system specification and techniques he also understood statistics, data structure, graph, different kinds of algorithms and other related principles, he will be able to create a solid and efficient asset management system compared to those who don’t know those principles. The last example is a Game Programmer that needs to implement a feature request from an inexperienced game designer, the feature seems easy to implement on the surface but it’s actually very hard or even impossible to solve, if he knows about computer complexity and intractability (NP-completeness) he will take less time in deciding whether a particular problem is unsolvable (NP-complete) and tell the game designer about it as soon as possible so that she can change her design, Game programmer that does not know this principle will spend months to solve this problem and failed (of course it is, because it is an NP-complete problem) during which many expensive assets and features have been created in the assumption that the problem can be solved, it’s waste of time and money and the game will definitely suffer a major step back or even cancelled.
About Design Pattern
Design pattern is, i think, a dividing line between principles and technique, depending on how or where we see it, it can become a non-binding principle or a technique.
Design patterns are the collective wisdom of many game developers, they are things that are extracted from hundreds of hours of hands on experience, failures and research. They are not as commanding as Math, but it would be foolish to ignore the wisdom and try to re-invent the wheel yourself. It’s not that easy to differentiate between design pattern and techniques, to know which is which we need to know the term of Design Pattern itself, Design Patterns are reusable solutions to commonly recurring problems, it’s like a wisdom a child get from his or her parents about brushing teeth at least twice a day, the child does not yet know about tooth cavity or the intense pain it caused, but their parents have, and it would be foolish for the child to grow up into an adult without doing it and got his or her teeth damaged because of it. The habit of brushing teeth twice a day is a design pattern, the details on how to brush teeth including what kind of toothpaste and toothbrush to use is a technique. An example in game programming would be the common solution to solve path finding, the math behinds it is graph and many algorithm related to it (e.g Djikstra) the design pattern is A* or navigation mesh, you don’t have to reinvent the wheel by trying to come up with a solution because experts has already spent years inventing them, a basic understanding about the underlying math is all we need to adapt to the many implementations of these design patterns. But if you yourself is trying to come up with your own design pattern that is more efficient than the existing ones then you can not see them as a non-binding principles anymore, a basic understanding of their underlying principles are also not adequate to reach your goal anymore, you need to go deeper and be ready to spent hours, weeks, months or even years developing it.
Pitfall of Principles
I would like to warn you about what I think is the pitfall of Principles. If you only concern yourself with Principles and ignores techniques all together then you are a mathematician, you’re a scientist, you’re a philosopher, you’re anything but a game programmer, because you see, game programmer basically programs a game or at least has his or her goals set to creating a game, it’s the main quest for a game programmer (not a sub quest and definitely not a side quest), he learns algebra with the goal of increasing his productivity and capability in solving problems he will have in programming a game, with that goal in sight he will ignore the philosophical side of algebra of near infinite-dimension of real space, he will even ignore 5th or more dimension because it has no practical usage in Game programming.
It is very easy to avoid this pitfall, just like I said, you need to have a strong goal in your mind so that you don’t wander around aimlessly in the infinite realm of principles. By having a goal you will most likely find the proper balance between principles and techniques that really suits your needs.
heapcleaner 