# Beyond "Novice" Game Projects

I was reading this answer on the type of math a game developer should know and this part really stood out at me:

How do I move my game object? The novice might say:

"I know! I'll just do:" object.position.x++.


That is how I would think to do it so I guess that shows my skill level. At least for the types of 2D side-scrolling, arcade-style games that I've made in the past, that's all I needed. That and a bit of trigonometry.

In fact, I haven't used much linear algebra or even heard of quaternions before reading that post. Is it because these math don't show up until you work with 3D or is it because my 2D games are fairly simple that I got away with naive implementations.

Follow up question: If I want to get familiar with that type of math, what type of projects should I undertake? IE: write a game engine, work on a 3D game, etc.

• khanacademy.org is great for learning beginner and advanced math. Plus theres achievements! Nothing like game theory to liven any boring academia. Nov 9 '11 at 20:50

The real trick with this is high school-level science; which you should have done. In the event that you didn't a quick Google search will get you started. To explain how you avoid the 'novice' mindset take the lunar lander example.

Once you have read that [change in position] = [velocity] * [time passed] it becomes clear that would need to keep track of those variables:

float x, y; // Your X and Y co-ordinates.
float vx, vy; // Your X and Y velocity.
float deltaTime; // Change in time.


Following that you would simply apply the velocity to the position each frame:

// Change X by the velocity multiplied by the time.
x = x + vx * deltaTime;
y = y + vy * deltaTime;


Now we would like to alter the velocity each frame so that we can add gravity. According to the exact same source [change in velocity] = [acceleration] * [time passed]. Therefore we can apply the exact same principle:

const float gravity = 9.8f; // The gravity of the earth.

// Add gravity to the vertical velocity.
vy = vy + gravity * deltaTime;
// Change X by the velocity multiplied by the time.
x = x + vx * deltaTime;
y = y + vy * deltaTime;


Now you need a way for the player to control his spacecraft. From reading more about basic physics you will learn that motion is the result of force - I can't find a source but [change in acceleration] = ([force] / [mass]) * time (as far as I remember). So when the player presses a key you would simply set the fx and fy variables to something and apply the equation during your update.

Ultimately you need to think about the physics around the objects in your game - and instead of trying to make them move in the way you would think, rather look up the equation.

Future Note: Remember that this is definitely not the best way to do physics (this is called Euler Integration and can lead to some odd scenarios at low frame rates) - you need to look into other ways of doing things (That article has quite a nice write-up on the bare basics as well). However, stick with Euler Integration for now, as it is means you are trying to learn one thing less.

Which games would teach you how to think in the correct mindset?

How would you test that you have done things correctly and with the correct mindset? Insert a Sleep(10 milliseconds) in your game loop and everything should still move and react the same way as the full framerate.

Finally, please keep well away from 3D (and thereforce Quaternions and Matrices) until you have a good amount of experience with making 2D games work. I would venture to say that quite a few game developers don't actually know how Quaternions or Matrices work - but merely know how to use them - approach them much later on (or never, 2D games are a lot of fun and can be quite successful). You don't really need to know linear algebra and so forth to do this at the basic level (but it really does help, so go to some night classes if you can).

Final bonus: One thing my art teacher always told me is "don't draw what you think you see, draw what you see." The same thing applies here "don't model what you think happens (object.position++), model what happens (object.position += velocity * time)" - at least to reasonable limits (you are not modelling a perfectly accurate system, but make something that is a good immitation).

• I like your idea of inserting artificial lag for testing. Also, Earth's gravity is 9.8, not 9.1 Nov 8 '11 at 21:11
• Be careful with "don't model what you think happens, model what happens" unless you're writing an actual simulation. Scale as necessary for your project. Sometimes "what you think happens" is a good answer for your design. Nov 8 '11 at 22:37
• @chaosTechnician at this level "what you think happens" is object.position++. I will clarify the answer. Nov 8 '11 at 22:38
• -1 for instead of trying to make them move in the way you would think, rather look up the equation. It's about understanding the equations, not looking them up. What's most important is making the game fun, and who knows, maybe you'll find some variable-acceleration makes the gravity more fun. But it's going to be very hard to reason how to do that if you don't understand the equations. Nov 9 '11 at 1:39
• @BlueRaja-DannyPflughoeft that is exactly what I explained to him: not knowing the equation in the first place means you can never understand it - and the only way to understand them is to use them in a real situation. Nov 9 '11 at 7:56

I think parts of the answer you linked to are a bit elitist in their presentation. Extolling the virtues of vector math then saying an object needs a position, direction, and acceleration is inconsistently specific because it's really just going to boil down to something like object.position.x += (object.velocity.x + object.acceleration.x) * deltaTime—which, fundamentally, isn't that different from object.position.x++`. Quaternions are one of many ways to represent rotations; I like them but they're not essential to understanding 3D rotations. Despite what many Quaternion users will imply, they are not the Holy Grail of rotational math.

The principles of linear algebra are present in simple 2D movement, rotation, etc. but the math is more simple because there are only two dimensions. Here's an example.

There are plenty of ways to learn/improve your knowledge of linear algebra:

1. I've considered taking a course in linear algebra but my courseload is already pretty heavy so I haven't been able to justify the extra work.
2. My understanding of linear algebra has grown much more significantly as I've taken a series of game engine programming classes. For me, use of Vectors, Matrices, etc. has been (generally speaking) more prevalent on the engine side of things than on the game side. Of course, that's not to say I haven't used matrices in game code—I just don't use them as often as I have in engine coding. ymmv
3. There are also plenty of books that can help you understand the math you'd need to know, as well. I like this book which has a chapter titled "3D Math for Games."

Lastly, if the design of your games doesn't call for the complex math, don't use it. :) But, of course, don't let that stop you from delving into designing a game that does.

Quaternions for 2D would be complete overkill, not to mention computationally way too expensive. Bitmap rotation (2D) is handled by a great many platforms/libraries implicitly, because it's so fundamental to writing any application, and even where it isn't, rotation of 2D bitmaps is nothing more than a bit of simple trig. In 3D, things become considerably less intuitive to the average human being, unless of course said human being grew up writing 3D code when they should've been out riding bike.

Linear algebra is applicable to 2D as it is to 3D and should be something you're familiar with even if you only did junior high school math. If you've ever done line intersections, or periodic plotting on a line (integration), then you've used linear algebra.

Learning 3D math usually starts with placing a simple object (like a cube) in 3D space, and implementing a movable camera which can view that object from different perspectives, and that perspective can start out orthogonal to keep things even simpler. It's about projecting points onto a 3D plane representing your screen (formula here, you would extend this to x and z axis in addition to y). Really, that's the beginning of writing any 3D engine, irrespective of your level of experience. Flash and Processing.js are two great ways to prototype something like this easily.

You're right on track that linear algebra and more complex math usually involves 3D graphics and 3D space. But there's still more math that can be done within 2D games. Physics math can get pretty hardcore, and it gets more complex if you consider soft body physics and B-spline dynamics (and still in 2D, keep in mind)

Try building or dissecting a physics library that will cover collision handling and response for common 2D shapes. Linear algebra is pretty useful for calculating trajectory vectors for collisions. The dot product is quite related to the unit circle used in trigonometry. Yet, the complexity of rigid body physics increases exponentially when applying it in 3D.

3D graphics gives you a greater understanding of matrix calculations, quaternions, linear algebra, and some applied calculus. The first thing you'll probably pick up on is using matrices to move and manipulate objects in 3D space.

If you're writing 2D games, you're probably using linear algebra already.. you just don't know it! Formally learning at least the basics about vectors is pretty easy, but goes a long way in simplifying thinking about otherwise-complex movement.

For example, we get a lot of questions here about what equations to use to simulate curved movement, such as for a cannonball shot from a cannon, or a homing-missile. But if you understand vectors, the only "equation" you need is that for adding two vectors together. Not only that, but adding things like air-drag or friction becomes incredibly simple - just calculate the drag-vector, and add it to the velocity. Presto!