Math in Game Engines Interview for School

lots of math can be used in games, but linear algebra is the major core that is needed.

Being able to work with matrices (or at least understand how they work) and being able to work with vectors, normalizing them, cross product, dot product, most of everything you do in game programming uses that stuff as basics.

For instance, a TON of collision detection is based on projecting one vector onto another.

Have you ever created a game before? I think a 3D game would be a much better option for your senior project than a multithreaded 3D game engine, in particular if you have never developed a game engine or game before.

Quote:

Original post by mikfig Physics for Game Developers

Assuming you mean the David M Bourg/O'Reilly book... you should steer clear of it, in my opinion. It is a complete mess.

Edit 1: That comment may seem a bit harsh... but really it is about the only book I own that I really regret spending the money on... So it tends to make me a bit cross!

Edit 2: A better book - I don't actually own anything similar but better. However Kenny Erleben's "Physics based animation" is good, but it might be a bit daunting, depending on your background. I haven't really kept my eye on what physics books have come out in the last few years though, so there may be some good introductory books now.

Quote:

Original post by MrRowl Quote: Original post by mikfig Physics for Game Developers Assuming you mean the David M Bourg/O'Reilly book... you should steer clear of it, in my opinion. It is a complete mess.

Could you recommend something else?

Quote:

Original post by apatriarca Have you ever created a game before? I think a 3D game would be a much better option for your senior project than a multithreaded 3D game engine, in particular if you have never developed a game engine or game before.

No I've never completed a full game before, I got bored with 2D after barely touching it. I jumped straight to 3D in search of the ultimate challenge, learned DirectX and read all through Real-Time Rendering 3rd Edition. I was starting to design a game engine before, and I came across the article on Gamasutra about the multi-threading involved in the Smoke demo.

So by making a multi-threaded game engine similiar in it's framework to Smoke, I have found the ultimate challenge. But I'm definitely up for the challenge, I don't mind a lack of sleep and since its an actual school project, I have the ultimate motivation to finish it.

I already have done a good deal of research on different subjects, I understand the workings of Havok Physics & Animation from the documentation, and the simplicity of OpenAL is a huge plus here.

My next step though is to get the Smoke demo to actually run on my PC so that I can step through it in the debugger. The only problem is that my video card is below its minimum requirement of GeForce 8800 so I have to figure out how to take graphics out of the equation and just run the framework with its physics, ai, etc components. But my understanding of the smoke framework so far is pretty good IMO. The isolation of the different parts lends itself to a great design, and I think I can do it :D

So yes I know its a great challenge, but its exactly what I'm looking for.

Is there any that would allow me to interview them?

Quote:

Original post by Gage64 Quote: Original post by MrRowl Quote: Original post by mikfig Physics for Game Developers Assuming you mean the David M Bourg/O'Reilly book... you should steer clear of it, in my opinion. It is a complete mess. Could you recommend something else?

Yes. My recommendation is to use the free "essential math" tutorials, which are basically powerpoint files from a game developer's conference two day course on physics for games, given by industry game physics leaders. You can find a link to these tutorials in the sticky thread on physics engines and resources at the top of this forum, linked below for convenience:

List of physics engines and reference material

Please don't try to be too ambitious. I can envision a very simple game engine that uses the technologies you mention but is NOT full featured, and if you are proficient with geometry and algebra and computer programming you could possibly pull it off for a senior project. Just stay very focused and limited in what you attempt. You might even consider posting a "feature list" here, with priorities and a draft work schedule, to solicit advice about whether you're trying to do too much for a school project in the midst of classes, homework, extracurricular actitivies, etc. I'm at least happy to see you are planning to use middleware for audio and physics rather than try to write those components also.

Don't get much more ambitious than something Tetris-y for a highschool project. Difficulty aside, you just won't have the time to finish it and then you'll get bad marks. If you have something cool to demo you'll get good marks.

A simple FPS with a simple level would be a good goal if you want to do something 3D. The basic rendering of static geometry + ray casting for guns is a good base, and you can easily scale the project depending on your time/interest to add in animation on bad guys and some sort of interactive physics, or post processing shader effects, etc.

I did a tetris clone in DOS for a high school junior project, and I was able to finish 85% of it during spring break week. I got good marks for it. Life was happy. I tried producing a play for a sophomore project, which was too big and I had to downsize my scope, for which I got poor marks.

It's always better to finish a base and add on than set sights too large and have to downsize, from a purely impress-the-teacher point of view.

For the short term, tackle a simple problem such as two pool balls colliding and ricocheting, or load a model of a toy gun and have it aim "at" the mouse target, or simulate a ball bouncing on a curved surface.

Specify in advance the exact milestones, and make sure all technology you will use is already working first. Remember, a whole game takes about 20 man years, and it's 10% inspiration, 90% perspiration.

For the long term, here are some books that have survived the test of time, they are loaded with practice examples.

The C Programming Language (Kernighan, Ritchie)
Elementary Linear Algebra (Howard Anton, 1988)
Advanced Rendering and Animation (Watt & Watt, 1992)
Generative Modeling for CG and CAD (John Snyder, 1992)
OpenGL Red book and Blue book (latest edition)
OpenGL Orange book (shader language)
3D Game Engine Design (Eberly)
ShaderX series and GPU Gems are great.

I too would be careful about this project. A lot of software projects suffer from project creep since there is always ways to make a program better and it always seems like it is just within reach. I would use an iterative approach to making your engine. Meaning, get basic functionality working and tested, then add a new feature or 2. Get that new feature working and then add another one, but don't try to get a whole slew of features done up front and at the same time. If you do, you are more likely to end up with nothing or something that is "almost working" than a good finished project.

As far as the interview, I regretfully don't know anyone to help with that, but I do have to wonder why you want an interview to be your source. After all, I assume that will have to have cited references and citing an interview might be a little flimsy as far as sources go. Published work is better to cite because it gives others the chance to refute it.

Quote:

Original post by landagen I too would be careful about this project. A lot of software projects suffer from project creep since there is always ways to make a program better and it always seems like it is just within reach. I would use an iterative approach to making your engine. Meaning, get basic functionality working and tested, then add a new feature or 2. Get that new feature working and then add another one, but don't try to get a whole slew of features done up front and at the same time. If you do, you are more likely to end up with nothing or something that is "almost working" than a good finished project. As far as the interview, I regretfully don't know anyone to help with that, but I do have to wonder why you want an interview to be your source. After all, I assume that will have to have cited references and citing an interview might be a little flimsy as far as sources go. Published work is better to cite because it gives others the chance to refute it.

Hmmm...that iterative approach sounds like a great idea, reminds me a lot of the concept of stripes mentioned in Software Engineering for Game Developers that I skimmed over. I'm not sure how I would make this iterative just yet, but all good ideas need some thought :D

As for why I need an interview, it actually is not my idea. It is kind of a requirement for the assignment. The way my teacher put it, we need a primary source. When she mentions primary source, she always mentions interview and I thus assumed that that would be the only possible "primary source". But I double checked with her today and she said it could be a interview, an autobiography, or a journal. I'm thinking that I may be able to find a blog that qualifies as a journal, it just has to have the author refer to himself as I or something like that.

Thanks a ton for all the suggestions guys :D,
Mikael

Anyways, I found my primary source. I think I'll be using Ysaneya's dev journal. Always found that journal pretty interesting :D, why not use it.

Haven't had a chance to look at the iterative software engineering thing yet. Took SATs Saturday, my favorite thing is to spend 3 hours filling in bubbles with a #2 Pencil, so...
Then I've spend the later part of the weekend practicing my integral calculus as I'm reading Differential Equations Demystified.

Anyways,
Thanks a ton for all the responses,
I will try to keep in mind all your suggestions as I do this project,
Mikfig

Hi mikfig,

When you think about game development in academics their not looking to see if you can programme. They will look at your coding ability to some degree but what their really looking for you to do is explore the "science" part of your course not your game developing ability.

Take for example the project I presented in my final year. It was all based around creating, testing and evaluating the use of a neural network for autonomous control. My initial discussion with members of this site was that they were terrible for games, this formed my hypothesis.

The next step was to create a test environment, I decided to do a quantitative research which meant I looked at solid numbers like time, frames per second etc. and analysed them, the results would help me either prove or discredit my hypothesis (what I think is going to happen).The outcome of the research was that neural networks were time consuming, to build, test and debug. They also drained resources making the overall simulation slow. I proved my hypothesis (and got a good mark ;-) ).

So here's a few steps on how to do your project:

- Select a topic to research
- Create a hypothesis (what do you think is going to happen if you create this)
- Decide on the type of research to conduct (this is a simple explaination and not accurate, do research into this):
-- Quanitative measures numberical properties
-- Qualitative measures visual properties*
- Program your idea remembering what your going to measure to prove your hypothesis
- Get your results
- Look at other peoples work, what have other researchers found?
- Write your paper, did you get the results you expected? Are your ideas the same as other researchers? Are there factors that could have influenced your results?

*Qualitative is hard to measure, its not enough to say one "looks" better than another. Quantitative is more factual, for example you can say using method A we achieved x fps where as with method B we only got y fps, this proves my hypothesis is correct....

Sorry about the lecture.. Your idea to do a game engine is huge, what are you going to measure? What do you want to prove? What are you going to compare against?

If i was you i would think on a smaller scale. Maybe, compare voxel rendering to normal rendering?! This is the type of thing the academics want to see.

Quote:

Original post by LionMX Hi mikfig, When you think about game development in academics their not looking to see if you can programme. They will look at your coding ability to some degree but what their really looking for you to do is explore the "science" part of your course not your game developing ability. Take for example the project I presented in my final year. It was all based around creating, testing and evaluating the use of a neural network for autonomous control. My initial discussion with members of this site was that they were terrible for games, this formed my hypothesis. The next step was to create a test environment, I decided to do a quantitative research which meant I looked at solid numbers like time, frames per second etc. and analysed them, the results would help me either prove or discredit my hypothesis (what I think is going to happen).The outcome of the research was that neural networks were time consuming, to build, test and debug. They also drained resources making the overall simulation slow. I proved my hypothesis (and got a good mark ;-) ). So here's a few steps on how to do your project: - Select a topic to research - Create a hypothesis (what do you think is going to happen if you create this) - Decide on the type of research to conduct (this is a simple explaination and not accurate, do research into this): -- Quanitative measures numberical properties -- Qualitative measures visual properties* - Program your idea remembering what your going to measure to prove your hypothesis - Get your results - Look at other peoples work, what have other researchers found? - Write your paper, did you get the results you expected? Are your ideas the same as other researchers? Are there factors that could have influenced your results? *Qualitative is hard to measure, its not enough to say one "looks" better than another. Quantitative is more factual, for example you can say using method A we achieved x fps where as with method B we only got y fps, this proves my hypothesis is correct.... Sorry about the lecture.. Your idea to do a game engine is huge, what are you going to measure? What do you want to prove? What are you going to compare against? If i was you i would think on a smaller scale. Maybe, compare voxel rendering to normal rendering?! This is the type of thing the academics want to see.

Heh, well thanks for the advice. But I don't think that this applies to my situation. I'm doing a high school senior project and seems to me that you are speaking of college research projects. The purpose of this project in fact is just do do something that is challenging.

It doesn't hurt to go the extra mile ;-)

Quote:

Original post by LionMX It doesn't hurt to go the extra mile ;-)

Yes I know but the challenge I'm already taking on is what I would consider "going the extra mile". I don't want to overwhelm myself with doing something like voxel rendering vs triangle rendering or something as even this engine is my first game engine. I've done simple rendering stuff, and I think I have almost completed an application like GPU Gems 2's "Toward Photorealism in Virtual Botany" paper or whatever. But generally my experience in game programming is not that heavy. So I know that this multi-threaded game engine will be a great challenge that will demand much work and lost sleep, but I am up for this. However, I want at least even the smallest possibility of success.

Thanks for the tips though LionMX,
Mikfig

Ok, I must warn you a game engine is a massive project to take on, why dont you start off small, maybe create your own software renderer? You can easily do this iteratively :

- Learn about the framebuffer
- Learn how to draw a pixel to the framebuffer
- Learn how to draw a line
- Learn how to draw a triangle
- Create a wireframe triangle
- Create a flat shaded triangle
- Create a Gouraud shaded triangle
- Add lighting
- Add hidden surface removal etc.

Thats just a few idea's there are hundreds of books and if you get stuck you have the redbook on hand to see how OpenGL does it.

Quote:

Original post by LionMX Ok, I must warn you a game engine is a massive project to take on, why dont you start off small, maybe create your own software renderer? You can easily do this iteratively : - Learn about the framebuffer - Learn how to draw a pixel to the framebuffer - Learn how to draw a line - Learn how to draw a triangle - Create a wireframe triangle - Create a flat shaded triangle - Create a Gouraud shaded triangle - Add lighting - Add hidden surface removal etc. Thats just a few idea's there are hundreds of books and if you get stuck you have the redbook on hand to see how OpenGL does it.

Hmmm...that sounds very enticing, I'll think about it. That's cool though that the OpenGL redbook actually tells you how OpenGL works in its guts rather than just giving you API calls and what not.

Hmmm...very interesting...

Well thanks for the ideas,
I'll keep them in mind and make sure not to chew off more than I can handle,
Mikfig

Quote:

Original post by LionMX So here's a few steps on how to do your project: - Select a topic to research - Create a hypothesis (what do you think is going to happen if you create this) - Decide on the type of research to conduct (this is a simple explaination and not accurate, do research into this): -- Quanitative measures numberical properties -- Qualitative measures visual properties* - Program your idea remembering what your going to measure to prove your hypothesis - Get your results - Look at other peoples work, what have other researchers found? - Write your paper, did you get the results you expected? Are your ideas the same as other researchers? Are there factors that could have influenced your results?

hmmm... Why does this sound familiar? I think I'll go ask Roger Bacon...